One unique and new feature of Slang that sets it apart from existing shading languages is support for differentiation and gradient computation/propagation - while still cross-compiling generated forward and backward passes to other, platform-specific shading languages.
Before, the only way to backpropagate through shader code (such as material BRDF or lighting computation) was to either manually differentiate every function and chain them together, or rewrite it in another language or framework - such as PyTorch or a specialized language/framework like as Dr.Jit, and keeping both versions in sync after any changes.
Game developers typically don't use those, programming models are different (SIMT kernels vs array computations), it's a maintenance headache, and it was a significant blocker for a wider adoption of data-driven techniques and ML in existing renderers or game engines.
The design of generics in this one seems rather well balanced in simplicity vs power.
The part about interface-typed values [1] is interesting. They do dynamic dispatch as a fallback when the function is too polymorphic to be be specialized.
In Rust terms it's as if it picks between `dyn` and `impl` automatically. It looks convenient, but also a bit of a non-obvious performance pitfall.
It seems like the type checker could call out polymorphic functions both when compiling and even highlighting them in the editor when checking for type errors.
I've been very impressed by Slang as an open source project. The development team is quick to respond to issues and review pull requests. It's clear from their repository and their presentations that they take Slang seriously as a user-facing project, not a research demo.
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.
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.
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.
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.
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.
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.
I have to wonder how this fits in with other shader technologies that seem to have overlapping purposes. (There's Khronos' own Spir-V, SDL's SDLSL, Three's TSL, and WebGPU's WGSL)
The reflection and automatic differentiation look interesting, I just wish I understood better what problems they're trying to solve.
I actually think WebGPU/WGSL will and should become ubiquitous, though it's a shame it's not more C/GLSL-like, Slang may yet be a missing part of that solution.
I wonder if this is Khronos trying to fix the shader lang debacle with Apple that led to WGSL being what it is?
Thoughts?
- the frontend language is mostly compatible with HLSL, which is the defacto shader authoring standard in the gamedev industry
- it compiles to the 'shader language/bytecode zoo' of the different 3D APIs (since recently even WGSL/WebGPU)
So it lets you author your shaders in a single language that's already accepted by most of the industry, and target the various 3D APIs (D3D, Metal, GL, WebGPU, ...).
It is already possible to build such a tool yourself by glueing together existing libraries (like glslang, SPIRVTools, SPIRVCross and Tint), but it requires quite some work and there are little annoying details like SPIRVCross never supporting WGSL output for some non-technical reasons (so that you need a separate library like Tint just for the SPIRV-to-WGSL conversion). In fact there are tons of such engine-specific shader cross-compilers, all built around the same few Khronos libraries and doing more or less the same thing. Slang looks like it could be the standard replacement for all those custom solutions.
For my own needs, the main thing I'll need to investigate is how easy it is to add engine-specific custom annotations to Slang resources and then output those as part of the reflection information.
In my very limited experience: In addition to cross-compiling, you want additional features that WGSL doesn't provide if you want to compose shaders, so you'd end up with a tool like naga-oil [1] or wesl anyways.
Thanks.
Yes I do tend to overlook HLSL, despite being a windows user and a game developer, I tend to focus on gfx technologies that come out of Khronos and the W3C.
Slang does look a lot like GLSL, I am trying to get used to WGSL at the moment and it's slow going.
It does!
Both platform-specific compute shaders as well as cross-compilation to CUDA. The authors even provide some basic PyTorch bindings to help use existing shader code for gradient computation and backpropagation in ML and differentiable programming of graphics-adjacent tasks: https://github.com/shader-slang/slang-torch
(Disclaimer: this is the work of my colleagues, and I helped test-drive differentiable Slang and wrote one of the example applications/use-cases)
Don't we already have a shader language with Rust-syntax in WGSL?
It also works everywhere, given that WebGPU works wherever Vulkan, Metal & DirectX do...
One problem with WGSL is that the binding annotations (e.g. @group and @binding) are closely tied to the WebGPU resource binding model via BindGroups, but doesn't match other 3D APIs (except Vulkan's descriptor sets maybe). Don't know how Slang solves this problem though (e.g. if it is HLSL compatible it might suffer from the same problem - just with D3D's resource binding model).
WGSL will also always only cover the WebGPU feature set, which is very conservative by definition (e.g. no modern features like mesh shaders, raytracing, etc...). Again, I don't know how much of this Slang provides though.
...which is only a problem on Linux though (turns out that system-wide shared locations for headers and linker libraries are not a great idea). Most Slang users will probably be on Windows, and apart from that there's also most likely not much overlap with S-Lang users.
