Hacker News Reader

Comment by pjmlp | Hacker News Reader

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.

View on HN

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

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/

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 :)

Interesting, does it work on the browser, or wgpu?

I've only ever tested it in wgpu, but there's no reason it shouldn't work in the browser (WebGPU). It only needs compute shaders, storage buffers, and single indirect draws, which are all available in WebGPU.

I see, thanks. Maybe I should not be so negative about it. :)

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?

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

[2] https://registry.khronos.org/vulkan/specs/1.3-extensions/man...

[3] https://registry.khronos.org/vulkan/specs/1.3-extensions/man...

[4] https://registry.khronos.org/vulkan/specs/1.3-extensions/man...

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.

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.

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.

Reply on news.ycombinator.com