[HN Gopher] The Slang Shading Language
       ___________________________________________________________________
        
       The Slang Shading Language
        
       Author : lmariscal
       Score  : 129 points
       Date   : 2024-11-26 10:40 UTC (5 days ago)
        
 (HTM) web link (shader-slang.com)
 (TXT) w3m dump (shader-slang.com)
        
       | lmariscal wrote:
       | Also of importance, the Slang initiative supported by Khronos:
       | https://www.khronos.org/news/press/khronos-group-launches-sl...
        
         | dragonelite wrote:
         | Ooh interesting i was just looking into Vulkan, Khronos
         | supporting Slang maybe i will skip glsl and just jump to Slang.
        
       | Conscat wrote:
       | 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.
        
         | pjmlp wrote:
         | Several commercial products are already using Slang, it has
         | moved beyond research demo for quite some time now.
         | 
         | The main difference, with something like Cg, is that now it
         | isn't NVidia only.
        
           | subharmonicon wrote:
           | I have known about slang for some time but hadn't heard about
           | these commercial products.
           | 
           | Can you elaborate?
        
             | pjmlp wrote:
             | From Vulkanised 2024,
             | 
             | https://vulkan.org/user/pages/09.events/vulkanised-2024/vul
             | k...
             | 
             | Omniverse, Portal RTX, RTX Remix, Source 2 shading
             | infrastructure,
        
         | machinekob wrote:
         | It isn't weird it started inside NV and folks from there are
         | still working on the project.
        
       | otteromkram wrote:
       | Will the real Slang Shady please compile up?
       | 
       | We're gonna have a problem here...
        
       | mpartel wrote:
       | 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.
       | 
       | [1] https://shader-slang.com/slang/user-guide/interfaces-
       | generic...
        
         | hajile wrote:
         | 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.
        
       | jacobgorm wrote:
       | Will Slang support compute shaders too, or is it just for
       | graphics.
        
         | Cotterzz wrote:
         | It's compute also, though that may depend on the target
         | language.
        
         | bartwr wrote:
         | 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)
        
       | LegNeato wrote:
       | Also check out Rust GPU, which has similar features and uses Rust
       | rather than a new language:
       | 
       | https://github.com/Rust-GPU/rust-gpu
        
         | Cotterzz wrote:
         | 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...
        
           | flohofwoe wrote:
           | 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.
        
           | LegNeato wrote:
           | It's not just syntax, it is semantics as well.
        
       | Cotterzz wrote:
       | 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?
        
         | flohofwoe wrote:
         | IMHO Slang fixes two problems in one tool:
         | 
         | - 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.
        
           | Cotterzz wrote:
           | 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.
        
           | skitter wrote:
           | 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.
           | 
           | [1] https://github.com/bevyengine/naga_oil
        
       | coffeeaddict1 wrote:
       | 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.
        
         | mistercow wrote:
         | 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.
        
           | incrudible wrote:
           | 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.
        
             | mistercow wrote:
             | 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.
        
               | my123 wrote:
               | 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.
        
         | incrudible wrote:
         | 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.
        
           | coffeeaddict1 wrote:
           | > 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.
        
           | raphlinus wrote:
           | 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
        
           | ranger_danger wrote:
           | 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.
        
             | BearOso wrote:
             | 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.
        
         | CyberDildonics wrote:
         | What is missing from GLSL?
        
           | coffeeaddict1 wrote:
           | 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.
        
       | bartwr wrote:
       | 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.
        
       | koolala wrote:
       | I wish it supported WGSL. WebGPU seems 5 years away from being
       | standard on devices and browsers.
        
       | ImHereToVote wrote:
       | Will it provide unified screen space derivatives?
        
       | pornel wrote:
       | Hello https://xkcd.com/927
       | 
       | There's also WESL that aims to extend WGSL with modules and
       | generics:
       | 
       | https://github.com/wgsl-tooling-wg/wesl-spec
       | 
       | and there's Naga project that can translate WGSL to other
       | languages:
       | 
       | https://github.com/gfx-rs/wgpu/tree/trunk/naga
        
       | darkest_ruby wrote:
       | Slang is GS internal database language
        
       ___________________________________________________________________
       (page generated 2024-12-01 23:01 UTC)