Rendering is _hard_, and Rust is an uncommon toolchain in the gamedev industry. I don't think wgpu has much to do with it. Vulkan via ash and DirectX12 via windows-rs are both great options in Rust.
> After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Performance isn't most of the wgpu maintainer's (who are paid by Mozilla) priority at the moment. Fixing bugs and implementing missing features so that they can ship WebGPU support in Firefox is more important. The other maintainers are volunteers with no obligation besides finding it enjoyable to work on. Performance can always be improved later, but getting working WebGPU support to users so that websites can start targeting it is crucial. The annoyance is that you were rude about it.
> Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026.
The bindless stuff is basically "developers requested it a ton when we asked for feedback on features they wanted (I was one of those people who gave them feedback), and we had some draft proposals from (iirc) 1-2 different people". It's wanted, but there are still major questions to answer. It's not like this is a set thing they've been developing and are preparing to release. All the features listed are just feedback from users and discussion that took place at the WebGPU face to face recently.
Sounds like WGPU, the project, should be detached from Firefox?
To me the priority of shipping WGPU on FF is kind of mind-boggling, as I consider the browser irrelevant at this point in time.
(b) WGPU, gfx-rs/wgpu, wgpu.rs -> Rust crate implementing WebGPU
(c) wgpu -> the prefix used by the C API for all WebGPU native implementations.
(d) 'wgpu' -> a cute shorthand used by everyone to describe either (a), (b), or (c) with confusion.
WGPU has to decide, either stay compatible with WebGPU, and thus be constrained by the design of a Web 3D API, or embrace native code and diverge from WebGPU.
But even more, the level at which WebGPU exists (not too high level, not too low level) necessitates that if a native API graphics abstraction sticks with the WebGPU's API design and only 'extends' it, you actually end up with three totally different ways to use the API:
* The one with your native 'extensions' -> your app will only run natively and never in the browser unless you implement two different WebGPU rendering backends. Also won't run on Chromebook-type devices that only have GLES-era hardware.
* The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.
* The new 'compatability' mode in WebGPU -> your app runs everywhere, but perish in the verbosity of not having bindless, suffer without reversed-z buffers because the underlying API doesn't support it.
And if you want your app to run in all three as best as possible, you need to write three different webgpu backends for your app, effectively, as if they are different APIs and shading languages.
Note, regarding "GLES-era": WGPU does have a GLES/WebGL2 backend; missing WebGL1 is unfortunate, but at least it covers most recent browsers/hardware that happens to not have WebGPU supported yet.
(and there's necessarily some added overhead from having to adapt to GLES-style api; it's especially silly if you consider that the browser might then convert the api calls and shaders _again_ to D3D11 via ANGLE)
And interestingly, WebGL2 in Chrome on Windows (which runs on top of D3D11) handily beats WebGPU in some of my tests (with setBindGroup being the bottleneck).
My team at Mozilla are active contributors to WGPU. For the moment, when we Mozilla engineers are prioritizing our own work, we are focused on compatibility and safety, because that's what we need most urgently for our use case. Once we have shipped WebGPU in Firefox, we will start putting our efforts into other things like performance, developer experience, and so on.
But WGPU has other contributors with other priorities. For example, WGPU just merged some additions to its nascent ray tracing support. That's not a Mozilla priority, but WGPU took the PR. Similarly for some recent extensions to 64-bit atomics (which I think is used by Bevy for Nanite-like techniques?), and other areas.
WGPU is an open source project. We at Mozilla contribute to the features we need; other people contribute to what they care about; and the overall direction of the project is determined by what capable contributors put in the time to make happen.
Yep! The 64-bit atomic stuff let me implement software rasterization for our Nanite-like renderer - it was a huge win. Same for raytracing, I'm using it to develop a RT DI/GI solution for Bevy. Both were really exciting additions.
The question of how performant and featureful wgpu is is mostly just a matter of resources in my view. Like with Bevy, it's up to contributors. The unfortunate reality is that if I'm busy working on Bevy, I don't have any time for wgpu. So I'm thankful for the people who _do_ put in time to wgpu, so that I can continue to improve Bevy.
Yes. I think I'm beginning to see what's gone wrong with the Rust crates. It's an architectural problem. Vulcano and WGPU try to create a Rust safety perimeter at an API that's basically a wrapper around Vulkan. This may be the wrong boundary for that safety perimeter.
Moving buffer allocation inside the safety perimeter may eliminate a level of locking and checking. Bindless really brings this out, because somebody has to keep the descriptor table and buffer allocation in sync. The GPU depends on that. So that has safety implications.
If this problem is partitioned differently, the locking problems for concurrent GPU content updating may become simpler. Right now, both Vulcano and WGPU force more serialization than Vulkan itself requires. The rendering thread is too often stalled on a lock waiting for some content updating operation that should not interfere with rendering.
Too much detail for this forum. I'll continue this elsewhere. This has been useful.
[1] https://discussions.unity.com/t/gpu-bindless-resources-suppo...
The industry has moved beyond that, with teams where programmers only have a minor role (quite important nontheless), on the whole game design, with plenty of tooling for designers and other non-programmer folks to do their tasks.
Eventually with more graphical tooling, or scripting systems, it will start to gain more steam.
Note that TinyGlade also created most of their tooling in-house, they only partially depend on Bevy.
Bindless is a game changer - pun intended. It can’t happen soon enough.
Just curious, what are the three major projects that were cancelled?
I also want to mention that folks are shipping high performance games in Rust - the first title that comes to mind is “Tiny Glade” which is breathtakingly gorgeous, though it is a casual game. It does not run on wgpu though, to my knowledge. I may have a different definition of high performance, with lower expectations.
Here are some:
- LogLog Games [1]. Not happy with Bevy. Not too unhappy about performance, although it's mentioned.
- Moonlight Coffee [2]. Not a major project, but he got as far as loading glTF and displaying the results, then quit. That's a common place to give up.
- Hexops. [3] Found Rust "too hard", switched to Zig.
Tiny Glade is very well done. But, of course, it's a tiny glade. This avoids the scaling problems.
[1] https://news.ycombinator.com/item?id=40172033
[2] https://www.gamedev.net/blogs/entry/2294178-abandoning-the-r...
[3] https://devlog.hexops.com/2021/increasing-my-contribution-to...
Rust for game engine has always been a highly risky endeavor since the ecosystem is much less mature than everything else, and even though things have improved a ton over the past few years, it's still light-years away from the mainstream tools.
Building a complete game ecosystem is very hard and it's not surprising to see that Rust is still struggling.
1. It's a game studio not a project (CEO here :))
2. It's very much still alive and well today, not 'cancelled'
3. We never even used WebGPU in Rust, this was before WebGPU was really a thing.
It is true that we looked elsewhere for a better language for us with different tradeoffs, and have since fully embraced Zig. It's also true that we were big proponents of WebGPU earlier on, and have in recent years abandoned WebGPU in favor of something which is better for graphics outside the browser (that's its own worthwhile story)..
But we've never played /any/ role in the Rust gamedev ecosystem, really.
Nobody needs all of Vulkan, but everyone needs quite a bit of it. Buffer allocation? Command encoding? Scheduling? Synchronization? Abstracting GPU architecture differences (and GPUs vary a lot)? Render pipeline fixed-function stages like primitive assembly, tiling, and blending? You're signing up to implement all of that - good luck!
In this view, your idea is the assertion, "I could do a better job at all that stuff than the driver developers." Maybe so! They're only human. Drivers do have bugs. But you're only human too.
Also, the onus is actually on the GPU manufacturers (not game engine devs) to simplify the programmability of the GPUs to the level we have for CPUs (we also do not write microcode, however, the programmability is much much simpler with access to good compiler toolchains). This will massively help non game engine developers who need GPUs for other kinds of compute.
* Before the major rework called "arcanization", `wgpu_core` used a locking design that caused huge amounts of contention in any multi-threaded program. It took write locks so often I doubt you could get much parallelism at all out of it. That's all been ripped out, and we've been evolving steadily towards a more limited and reasonable locking discipline.
* `wgpu_core` used to have a complex system of "suspected resources" and deferred cleanup, apparently to try to reduce the amount of work that needed to be done when a command buffer finished executing on the GPU. This turned out not to actually save any work at all: it did exactly the same amount of bookkeeping, just at a different time. We ripped out this complexity and got big speedups on some test cases.
* `wgpu_core` used to use Rust generics to generate, essentially, a separate copy of its entire code for each backend (Vulkan, Metal, D3D12) that it used. The idea was that the code generator would be able to see exactly what backend types and functions `wgpu_core` was using, inline stuff, optimize, etc. It also put our build times through the roof. So, to see if we could do something about the build times, Wumpf experimented with making the `wgpu_hal` API use dynamic dispatch instead. For reasons that are not clear to me, switching from generics to dynamic dispatch made WGPU faster --- substantially so on some benchmarks.
Animats posts frequently about performance problems they're running into, but when they do it's always this huge pile of unanalyzed data. It's almost as if, they run into a performance problem with their code, and then rather than figuring out what's going on themselves, they throw their whole app over the wall and ask WGPU to debug the problem. That is just not a service we offer.
I honestly don't get your annoyed response; any OSS project wishes they had such detailed bug reports, and such a performance regression would concern me very much if it happened in a project I maintain.
Does it directly, internally, support Vulkan instead of on-the-fly translation from WebGPU to VK?
The main purpose of WebGPU is to specify a 3D API over the common subset of Metal/D3D12/Vulkan features (e.g. doing an 'on-the-fly translation' of WebGPU API calls to Metal/D3D12/Vulkan API calls, very similar to how (a part of) Proton does an on-the-fly translation of the various D3D API versions to Vulkan.
OP claimed WGPU had native support for VK, DX and others. But as far as I know, WGPU just supports WebGPU being translated on the fly to those other backends, with the obvious performance hit. If I'm wrong, I'd be interested to know, as this would make WGPU a more interesting choice for many if, in reality, the code was native instead of translation.
Edit: https://docs.rs/wgpu/latest/wgpu/#backends it seems they indeed support native code in almost every backend?
Those three WebGPU implementation libraries are compiled to native code (they are written in Rust or C/C++), and at least WGPU and Dawn are usable as native libraries outside the browser in regular native apps that want to use WebGPU as a cross-platform 3D API.
Yet still, those native libraries do a runtime translation of WebGPU API calls to DX/Vk/Metal API calls (and also a runtime translation of either WGSL or SPIRV to the respective 3D backend API shading languages) - in that sense, quite similar to what Proton does, just for a different 'frontend API'.
Unless we are talking about cool shadertoy examples.
Streaming solves the business case, with native APIs using server side rendering.
> Streaming solves the business case, with native APIs using server side rendering.
And yet history is littered with the dead husks of game streaming services ;)
Game Pass, GeForce Now, are doing alright.
Stadia failed, because Google doesn't get games industry.
Shadertoy is full of impressive demos.
Bindless lets you reduce the amount of book keeping you have to do per-object on the CPU, but much more importantly opens the door for GPU driven rendering.
The problem with WebGPU is there's no bindless and the 'bindful' path is quite expensive to meet the safety requirements of a browser API. There's no way around the slow path, and the slow path is quite slow. In this case the workaround is cut features because the API simply imposes too much overhead.
But I would prefer to first bring the peformance of the slot-based binding model to a point where it is similar to D3D11 or Metal instead of ignoring that part of the API and 'skipping ahead' to bindless (which will probably have to be behind an extension anyway). Otherwise WebGPU will become a cemetery of abandondend attempts like OpenGL.
Most of the gamedev in my opinion is extremely exploratory and demands constant experimentation with design. C/C++ offer fluidity, a very good and mature debug toolchain, solid performance ceiling and support from other people.
It will be really hard to replace C++ in performance/simulation contexts. Security takes a backseat there.
Someone was seemingly "annoyed" by an impatient end-user asking for an status update ("It's now next week. Waiting.") and nothing more. They didn't seem to be annoyed about that you pointed out a performance issue, and instead explained that their current focus is elsewhere.
Yes.
This has had a devastating effect on Rust 3D graphics. The main crate for doing 3D graphics in Rust is WGPU. WGPU supports not just WebGPU, but Android, Vulkan, Metal, Direct-X 12, and OpenGL. It makes them all look much like Vulkan. Bevy, Rend3, and Renderling, the next level up, all use WGPU. It's so convenient.
WGPU has lowest common denominator support. If WebGPU can't do something inside a browser, then WGPU probably can't do it on other platforms which could handle it. So WGPU makes your gamer PC perform like a browser or a phone. No bindless, no multiple queues, and somewhat inefficient binding and allocation.
This is one reason we don't see high-performance games written in Rust.
After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026. I'm not sure that game dev in Rust has that much runway left. Three major projects have been cancelled and the main site for Rust game dev stopped updating in June 2024.[2]
[1] https://github.com/gfx-rs/wgpu/issues/6434
[2] https://gamedev.rs/