> This is one reason we don't see high-performance games written in Rust.

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.

There have been a bunch of significant improvements to WGPU's performance over the last few years.

* 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.

> When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]

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.

Tbh I was annoyed reading it too as an open source developer. The people you are talking to are volunteering their time, and you weren’t very considerate of that. Open source software isn’t the same support structure as paid software. You don’t file tickets and expect them to be promptly fixed, unless you do the legwork yourself.

Tbf, tons of games have been created and are still being created without bindless resource binding. While WebGPU does have some surprising performance bottlenecks around setBindGroup(), details like that hardly make or break a game (if the devs are somewhat competent they'll come up with ways to workaround 3D API limitations - that's how it's always been and always will be - the old batching tricks from the D3D9 era still sometimes make sense, I wonder if people simply forgot about those or don't know them in the first place because it was before their time).

As far as I know, Unity doesn't support bindless either. However thousands of Unity games are released on Steam every year. So it's safe to say performance isn't the main (or major) reason why Rust gamedev isn't getting much traction.

Another reason is that exploratory programming is hard by design in Rust. Rust is great if you already have a spec and know what needs to be done.

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.

Author of Renderling here. Thanks for the shout out Animats!

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.

I thought WGPU only supported WebGPU, and then there were translation libraries (akin to Proton) to run WebGPU over Vulkan.

Does it directly, internally, support Vulkan instead of on-the-fly translation from WebGPU to VK?

The tone of the thread was perfectly fine until you made a passive aggressive comment

It's partly because WebGPU has very conservative default texture limits so that they can support old mobile devices, and partly it's a problem for engines that may have a bunch of different bindings and have increasingly hacky workarounds to compile different variants with only the enabled features so that you don't blow past texture limits.

For an idea of bevy's default view and PBR material bindings, see:

* https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr...

* https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr...

They're talking about the 16 sampled texture binding limit which is the same as webgl2. If you look at eg. the list of devices that are stuck with that few texture bindings they don't even support basic GL with compute shaders or vulkan, so they can't even run webgpu in the first place.

Yes. If you're stuck with that limitation, you pack up related textures into a big texture atlas. When you enter a new area, the player sees "Loading..." while the next batch of content is loaded. That was the state of the art 15 years ago. It's kind of dated now.

We do when there available, but I think the way browsers implement limit bucketing (to combat fingerprinting) means that some users ran into the limit.

I never personally ran into the issue, but I know it's a problem our users have had.

Yeah I went down the rabbit hole of trying to rewrite all our shaders to work on webgpu’s crazy low limits. I’m embarrassed to say how long I worked that problem until I tried requesting higher limits, and it worked on every device we were targeting.

The default limits are like the lowest common denominator and typically way lower than what the device actually supports.

I don't necessarily disagree. But I don't agree either. WebGPU has given us as many positives as it has negatives. A lot of our user base is not on modern hardware, as much as other users are.

Part of the challenge of making a general purpose engine is that we can't make choices that specialize to a use case like that. We need to support all the backends, all the rendering features, all the tradeoffs, so that our users don't have to. It's a hard challenge.