Remix.run Logo
jms55 a year ago

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

jblandy a year ago | parent | next [-]

WGPU dev here. I agree with everything JMS55 says here, but I want to avoid a potential misunderstanding. Performance is definitely a priority for WGPU, the open source project. Much of WGPU's audience is very concerned with performance.

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.

jms55 a year ago | parent [-]

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

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.

Animats a year ago | parent | prev | next [-]

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

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.

pjmlp a year ago | parent | next [-]

Back in the day I did a similar error with wrapping C graphic libraries directly 1:1 with improved C++ bindings, until I realised it was more ergonomic to think in higher level C++ abstractions, and exposed those concepts instead, fully hiding the underlying unsafe C APIs.

ladyanita22 a year ago | parent | prev [-]

I'm interested in reading more. Where will you continue this?

kookamamie a year ago | parent | prev [-]

> implementing missing features so that they can ship WebGPU support in Firefox

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.

brookman64k a year ago | parent | next [-]

Just to avoid potential confusion: WebGPU and WGPU are different things.

littlestymaar a year ago | parent | prev | next [-]

The irrelevant browser is the one paying developers to build wgpu though…

pjmlp a year ago | parent | prev | next [-]

Outside of the browser the answer is middleware.

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.

adastra22 a year ago | parent | prev [-]

Is WGPU even a Mozilla project? I think he is just saying that those paid developers (paid by Mozilla) have that priority, and everyone else is volunteer. Not that WGPU is a Firefox project.