Item — HN Reader

Lots of problems with this (https://xkcd.com/386/).

"All shader languages are very similar to C". Even counting only mainstream shader languages, MSL is explicitly based on C++ and not C. There is a big difference. The non-mainstream shader languages will also be increasingly important, because who wants to be restricted to C dialects?

"and have all the usual features associated with C save for pointers." MSL has strong built-in support for pointers. In addition, the future of Vulkan is increasingly pointer-friendly.

HLSL compilation. This oversimplifies the story a bit. DXC only produces DXIL which is D3D12+ (and SPIR-V, so it can be used on Vulkan with little hassle). Older dialects (shader model 5) work on D3D11 as well, and can also be compiled offline, but that requires FXC [1] (FXC output, DXBC, can be used in D3D12, you just don't get as much access to newer features).

"Some languages however encourage you not to compile shaders to an IR such as GLSL with OpenGL". This is no longer true as of OpenGL 4.6, which can use SPIR-V. On the other hand, it's probably best to think of OpenGL as a nearly obsolete API, only useful for compatibility.

"The metallib compiler is available in the command line in any recent MacOS installation." It might also be worth pointing out that it is also now available on Windows. Thus, on a single Windows box it is possible to go from your source language to all major shader IL's.

"GLSLang even supports compiling HLSL to SPIR-V, though this feature is still experimental." Yes, but use DXC instead, that's actively being developed.

"transpiling it to either GLSL, HLSL, or MSL is trivial." It's not trivial. There are important semantic differences between these shader languages, and transpilation is a leaky abstraction. One case in point, memory barriers of device scope are not available in current MSL, so transpilation of such barriers is likely to silently result in barriers of merely workgroup scope. These kinds of problems are fun to debug.

"Mozilla Naga is the Firefox WGSL to SPIR-V compiler written in Rust." It has many more transpilation options, and in fact a major goal was to avoid the need for spirv-cross to generate HLSL and MSL. Similar for Dawn.

This might be a useful resource for some, but don't take its advice too seriously.

[1]: https://asawicki.info/news_1719_two_shader_compilers_of_dire...

2 comments

> "All shader languages are very similar to C". Even counting only mainstream shader languages, MSL is explicitly based on C++ and not C.

C++ is a C variant. I think they were more getting at where’s Shader Pascal, Ruby, Lisp?

The deference between C and C++ is vast. You can do templates and meta programming in C++ that you can't in C. Similarly you can do templates and meta programming in Metal

So to say all shader languages are based on C is as useful as saying they're all based on assembly. I'm not saying C++ style templates are good or bad but they're vastly more powerful than not having them and if you're using those other C based shader languages you'll end up having to do code generation in some other language to provide the same features as a C++ based shader language

While it has roots in C, I think it's better to consider it a separate language, especially in more modern forms (Metal is C++14). Metal is locked into Apple's proprietary platforms, but there is other work in compiling C++ to portable shaders, particularly Sean Baxter's Circle, as well as some academic work[1].

There's also of course rust-gpu. I think it's fair to say that in 5 to 10 years we will no longer be writing shaders in C, but will have moved on to a higher level language.

[1]: https://arxiv.org/pdf/2109.14682.pdf

Python has roots in C, but you can still write valid compilable C alongside C++, so I'm not sure what you're trying to imply.

Sure it's another language, but the C at it's core isn't going anywhere.

Bunch of internal lisps generating all kinds of shader code (or OpenCL in at least one case), plus things like CEPL (which also generates shaders from CL data/code) and Shinmera uses in his game engine automatic composition of shaders using CLOS metaobjects, iirc

You and I are ape variants. But it is the sum of our differences from apes that matters, almost always.

C++ code that looks like C is, typically, bad code. The C legacy is not going away, but is less and less relevant.

Now that is something I agree on. :)

OpenGL is obsolete?

Very. It is a terrible API to talk through a modern GPU to, and I doubt any vendor is supporting it as anything but legacy at this point.

What are people in that camp using then? Vulkan? That seems too low level for most people

It is not going anywhere, but don't expect anything after 4.6 to ever come up.

yes ... or maybe for all intents and purposes, deprecated or mostly abandoned are better words. Hardware vendors really don't want to spend any more resources on it.