10 ms·

Wgpu-0.10 released: WebGPU implementation now in pure Rust

216 points by kvark 5y ago

encryptluks2 5y ago
> gfx-rs community’s goal is to make graphics programming in Rust easy, fast, and reliable. Yet one of their main projects involves reliance on the web for graphics programming. This is the opposite of their stated goal in my opinion.
- pitaj 5y ago
  What are you talking about?
- zamadatix 5y ago
  You may want to take a look at what exactly WebGPU is and the wgpu repository, particularly the examples subfolder, before drawing conclusions based on the name.
- _cart 5y ago
  Yup wgpu has a WebGPU backend, but it also has first-class native backends for Vulkan, Metal, DX12, and OpenGL ES (with upcoming support for DX11 and WebGL). It is designed to be a cross platform graphics API. It isn't "web based", just "web compatible". And it has super solid "feature detection" that enables you to opt in to "native only" features like push constants.
  - encryptluks2 5y ago
    So then why is this being advertised as a WebGPU implementation if it isn't the focus? The title is misleading in that case and instead should just be titled Graphics implementation now in pure Rust.
    - Jweb_Guru 5y ago
      WebGPU is a specification for safe, efficient, cross-platform access to the GPU. It is intended to provide a small set of core primitives that are widely implementable without compromising safety or performance: attention is paid to both use from many client platforms (such as Rust, C, JavaScript, and WASM) and to implementation on many graphics backends (not only in terms of Metal / DirectX 11/12 / Vulkan / OpenGL drivers, but also in terms of trying to choose core features that are actually implemented on things like mobile GPUs, which are often left out of powerful modern graphics abstractions). wgpu-rs is an end-to-end implementation of that spec, for a Rust frontend and many backends. It is designed so that the same code can be used on the web (via WASM) or on native, with no changes to the implementation; however, you can happily ignore the WASM compilation target and just use it natively. It also includes some extensions for widely supported features that aren't available on all GPUs, that you can request if you are willing to restrict the platforms you run on (this is especially helpful on native). As you can see, the fact that it implements the WebGPU spec is very relevant because it inherits all the nice properties of the spec (efficiency, safety, and portability), as well as because there is a specification that you can refer back to in order to figure out (mostly) what the behavior is supposed to be. There is nothing misleading going on here about saying it's a WebGPU implementation. If there's anything misleading, it's probably the name of the spec (but that ship has long since sailed). The other two major components of the system are: * wgpu-core. A cross-platform, safe, efficient, pure-Rust implementation that is used by wgpu-rs, but does not actually implement the full WebGPU spec, and is not really designed for ease of use. It is mostly intended as the basis of other implementations of WebGPU frontends, such as wgpu-rs, wgpu-native (C bindings), and implementations of backends in larger systems like Deno and Servo. * wgpu-hal. A cross-platform, efficient, unsafe, pure-Rust implementation that primarily exists to abstract away differences between platforms targeted by wgpu-core. The lack of attention to safety means it can often approach or match the performance of the native drivers, but also makes it extremely hard to use, and the exposed API is very closely tied to whatever wgpu-core needs (this is a big difference between it and the older gfx-hal, which was intended to a broader unsafe abstraction layer for independent use). These two systems are not as cleanly tied to WebGPU, but they are still primarily intended for use by clients that implement the WebGPU spec. That said, this is not a requirement--there are a few other abstractions built directly on top of wgpu-core or wgpu-hal, and they do not consider themselves as WebGPU implementations (because they aren't!).
- deleted 5y ago
  [deleted]
- nextaccountic 5y ago
  Wgpu-rs doesn't rely on the web. The API is just a simplified Vulkan. The API can be implemented for the web (and Firefox uses wgpu-rs) but it is also adequate for native applications. See https://news.ycombinator.com/item?id=23079200 https://news.ycombinator.com/item?id=23079200 (that was posted elsewhere in this thread) for more details.
_cart 5y ago
As Bevy Engine's lead developer (which uses wgpu), this release excites me for a number of reasons: * A smaller (and less abstracted) codebase means that we can more easily extend wgpu with the features we need now and in the future. (ex: XR, ray tracing, exposing raw backend apis). The barrier to entry is so much lower. * It shows that the wgpu team is receptive to our feedback. There was a point during our "new renderer experiments" where we were considering other "flatter" gpu abstractions for our new renderer. They immediately took this into account and kicked off this re-architecture. There were other people with similar feedback so I can't take full credit here, but the timing was perfect. * A pure rust stack means that our builds are even simpler. Combine that with Naga for shader reflection and compilation and we can remove a lot of the "build quirks" in our pipeline that come from non-rust dependencies. Windows especially suffers from this type of build weirdness and I'm excited to not need to deal with that anymore. * The "risk" of treating wgpu as our "main gpu abstraction layer" has gone way down thanks to the last few points. As a result, we have decided to completely remove our old "abstract render layer" in favor of wgpu. This means that wgpu is no longer a "bevy_render backend". It is now bevy_render's core gpu abstraction. This makes our code smaller, simpler, and more compatible with the wider wgpu ecosystem. * There is a work-in-progress WebGL2 backend for the new wgpu. This will hopefully ultimately remove the need for the third party bevy_webgl2 backend (which has served us well, but it has its own quirks and complexities).
- timClicks 5y ago
  Wow, this feels like a win-win-win for wgpu, bevy and the rust ecosystem in general
- CyberRabbi 5y ago
  > This means that wgpu is no longer a "bevy_render backend". It is now bevy_render's core gpu abstraction. Experience has shown me that you will eventually regret this decision
  - _cart 5y ago
    Snarky answer first: my experience tells me that I won't regret this decision :) Real answer: You can use this argument to justify abstracting out literally anything. Clearly we shouldn't abstract everything and the details of each specific situation will dictate what abstractions are best (and who should own them). Based on the context that I have, Bevy's specific situation will almost certainly benefit from this decision. Bevy needs an "abstract gpu layer". We are currently maintaining our own (more limited) "abstract gpu layer" that lives on top of wgpu. Both my own experience and user experiences have indicated that this additional layer provides a worse experience: it is harder to maintain, harder to understand (by nature of being "another layer"), it lacks features, it adds overhead. Wgpu _is_ a generic abstraction layer fit for an engine. If I was building an abstract layer from scratch (with direct api backends), it would look a lot like wgpu. I understand the internals. I have a good relationship with the wgpu project lead. They respond to our needs. The second anything changes to make this situation suboptimal (they make massive api changes we don't like, they don't accept changes we need, they add dependencies we don't like, etc) I will happily fork the code and maintain it. I know the internals well enough to know that I couldn't do better and that I could maintain it if push comes to shove. The old Bevy abstraction layer adds nothing. In both situations we are free to extend our gpu abstraction with new features / backends. The only difference is the overall complexity of the system, which will be massively reduced by removing the intermediate layer.
efnx 5y ago
This is great. I switched my renderer from OpenGL to wgpu for my engine and I cannot exaggerate how much better the error reporting is. Instead of "working incorrectly" or simply not working and providing a vague error code (like OpenGL), wgpu tells me exactly what I did wrong, which is a life saver. Also - types. Thanks wgpu team!
- porphyra 5y ago
  Ah yes, OpenGL's error reporting is notoriously bad. If you forget to call disable on a vertex attribute you might just get a random error 1282 (invalid operation) somewhere down the line in a totally irrelevant part of the code, lol.
  - skocznymroczny 5y ago
    It's much better when you use a debug context, although as usual with OpenGL the details vary between graphics card drivers. I had very good debug messages with Nvidia.
- ComputerGuru 5y ago
  Does wgpu finally support OpenGL?
  - kvark 5y ago
    Yeah, we support OpenGL ES-3.0 with a few major caveats.
    - ComputerGuru 5y ago
      That’s awesome. Wgpu did not support a single Linux machine I tried it on, all with various hardware/driver combos, back when OpenGL wasn’t available and later when it was first previewed. It was the only reason I used a different abstraction.
      - adamnemecek 5y ago
devwastaken 5y ago
Does WebGPU protect against DOS via shaders, crashes, etc? Games like VRChat, where a user can just make shaders in Unity and have them ran on everyone elses computer - could really benefit from such a thing. There's an increase in games that are marketed as being able to create your own content that is displayed for other users in a game.
- kvark 5y ago
  If there is too much GPU work thrown at a WebGPU implementation, the best it could do is terminate the logical device on timeout.
- gfxgirl 5y ago
  That's arguably not wgpu's responsibility. It's usually the OS's. Windows will reset the GPU if it doesn't return. Chrome tries to catch it before the OS IIRC. In any case, other than resetting the GPU there is no way to stop DOS via shaders. I can easily write a 3 line shader that has a legit use at 1x1 pixels but will DOS your machine at 2000x2000 pixels. It's basically the halting problem. The only known solutions are (a) reset the GPU or (b) design preemptable GPUs
  - nextaccountic 5y ago
    The commenter said about DoS but what about the fact that GPU memory isn't protected? What if two different shaders run at the same time at the gpu - will one be able to read the other's private memory? There are GPUs that support IOMMU but they cost a fortune. (or is IOMMU a separate feature than just having virtual memory for GPU memory?) Running user-supplied shaders seems like a security nightmare.
    - garaetjjte 5y ago
      All modern GPUs have MMUs that prevent shaders from accessing arbitrary memory. In rare cases where it is absent (like VC4 on Raspberry Pi) driver needs to statically analyze shaders and ensure that all memory accesses are clamped.
- 5y ago
jaas 5y ago
Can/will this be used in Firefox at some point?
- kvark 5y ago
  Yes, in fact in two different ways. 1. Firefox uses wgpu for implementing WebGPU. 2. Applications on wgpu can be compiled in wasm for the web and ran in Firefox Nightly. This is harmed by the fact WebGPU API is still not stable. Hopefully, not for long!
tenaciousDaniel 5y ago
So I'm familiar with WebGPU, but I'm not really sure why there would be a native (non-web) implementation of it. What are the practical uses of this, as opposed to just using something like Vulkan?
- enos_feedler 5y ago
  Cross platform. You could build a rust app with a WebGPU target that runs across web and native.
  - tenaciousDaniel 5y ago
    Ah nice, I see. Any particular reason for Rust being used? Just curious, because I would (naively) expect to see similar projects with Golang, C++ etc but I really only see Rust.
    - jms55 5y ago
      This implementation is developed by firefox (at least, last I checked). Google has an implementation along similar lines in C++ called dawn, and I'm pretty sure webkit plans to use dawn. So you see them in Rust/C++, but no one has written an implementation in go afaik.
      - kvark 5y ago
        For all we know, Safari on Windows(!) is going to use Dawn. But anything on Apple platforms isn't quite clear. They may get their own implementation.
        frutiger 5y ago
        The Windows version of Safari was discontinued in 2012.
        kangz 5y ago
        I think you meant WebKit on Windows (used for other browsers than Safari). Once Dawn is integrated in WebKit for one OS, it should be easy to extend WebKit to use it on other OSes so maybe it will be a quick way to have WebGPU implemented in Safari?
Shadonototro 5y ago
I first thought wgpu was WebGPU, i googled and it is not https://www.w3.org/TR/webgpu/ https://www.w3.org/TR/webgpu/ Naming is important, you want to avoid confusing as much as possible
- math 5y ago
  it is the WebGPU API (targeting both the web and native)
- user-the-name 5y ago
  wgpu is an implementation of WebGPU.
  - Shadonototro 5y ago
    that's exactly what i am saying, they want to confuse people why deny
    - user-the-name 5y ago
      Where on earth do you get "they want to confuse people"?
Animats 5y ago
I've been using the previous version for months. Underneath Rend3, which handles some of the queuing and threading issues for Wgpu. Not for a web client; for complex 3D content on Linux. It's working well. With the new version, I should be able to cross-compile Rust to Windows as well as Linux, and generate a Windows executable without having to use any Microsoft products.
- mikevm 5y ago
  What's your current opinion on Rust viz-a-viz Go? I remember that you had a few complaints about Rust.. I wonder if that has changed? :)
  - Animats 5y ago
    Long subject. Short version: for server-side webcrap, use Go. All the standard parts needed for that are in good shape. For complicated stuff with real-time or graphics aspects, use Rust.
astlouis44 5y ago
WebGPU is going to be huge for Unity/Unreal browser games, and instrumental in architecting the open metaverse via the web.
pjmlp 5y ago
The API that Vulkan should have been. Looking forward to see it take up adoption outside of the browsers that are decades away of being an API one can rely on, and without blacklisting.
skocznymroczny 5y ago
Good news. I switched to WebGPU from OpenGL for my homemade game engine and I am very happy with it. I don't use Rust though, but D, the only time I see Rust code is in the stacktraces when I get an error. Personally, I think there is a lot of potential for WebGPU outside of web/Rust ecosystems. WebGPU provides a great balance between awkwardness of OpenGL (global state, suboptimal resource binding patterns) and the verbosity and expertise required for Vulkan (barriers, synchronization, everything are needed even for a basic triangle and it only gets harder from there).

216 points by kvark 5y ago

> gfx-rs community’s goal is to make graphics programming in Rust easy, fast, and reliable. Yet one of their main projects involves reliance on the web for graphics programming. This is the opposite of their stated goal in my opinion.

pitaj 5y ago
What are you talking about?
zamadatix 5y ago
You may want to take a look at what exactly WebGPU is and the wgpu repository, particularly the examples subfolder, before drawing conclusions based on the name.
_cart 5y ago
Yup wgpu has a WebGPU backend, but it also has first-class native backends for Vulkan, Metal, DX12, and OpenGL ES (with upcoming support for DX11 and WebGL). It is designed to be a cross platform graphics API. It isn't "web based", just "web compatible". And it has super solid "feature detection" that enables you to opt in to "native only" features like push constants.
- encryptluks2 5y ago
  So then why is this being advertised as a WebGPU implementation if it isn't the focus? The title is misleading in that case and instead should just be titled Graphics implementation now in pure Rust.
  - Jweb_Guru 5y ago
    WebGPU is a specification for safe, efficient, cross-platform access to the GPU. It is intended to provide a small set of core primitives that are widely implementable without compromising safety or performance: attention is paid to both use from many client platforms (such as Rust, C, JavaScript, and WASM) and to implementation on many graphics backends (not only in terms of Metal / DirectX 11/12 / Vulkan / OpenGL drivers, but also in terms of trying to choose core features that are actually implemented on things like mobile GPUs, which are often left out of powerful modern graphics abstractions). wgpu-rs is an end-to-end implementation of that spec, for a Rust frontend and many backends. It is designed so that the same code can be used on the web (via WASM) or on native, with no changes to the implementation; however, you can happily ignore the WASM compilation target and just use it natively. It also includes some extensions for widely supported features that aren't available on all GPUs, that you can request if you are willing to restrict the platforms you run on (this is especially helpful on native). As you can see, the fact that it implements the WebGPU spec is very relevant because it inherits all the nice properties of the spec (efficiency, safety, and portability), as well as because there is a specification that you can refer back to in order to figure out (mostly) what the behavior is supposed to be. There is nothing misleading going on here about saying it's a WebGPU implementation. If there's anything misleading, it's probably the name of the spec (but that ship has long since sailed). The other two major components of the system are: * wgpu-core. A cross-platform, safe, efficient, pure-Rust implementation that is used by wgpu-rs, but does not actually implement the full WebGPU spec, and is not really designed for ease of use. It is mostly intended as the basis of other implementations of WebGPU frontends, such as wgpu-rs, wgpu-native (C bindings), and implementations of backends in larger systems like Deno and Servo. * wgpu-hal. A cross-platform, efficient, unsafe, pure-Rust implementation that primarily exists to abstract away differences between platforms targeted by wgpu-core. The lack of attention to safety means it can often approach or match the performance of the native drivers, but also makes it extremely hard to use, and the exposed API is very closely tied to whatever wgpu-core needs (this is a big difference between it and the older gfx-hal, which was intended to a broader unsafe abstraction layer for independent use). These two systems are not as cleanly tied to WebGPU, but they are still primarily intended for use by clients that implement the WebGPU spec. That said, this is not a requirement--there are a few other abstractions built directly on top of wgpu-core or wgpu-hal, and they do not consider themselves as WebGPU implementations (because they aren't!).
deleted 5y ago
[deleted]
nextaccountic 5y ago
Wgpu-rs doesn't rely on the web. The API is just a simplified Vulkan. The API can be implemented for the web (and Firefox uses wgpu-rs) but it is also adequate for native applications. See https://news.ycombinator.com/item?id=23079200 https://news.ycombinator.com/item?id=23079200 (that was posted elsewhere in this thread) for more details.

_cart 5y ago

As Bevy Engine's lead developer (which uses wgpu), this release excites me for a number of reasons: * A smaller (and less abstracted) codebase means that we can more easily extend wgpu with the features we need now and in the future. (ex: XR, ray tracing, exposing raw backend apis). The barrier to entry is so much lower. * It shows that the wgpu team is receptive to our feedback. There was a point during our "new renderer experiments" where we were considering other "flatter" gpu abstractions for our new renderer. They immediately took this into account and kicked off this re-architecture. There were other people with similar feedback so I can't take full credit here, but the timing was perfect. * A pure rust stack means that our builds are even simpler. Combine that with Naga for shader reflection and compilation and we can remove a lot of the "build quirks" in our pipeline that come from non-rust dependencies. Windows especially suffers from this type of build weirdness and I'm excited to not need to deal with that anymore. * The "risk" of treating wgpu as our "main gpu abstraction layer" has gone way down thanks to the last few points. As a result, we have decided to completely remove our old "abstract render layer" in favor of wgpu. This means that wgpu is no longer a "bevy_render backend". It is now bevy_render's core gpu abstraction. This makes our code smaller, simpler, and more compatible with the wider wgpu ecosystem. * There is a work-in-progress WebGL2 backend for the new wgpu. This will hopefully ultimately remove the need for the third party bevy_webgl2 backend (which has served us well, but it has its own quirks and complexities).

timClicks 5y ago
Wow, this feels like a win-win-win for wgpu, bevy and the rust ecosystem in general
CyberRabbi 5y ago
> This means that wgpu is no longer a "bevy_render backend". It is now bevy_render's core gpu abstraction. Experience has shown me that you will eventually regret this decision
- _cart 5y ago
  Snarky answer first: my experience tells me that I won't regret this decision :) Real answer: You can use this argument to justify abstracting out literally anything. Clearly we shouldn't abstract everything and the details of each specific situation will dictate what abstractions are best (and who should own them). Based on the context that I have, Bevy's specific situation will almost certainly benefit from this decision. Bevy needs an "abstract gpu layer". We are currently maintaining our own (more limited) "abstract gpu layer" that lives on top of wgpu. Both my own experience and user experiences have indicated that this additional layer provides a worse experience: it is harder to maintain, harder to understand (by nature of being "another layer"), it lacks features, it adds overhead. Wgpu _is_ a generic abstraction layer fit for an engine. If I was building an abstract layer from scratch (with direct api backends), it would look a lot like wgpu. I understand the internals. I have a good relationship with the wgpu project lead. They respond to our needs. The second anything changes to make this situation suboptimal (they make massive api changes we don't like, they don't accept changes we need, they add dependencies we don't like, etc) I will happily fork the code and maintain it. I know the internals well enough to know that I couldn't do better and that I could maintain it if push comes to shove. The old Bevy abstraction layer adds nothing. In both situations we are free to extend our gpu abstraction with new features / backends. The only difference is the overall complexity of the system, which will be massively reduced by removing the intermediate layer.

efnx 5y ago

This is great. I switched my renderer from OpenGL to wgpu for my engine and I cannot exaggerate how much better the error reporting is. Instead of "working incorrectly" or simply not working and providing a vague error code (like OpenGL), wgpu tells me exactly what I did wrong, which is a life saver. Also - types. Thanks wgpu team!

porphyra 5y ago
Ah yes, OpenGL's error reporting is notoriously bad. If you forget to call disable on a vertex attribute you might just get a random error 1282 (invalid operation) somewhere down the line in a totally irrelevant part of the code, lol.
- skocznymroczny 5y ago
  It's much better when you use a debug context, although as usual with OpenGL the details vary between graphics card drivers. I had very good debug messages with Nvidia.
ComputerGuru 5y ago
Does wgpu finally support OpenGL?
- kvark 5y ago
  Yeah, we support OpenGL ES-3.0 with a few major caveats.
  - ComputerGuru 5y ago
    That’s awesome. Wgpu did not support a single Linux machine I tried it on, all with various hardware/driver combos, back when OpenGL wasn’t available and later when it was first previewed. It was the only reason I used a different abstraction.
    - adamnemecek 5y ago

devwastaken 5y ago

Does WebGPU protect against DOS via shaders, crashes, etc? Games like VRChat, where a user can just make shaders in Unity and have them ran on everyone elses computer - could really benefit from such a thing. There's an increase in games that are marketed as being able to create your own content that is displayed for other users in a game.

kvark 5y ago
If there is too much GPU work thrown at a WebGPU implementation, the best it could do is terminate the logical device on timeout.
gfxgirl 5y ago
That's arguably not wgpu's responsibility. It's usually the OS's. Windows will reset the GPU if it doesn't return. Chrome tries to catch it before the OS IIRC. In any case, other than resetting the GPU there is no way to stop DOS via shaders. I can easily write a 3 line shader that has a legit use at 1x1 pixels but will DOS your machine at 2000x2000 pixels. It's basically the halting problem. The only known solutions are (a) reset the GPU or (b) design preemptable GPUs
- nextaccountic 5y ago
  The commenter said about DoS but what about the fact that GPU memory isn't protected? What if two different shaders run at the same time at the gpu - will one be able to read the other's private memory? There are GPUs that support IOMMU but they cost a fortune. (or is IOMMU a separate feature than just having virtual memory for GPU memory?) Running user-supplied shaders seems like a security nightmare.
  - garaetjjte 5y ago
    All modern GPUs have MMUs that prevent shaders from accessing arbitrary memory. In rare cases where it is absent (like VC4 on Raspberry Pi) driver needs to statically analyze shaders and ensure that all memory accesses are clamped.
5y ago

jaas 5y ago

Can/will this be used in Firefox at some point?

kvark 5y ago
Yes, in fact in two different ways. 1. Firefox uses wgpu for implementing WebGPU. 2. Applications on wgpu can be compiled in wasm for the web and ran in Firefox Nightly. This is harmed by the fact WebGPU API is still not stable. Hopefully, not for long!

tenaciousDaniel 5y ago

So I'm familiar with WebGPU, but I'm not really sure why there would be a native (non-web) implementation of it. What are the practical uses of this, as opposed to just using something like Vulkan?

enos_feedler 5y ago
Cross platform. You could build a rust app with a WebGPU target that runs across web and native.
- tenaciousDaniel 5y ago
  Ah nice, I see. Any particular reason for Rust being used? Just curious, because I would (naively) expect to see similar projects with Golang, C++ etc but I really only see Rust.
  - jms55 5y ago
    This implementation is developed by firefox (at least, last I checked). Google has an implementation along similar lines in C++ called dawn, and I'm pretty sure webkit plans to use dawn. So you see them in Rust/C++, but no one has written an implementation in go afaik.
    - kvark 5y ago
      For all we know, Safari on Windows(!) is going to use Dawn. But anything on Apple platforms isn't quite clear. They may get their own implementation.
      - frutiger 5y ago
        The Windows version of Safari was discontinued in 2012.
      - kangz 5y ago
        I think you meant WebKit on Windows (used for other browsers than Safari). Once Dawn is integrated in WebKit for one OS, it should be easy to extend WebKit to use it on other OSes so maybe it will be a quick way to have WebGPU implemented in Safari?

Shadonototro 5y ago

I first thought wgpu was WebGPU, i googled and it is not https://www.w3.org/TR/webgpu/ https://www.w3.org/TR/webgpu/ Naming is important, you want to avoid confusing as much as possible

math 5y ago
it is the WebGPU API (targeting both the web and native)
user-the-name 5y ago
wgpu is an implementation of WebGPU.
- Shadonototro 5y ago
  that's exactly what i am saying, they want to confuse people why deny
  - user-the-name 5y ago
    Where on earth do you get "they want to confuse people"?

Animats 5y ago

I've been using the previous version for months. Underneath Rend3, which handles some of the queuing and threading issues for Wgpu. Not for a web client; for complex 3D content on Linux. It's working well. With the new version, I should be able to cross-compile Rust to Windows as well as Linux, and generate a Windows executable without having to use any Microsoft products.

mikevm 5y ago
What's your current opinion on Rust viz-a-viz Go? I remember that you had a few complaints about Rust.. I wonder if that has changed? :)
- Animats 5y ago
  Long subject. Short version: for server-side webcrap, use Go. All the standard parts needed for that are in good shape. For complicated stuff with real-time or graphics aspects, use Rust.

astlouis44 5y ago

WebGPU is going to be huge for Unity/Unreal browser games, and instrumental in architecting the open metaverse via the web.

pjmlp 5y ago

The API that Vulkan should have been. Looking forward to see it take up adoption outside of the browsers that are decades away of being an API one can rely on, and without blacklisting.

skocznymroczny 5y ago

Good news. I switched to WebGPU from OpenGL for my homemade game engine and I am very happy with it. I don't use Rust though, but D, the only time I see Rust code is in the stacktraces when I get an error. Personally, I think there is a lot of potential for WebGPU outside of web/Rust ecosystems. WebGPU provides a great balance between awkwardness of OpenGL (global state, suboptimal resource binding patterns) and the verbosity and expertise required for Vulkan (barriers, synchronization, everything are needed even for a basic triangle and it only gets harder from there).