4 ms·

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

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 2y 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 2y 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 2y 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 2y 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 2y 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.
- Const-me 2y ago
  > Sharing of data structures between CPU and GPU is nice too How they did it? Hard to do because GPU hardware can convert data types on the fly, e.g. you can store bytes in VRAM, and convert them to 32-bit floats in [ 0 .. +1 ] in the shader. GPUs can do that for both inputs (loaded texture texels, loaded buffer elements, vertex attributes) and outputs (rendered pixels, stored UAV elements).
  - exDM69 2y ago
    If you are using plain buffers the GPU and the CPU access data pretty much exactly the same way. With scalar block layout all the alignments are pretty much the same too. To get the format conversion stuff you talk about, you need to use images, vertex input or texel buffers and configure the format conversion explicitly. It's a good question how much of these conversions are actually done by GPU hardware and how much of it is just software (which you could write yourself in a shader and get same perf). I have not seen an apples to apples benchmark about these format conversions.
    - Const-me 2y ago
      > If you are using plain buffers the GPU and the CPU access data pretty much exactly the same way Yeah, that will work fine for byte address buffers, to lesser extent constant buffers (they don’t convert data types but the access sematic and alignment are a bit tricky), but not much else. Vertex buffers, textures, and texel buffers / typed buffers in D3D are all widely used in real-time graphics. > which you could write yourself in a shader and get same perf Pretty sure it’s hardware. Emulating anisotropic texture sampler with HLSL codes would need hundreds of instructions, prohibitively expensive. Even simpler trilinear sampling is surprisingly tricky to emulate due to these screen-space partial derivatives on input. > I have not seen an apples to apples benchmark about these format conversions. Here’s a benchmark for vertex buffers https://wickedengine.net/2017/06/should-we-get-rid-of-vertex-buffers/ https://wickedengine.net/2017/06/should-we-get-rid-of-vertex... As you see, on AMD GCN4 he indeed measured pretty much the same perf, however on nVidia Maxwell vertex buffers were 2-4 times faster.
wyager 2y ago
Rust's ecological niche, besides the affine types/lifetime stuff, is "borrow as much stuff as we can from Haskell/ML without dragging in a language runtime". "Without dragging in a language runtime" happens to be a primary requirement for writing bare-metal code or writing GPU shaders. So you have a language that does have a bunch of nice new features (ADTs, acceptably modern type system, etc.) and doesn't have any of the stuff that prevents you from compiling it to random bare-metal targets like GPUs or MMUless microcontrollers.
- pjmlp 2y ago
  Basically slang, GLSL replacement, designed by NVidia and adopted by Khronos as industry standard.
marsven_422 2y ago
[dead]
shadowgovt 2y ago
Update: thanks to everyone for the thoughtful comments on this. I'm so in the weeds with dealing with GLSL these days that "What if you could use the same language to implement the CPU logic as the GPU logic" wasn't even a goal I could see. That's actually quite huge; my concerns around Rust were mostly that it's not a deeply simple language and so much of shader frameworks is code-that-writes-code, but it's simple enough that I think it could still be used in that space, while granting the advantages of not having to context-switch in and out of one's CPU-language while developing a shader. This has promise!

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 2y 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 2y 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 2y 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 2y 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 2y 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.

Const-me 2y ago
> Sharing of data structures between CPU and GPU is nice too How they did it? Hard to do because GPU hardware can convert data types on the fly, e.g. you can store bytes in VRAM, and convert them to 32-bit floats in [ 0 .. +1 ] in the shader. GPUs can do that for both inputs (loaded texture texels, loaded buffer elements, vertex attributes) and outputs (rendered pixels, stored UAV elements).
- exDM69 2y ago
  If you are using plain buffers the GPU and the CPU access data pretty much exactly the same way. With scalar block layout all the alignments are pretty much the same too. To get the format conversion stuff you talk about, you need to use images, vertex input or texel buffers and configure the format conversion explicitly. It's a good question how much of these conversions are actually done by GPU hardware and how much of it is just software (which you could write yourself in a shader and get same perf). I have not seen an apples to apples benchmark about these format conversions.
  - Const-me 2y ago
    > If you are using plain buffers the GPU and the CPU access data pretty much exactly the same way Yeah, that will work fine for byte address buffers, to lesser extent constant buffers (they don’t convert data types but the access sematic and alignment are a bit tricky), but not much else. Vertex buffers, textures, and texel buffers / typed buffers in D3D are all widely used in real-time graphics. > which you could write yourself in a shader and get same perf Pretty sure it’s hardware. Emulating anisotropic texture sampler with HLSL codes would need hundreds of instructions, prohibitively expensive. Even simpler trilinear sampling is surprisingly tricky to emulate due to these screen-space partial derivatives on input. > I have not seen an apples to apples benchmark about these format conversions. Here’s a benchmark for vertex buffers https://wickedengine.net/2017/06/should-we-get-rid-of-vertex-buffers/ https://wickedengine.net/2017/06/should-we-get-rid-of-vertex... As you see, on AMD GCN4 he indeed measured pretty much the same perf, however on nVidia Maxwell vertex buffers were 2-4 times faster.

wyager 2y ago

Rust's ecological niche, besides the affine types/lifetime stuff, is "borrow as much stuff as we can from Haskell/ML without dragging in a language runtime". "Without dragging in a language runtime" happens to be a primary requirement for writing bare-metal code or writing GPU shaders. So you have a language that does have a bunch of nice new features (ADTs, acceptably modern type system, etc.) and doesn't have any of the stuff that prevents you from compiling it to random bare-metal targets like GPUs or MMUless microcontrollers.

pjmlp 2y ago
Basically slang, GLSL replacement, designed by NVidia and adopted by Khronos as industry standard.

marsven_422 2y ago

[dead]

shadowgovt 2y ago

Update: thanks to everyone for the thoughtful comments on this. I'm so in the weeds with dealing with GLSL these days that "What if you could use the same language to implement the CPU logic as the GPU logic" wasn't even a goal I could see. That's actually quite huge; my concerns around Rust were mostly that it's not a deeply simple language and so much of shader frameworks is code-that-writes-code, but it's simple enough that I think it could still be used in that space, while granting the advantages of not having to context-switch in and out of one's CPU-language while developing a shader. This has promise!