[adastra22]

Care to give an example? From my viewpoint as a WebGPU user, we consistently get access to new GPU features with every refresh. E.g: https://developer.chrome.com/blog/webgpu-io2023

You just have to set limits correctly when you initialize a GPU instance in order to have access to the new features.

[pjmlp]

Mesh shaders, raytracing, DirectStorage, GPU work graphs, C++ features on shading languages, some of the post 2015 features that aren't coming to WebGPU any time soon.

[adastra22]

The features you mention are mostly applications of compute shaders, which are fully capable of being written in WebGPU, as WebGPU supports buffer -> buffer compute shaders when the underlying GPU supports it.

I've personally implemented mesh shaders in my own project, and there are plenty of examples of WebGPU real time raytracers out there. DirectStorage I had to google and it looks like a Windows DMA framework for loading assets directly to GPU ram? That's not even in scope for WebGPU, and would be handled by platform libraries. Linux has supported it for ages.

Seriously I get the impression from your posts that really don't have any experience with WebGPU at all, and are basing your understanding off of misinformation circulating in other communities. Especially with your continued nonsensical statements about not supporting "post-2015 features." 2015-era chipsets are a minimum supported feature set, not a maximum.

Please just take the L and read up to inform yourself about WebGPU before criticizing it more.

[pjmlp]

I bet those implementation of yours weren't done in WebGPU actually running on the browser, otherwise I would greatly appreciate being corrected with an URL.

DirectStorage started as a Windows feature, is actually quite common in game consoles, and there is ongoing work to expose similar functionality in Vulkan.

Yes, I do have WebGPU experience and have already contributed to BabylonJS a couple of times.

Maybe I do actually know one or two things about graphics APIs.

[adastra22]

WebGPU is not a browser API. It is a lower level API with official, supported implementations in C++ and Rust with zero browser dependencies. See for example:

https://dawn.googlesource.com/dawn

https://eliemichel.github.io/LearnWebGPU/

Yes it is exposed to Javascript applications by browsers that support it, much like WebGL exposes OpenGL ES. But that’s a separate thing.

[mschuetz]

Apart from the examples given by the other user: 64 bit integers and their atomics which are the bread and butter of efficient software rasterizers such as Nanite, or for point clouds which can be rendered multiple times faster with 64 bit atomics compared to using the "point-list" primitive; subgroup operations; bindless; sparse buffers; printf; timestamps inside shaders; async memcpy and copy without the necessity for an intermediate copy buffer and so much more. One of the worst is that they're adding limitations of all languages, but not the workarounds that may exist in them. Like WebGPU actively prohibits buffer aliasing or mixing atomic and non-atomic access to memory because of Apple's Metal Shading Language, but Metal supports it via workarounds! I mean... seriously? That actually makes WebGPU even worse than the lowest common denominator.

One of the turning points for the worse was the introduction of WGSL. Before WGSL, you could do lots of stuff with spirv shaders because they weren't artifically limited. But with WGSL, they went all in on turning WebGPU into a toy-language that only supports whatever last decades mobile phones support. I was really hopeful for WebGPU because UX-wise, it is so much better than anything else. Far better than Vulkan or OpenGL. But feature-wise, WebGPU so limited that I had to go back to desktop OpenGL.

In one way WebGPU really has become a true successor to WebGL though - it is a graphics API that is outdated on arrival.