6 ms·

Shadertoys Ported to Rust GPU

98 points by efnx 1y ago

hackyhacky 1y ago
> 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't support the traditional graphics pipeline. Examples of this include *CUDA* and *OpenCL*. Are CUDA and OpenCL really "better alternatives" to HLSL and GLSL? 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's dishonest to claim that CUDA is intended as an updated alternative to GLSL. It's simply apples and oranges.
- pjmlp 1y ago
  OpenCL no one cares about. CUDA yes, it is already being used in commercial visualisation products like OctaneRender, one of the most important tools in the VFX industry. NVidia also has plenty of customers on OptiX. GLSL is dead end, Khronos is on the record they aren't going to develop it further, even for Vulkan, HLSL and now slang, are the way forward. HLSL due to its use in the games industry, slang due to being developed by NVIDIA and given to Khronos as GLSL replacement.
  - rand0m4r 1y ago
    > GLSL is dead end, Khronos is on the record they aren't going to develop it further, even for Vulkan, HLSL and now slang, are the way forward. I've been seeing more comments like yours saying GLSL is a dead end, and it’s making me question whether I should keep learning it. But at the same time, it’s still very accessible, well-documented, and used in OpenGL demos and educational content. Would you say there's still a case for GLSL in hobby projects, demoscene work, or rapid prototyping? Or is it really time to move on even in those contexts?
tubs 1y ago
I understand the sentiment but to be very pedantic most GPUs do not understand SPIRV, it’s the drivers that do.
- ImHereToVote 1y ago
  I hate to be pedantic but drivers don't understand at all. The driver accepts and can execute SPIR-V bytecode.
impure 1y ago
This is big news. Shaders have been a pain to develop for in Unity. If I can program them in Rust, leveraging Rust's tooling and ecosystem, that would be huge.
tripplyons 1y ago
Very exciting project! Does this work on M-series macs? I've had trouble running some shaders on my laptop before.
- LegNeato 1y ago
  Yes. Under the hood it uses wgpu and naga, which translates the SPIR-V into metal so it runs iOS and macOS (on Linux and Windows it uses spirv on vulkan directly)
nefarious_ends 1y ago
Anyone have recommendations for resources for learning to write shaders?
- FjordWarden 1y ago
  I've always enjoyed watching The Art of Code[1], Freya[2] also has a good number of videos on it. But that is just vertex shaders for things like Shadertoys. There is much more to computer graphics or GPGPU than this though, Im still learning about that myself X). [1] https://www.youtube.com/watch?v=eKtsY7hYTPg https://www.youtube.com/watch?v=eKtsY7hYTPg [2]https://www.youtube.com/watch?v=kfM-yu0iQBk https://www.youtube.com/watch?v=kfM-yu0iQBk
- jms55 1y ago
  If you want to make nice looking materials and effects, you need a combination of good lighting (comes from the rendering engine, not the material), and artistic capabilities/talent. Art is a lot harder to teach than programming I feel, or at least I don't know how to teach it. Programming the shaders themselves are pretty simple imo, they're just pure functions that return color data or triangle positions. The syntax might be a little different than you're used to depending on the shader language, but it should be easy enough to pick up in a day. If you want to write compute shaders for computation, then it gets a lot more tricky and you need to spend some time learning about memory accesses, the underlying hardware, and profiling.
- pornel 1y ago
  https://www.scratchapixel.com https://www.scratchapixel.com https://www.youtube.com/c/acerola_t https://www.youtube.com/c/acerola_t https://www.shadertoy.com https://www.shadertoy.com https://google.github.io/tour-of-wgsl/ https://google.github.io/tour-of-wgsl/
- alook 1y ago
  The book of shaders is fantastic: http://www.thebookofshaders.com/ http://www.thebookofshaders.com/
  - 1y ago
shadowgovt 1y ago
So why Rust? Rust is great for tracking the lifetime of long-lived resources, which everything in a shader isn't. Apart from that, what makes Rust a good fit for this problem domain?
- xphos 1y ago
  I think being able to develop it is a testiment that rust makes embeddeding stuff like this much easier than other languages. Its also intergrated in a rust project so you might not want to hop to a new language to do some shader stuff quickly
- thrance 1y ago
  Rust also has a great type system and zero-cost abstractions. Plus there's already cuda if you want to run C on the GPU.
- virtualritz 1y ago
  I think that if you have a game/DCC/whatever app you write in Rust, being able to also write any shaders it uses in Rust is simply nice. And as an added benefit it means not adding another language to a project and all that comes with it for build system/CI. I.e. cargo takes care of everything. That alone is worth a lot IMHO. Apart from that its not related to Rust. Just replace Rust with your fav. language and imagine you could also write shaders/GPU-targeted code in it. Isn't that desirable?
  - ghfhghg 1y ago
    Kind of and I've certainly used systems like that before but in practice it's not really a massive improvement. Sometimes it's even a tad annoying having another layer of indirection.
- pornel 1y ago
  Lifetime tracking isn't just for safety or resource management. It also helps write correct code, especially parallel one where shared vs mutable matters. Unit testing of shaders is usually a pain. Traditionally they're a black box without any assert() equivalent, and you can at best try to propagate NaN and generate magenta pixels on failure. Sharing Rust code lets you unit-test parts of it on the CPU. Sharing of data structures between CPU and GPU is nice too. WGSL is superficially similar to Rust, but using plain WGSL requires maintaining bindings and struct layouts by hand, which is a chore. For CUDA, the alternative is C++. On the upside that's the official first-class API for CUDA, but the downside is that it's C++. With Rust you don't have the legacy language cruft, nor busywork like header files or makefiles. You get working dependency management, and don't get caught in the unix vs Windows schism.
AndrewPGameDev 1y ago
I've spent a little time in this space, and I'm not sure it's a good idea to write shaders in Rust, although it's probably better than GLSL or WGSL. Let me start with the pros: 1. Don't have to learn 2 different languages 2. Modules, crates, and the easier ability to share code 3. Easier sharing between rust structs and shader code. Now the cons, in comparison to Slang [1] 1. No autodiff mode 2. Strictly outputs SPIR-V, while Slang can do CPU, CUDA, Pytorch, Optix, and all the major graphics APIs 3. Less support - Slang is supported by the Khronos group, and Slang gets use at Nvidia, EA, and Valve. 4. Safety isn't very valuable, most GPU code does not use pointers (it's so rare it's considered a feature by Slang!) 5. slangc probably runs a lot faster than rustc (although I would like to see a benchmark.) 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. 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 <-> gpu much easier. Also, the example shown on the website uses `bytemuck`, but `bytemuck` won'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'm not sure given the example on the website how it would work with WebGPU. 8. If you have pre-existing shaders in GLSL or HLSL, you can use slangc directly on them. No need to rewrite. 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. [1] https://shader-slang.org/ https://shader-slang.org/ [2] https://webgpufundamentals.org/webgpu/lessons/resources/wgsl-offset-computer.html# https://webgpufundamentals.org/webgpu/lessons/resources/wgsl... WGSL struct alignment widget [3] https://github.com/teoxoy/encase https://github.com/teoxoy/encase
- wyager 1y ago
  Had not heard of Slang, thanks for sharing. It's interesting that Slang looks more like Rust than WGSL does, despite WGSL kind of being de facto "owned by" the Rust community.
  - 1y ago
deleted 1y ago
[deleted]
Jothamcloud 1y ago
[flagged]

98 points by efnx 1y ago

> 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't support the traditional graphics pipeline. Examples of this include *CUDA* and *OpenCL*. Are CUDA and OpenCL really "better alternatives" to HLSL and GLSL? 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's dishonest to claim that CUDA is intended as an updated alternative to GLSL. It's simply apples and oranges.

pjmlp 1y ago
OpenCL no one cares about. CUDA yes, it is already being used in commercial visualisation products like OctaneRender, one of the most important tools in the VFX industry. NVidia also has plenty of customers on OptiX. GLSL is dead end, Khronos is on the record they aren't going to develop it further, even for Vulkan, HLSL and now slang, are the way forward. HLSL due to its use in the games industry, slang due to being developed by NVIDIA and given to Khronos as GLSL replacement.
- rand0m4r 1y ago
  > GLSL is dead end, Khronos is on the record they aren't going to develop it further, even for Vulkan, HLSL and now slang, are the way forward. I've been seeing more comments like yours saying GLSL is a dead end, and it’s making me question whether I should keep learning it. But at the same time, it’s still very accessible, well-documented, and used in OpenGL demos and educational content. Would you say there's still a case for GLSL in hobby projects, demoscene work, or rapid prototyping? Or is it really time to move on even in those contexts?

tubs 1y ago

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

ImHereToVote 1y ago
I hate to be pedantic but drivers don't understand at all. The driver accepts and can execute SPIR-V bytecode.

impure 1y ago

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

tripplyons 1y ago

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

LegNeato 1y ago
Yes. Under the hood it uses wgpu and naga, which translates the SPIR-V into metal so it runs iOS and macOS (on Linux and Windows it uses spirv on vulkan directly)

nefarious_ends 1y ago

Anyone have recommendations for resources for learning to write shaders?

FjordWarden 1y ago
I've always enjoyed watching The Art of Code[1], Freya[2] also has a good number of videos on it. But that is just vertex shaders for things like Shadertoys. There is much more to computer graphics or GPGPU than this though, Im still learning about that myself X). [1] https://www.youtube.com/watch?v=eKtsY7hYTPg https://www.youtube.com/watch?v=eKtsY7hYTPg [2]https://www.youtube.com/watch?v=kfM-yu0iQBk https://www.youtube.com/watch?v=kfM-yu0iQBk
jms55 1y ago
If you want to make nice looking materials and effects, you need a combination of good lighting (comes from the rendering engine, not the material), and artistic capabilities/talent. Art is a lot harder to teach than programming I feel, or at least I don't know how to teach it. Programming the shaders themselves are pretty simple imo, they're just pure functions that return color data or triangle positions. The syntax might be a little different than you're used to depending on the shader language, but it should be easy enough to pick up in a day. If you want to write compute shaders for computation, then it gets a lot more tricky and you need to spend some time learning about memory accesses, the underlying hardware, and profiling.
pornel 1y ago
https://www.scratchapixel.com https://www.scratchapixel.com https://www.youtube.com/c/acerola_t https://www.youtube.com/c/acerola_t https://www.shadertoy.com https://www.shadertoy.com https://google.github.io/tour-of-wgsl/ https://google.github.io/tour-of-wgsl/
alook 1y ago
The book of shaders is fantastic: http://www.thebookofshaders.com/ http://www.thebookofshaders.com/
- 1y ago

shadowgovt 1y ago

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

xphos 1y ago
I think being able to develop it is a testiment that rust makes embeddeding stuff like this much easier than other languages. Its also intergrated in a rust project so you might not want to hop to a new language to do some shader stuff quickly
thrance 1y ago
Rust also has a great type system and zero-cost abstractions. Plus there's already cuda if you want to run C on the GPU.
virtualritz 1y ago
I think that if you have a game/DCC/whatever app you write in Rust, being able to also write any shaders it uses in Rust is simply nice. And as an added benefit it means not adding another language to a project and all that comes with it for build system/CI. I.e. cargo takes care of everything. That alone is worth a lot IMHO. Apart from that its not related to Rust. Just replace Rust with your fav. language and imagine you could also write shaders/GPU-targeted code in it. Isn't that desirable?
- ghfhghg 1y ago
  Kind of and I've certainly used systems like that before but in practice it's not really a massive improvement. Sometimes it's even a tad annoying having another layer of indirection.
pornel 1y ago
Lifetime tracking isn't just for safety or resource management. It also helps write correct code, especially parallel one where shared vs mutable matters. Unit testing of shaders is usually a pain. Traditionally they're a black box without any assert() equivalent, and you can at best try to propagate NaN and generate magenta pixels on failure. Sharing Rust code lets you unit-test parts of it on the CPU. Sharing of data structures between CPU and GPU is nice too. WGSL is superficially similar to Rust, but using plain WGSL requires maintaining bindings and struct layouts by hand, which is a chore. For CUDA, the alternative is C++. On the upside that's the official first-class API for CUDA, but the downside is that it's C++. With Rust you don't have the legacy language cruft, nor busywork like header files or makefiles. You get working dependency management, and don't get caught in the unix vs Windows schism.

AndrewPGameDev 1y ago

I've spent a little time in this space, and I'm not sure it's a good idea to write shaders in Rust, although it's probably better than GLSL or WGSL. Let me start with the pros: 1. Don't have to learn 2 different languages 2. Modules, crates, and the easier ability to share code 3. Easier sharing between rust structs and shader code. Now the cons, in comparison to Slang [1] 1. No autodiff mode 2. Strictly outputs SPIR-V, while Slang can do CPU, CUDA, Pytorch, Optix, and all the major graphics APIs 3. Less support - Slang is supported by the Khronos group, and Slang gets use at Nvidia, EA, and Valve. 4. Safety isn't very valuable, most GPU code does not use pointers (it's so rare it's considered a feature by Slang!) 5. slangc probably runs a lot faster than rustc (although I would like to see a benchmark.) 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. 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 <-> gpu much easier. Also, the example shown on the website uses `bytemuck`, but `bytemuck` won'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'm not sure given the example on the website how it would work with WebGPU. 8. If you have pre-existing shaders in GLSL or HLSL, you can use slangc directly on them. No need to rewrite. 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. [1] https://shader-slang.org/ https://shader-slang.org/ [2] https://webgpufundamentals.org/webgpu/lessons/resources/wgsl-offset-computer.html# https://webgpufundamentals.org/webgpu/lessons/resources/wgsl... WGSL struct alignment widget [3] https://github.com/teoxoy/encase https://github.com/teoxoy/encase

wyager 1y ago
Had not heard of Slang, thanks for sharing. It's interesting that Slang looks more like Rust than WGSL does, despite WGSL kind of being de facto "owned by" the Rust community.
- 1y ago

deleted 1y ago

[deleted]

Jothamcloud 1y ago

[flagged]