3 ms·

> for some reason they tend to die out I think the reason is questionable value. Native GPU programming languages, HLSL and GLSL, have a simple and readable s

> for some reason they tend to die out I think the reason is questionable value. Native GPU programming languages, HLSL and GLSL, have a simple and readable syntax. The complexity is not in the language, it’s in the runtime and surrounding infrastructure: weird execution model with these wavefronts and interleaved programmable/fixed function blocks in the graphics pipeline, weird memory model with load/store coalescence and manually managed groupshared, weird IO without even printf() available, and poor tooling (I think only CUDA did it right). Replacing the programming language does nothing with execution model, memory model, and IO. These quirks come from the hardware not software and are inevitable. Custom languages break tooling: RenderDoc HLSL debugger is not great but much better than nothing. Sometimes they break other things as well, for example WebGPU derived their shader language from Rust which is IMO unreadable by design.

esperent 2y ago
> I think the reason is questionable value. It's my hope, having casually followed the development of the three.js shader nodes and now TSL, that they will end up getting wrapped up into a visual node editor of high quality. As far a I'm aware, they have made some attempt at following the MaterialX spec which should help here. So even if writing code in TSL has limited utility over pure shader code (I don't have an opinion here but I've seen it brought up a few times), it should make writing a three.js visual node editor much simpler.
- pjmlp 2y ago
  That is the BabylonJS approach.
flohofwoe 2y ago
> for example WebGPU derived their shader language from Rust which is IMO unreadable by design The reason why typical Rust code is so unreadable is not because the type is on the right side ;) The same 'readability argument' could be brought up with HLSL and MSL too because of their similarity to C++ - "modern C++" code typically isn't very readable either unless the reader closely followed C++ development since around 1998 or so. FWIW I consider WGSL syntax a pretty good balance between simplicity and convenience (much better than "GLSL 300 es" anyway).
unconed 2y ago
The complexity absolutely is in the language, otherwise you wouldn't have 4 or 5 different ways to pass data in and out of a shader, and turning e.g. a mesh renderer into a wireframe renderer would be a simple case of function composition. The surrounding infrastructure is atrocious on top of that, but the idea that shading languages are fine is just off-base. They don't have real module systems, they don't let you compose, and the norm is still just to use preprocessor hacks to produce shader variants. (this is why I built Use.GPU around a modular WGSL linker)

esperent 2y ago

> I think the reason is questionable value. It's my hope, having casually followed the development of the three.js shader nodes and now TSL, that they will end up getting wrapped up into a visual node editor of high quality. As far a I'm aware, they have made some attempt at following the MaterialX spec which should help here. So even if writing code in TSL has limited utility over pure shader code (I don't have an opinion here but I've seen it brought up a few times), it should make writing a three.js visual node editor much simpler.

pjmlp 2y ago
That is the BabylonJS approach.

flohofwoe 2y ago

> for example WebGPU derived their shader language from Rust which is IMO unreadable by design The reason why typical Rust code is so unreadable is not because the type is on the right side ;) The same 'readability argument' could be brought up with HLSL and MSL too because of their similarity to C++ - "modern C++" code typically isn't very readable either unless the reader closely followed C++ development since around 1998 or so. FWIW I consider WGSL syntax a pretty good balance between simplicity and convenience (much better than "GLSL 300 es" anyway).

unconed 2y ago

The complexity absolutely is in the language, otherwise you wouldn't have 4 or 5 different ways to pass data in and out of a shader, and turning e.g. a mesh renderer into a wireframe renderer would be a simple case of function composition. The surrounding infrastructure is atrocious on top of that, but the idea that shading languages are fine is just off-base. They don't have real module systems, they don't let you compose, and the norm is still just to use preprocessor hacks to produce shader variants. (this is why I built Use.GPU around a modular WGSL linker)