Post B14bqUK7DeqxKck4qe by crzwdjk@mastodon.social
 (DIR) More posts by crzwdjk@mastodon.social
 (DIR) Post #B14bqRNu976MDVUYq0 by mcc@mastodon.social
       2025-12-08T18:47:40Z
       
       0 likes, 0 repeats
       
       (I'm writing WebGPU code)Me: I cannot BELIEVE that Apple is forcing me to use WGSL. This is an OUTRAGE and I will NEVER FORGIVE THEM(I'm writing SDL3 or literally any other that is not WebGPU)Me: Hey can I use WGSL with this(I am a cat?)
       
 (DIR) Post #B14bqStqVqFIurRaGO by lynne@mk.pars.ee
       2025-12-08T19:01:08.827Z
       
       0 likes, 0 repeats
       
       @mcc@mastodon.social I too get thoughts like these, because I hate GLSL with a passion larger than the force of a thousand suns.But WGSL doesn't have pointers, so its useless to me.
       
 (DIR) Post #B14bqUK7DeqxKck4qe by crzwdjk@mastodon.social
       2025-12-08T21:26:24Z
       
       0 likes, 0 repeats
       
       @lynne What exactly do you hate about GLSL and is there a way the language could be improved such that you would hate it less?
       
 (DIR) Post #B14bqV5yLj8Nj38IRU by lynne@mk.pars.ee
       2025-12-09T00:22:52.991Z
       
       1 likes, 0 repeats
       
       @crzwdjk@mastodon.social Its a very locked down language made from nearly 30 years of accumulated crud. - The tooling is horrible. glslang is very orientated towards compiling files, not for runtime use. Before we patched it a few years ago, its init was not threadsafe. The library is massive, has many dependencies, has no concept of stable APIs, its slow, sometimes it crashes, and it still has global state. Its C++/C APIs are not kept in sync or maintained in the same way. - You cannot just precompile SPIR-V chunks and glue them together during link-time. This is the majority of what we do. Slang is able to, but slang is extremely orientated towards being directly embedded, having no language stability, and is far too massive to statically link into FFmpeg. - bitfield operations (bitfieldExtract and others) are 32-bit signed/unsigned ints only. - Features locked behind kernel mode, such as pipes. Why make a single unified IR language and then lock features out of what you actually want to use?! - cooperative matrices have the worst syntax possible - Good luck figuring out how to use 16-bit floats. Its very annoying. - I don't like how there's a lack of automatic demotion. I know whether a statement will overflow or not. Don't make me explicitly force casts. And don't make immediate values integers by default: uint8_t i = uint8_t(0) is awful to write over and over again.
       
 (DIR) Post #B14bwdDZ3yzqedbj28 by crzwdjk@mastodon.social
       2025-12-09T03:06:37Z
       
       0 likes, 0 repeats
       
       @lynne Thanks, that's good feedback. We have been working on having a more reasonable API surface for glslang and I really want to make separate compilation more of a thing for GLSL where you can compile chunks separately and link SPIR-V files. There's actually a spirv-link tool and a way to use it with glslang but it was never really meant for public use. Feel free to file issues, I can't promise anything but at least we'll have a record that someone wants this.
       
 (DIR) Post #B14bwedplnbV4OuDcO by crzwdjk@mastodon.social
       2025-12-09T03:12:44Z
       
       0 likes, 0 repeats
       
       @lynne With both glslang and the GLSL language itself it feels like there's a lot of users just suffering in silence, I would really love to move the language forward but it's hard to make a case for it because it seems like there isn't demand, but it might only seem that way because people figure nothing will happen. And there's a lot of structural history for how it ended up this was. Gotta try to build a community somehow now that IHVs don't care about GLSL anymore.
       
 (DIR) Post #B14bwfut1sq31ZtLpw by lynne@mk.pars.ee
       2025-12-09T13:23:08.684Z
       
       1 likes, 0 repeats
       
       @crzwdjk@mastodon.social There's no one really bending it in the same way we do by writing encoders and decoders in it. Nor by constructing shaders during runtime.Me and the maintainer of libplacebo have been so fed up with it that we started to write our own SPIR-V assembler with a C API just to escape it. We're pretty used to writing assembly in FFmpeg.Originally, we planned to take the whole GLSL->NIR->SPIR-V pipeline that Zink uses, and make that into its own library, but its quite large, and still in flux.glslang is also a big pain for distributions to package and users to link against. There's no pkg-config file (...because of course there isn't, projects like these never have pkg-config files), so users need to maintain a list of hardcoded library names and update them.That's why we need stuff like: https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/f1e9032a2000b8b885cffd6fed8eacd47b37673f occasionally. Distributions sometimes make up a pkg-config file (Debian) for glslang, but its never kept up to date either.Literally having a pkg-config file would be an immediate improvement. There's already an issue open: https://github.com/KhronosGroup/glslang/issues/1715