Hacker News Reader

Comment by Kelteseth | Hacker News Reader

S̶o̶u̶n̶d̶s̶ ̶c̶o̶o̶l̶,̶ ̶b̶u̶t̶ ̶t̶h̶i̶s̶ ̶r̶e̶q̶u̶i̶r̶e̶s̶ ̶y̶e̶t̶ ̶a̶n̶o̶t̶h̶e̶r̶ ̶l̶a̶n̶g̶u̶a̶g̶e̶ ̶t̶o̶ ̶l̶e̶a̶r̶n̶[0]. As someone who only has limited knowledge in this space, could someone tell me how comparable is the compute functionality of rust-gpu[1], where I can just write rust?

[0] https://github.com/Hugobros3/shady#language-syntax

[1] https://github.com/EmbarkStudios/rust-gpu

Edit: No new language to learn required, this was about IR

View on HN

I often see folks complain/express confusion about shading languages.. but I think it's often incorrectly stated as syntax of the language, when in reality the confusion is about underlying GPU concepts.

Like, people (naturally) want to say 'I know how to write X, and therefor if X can run on the GPU then I can just write X for the GPU and be productive!" but in reality programming for a CPU and GPU are just.. very very different.

Vector processing differences.. shader stage concepts.. primitive types like textures/samplers.. bindings.. push constants.. uniforms.. recursion limitations.. dynamic array limitations.. invocation groups.. control flow limitations.. extension hell.. -- these aren't going anywhere

Heck, even if you stick with just modern compute APIs like Cuda - as close as you can get to treating the GPU as a general compute device - the way you write code for a GPU using that is just going to be very very different than how most write code for the CPU.

"I often see folks complain/express confusion about shading languages.. "

The confusion already starts with the name. Historically shading languages had the purpose once to calculate shades - but otherwise there are no shades and more correct and helpful would be just "GPU language". As yes, it is very different than writing something for a CPU.

> Vector processing differences.. shader stage concepts.. primitive types like textures/samplers.. bindings.. push constants.. uniforms.. recursion limitations.. dynamic array limitations.. invocation groups.. control flow limitations.. extension hell.. -- these aren't going anywhere

The point of Vcc/Shady is to address some of these, in particular recursion is now possible in Vulkan, and control-flow is no longer limited. A lot of those are just historical language limitations and can be eliminated with enough effort.

The elephant in the room is SIMT and the subgroup/workgroup considerations, which don't really require any changes to syntax but indeed needs the programmer to have a good mental model. But I don't think it would be incompatible with raising the bar on expressiveness or host/device code interoperability !

> recursion is now possible in Vulkan, and control-flow is no longer limited.

If you care about mobile devices (even modern android phones) I suspect this is not true

As others have commented, Shady is an IR that happens to have a Clang front-end bolted on, that combination is what I call Vcc. I really don't expect people to start writing shaders in the IR directly, even though has a textual form!

It's very comparable to Rust-GPU, I actually know a really nice person who does key work on that (you know who you are!) and they're actually facing very similar challenges, and we get to exchange ideas regularly. I am confident it's in good hands.

IDK that shady is that far from literally any other C-like shader language. Any skill you have in that area is going to transfer (unless you only know Rust, lol)

No, the entire project is about using existing languages (C/C++) on GPUs, the project you linked is their internal IR (intermediate representation) which is what they compile the C/C++ down to before it is turned into a Vulkan compute shader.

Ahh, thanks for the clarification!

Reply on news.ycombinator.com