Hacker News Reader

Comment by coffeeaddict1 | Hacker News Reader

I hope this becomes the standard way of writing shaders across all platforms. There is no compelling reason for having to use WGSL, HLSL, GLSL or Metal C++. Having one single feature-complete language is a huge QoL improvement.

View on HN

Nobody is using all these languages at the same time, anyone who targets all these platforms already has some mechanism to turn HLSL or GLSL (or whatever) into what the target platform needs. That's why Slang will have difficulty finding adoption, it's the N+1th solution to a problem that already has been solved N times.

> anyone who targets all these platforms already has some mechanism to turn HLSL or GLSL (or whatever) into what the target platform needs

Slang provides a standard and open source solution that's better and more featureful than those custom solutions.

For a greenfield project, perhaps that makes it a good choice, but using it to replace established systems needs more arguments than "it's better". Is it really better than a existing, bespoke solution? Keep in mind that the shader language is just one part of targeting a graphics API, you still need a lot of boilerplate surrounding it and Slang doesn't (and probably shouldn't) solve that problem.

I see your point, but one issue is that you can't go from HLSL or GLSL to WGSL for compute work, as the way atomics are typed is incompatible[1]. That's a primary reason we (currently) use WGSL, because going from that to legacy shader languages does work. But then you have all the limitations of WGSL.

Slang had to make a change to its type system[2] to make this work. But they did it, and as a result Slang is appealing as an "apex" language - you can translate from that to anything, and also get advanced features lacking in WebGPU.

[1]: https://github.com/gpuweb/gpuweb/issues/2377

[2]: https://github.com/shader-slang/slang/issues/5084

RetroArch uses all of them. HLSL, GLSL, Vulkan, Slang, Cg as well as proprietary shader formats used on consoles, as some platforms only support specific formats, so they often convert between all of them to offer as many shaders as possible across all combinations of platforms.

But one of their big contributors also worked on Vulkan and Slang/SPIR-V itself if I recall correctly (and works at ARM on GPU drivers), so there's that.

Retroarch can ingest GLSL, Cg, and its own extension of GLSL it calls "Slang shaders." Cg is deprecated. It uses SPIRV-Cross, the de facto solution to transliterate to other APIs. The "slang" in this article is an entirely different "slang".

The guy who created Retroarch, Themaister, seems to work for Valve now, and continues to work on SPIRV-Cross among other things, making gaming on Linux actually viable.

I think there is a compelling reason to have WGSL as a separate language (but maybe not sufficiently compelling): WebGPU is a lowest common denominator which can only have features which are in the intersection of its target platforms, and so WGSL has no “dead syntax” to memorize. If the language spec says it’s there, you can use it, and you won’t find examples online of code that just won’t work in WebGPU because of missing features.

Of course, the f16 extension immediately weakens that, and demonstrates that this situation probably won’t last.

It must not last, because any API that is the common denominator between 10 year old mobile SOCs and current year high end desktop GPUs is doomed to do injustice to either platform.

The only way for it to last would be for browsers to compile into some kind of compatibility layer for newer GPU features on older hardware, but that’s probably going to be extremely tough to do in some cases without killing performance on the older platforms, particularly if those features relate to things like synchronization.

Newer mobile GPUs worth a damn pretty much have the same feature set as desktop.

Except texture formats in case of Mali and Exynos w/ RDNA. But QCOM (since quite a while) and Apple (E17+) have a unified set there including BC7 support.

So perhaps split things into profiles, with a more modern profile where the only thing varying is texture format support.

What is missing from GLSL?

It depends on your needs, but there's a reason why HLSL took over GLSL. HLSL provides enums, templates, namespaces and many other QoL improvements that GLSL didn't get.

I for example really welcome Slang's support for automatic differentiation.

Reply on news.ycombinator.com