5 ms·

Anyone else excited for what WebGPU will enable for next generation browser games and real-time 3D web applications?

janosd 3y ago
There was a discussion on the BabylonJS forums back in August about this. [1] TL;DR the GPU may now be available, but having to download several gigabytes of assets to download and sit in your browser cache may be a bit problematic. Also, the expectations towards a web-based thing are different than a dedicated download. [1] https://forum.babylonjs.com/t/why-havent-3d-web-games-reached-the-scale-of-runescape-despite-advanced-web-tech/43405 https://forum.babylonjs.com/t/why-havent-3d-web-games-reache...
SeanAnderson 3y ago
I definitely am :D to the point that I started trying to build a WASM game just to start troubleshooting pain points.
pjmlp 3y ago
Nah, it is an API for 2015 hardware, after a decade of WebGL we still haven't got anything better than SpectorJS, and on top of it we have to either use yet another shading language, or abstract it via code generation tooling. The only thing good about it, is moving the Web 3D beyond GL ES 3.0 subset. Don't expect nanite or Fortnite on the browser anytime soon.
- lyu07282 3y ago
  Why? It's pretty close to the Vulcan API why is Web GPU stuck in 2015 as you claim? Also Web GPU isn't just the browser didn't you read the article?
  - flohofwoe 3y ago
    Vulkan is moving away from the extreme "everything is baked into immutable objects" philosophy of Vulkan 1.0 (see: [1], [2], [3], [4] - although these extension swing the pendulum back too much to the granular OpenGL API model, which also sucks), while WebGPU will be stuck with the "rigid model" for quite a while and even adds more rigidness (for instance baking shader resource bindings into immutable BindGroup objects). WebGPU still has a nice balance between convenience and a somewhat modern feature set, but going down to the native platform 3D APIs (Metal, D3D12 and Vulkan) will always offer a much bigger feature set and less CPU overhead (mainly because WebGPU also needs to support mobile GPUs, and some of those are indeed 10 years behind the curve). [1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [2] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state2.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [3] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state3.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [4] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_vertex_input_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man...
  - pjmlp 3y ago
    Because 2015 hardware is the baseline for the MVP 1.0. WebGPU outside of the browser doesn't really matter, middleware engines already cover that, and with much better tooling. Besides WebGPU outside of the browser cannot deviate from the WebGPU on the browser, otherwise it is exactly the same pain as porting between OpenGL ES, OpenGL and WebGL, API that are only compatible in name.
- rezmason 3y ago
  In many ways, you're right. In my opinion, the main strength of WebGPU is it removes the cost of re-implementing something when targeting a different platform. If that was present in 2015, maybe we'd have more games, more interesting applications, and less pressure on people who feel locked into one vendor's ecosystem.
  - pjmlp 3y ago
    Anyone that has taken part in GDC, PAX, or similar conferences, knows how little the game studios care about something that is so dear to the hearts of FOSS folks when discussing 3D APIs.
- jms55 3y ago
  Most of Nanite (at least, everything but the LOD system, I haven't tried that part, and the compute rasterizer due to lack of storage image atomics because Metal lacks them...) is implementable in WebGPU actually. I have a PR that does a lot of the same things (meshlets, visbuffer, material depth, two pass occlusion culling) open for Bevy https://github.com/bevyengine/bevy/pull/10164 https://github.com/bevyengine/bevy/pull/10164 that I've been working on, which uses WebGPU. WebGPU is actually a pretty good API imo. It's missing some advanced features like raytracing, mesh shaders, and subgroup operations (coming soon!), but it can still do a lot. The much bigger missing feature is "bindless" support (non-uniform arrays of bound resources). BindGroup overhead (and ergonomics) is a significant downside.
  - astlouis44 3y ago
    Great points. JMS55, are you interested in contributing to UE5 WebGPU? My team and I have been working on this for the past several years, and would welcome some help. If you're ever looking to join a team to advance Unreal Engine 5 and graphics in the browser, please reach out. We're tackling Nanite and Lumen in the browser, and contributing to the WebGPU spec in collaboration with Google. You can reach me on Discord - my username is astlouis44 I'm also on LinkedIn: https://www.linkedin.com/in/alex-st-louis-3986a5102/ https://www.linkedin.com/in/alex-st-louis-3986a5102/
    - jms55 3y ago
      Thanks for the offer, but unfortunately developing one game engine at a time is my limit :). I'm avoiding looking at UE source code specifically to ensure I don't accidentally copy code into Bevy. Best of luck though, and always glad to see more people work on the WebGPU spec! Maybe you can help push for raytracing and bindless extensions :)
  - pjmlp 3y ago
    Interesting, does it work on the browser, or wgpu?
    - jms55 3y ago
beebeepka 3y ago
More scared than excited but yeah, definitely excited. As a non game developer, though, I am wondering if migrating existing renderers would allow me to create UIs, or parts of them, using graphics that is not just html+CSS without the massive overhead that we currently have. I mean, I can draw the frames just fine but these extra cycles suck power and produce heat
- neftaly 3y ago
  https://github.com/coconut-xr/apfel-kruemel https://github.com/coconut-xr/apfel-kruemel works today, I only know about battery-optimized software in the context of games and IoT though. https://felt.com/blog/svg-to-canvas-part-2-building-interactions https://felt.com/blog/svg-to-canvas-part-2-building-interact... and https://github.com/servo/pathfinder/ https://github.com/servo/pathfinder/ might be of interest.
gmiller123456 3y ago
I'm not expecting too much, as it's going to be hard to monetize something people get the source code to. So I think it's going to be limited to small projects, or sub projects that don't cost a lot to develop.
- vore 3y ago
  If you're so worried about people getting the source code to it, you can just compile to WebAssembly.
- connicpu 3y ago
  I imagine any serious project won't be written in JavaScript, and WASM code with symbols stripped out is about as opaque as x86 or ARM assembly, especially when you start getting into the code sizes you expect for a full game engine or productivity suite.
  - Waterluvian 3y ago
    When you minify js don’t you end up with the same kind of thing? You can “decompile” both and neither give you any symbols. Just a bunch of random letters calling other random letters, etc. Maybe I need an example to understand.
    - Drakim 3y ago
      Not quite, minify JS can be "beautified" to get pretty reasonable JS back, sans variables and functions having letters for names as you noted. But this is because obfuscated JS is still valid JS, it's just made ugly. Obfuscated assembly is often changed in such a way that there are no corresponding language constructs to "reverse" back to, if it originally came from a language like C++. Sure you can see the actual assembly code, but you can't recreate the higher level C++ constructs in a sane way, because the obfuscation technique scrambles things too much.
      - slimsag 3y ago
        I think you're missing a good amount of nuance here minified JS can be turned into reasonable JS, yes, but you're probably not going to get TypeScript code back, so the same sort of challenge exists there. Assembly -> high-level language is harder, but there are absolutely binary -> C decompilers that are very popular/used in the RE community to make changes to existing programs. But that doesn't even matter, WASM is much higher level than assembly, it's a stack machine, there is no arbitrary control flow / labels / `goto`, there are pre-defined data types, etc. all of this means it's easier to convert WASM -> high-level language than it is with a generic x86/arm binary. There are WASM decompilers[0][1] which can convert WASM binaries into C code and back. In both cases (minified JS and WASM), you're not going to get out exactly what you put in, but WASM doesn't really change the situation very much given the widespread adoption of 'compile to JS' languages like TypeScript these days. [0] https://chromium.googlesource.com/external/github.com/WebAssembly/wabt/+/HEAD/wasm2c/README.md https://chromium.googlesource.com/external/github.com/WebAss... [1] https://github.com/wwwg/wasmdec https://github.com/wwwg/wasmdec
flohofwoe 3y ago
Don't get yourself too hyped up, in the end WebGPU is running on the same GPU as WebGL2, and unless your code is CPU bound you won't see performance improvements if your WebGL2 code is already well optimized. And currently some high-frequency WebGPU calls have an even higher CPU overhead than similar WebGL2 calls (I wrote about that here a bit: https://floooh.github.io/2023/10/16/sokol-webgpu.html https://floooh.github.io/2023/10/16/sokol-webgpu.html). WebGPU allows more flexibility of course, compute shaders and storage buffers are more flexible and cleaner than trying to shoehorn the same stuff into vertex/fragment shaders and using textures as "poor man's storage buffer", but that doesn't mean that one approach is slower or faster than the other.
- animatethrow 3y ago
  Does WebGPU enable a pure 2D game with many sprite animations to not need to pack a texture atlas for best performance? I.e. can I tell the GPU, "Draw these 1000 quads using the following distinct 1000 textures using just this one draw call. I'll be changing the 1000 textures each frame." My experience with OpenGL and D3D11 is that an atlas is the only way to do this. (I've found stb_rect_pack.h to be the least hassle route to packing the atlas.) I started looking at D3D12 and saw that it had command recording but it wasn't clear to me if this is any more efficient for a 2D game than just using D3D11/OpenGL to send 1000 separate pairs of commands to set-this-texture/draw-this-quad. With D3D12 the CPU is still performing thousands of function calls per frame to "record" these commands and I don't see how this is cheaper than having D3D11 do thousands of draw calls. D3D11 just puts a draw call into a command queue and immediately returns so isn't this effectively kinda the same thing as using ID3D12CommandQueue "command recording"? I never got around to benchmarking or learning more, so I'm sure I must be misunderstanding the advantages. I've also noticed that despite D3D12 launching back in 2015, the #1 most used engine Unity is still defaulting to D3D11 and has struggled to make D3D12 as performant/stable. So it seems I'm not the only one who can't figure out how the newer APIs offer more performance.
  - flohofwoe 3y ago
    WebGPU currently doesn't support the "bindless" resource access model (see: https://github.com/gpuweb/gpuweb/issues/380 https://github.com/gpuweb/gpuweb/issues/380). The "max number of sampled texture per shader stage" is a runtime device limit, and the minimal value for that seems to be 16. So texture atlasses are still a thing in WebGPU. WebGPU has render bundles, which allow to pre-record command sequences, but even with that you don't want to change resource bindings thousands of times per frame (or even hundreds of times). It might make sense though to build texture atlases dynamically (basically use one very big texture as "tile cache") and update that via writeTexture() calls (just don't rebuild the entire atlas each frame).
troupo 3y ago
> will enable for next generation browser games and real-time 3D web applications Not excited, and very few of those will materialise. Next gen games require next gen graphics. You can check for yourself how much those graphics weigh.

There was a discussion on the BabylonJS forums back in August about this. [1] TL;DR the GPU may now be available, but having to download several gigabytes of assets to download and sit in your browser cache may be a bit problematic. Also, the expectations towards a web-based thing are different than a dedicated download. [1] https://forum.babylonjs.com/t/why-havent-3d-web-games-reached-the-scale-of-runescape-despite-advanced-web-tech/43405 https://forum.babylonjs.com/t/why-havent-3d-web-games-reache...

SeanAnderson 3y ago

I definitely am :D to the point that I started trying to build a WASM game just to start troubleshooting pain points.

pjmlp 3y ago

Nah, it is an API for 2015 hardware, after a decade of WebGL we still haven't got anything better than SpectorJS, and on top of it we have to either use yet another shading language, or abstract it via code generation tooling. The only thing good about it, is moving the Web 3D beyond GL ES 3.0 subset. Don't expect nanite or Fortnite on the browser anytime soon.

lyu07282 3y ago
Why? It's pretty close to the Vulcan API why is Web GPU stuck in 2015 as you claim? Also Web GPU isn't just the browser didn't you read the article?
- flohofwoe 3y ago
  Vulkan is moving away from the extreme "everything is baked into immutable objects" philosophy of Vulkan 1.0 (see: [1], [2], [3], [4] - although these extension swing the pendulum back too much to the granular OpenGL API model, which also sucks), while WebGPU will be stuck with the "rigid model" for quite a while and even adds more rigidness (for instance baking shader resource bindings into immutable BindGroup objects). WebGPU still has a nice balance between convenience and a somewhat modern feature set, but going down to the native platform 3D APIs (Metal, D3D12 and Vulkan) will always offer a much bigger feature set and less CPU overhead (mainly because WebGPU also needs to support mobile GPUs, and some of those are indeed 10 years behind the curve). [1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [2] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state2.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [3] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_extended_dynamic_state3.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man... [4] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_vertex_input_dynamic_state.html https://registry.khronos.org/vulkan/specs/1.3-extensions/man...
- pjmlp 3y ago
  Because 2015 hardware is the baseline for the MVP 1.0. WebGPU outside of the browser doesn't really matter, middleware engines already cover that, and with much better tooling. Besides WebGPU outside of the browser cannot deviate from the WebGPU on the browser, otherwise it is exactly the same pain as porting between OpenGL ES, OpenGL and WebGL, API that are only compatible in name.
rezmason 3y ago
In many ways, you're right. In my opinion, the main strength of WebGPU is it removes the cost of re-implementing something when targeting a different platform. If that was present in 2015, maybe we'd have more games, more interesting applications, and less pressure on people who feel locked into one vendor's ecosystem.
- pjmlp 3y ago
  Anyone that has taken part in GDC, PAX, or similar conferences, knows how little the game studios care about something that is so dear to the hearts of FOSS folks when discussing 3D APIs.
jms55 3y ago
Most of Nanite (at least, everything but the LOD system, I haven't tried that part, and the compute rasterizer due to lack of storage image atomics because Metal lacks them...) is implementable in WebGPU actually. I have a PR that does a lot of the same things (meshlets, visbuffer, material depth, two pass occlusion culling) open for Bevy https://github.com/bevyengine/bevy/pull/10164 https://github.com/bevyengine/bevy/pull/10164 that I've been working on, which uses WebGPU. WebGPU is actually a pretty good API imo. It's missing some advanced features like raytracing, mesh shaders, and subgroup operations (coming soon!), but it can still do a lot. The much bigger missing feature is "bindless" support (non-uniform arrays of bound resources). BindGroup overhead (and ergonomics) is a significant downside.
- astlouis44 3y ago
  Great points. JMS55, are you interested in contributing to UE5 WebGPU? My team and I have been working on this for the past several years, and would welcome some help. If you're ever looking to join a team to advance Unreal Engine 5 and graphics in the browser, please reach out. We're tackling Nanite and Lumen in the browser, and contributing to the WebGPU spec in collaboration with Google. You can reach me on Discord - my username is astlouis44 I'm also on LinkedIn: https://www.linkedin.com/in/alex-st-louis-3986a5102/ https://www.linkedin.com/in/alex-st-louis-3986a5102/
  - jms55 3y ago
    Thanks for the offer, but unfortunately developing one game engine at a time is my limit :). I'm avoiding looking at UE source code specifically to ensure I don't accidentally copy code into Bevy. Best of luck though, and always glad to see more people work on the WebGPU spec! Maybe you can help push for raytracing and bindless extensions :)
- pjmlp 3y ago
  Interesting, does it work on the browser, or wgpu?
  - jms55 3y ago

beebeepka 3y ago

More scared than excited but yeah, definitely excited. As a non game developer, though, I am wondering if migrating existing renderers would allow me to create UIs, or parts of them, using graphics that is not just html+CSS without the massive overhead that we currently have. I mean, I can draw the frames just fine but these extra cycles suck power and produce heat

neftaly 3y ago
https://github.com/coconut-xr/apfel-kruemel https://github.com/coconut-xr/apfel-kruemel works today, I only know about battery-optimized software in the context of games and IoT though. https://felt.com/blog/svg-to-canvas-part-2-building-interactions https://felt.com/blog/svg-to-canvas-part-2-building-interact... and https://github.com/servo/pathfinder/ https://github.com/servo/pathfinder/ might be of interest.

gmiller123456 3y ago

I'm not expecting too much, as it's going to be hard to monetize something people get the source code to. So I think it's going to be limited to small projects, or sub projects that don't cost a lot to develop.

vore 3y ago
If you're so worried about people getting the source code to it, you can just compile to WebAssembly.
connicpu 3y ago
I imagine any serious project won't be written in JavaScript, and WASM code with symbols stripped out is about as opaque as x86 or ARM assembly, especially when you start getting into the code sizes you expect for a full game engine or productivity suite.
- Waterluvian 3y ago
  When you minify js don’t you end up with the same kind of thing? You can “decompile” both and neither give you any symbols. Just a bunch of random letters calling other random letters, etc. Maybe I need an example to understand.
  - Drakim 3y ago
    Not quite, minify JS can be "beautified" to get pretty reasonable JS back, sans variables and functions having letters for names as you noted. But this is because obfuscated JS is still valid JS, it's just made ugly. Obfuscated assembly is often changed in such a way that there are no corresponding language constructs to "reverse" back to, if it originally came from a language like C++. Sure you can see the actual assembly code, but you can't recreate the higher level C++ constructs in a sane way, because the obfuscation technique scrambles things too much.
    - slimsag 3y ago
      I think you're missing a good amount of nuance here minified JS can be turned into reasonable JS, yes, but you're probably not going to get TypeScript code back, so the same sort of challenge exists there. Assembly -> high-level language is harder, but there are absolutely binary -> C decompilers that are very popular/used in the RE community to make changes to existing programs. But that doesn't even matter, WASM is much higher level than assembly, it's a stack machine, there is no arbitrary control flow / labels / `goto`, there are pre-defined data types, etc. all of this means it's easier to convert WASM -> high-level language than it is with a generic x86/arm binary. There are WASM decompilers[0][1] which can convert WASM binaries into C code and back. In both cases (minified JS and WASM), you're not going to get out exactly what you put in, but WASM doesn't really change the situation very much given the widespread adoption of 'compile to JS' languages like TypeScript these days. [0] https://chromium.googlesource.com/external/github.com/WebAssembly/wabt/+/HEAD/wasm2c/README.md https://chromium.googlesource.com/external/github.com/WebAss... [1] https://github.com/wwwg/wasmdec https://github.com/wwwg/wasmdec

flohofwoe 3y ago

Don't get yourself too hyped up, in the end WebGPU is running on the same GPU as WebGL2, and unless your code is CPU bound you won't see performance improvements if your WebGL2 code is already well optimized. And currently some high-frequency WebGPU calls have an even higher CPU overhead than similar WebGL2 calls (I wrote about that here a bit: https://floooh.github.io/2023/10/16/sokol-webgpu.html https://floooh.github.io/2023/10/16/sokol-webgpu.html). WebGPU allows more flexibility of course, compute shaders and storage buffers are more flexible and cleaner than trying to shoehorn the same stuff into vertex/fragment shaders and using textures as "poor man's storage buffer", but that doesn't mean that one approach is slower or faster than the other.

animatethrow 3y ago
Does WebGPU enable a pure 2D game with many sprite animations to not need to pack a texture atlas for best performance? I.e. can I tell the GPU, "Draw these 1000 quads using the following distinct 1000 textures using just this one draw call. I'll be changing the 1000 textures each frame." My experience with OpenGL and D3D11 is that an atlas is the only way to do this. (I've found stb_rect_pack.h to be the least hassle route to packing the atlas.) I started looking at D3D12 and saw that it had command recording but it wasn't clear to me if this is any more efficient for a 2D game than just using D3D11/OpenGL to send 1000 separate pairs of commands to set-this-texture/draw-this-quad. With D3D12 the CPU is still performing thousands of function calls per frame to "record" these commands and I don't see how this is cheaper than having D3D11 do thousands of draw calls. D3D11 just puts a draw call into a command queue and immediately returns so isn't this effectively kinda the same thing as using ID3D12CommandQueue "command recording"? I never got around to benchmarking or learning more, so I'm sure I must be misunderstanding the advantages. I've also noticed that despite D3D12 launching back in 2015, the #1 most used engine Unity is still defaulting to D3D11 and has struggled to make D3D12 as performant/stable. So it seems I'm not the only one who can't figure out how the newer APIs offer more performance.
- flohofwoe 3y ago
  WebGPU currently doesn't support the "bindless" resource access model (see: https://github.com/gpuweb/gpuweb/issues/380 https://github.com/gpuweb/gpuweb/issues/380). The "max number of sampled texture per shader stage" is a runtime device limit, and the minimal value for that seems to be 16. So texture atlasses are still a thing in WebGPU. WebGPU has render bundles, which allow to pre-record command sequences, but even with that you don't want to change resource bindings thousands of times per frame (or even hundreds of times). It might make sense though to build texture atlases dynamically (basically use one very big texture as "tile cache") and update that via writeTexture() calls (just don't rebuild the entire atlas each frame).

troupo 3y ago

> will enable for next generation browser games and real-time 3D web applications Not excited, and very few of those will materialise. Next gen games require next gen graphics. You can check for yourself how much those graphics weigh.