In my view, WebGPU is the future of cross-platform graphics. I wrote about this and why we chose it for a game engine we're developing in Zig[0]
It's the one API that Mozilla, Google, Microsoft, Apple, and Intel can all agree on. Nvidia and AMD are silent, but it's on top of Metal/DirectX/Vulkan behind the scenes so they don't really need to care.
Today, Vulkan with MoltenVK (for Apple devices) has more _features_, but even that is not super clear-cut. For example, mesh shaders are supported on AMD cards in DirectX 12 but not Vulkan.
It's not just Apple who continues to push their own API, either. DirectX 13 is likely coming soon, and from what I understand Vulkan gets "ported" features after they land in DirectX.
If you want bleeding edge features, you're going to need to use the native API: Vulkan on Linux, DirectX on Windows, and Metal on Apple.
But if you just want the common denominator? WebGPU native isn't a bad choice IMO. And it being a cleaner API than Vulkan may mean you need less abstraction on top to work with it.
Yes, if you need a cross platform graphics API with maximum compatibility today, an OpenGL ES 2.0 context provided by ANGLE is what you should use (or ES 3.0 if dropping support for very old hardware is OK). Not only does ANGLE have very wide platform support, including platforms that don't natively support OpenGL ES, but it will behave the same everywhere, which is something even OpenGL has always struggled with when using platform/driver implementations instead of ANGLE (check out Chromium's list of driver bug workarounds: https://chromium.googlesource.com/chromium/src/+/HEAD/gpu/co...). And ANGLE is used by all three major web browsers in their WebGL implementations so it is guaranteed to be maintained essentially forever.
Eventually WebGPU will get there too, but it will take time.
Google's native implementation of WebGPU, Dawn, has DirectX/Metal/Vulkan backends, as well as fallback to OpenGL when not available. So it's already ubiquitous today, you just can't use it in the browser (yet)
Right. Nintendo cares about NVN[0], the lower level API for the Switch (not Vulkan, which they added much later as an option)
Sony cares about GNM and their custom shader language PSSL[1]. Seems unlikely they'll support Vulkan anytime soon either.
Arguably, it is more likely WebGPU will continue to have a reasonable translation to these platform's native APIs compared to Vulkan, given that WebGPU is the common denominator between Vulkan/Metal/DirectX.
That's not to speak of the market pressures having a large swath of browser-based games written with WebGPU would have in encouraging Nintendo/Sony to care about these.
It's the one API that Mozilla, Google, Microsoft, Apple, and Intel can all agree on. Nvidia and AMD are silent, but it's on top of Metal/DirectX/Vulkan behind the scenes so they don't really need to care.
Today, Vulkan with MoltenVK (for Apple devices) has more _features_, but even that is not super clear-cut. For example, mesh shaders are supported on AMD cards in DirectX 12 but not Vulkan.
It's not just Apple who continues to push their own API, either. DirectX 13 is likely coming soon, and from what I understand Vulkan gets "ported" features after they land in DirectX.
If you want bleeding edge features, you're going to need to use the native API: Vulkan on Linux, DirectX on Windows, and Metal on Apple.
But if you just want the common denominator? WebGPU native isn't a bad choice IMO. And it being a cleaner API than Vulkan may mean you need less abstraction on top to work with it.
[0] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...