3 ms·

I've seen this done in C++ for generating GLSL before a few times. One from Waterloo Univeesity in the early 2000s became RapidMind: http://web.cs.ucla.edu/~pa

I've seen this done in C++ for generating GLSL before a few times. One from Waterloo Univeesity in the early 2000s became RapidMind: http://web.cs.ucla.edu/~palsberg/course/cs239/papers/rapidmind.pdf http://web.cs.ucla.edu/~palsberg/course/cs239/papers/rapidmi... There were a few others, but I can not remember their names. Generally these techniques work, but for some reason they tend to die out.

Const-me 2y ago
> 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)
HammadB 2y ago
a lot of game engines have higher level shading languages (often visually programmed) that are long-lived and widely used.
flohofwoe 2y ago
You're essentially building an AST via function calls, this is a lot less ergonomic than having a custom programming language to describe the AST (especially when building conditions, loops and complex math expressions). It could be a good base for a noodle graph shader editor though (or even for a language compiler outside of three.js which compiles to "TLS" Javascript code - but at that point (of having an offline compile step) why not get rid of the middleman and compile from (yet another) custom shading language to GLSL or WGSL directly).

Const-me 2y ago

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

HammadB 2y ago

a lot of game engines have higher level shading languages (often visually programmed) that are long-lived and widely used.

flohofwoe 2y ago

You're essentially building an AST via function calls, this is a lot less ergonomic than having a custom programming language to describe the AST (especially when building conditions, loops and complex math expressions). It could be a good base for a noodle graph shader editor though (or even for a language compiler outside of three.js which compiles to "TLS" Javascript code - but at that point (of having an offline compile step) why not get rid of the middleman and compile from (yet another) custom shading language to GLSL or WGSL directly).