Comment by flohofwoe | Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Parent Full thread

Many reasons, some of them not technical (e.g. historical baggage and closely guarded IPs), but mainly because GPUs are by far not as standardized and "open" as CPUs. On CPUs, the instruction set is basically the abstraction layer to the underlying hardware, on GPUs the abstraction layer is a software driver instead, and that needs to be much more abstract because the differences between the various GPU architectures are much bigger than the differences between ISAs like x86 vs ARM.

Having said that: your idea absolutely makes sense, and I would love to see shader compilers merged into regular compiler toolchains, so that CPU and GPU code can be easily mixed in the same source file (technically it's definitely possible, but this would also be the death of "3D APIs as we know them" - those would basically be merged into language stdlibs, and it would require many parties working closely together - so there's a risk of the 'many cooks' problem).

But give it a decade or so, and hopefully we'll get exactly that :)

> I would love to see shader compilers merged into regular compiler toolchains

they are already using the same compiler infrastructure: pretty much every relevant shader or otherwise GPU oriented compiler out there is based on LLVM. As for the parts of the toolchains that are different: that's simply because GPUs and CPUs are inherently very different.

> so that CPU and GPU code can be easily mixed in the same source file

what advantage would it have to mix together into the same source file the code for totally different targets with totally different parallelism models? I find it cleaner and simpler (apart from maybe trivial one-liner shaders that you can embed in a string) to keep them separated. Also makes debugging much easier.

> what advantage would it have to mix together into the same source file

It would be easier to share data structure declarations between the CPU and GPU side (MSL can already do this by sharing header files, a complete integration would just be the next step). GPU buffers and images could be described with [[attribute]] annotations (also very similar to what MSL does to extend C++ with shader semantics).

E.g. maybe a GPU buffer with vertex data could be described like this:

    [[gbu_buffer]] vertex_t vertices[] = {...};

...instead of calling a CreateBuffer(...) 3D-API functions, etc... (the code that's generated by the compiler might actually call a 'builtin' CreateBuffer function under the hood).

TL;DR: MSL is already halfway there by using standard C++ extended with custom attributes, it's just missing the last step to merge the Metal shader compiler with Apple's Clang toolchain.

PS: also if shader functions could be directly defined as 'regular functions' in CPU-side source code (and behind a special function pointer type), there would be no need for string literal shenanigans like this:

https://github.com/floooh/sokol-samples/blob/3f10c1a0620cec9...

(and shader compilation would happen during the regular build and would also generate regular compiler errors - with current toolchains that's only possible with a lot of build system magic)

Reply on news.ycombinator.com