I poked around a bit on their docs site [1] to get a feel for the language, and these two features stood out to me:
> - Interfaces and generics provide first-class alternative to hacky preprocessor-based or string-pasting shader specialization. Preprocessor hacks can be replaced with a well-understood language feature already used in Rust, Swift, C#, Java, and more.
> - Automatic differentiation greatly simplifies the implementation of learning-based techniques in shaders. Slang supports automatically generating both forward derivative and backward derivative propagation functions from forward computation code.
> - Slang supports a first class module system, which enables true separate compilation and semantic checking of shader code.
I am a total beginner at shaders, but when I've dabbled in them they are mostly surrounded by string concatenation and a variety of wild macros, so it's cool to see a "typescript for shaders" with such broad support, both of vendors, and of target shader languages.
[1]: https://shader-slang.com/slang/user-guide/introduction.html
I have a use case for slang, I want to use it to transpile user provided shaders to WGSL and then use it's custom user attributes to provide metadata for setting up composable image processing shaders with minimal developer intervention, like shader toy or compute toy. The thing that is making this annoying is that the tooling is very bound to C++. Has anyone found a good rust wrapper for slang?
I wish these people would make up their own names instead of using what already is in use :)
At first I thought it was S-lang used in jed.
Recent and related:
The Slang Shading Language - https://news.ycombinator.com/item?id=42244472 - Nov 2024 (44 comments)
It looks interesting and I'm considering switching to Slang, currently using HLSL but I've never really liked it or GLSL, they are both overly simple.
i’m confused who the intended userbase for this is
you either use like a game engine that generates all the platform specific gpu code and shaders for you, or you can take advantage of writing all the different gpu specific and shader code yourself (bc you need specific features or can make it faster or some such), i can’t really imagine something in between tbh
and a generalised tool like this is destined to not fit platform specific features that well; for example, i couldn’t find any mention of an interface to use tensor cores, and automatic differentiation w/o a relatively complex expression optimiser is kinda useless for machine learning, where tensor wrt tensor derivatives' dimensionality explodes w/o using an expression optimiser…
it’s kind of the same story as w/ cross platform gpu frameworks: they’re destined to just kind of do everything but badly bc different platforms have different architectures that you can’t map to w/ a single api… imo the best solution remains to have domain specific solutions that generate separate cross platform code solely in that domain...
does anyone understand how this fits in with the weird mess of SPIR-V/WGSL/Vulkan/GSL/HSL?
is this supposed to take the place as the officially blessed frontend language for SPIR-V? or is this just another standard attempting to replace the other standards (insert XKCD)?
[flagged]
Another shader compiler to support?
Slang looks interesting, I've been reading a bit about it over the last few weeks.
However, I've already run into the problem that, while it's a clever name for a shading language, it's a terrible name when trying to find anything in a search engine.
Making sure that devs can search and find answers quickly is an extremely important aspect of developer ergonomics, and I hope this issue isn't reflected in other subtle design flaws throughout the project.
A much less clever name that isn't already a common English word is always preferable. Call it xyzSL or something boring like that, which is unique and will always return meaningful search results.