6 ms·
From GLSL to WGSL: the future of shaders on the Web (2021)
- alkonaut 2y agoThis 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 2y agoBut, on the other hand, more time-travel required?
- dwattttt 2y agoNot anymore. The time travel issue was fixed with time travel.
- davexunit 2y agoWGSL 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 2y agoThey 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.
- mwkaufma 2y agoWGSL is defined as a "bijection" to a "subset" of spir-v -- they could have simply specced that subset.
- MindSpunk 2y agoI do not believe this is true anymore and WGSL is a "real language" now that actually requires a "real language frontend" to compile. The original spec didn't even have while loops, they expected you to effectively write the SSA graph by hand (because SPIR-V is an SSA IR). Then the design drifted as they kept adding pieces until they accidentally made an actual language again.
- pjmlp 2y agoThat was the original plan, then they created their Rust inspired language instead.
- mwkaufma 2y agoYeah exactly, that's why refusing to simply spec the bytecode at the time was exactly the sabotage that everyone called it out as.
- modeless 2y agoIn comparison to inventing a new language and three independent interoperable implementations from scratch, I think "just" is appropriate.
- johnnyanmac 2y agoWhy 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.
- mwkaufma 2y agoSDL3 offers a spir-v-cross reference impl as an optional auxiliary library.
- modeless 2y agoAlso DirectX is adopting SPIR-V, so that will help in the future as well. Yes, it's true! https://devblogs.microsoft.com/directx/directx-adopting-spir-v/ https://devblogs.microsoft.com/directx/directx-adopting-spir...
- NekkoDroid 2y agoDXC can already compile to SPIR-V (with some missing features/limitations IIRC), this just effectivly replaces DXIL with SPIR-V in future shader models and makes it THE language the compiler speaks. They are also slowly but surely porting their DXC compiler (forked from Clang 3.6 I think) to upstream Clang.
- vrighter 2y agoIt's not a question of whether it can compile to spir-v, but a question of whether dx12 can consume spir-v
- davexunit 2y 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.
- bsder 2y agoWebGPU 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.
- modeless 2y agoApple 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.
- bsder 2y agoJust like Microsoft was slow about web standards in IE6. <rolls eyes> Tell Apple to fuck off and roll it out--designers will flock to Teh Shiny(tm). When enough designers can't run their glitzy web thing, Apple will cave.
- vetinari 2y agoGoogle and Mozilla are also pretty slow. Google still doesn't support it on more than some SoCs on their own Android, leaving the bulk of the market unsupported, never mind Linux. Mozilla also got lost somewhere.
- johnnyanmac 2y agoYeah, they weren't much faster with adopting WebGL nor Vulkan nor OpenGL ES either (even if it did indeed suck). Something tells me the business incentive isn't there as much for high performance on the web compared to desktop nor even mobile (which is starting to increase demand as Asia makes more AAA esque games for mobile). It's also not like advancement has been a priority for tech this decade so far.
- pjmlp 2y agoLets put it this way, a decade after WebGL 1.0, still there aren't any usable developer tools on browsers to sanily debug 3D rendering. To the point most studios would rather use something like streaming, where at least they enjoy the convenience of tooling like RenderDoc, PIX, Instruments, NInsight,....
- spookie 2y agoThe 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.
- jsheard 2y 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.
- davexunit 2y agoApple has been extremely slow about getting important features into Safari. They're about a year behind Chrome and Firefox on some WebAssembly things, too.
- jsheard 2y agoSafari's limitations are baffling sometimes, like it's the only browser that doesn't support SVG favicons aside from a non-standard monochrome-only variant. Their engine supports SVG, just not in that context, and you'd think they would be all over resolution independent icons given their fixation on extremely high DPI displays.
- pjmlp 2y agoOn the other hand, they are the only wall left standing between the old Web and ChromeOS everywhere.
- flykespice 2y agoApple is the epitome of Not Invented Here syndrome.
- andrewmcwatters 2y agoMan, since the departure from OpenGL/OpenGL ES, graphics programming is such a pain in the butt. It's totally unfun and ridiculous.
- 01HNNWZ0MV43FF 2y agoI 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.
- deleted 2y ago[deleted]
- davexunit 2y agoThe 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.
- deleted 2y ago[deleted]
- seivan 2y ago[dead]
- jms55 2y agoWhat 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 2y agoNot 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".
- jesse__ 2y agoFuck me .. as if we needed another shading language.
- beeflet 2y agoWGSL 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.
- pjmlp 2y agoWhich 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.