|
Top-level
 @mcc Interesting blog post! I'm doubtful that WebGPU replace Vulkan in the sense that it adds a fair bit of overhead for the various safety checks, etc, and game engines, middleware, etc that are concerned about performance and/or access to the latest hardware features will want to avoid this abstraction. I think it's more likely to replace OpenGL for software that wants a more modern GPU interface with a bit more safety, simplicity, and portability than Vulkan. 4 comments
 @mcc It sounded like that could be doable and I thiiink one of the implementations has a performance mode that does something like that. It's still an adapter layer on top of Vulkan (or a comparable lower level API), and at least the Chrome library for it looked pretty hefty at a glance. My suspicion is that big game engines, etc, would not see value in adding a simplifying layer that is more restrictive. For smaller apps, portability and simplicity could outweigh a bit of overhead. @mcc Of course if your goal is "run in browsers", it's a win, and if you want to run in browsers and elsewhere and are not looking for getting that last couple percent of performance and don't need the latest shiny API/extension-wise, it's pretty appealing to adopt as your GPU abstraction. I just don't think it's likely to replace Vulkan for most engine/middleware use. |
Gregory's Server
@mcc In particular, Vulkan just recently introduced Shader Objects which allow users to avoid the "have to build up entire pipelines at once" issue, more efficiently bind engines to GPU activity, mix and match shaders, and avoid some of the more expensive shader (re)compilation issues. WebGPU seems to be pretty firmly designed around the original Vulkan configure-the-whole-pipeline-at-once approach.