3 ms·

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

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.

hutzlibu 3y ago
"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.
g0b 3y ago
> 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 !
- slimsag 3y ago
  > 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

hutzlibu 3y ago

"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.

g0b 3y ago

> 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 !

slimsag 3y ago
> 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