From GLSL to WGSL: the future of shaders on the Web (2021)

https://dmnsgn.me/blog/from-glsl-to-wgsl-the-future-of-shaders-on-the-web/

by rossant • 2 years ago

40 59 2 years ago

alkonaut4• 2 years ago

This is from 2021 and the main issue the author has with wgsl has long since been fixed. There is a lot less <f32> needed in ~2014~. Edit: in 2024

kookamamie• 2 years ago

But, on the other hand, more time-travel required?

dwattttt• 2 years ago

Not anymore. The time travel issue was fixed with time travel.

davexunit6• 2 years ago

WGSL is easily the worst part of WebGPU, which I like overall. The world did not need another high-level shading language. They could have just used SPIR-V bytecode if it wasn't for Apple sabotage. The GPU API in SDL3, by comparison, has chosen the only sane option and just asks you to pass whatever the native shader format is.

Rusky• 2 years ago

They could not "just" have used SPIR-V bytecode. WebGL already had to do a bunch of work to restrict GLSL's semantics to work in the web sandbox; whatever WebGPU chose would have had the same problem.

mwkaufma3• 2 years ago

WGSL is defined as a "bijection" to a "subset" of spir-v -- they could have simply specced that subset.

modeless3• 2 years ago

In comparison to inventing a new language and three independent interoperable implementations from scratch, I think "just" is appropriate.

johnnyanmac5• 2 years ago

Why am I not surprised that it's Apple that continues to make the world of graphics programming even more difficult than it needs to be.

The GPU API in SDL3, by comparison, has chosen the only sane option and just asks you to pass whatever the native shader format is.

I get why their don't do this, to be fair. That would mean they would need to have a proper parser for a half dozen shader models. Or at least try to promise they will make and maintain others soon.

mwkaufma3• 2 years ago

SDL3 offers a spir-v-cross reference impl as an optional auxiliary library.

davexunit6• 2 years ago

That would mean they would need to have a proper parser for a half dozen shader models.

It avoids this entirely. If you're on a system whose GPU driver only speaks DXBC and you hand it SPIR-V, that would be an error. This is what SDL GPU does. The SDL team conveniently made a small library that can cross-compile SPIR-V to the other major bytecode formats that you can integrate into your build pipeline.

dan-robertson• 2 years ago

I think apple contributed lots of things that make wgpu a nicer api for people. I’m not saying this particular contribution was good, just that it’s not so black and white.

bsder2• 2 years ago

WebGPU was a total surrender to Apple, and Apple still didn't implement it.

Given that Microsoft has also thrown in with SPIR-V and Apple still isn't shipping WebGPU, the next version of WebGPU should tell Apple to fuck off, switch to SPIR-V, and pick up Windows, XBox, and Linux at a stroke.

modeless3• 2 years ago

Apple is implementing it. They are just slow. There's no point in a web standard that Apple won't implement as long as they hold a monopoly on iOS browser engines.

spookie• 2 years ago

The built-ins are named inconsistently, aren't visually any different from other parts of the code, and the change from sets to groups when there are workgroups makes no sense.

All around change for the sake of change.

jsheard2• 2 years ago

All around change for the sake of change.

More like change for the sake of politics, Apple didn't want to use any Khronos IP so the WebGPU committee had to work backwards to justify inventing something new from scratch, despite the feedback from potential users being overwhelmingly against doing that.

Then after sending the spec on a multi-year sidequest to develop a shader language from scratch, Apple still hasn't actually shipped WebGPU in Safari, despite Google managing to ship it across multiple platforms over a year ago. Apple only needs to support Metal.

davexunit6• 2 years ago

Apple has been extremely slow about getting important features into Safari. They're about a year behind Chrome and Firefox on some WebAssembly things, too.

flykespice• 2 years ago

Apple is the epitome of Not Invented Here syndrome.

rahkiin• 2 years ago

I’ve read this is because they are in a legal conflict with Khronos for a while already

jdashg2• 2 years ago

the WebGPU committee had to work backwards to justify

Do you mean to allege "[the Apple delegates to] the WebGPU committee"? Because the committee as a whole has a ton of public minutes that show how strident the opposition to this was. (Probably filed under "This is not a place of honor" :)) I don't even want to re-read what I said at the time. No one involved, literally no one, is happy about that chapter, believe me. We are happy to be shipping something, though.

pjmlp7• 2 years ago

Blaming Apple is cool and all, yet Vulkan also uses GLSL, which WebGPU committee could have kept using for WebGPU, as evolution from WebGL, just like it happened on the OpenGL to Vulkan transition.

andrewmcwatters2• 2 years ago

Man, since the departure from OpenGL/OpenGL ES, graphics programming is such a pain in the butt. It's totally unfun and ridiculous.

01HNNWZ0MV43FF• 2 years ago

I finally switched to WebGL 2, I think, to get nicer shadow maps. I'll ride that as far as I can. personally I liked gles2 a lot. Everything ran it.

davexunit6• 2 years ago

The fragmentation has been really frustrating but if things like WebGPU and SDL GPU become well supported it will make doing modern graphics programming mostly pleasant. I love/hate OpenGL and will miss it in a strange way.

jms554• 2 years ago

What part do you dislike? If it's the complexity of newer APIs (Vulkan in 8 years old at this point, DirectX12 9 years), then you might like WebGPU or any of the other userspace graphics APIs such as blade or sdl3 that have been invented over the past few years.

unconed• 2 years ago

Not OP, but IMO the real issue is pretending graphics is still about executing individual draw calls of meshes which map 1-to-1 to visible objects.

It's not true anymore, because you have all sorts of secondary rendering (e.g. shadow maps, or pre-passes), as well as temporal accumulation. These all need their own unique shaders. With meshlets and/or nanite, culling becomes a cross-object issue. With deferred rendering, separate materials require careful set up.

So now the idea that a dev can just bring their own shaders to plug into an existing pipeline kind of falls apart. You need a whole layer of infrastructure on top, be it node graphs, shader closures, etc. And dispatch glue to go along with it.

This is all true even with WebGPU where you don't have to deal with synchronization and mutexes. Just a shit show all around tbh. Rendering APIs have not kept up with rendering techniques. The driver devs just threw up their hands and said "look, it's a nightmare to keep up the facade of old-school GL, so why don't you do it instead".

johnnyanmac5• 2 years ago

That's more or less how graphics programming evolved over the last 20 years. Give up conviniences for the more performance, using as much control as GPU vendors would allow. It's basically inaccessible unless you're studying it in academia or employed in the few domains that require that power.

This also sadly means that most tools to help navigate these are probably also trapped in some studio codebases. I remember those promises with Vulkan 1.0 where you could potentially just wait until others would make some boilerplate abstraction so other could learn graphics programming before diving deep down into every nitty gritty detail. I haven't looked extensively for that, but nothing came on my radar while navigating through learning Vulkan.

alkonaut4• 2 years ago

Not at all. OpenGL had that get-something-done quickly feel but it was riddled with limitations and unnecessary complexity.

DX12/Vulkan means you do 2000 lines of boilerplate to get anywhere.

WebGPU is actually a nice step back towards OpenGL. You can get off the ground much faster, while still being modern in the way the APIs work.

jesse__• 2 years ago

Fuck me .. as if we needed another shading language.

beeflet3• 2 years ago

WGSL seems to inherit a more rust-like syntax versus GLSL which is similar to C.

I think the major advantage of WebGPU over WebGL2/OpenGLES3 is that you can write GPGPU shaders more easily versus OpenGL's Transform Feedback system which is very clunky. But this comes at a tradeoff of compatibility for the time being.

But in the rust ecosystem at least, WebGPU has taken the role of OpenGLES with libraries like wgpu becoming dominant.

pjmlp7• 2 years ago

Which is kind of bonkers, settling down on an API designed for sandboxed browser enviornments that isn't able to expose the actual capabilities of any graphics card designed after 2016.

From GLSL to WGSL: the future of shaders on the Web (2021)

Related Stories