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.
I usually agree with this sentiment, but for some reason I think this language might just need time to become more known. I like it more than "HLSL" or "SpirV" for instance... Idk maybe I'm just biased
The issue isn't about the language being well known. It's what happens when I open a search engine and type "normal maps slang", for example. There's no correct results. But if I search "normal maps SpirV" all of the results are relevant.
It's not just because Slang is new. If it was called xyzSL then right now I'd expect "normal maps xyzSL" to return at least a few results.
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.
auto-differentiation is the magic behind most neural net-based ML (you do get some madmen who do the task manually). Backpropagation is basically just a special case of AD, and it lets you evaluate the derivative of an arbitrary (well-enough behaved) function with respect to any of its inputs. It's very useful for a lot of optimisation applications, but ML is the biggest in terms of GPU compute use.
(It's not particularly magical from a mathematic point of view, it's basically just an application of the chain rule, but it's something where you either need a fairly complex library or language support to implement, because you effectively need to take the function(s) you want the derivative of and transform them into a different set of calculations)
If you have auto-differentiation, it is tractable to do machine learning in a language. Because slang runs on any shader language & GPU, it could enable generalized acceleration of ML training on any graphics hardware which is cool.
YouTube videos on backpropagation might explain it better
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’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...
What do you think those game engines use to do the translation? They certainly aren't writing their own compilers and languages, they've got more important things to burn engineer time on. Anyone writing cross platform shaders can consider Slang, even if only for the output targets.
The intended user _is_ game engines, and it's a damn good contender in its space. The average pipeline for shader translation right now is HLSL being fed into DXC to generate DXIL for D3D and SPIR-V for Vulkan. That SPIR-V will also get fed into another transpiler (SPIRV-Cross) to spit out shaders for other platforms like Metal. This pipeline is quite fragile, especially in the SPIRV-Cross step, and DXC is on life support with Microsoft integrating a DXIL target into Clang so they don't have to develop a pseudo-cpp frontend anymore.
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)?
Slang is a language largely derived from HLSL. It's a solid leap in capability with more powerful features like generics. Largely as a language it brings shader languages out of the stone ages of plain procedural C and adds tools to help make writing composable shader code less awful.
Slang the compiler is also very cool because it can directly target multiple different languages. Slang can compile to (among other things) HLSL, GLSL, SPIR-V, MSL and WGSL directly. The next closest game in town is DXC which compiles HLSL to DXIL or SPIR-V, with most game engines using a soup of SPIRV-Cross and other translators to convert the SPIR-V to other languages like MSL.
It's shaping up to be a solid choice for a single-source shader pipeline. Especially if you care about being portable to MSL as the current 'state of the art' for turning HLSL into MSL is a fragile chain of several tools.
> Largely as a language it brings shader languages out of the stone ages of plain procedural C
It's not the first to do so though, Metal's shading language is C++14 with some restrictions and some enhancements (which IMHO is overkill though, except for the ability to stamp out different specializations from the same template code).
It's kind of both. It can generate High level shaders as well as SPIRV, according to the doc.
I interpret this announcement as more about the governance of the open source project than brand new anything. The project has been around for years and there are even some SIGGRAPH papers in this thing.
Yeah the news here is that Khronos is finally throwing their weight behind something modern as the "default" Vulkan shader language, as GLSL has been stagnant for years.
It's a meta-language that compiles down to SPIR-V (edit: or other high level shader languages), if you already have your own solution for targeting those then you can just continue as you were. You're not forced to use it.
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.