Hi @haehn!

When WebGPU will be available everywhere is unfortunately a somewhat complicated thing to figure out. The biggest hurdle for that is for every major browser to enable it by default, and while Chrome has done that (mostly*) Firefox and Safari are still implementing the feature. To my knowledge those teams have not given any estimated dates for when they expect to ship WebGPU support, and I won't speak for them. I can say, however, that they are actively working on their implementations and making great progress! I would not expect a years-long gap between browsers in terms of support like we saw with WebGL initially.

*Chrome has shipped WebGPU on Windows, Mac, and Chrome OS, as well as some Android devices (Android 12+ with a Qualcomm or ARM GPU.) Linux and expanded Android support are planned but we do not have a timeline for when we expect to ship.

Even when WebGPU has shipped in all major browsers, however, there will still be hardware where it is not supported. See #1069 for the most up-to-date information on WebGPU's expected OS and hardware compatibility. We expect that WebGPU will quickly cover the majority of devices, but that there will be a long tail of older hardware that isn't capable enough which gets smaller as time goes on.

You can check https://web3dsurvey.com/webgpu to get a rough sense of how much of the web ecosystem currently supports WebGPU.

In terms of OpenGL limitations, WebGPU provides solutions for some of the concerns you mentioned. State based recompiles and expensive error checking, for example, are either eliminated or greatly improved by WebGPU's API shape. Most state is encapsulated in pipeline objects, for example, which prevents the need for drivers to do "silent" compliations when new state combinations are encountered. (This is a pattern adopted from the modern GPU APIs). Similarly, error handling in WebGPU does not require the blocking getError() pattern that WebGL/OpenGL used, which was very disruptive to GPU pipelining and could severely impact performance. I wrote about using WebGPU's new asynchronous error handling APIs here, if you'd like to read more about it.

I'm not sure what you are referring to by sync tracking, that could mean one of several things in this context. I will say, though, that explicit memory tracking and synchronization of the type that Vulkan uses is not part of the API. This is largely because not all modern APIs (specifically Metal) support the same level of memory management and WebGPU needed to be able to wrap all of them. As such we handle some level of memory management and synchronization internally, though developers still have quite a bit of control over the creation of buffers, textures, and other resources.

By TBR I assume you mean Tile-Based Rendering, to which it's difficult to say that it's "solved" (in WebGPU or native APIs), but WebGPU's render pass design should be more friendly to tile-based systems. We don't have a Vulkan-style subpass system, on advice from GPU vendors that they were rarely used and difficult to use correctly.

As for line rendering, WebGPU does support line primitives. It does not currently have any mechanisms, however, for controlling line width, and as such all lines will rasterize as 1px wide. This limitation existed is WebGL as well, and is in place because of lacking support of wide line rendering across the various backends that WebGL/WebGPU need to operate on top of. Besides, we find that most people that want wide line rendering also have specific needs in terms of how things like end caps are rendered, which is not something that the native APIs typically provide control over. If wide lines are needed the recommendation is to render them with triangles so that you have full control over their appearance.

Hopefully that addresses your questions, and feel free to ask if you'd like more informations about a specific subject!