Shadertoys Ported to Rust GPU

I&#x27;ve spent a little time in this space, and I&#x27;m not sure it&#x27;s a good idea to write shaders in Rust, although it&#x27;s probably better than GLSL or WGSL.<p>Let me start with the pros:<p>1. Don&#x27;t have to learn 2 different languages<p>2. Modules, crates, and the easier ability to share code<p>3. Easier sharing between rust structs and shader code.<p>Now the cons, in comparison to Slang [1]<p>1. No autodiff mode 2. Strictly outputs SPIR-V, while Slang can do CPU, CUDA, Pytorch, Optix, and all the major graphics APIs<p>3. Less support - Slang is supported by the Khronos group, and Slang gets use at Nvidia, EA, and Valve.<p>4. Safety isn&#x27;t very valuable, most GPU code does not use pointers (it&#x27;s so rare it&#x27;s considered a feature by Slang!)<p>5. slangc probably runs a lot faster than rustc (although I would like to see a benchmark.)<p>6. Worse debugging experience, slang has better interop with things like NSight Graphics, and their Shader Debugger. Slang recently got support in NSight graphics for shader profiling, for example.<p>7. Slang has support for reflection, and has a C++ api to directly output a JSON file that contains all the reflected aspects.This makes handling the movement between rust &lt;-&gt; gpu much easier. Also, the example shown on the website uses `bytemuck`, but `bytemuck` won&#x27;t take into consideration the struct alignment rules[2] when using WebGPU. Instead, you have to use a crate like `encase`[3] to handle that. I&#x27;m not sure given the example on the website how it would work with WebGPU.<p>8. If you have pre-existing shaders in GLSL or HLSL, you can use slangc directly on them. No need to rewrite.<p>9. In reality, you may not have to learn 2 languages but you have to learn 2 different compute models (CPU vs GPU). This is actually a much harder issue, and AFAICT it is impossible to overcome with a different language. The problem is the programmer needs to understand how the platforms are different.<p>[1] <a href="https:&#x2F;&#x2F;shader-slang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;shader-slang.org&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;webgpufundamentals.org&#x2F;webgpu&#x2F;lessons&#x2F;resources&#x2F;wgsl-offset-computer.html#" rel="nofollow">https:&#x2F;&#x2F;webgpufundamentals.org&#x2F;webgpu&#x2F;lessons&#x2F;resources&#x2F;wgsl...</a> WGSL struct alignment widget [3] <a href="https:&#x2F;&#x2F;github.com&#x2F;teoxoy&#x2F;encase">https:&#x2F;&#x2F;github.com&#x2F;teoxoy&#x2F;encase</a>

So why Rust?<p>Rust is great for tracking the lifetime of long-lived resources, which everything in a shader isn&#x27;t.<p>Apart from that, what makes Rust a good fit for this problem domain?

Anyone have recommendations for resources for learning to write shaders?

&gt; While over-all better alternatives to both languages exist, none of them are in a place to replace *HLSL* or *GLSL*. Either because they are vendor locked, or because they don&#x27;t support the traditional graphics pipeline. Examples of this include *CUDA* and *OpenCL*.<p>Are CUDA and OpenCL really &quot;better alternatives&quot; to HLSL and GLSL?<p>CUDA and OpenCL are compute languages; HLSL and GLSL and shader languages. And while one can theoretically do compute in a shader (and we used to!) or shaders in a compute language, I think it&#x27;s dishonest to claim that CUDA is intended as an updated alternative to GLSL. It&#x27;s simply apples and oranges.

This is big news. Shaders have been a pain to develop for in Unity. If I can program them in Rust, leveraging Rust&#x27;s tooling and ecosystem, that would be huge.

I understand the sentiment but to be very pedantic most GPUs do not understand SPIRV, it’s the drivers that do.

Very exciting project! Does this work on M-series macs? I&#x27;ve had trouble running some shaders on my laptop before.