[whatevsmate]

I'm not sure I disagree with you really - and I ack that webgpu feels like 2015 tech to someone who knows their stuff. I don't have a take on "l33t gfx coder"; I'm a hobbyist not a professional, and I've enjoyed getting up to speed with WebGPU over and above my experiences with WebGL. Happy to be schooled.

I've never impl PBF or raytracing because my interests haven't gone that way. I don't find SDFs to be a particularly difficult concept to "study up on" either though. It's about as close to math-as-drawing that I've seen and doesn't require much more than a couple triangles and a fragment shader. By contrast I've been learning about SVT for a couple months and still haven't quite pieced together a working impl in webgpu... though I understand there are extensions specifically in support of virtual tiling that WebGPU could pursue in a future version.

Agreed DevEx broadly isn't great when working on graphics. But WebGPU feels like a considerable improvement rather than a step backward.

[BigJono]

I can give a bit more context as someone that got on WebGL, then WebGPU, and is now picking up Vulkan for the first time.

The problem is that GPU hardware is rapidly changing to enable easier development while still having low level control. With ReBAR for example you can just take a pointer into gigabytes of GPU memory and pump data into it as if it was plain old RAM with barely any performance loss. 100 lines of bullshit suddenly turn into a one line memcpy.

Vulkan is changing to support all this stuff, but the Vulkan API was (a) designed when it didn't exist and is (b) fucking awful. I know that might be a hot take, and I'm still going to use it for serious projects because there's nothing better right now, but the same extensibility that makes it possible for Vulkan to just pivot huge parts of the API to support new stuff also makes it dogshit to use day to day, the code patterns are terrible and it feels like you're constantly compromising on readability at every turn because there is simply zero good options for how to format your code.

WebGPU doesn't have those problems, I quite liked it as an API. But it's based on a snapshot of these other APIs right at the moment before all this work has been done to simplify graphics programming as a whole. And trying to bolt new stuff onto WebGPU in the same way Vulkan is doing is going to end up turning WebGPU into a bloated pile of crap right alongside it.

If you're coming from WebGL, WebGPU is going to feel like an upgrade (or at least it did for me). But now that I've seen a taste of the future I'm pretty sure WebGPU is dead on arrival, it just had horrendous timing, took too long to develop, and now it's backed into a corner. And in the same vein, I don't think extending Vulkan is the way forward, it feels like a pretty big shift is happening right now and IMO that really should involve overhauls at the software/library level too. I don't have experience with DX12 or Metal but I wouldn't be surprised if all 3 go bye bye soon and get replaced with something new that is way simpler to develop with and reflects the current state of hardware and driver capabilities.

[pjmlp]

That is why game studios always went with engines, and never had a drama with APIs like FOSS developers happen to complain all the time.

You get to design a good developer experience, while the plugin system takes care of the optimal API and configuration for each platform.

[cylemons]

Historically, Microsoft didn't have a problem making breaking changes in new D3D APIs so I think they'll be one of the first to make a clean API to leverage the new hardware features

[pjmlp]

Console vendors, 8 and 16 bit computers did it first, even if in many cases it was bare metal programming, that is still an API kind of.

[MintPaw]

If it weren't for the brand new shading language it might have been a step forward. But instead it's further fragmentation. Vulkan runs happily with GLSL, Proton runs HLSL on Linux, SPIR-V isn't bad.

And the new shading language is so annoying to write it basically has to be generated. Weird shader compilation stuff was already one of the biggest headaches in graphics. Feels like it'll be decades before it'll all be stable.

[pjmlp]

While I am also not happy with WGSL, note that GLSL has reached a dead end, Khronos officially isn't developing it any further other than extensions, see Vulkanised 2024 talks/panel.

Hence why NVidia's slang offer was welcomed with open arms.

[socalgal2]

Vulkan does not run GLSL. There are tools that convert GLSL to SPIR-V. That's not the same thing. So, if you want the exact same experience, you grab a tool, say, Slang, and have it output WGSL. Now you've got the same experience. An API that doesn't take a language you want to write in and a tool that converts from some language you do into the other.

[pjmlp]

Only if you don't take tooling into consideration, after a decade of WebGL, there still isn't anything other than SpectorJS and no vendor sees as priority to provide anything beyond pixel debugging.