> - "Use this game engine or this old and outdated graphics library instead"
That is the actual answer for when people ask that question, most of the time. Almost nobody is asking for a raw GPU API, which is what Vulkan, DX12, and WebGPU are. Rather they want a graphics API. Something that provides utilities and helpers. Something that can actually load textures, models, and animations. Or has a particle effect system.
But if all you want is a GPU API, as I mentioned far higher up in the thread there's no shortage of those today either (like bgfx, or even Angle). 'native' WebGPU isn't addressing some unserved market here.
Although if you actually do want a GPU API, there's also a good chance you actively don't want to use a middleware like WebGPU since it limits what you can do and gets in the way...
bgfx is definitely a competitor in that sense. However, it doesn't have the same backing, is not standardized, and would have a hard time building momentum due to that.
I'm mostly thinking of indie game devs who decide to write their games from scratch (which still happens, though it's becoming rare), or up-and-coming game engines such as Bevy. They might not have a team who can spend the time optimizing Vulkan (while also making sure MoltenVK runs it fine, if they want to target MacOS), and might prefer something more modern than OpenGL.
>WebGPU since it limits what you can do and gets in the way
>Castrated by the security constraints of being a MVP 1.0 API to fit into the security sandbox of a Web browser.
What security contraints are you thinking of which are making it castrated? In what meaninful ways is it castrated?
> In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
So with Qt, can I write a complete renderer with advanced techniques, and have it run on all 3 platforms without changing a single file? If not, how is it relevant to even mention?
Here is a little secret, thanks to extension spaghetti and driver bugs, there is seldom "without changing a single file" unless it is some toy app, instead of being used across all possible consumer hardware.
Plus you are focusing too much on Qt while being defensive for WebGPU on native deployments, there are plenty of other middleware I can use as example.
What are you talking about? Are you saying that https://doc.qt.io/qt-6/qsgmaterialshader.html is less "castrated" than WGSL ? Doesn't look like it. I don't even see the spec, it only says "Vulkan-style GLSL"
>Here is a little secret
Google and Apple definitely have more resources to spend standardizing WGSL (WebGPU has a Conformance Test Suite) than whoever owns QT this time of the year.
> while being defensive for WebGPU on native deployments
Because I still haven't heard a single argument against it from you that isn't extremely vague and handwavey.
For example, you skipping over my questions regarding more details on what you think makes WebGPU bad/castrated, or what is making Qt the better choice over WevGPU? (ignoring the fact that Qt doesn't seem to have a common shader language)
I'm open to hear the reasons, but it seems like your goal is to be contrarian.
Castrated how? A single digit performance loss compared to the most extremely complex graphics APIs which aren't properly cross-platform?
>Want Vulkan/DX12/Metal without boilerplate?
>Just use Ogre or Godot, among endless other options.
"I want a graphics API!"
- "Use this game engine or this old and outdated graphics library instead"
>Even Qt is better than what WebGPU is capable of.
Ah, is it? Do you have any example of implementing forward+ rendering in pure Qt? No? What about GPU compute? Not that either?