14 ms·

Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless mak

by jms55 2y ago

Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state. The default texture limits without bindless are also way too small for serious applications - just implementing the glTF PBR spec + extensions will blow past them. I'm really looking forward to getting bindless later down the road, although I expect it to take quite a while. By the same token, I'm quite surprised that effort is being put into a compatibility mode, when WebGPU is already too old and limiting for a lot of people, and when WebGL(2) is going to have to be maintained by browsers anyways.

Animats 2y ago
> Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state. 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 https://github.com/gfx-rs/wgpu/issues/6434 [2] https://gamedev.rs/ https://gamedev.rs/
- jms55 2y 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.
  - kookamamie 2y ago
    > 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.
    - adastra22 2y ago
      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.
nox101 2y ago
> The default texture limits without bindless are also way too small for serious applications I'm not disagreeing that bindless is needed but it's a bit of hyperbole to claim the texture limits are too small for serious applications given the large list of serious graphics applications that shipped before bindless existed and the large number of serious graphics applications and games still shipping that don't use them.
- jms55 2y ago
  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/src/render/mesh_view_bindings.wgsl https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr... * https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr/src/render/pbr_bindings.wgsl https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr...
- elabajaba 2y ago
  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.
- Animats 2y ago
  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.
  - lpghatguy 2y ago
    You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.
modeless 2y ago
You don't have to settle for the default limits. Simply request more.
- adastra22 2y ago
  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.
- jms55 2y ago
  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.
  - modeless 2y ago
    That makes sense. I bet the WebGPU WG would be interested in hearing about that experience. They might be able to make changes to the buckets.
pjmlp 2y ago
It only goes to show the limitations of browser 3D APIs, and the huge mistake some folks do for native games using it instead of a proper middleware engines, capable of exposing modern hardware.
- jms55 2y ago
  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.
  - pjmlp 2y ago
    Basically the goal of any middleware engine, since the dawn of time in the games industry.
jblandy 2y ago
The nice thing about WebGPU's "compat mode" is that it's designed so browsers don't have to implement it if they don't want to. Chrome is really excited about it; Safari has no plans to implement it, ever. I agree that compat mode takes up more of the WebGPU standard committee's time than bindless. I'm not sure that's how I would prioritize things. (As a Mozilla engineer, we have more than enough implementation work to do already, so what the committee discusses is sort of beside the point for us...) What would be really helpful is if, once the bindless proposal <https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA?view https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA?view> gets merged into the spec repo <https://github.com/gpuweb/gpuweb/tree/main/proposals https://github.com/gpuweb/gpuweb/tree/main/proposals>, a contributor could start adapting what WGPU has now to match the proposal. Implementation experience would be incredibly valuable feedback for the committee.
deleted 2y ago
[deleted]
ribit 2y ago
Quick note: I looked at the bindless proposal linked from the blog post and their description of Metal is quite outdated. MTLArgumentEncoder has been deprecated for a while now, the layout is a transparent C struct that you populate at will with GPU addresses. There are still descriptors for textures and samplers, but these are hidden from the user (the API will maintain internal tables). It's a very convenient model and probably the simplest and most flexible of all current APIs. I'd love to see something similar for WebGPU.

by jms55 2y ago

Animats 2y ago

> Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state. 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 https://github.com/gfx-rs/wgpu/issues/6434 [2] https://gamedev.rs/ https://gamedev.rs/

jms55 2y 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.
- kookamamie 2y ago
  > 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.
  - adastra22 2y ago
    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.

nox101 2y ago

> The default texture limits without bindless are also way too small for serious applications I'm not disagreeing that bindless is needed but it's a bit of hyperbole to claim the texture limits are too small for serious applications given the large list of serious graphics applications that shipped before bindless existed and the large number of serious graphics applications and games still shipping that don't use them.

jms55 2y ago
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/src/render/mesh_view_bindings.wgsl https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr... * https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr/src/render/pbr_bindings.wgsl https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr...
elabajaba 2y ago
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.
Animats 2y ago
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.
- lpghatguy 2y ago
  You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.

modeless 2y ago

You don't have to settle for the default limits. Simply request more.

adastra22 2y ago
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.
jms55 2y ago
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.
- modeless 2y ago
  That makes sense. I bet the WebGPU WG would be interested in hearing about that experience. They might be able to make changes to the buckets.

pjmlp 2y ago

It only goes to show the limitations of browser 3D APIs, and the huge mistake some folks do for native games using it instead of a proper middleware engines, capable of exposing modern hardware.

jms55 2y ago
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.
- pjmlp 2y ago
  Basically the goal of any middleware engine, since the dawn of time in the games industry.

jblandy 2y ago

The nice thing about WebGPU's "compat mode" is that it's designed so browsers don't have to implement it if they don't want to. Chrome is really excited about it; Safari has no plans to implement it, ever. I agree that compat mode takes up more of the WebGPU standard committee's time than bindless. I'm not sure that's how I would prioritize things. (As a Mozilla engineer, we have more than enough implementation work to do already, so what the committee discusses is sort of beside the point for us...) What would be really helpful is if, once the bindless proposal <https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA?view https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA?view> gets merged into the spec repo <https://github.com/gpuweb/gpuweb/tree/main/proposals https://github.com/gpuweb/gpuweb/tree/main/proposals>, a contributor could start adapting what WGPU has now to match the proposal. Implementation experience would be incredibly valuable feedback for the committee.

deleted 2y ago

[deleted]

ribit 2y ago

Quick note: I looked at the bindless proposal linked from the blog post and their description of Metal is quite outdated. MTLArgumentEncoder has been deprecated for a while now, the layout is a transparent C struct that you populate at will with GPU addresses. There are still descriptors for textures and samplers, but these are hidden from the user (the API will maintain internal tables). It's a very convenient model and probably the simplest and most flexible of all current APIs. I'd love to see something similar for WebGPU.