> I'm not convinced by any of these arguments about "knowing how to program in WebGPU". Graphics 101 benchmarks are the entire point of a GPU.

You're totally right that it's the same hardware, but idiomatic use of the API can still affect performance pretty drastically.

Historically OpenGL and DX11 drivers would try to detect certain patterns and fast path them. Modern graphics APIs (WebGPU, Vulkan, DX12, Metal) make these concepts explicit to give developers finer grained control without needing a lot of the fast path heuristics. The downside is that it's easy to write a renderer targeting a modern graphics API that ends up being slower than the equivalent OpenGL/DX11 code, because it's up to the developer to make sure they're on the fast path instead of driver shenanigans. This was the experience with many engines that ported from OpenGL to Vulkan or DX11 to DX12: performance was roughly the same or worse until they changed their architecture to better align with Vulkan.

Simple graphics benchmarks aren't a great indicator for relative performance of graphics APIs for real use cases. As an extreme example, rendering "hello triangle" for Vulkan vs. OpenGL isn't representative of a real use case, but I've seen plenty of people measure this.

Mostly because their drivers suck, and don't get updates.

Android 10 made Vulkan required, because between Android 7 and 10, most vendors didn't care, given its optional status.

Android 15 is moving into OpenGL on top of Vulkan, because yet again, most vendors don't care.

The only ones that care are Google with their Pixel phones (duh), and Samsung on their flagship phones.

There is also the issue that by being NDK only, and not having managed bindings available, only game engine developers care about Vulkan on Android.

Everyone else, devs would still have better luck targeting OpenGL ES than Vulkan, given the APIs and driver quality, which isn't a surprise that now Google is trying to push for a WebGPU subset on top of OpenGL ES.