dcompute VS shaders

Shameless plug: LDC (the LLVM based D compiler) can already target CUDA (and OpenCL) and wraps its API and all of the nasty details involved in replicating <<<>>> kernel launches with https://github.com/libmir/dcompute/ with a sane syntax that's type safe. LLVM handles the codegen, and all of the "magic" is done in the library.

As noted elsewhere it seems your experience is somewhat outdated: the releases of the LLVM D Compiler (one of the two compilers worth using for production builds, the other being GDC) are buffered to the bugs introduced in DMD (which is more stable than it used to be although there are still regressions), and there is a fork based GC available for linux, but as the GC will only ever trigger on allocation, don't use it and it won't collect.

> While C++ is not by any means a great meta-language, it's improved considerably since that time.

C++ has also painted itself into a corner multiple times too, which despite being technically an improvement over the status quo are lacking severely in their utility. C++ screwed up "constexpr if" big time by always introducing a scope (which costs you a pair of {}'s in the rare occasion you need one) which means you can't conditionally insert declarations (i.e. variables, structs/classes, functions).

> but beyond the novelty you'd hardly find a mature or reliable codebase written by a team of professionals using hacks like [string manipulation and mixins].

They are a wonderful hack when you need them and nothing else will do what you want. This is not unlike resorting to macros in C++, except that its hygienic, unlike macros.

I'm not claiming the project is mature and I'm only one person, but reliable definitely out there. The most heinous set of string mixins i've ever written[1] has definitely got to be the code for generating wrappers to call the OpenCL object property querying functions (clGetDeviceInfo & friends). You need to pass a size and a void pointer to the address of the return object that you have to call once, twice or more (depending on the type of the queried property) to figure out how much memory you need to allocate to call it again.

The important thing is that the interface[2] you use to drive this code generation is very clean and return on investment for getting the generic case correct is large.

[1]: https://github.com/libmir/dcompute/blob/master/source/dcompu...

It may be close to a technical impossibility, but the Circle compiler by Sean Baxter is attempting it. That's based on an aggressive "de-pointerization" (see [1] in particular for details). There's also academic work[2] to compile C++ to shaders. I agree that it's an open question how well that will work out.

Also as pointed out elsethread, now that buffer device address is starting to land, the friction to compile pointer-intense C++ code should decrease even more. These are exciting times!

[1]: https://github.com/seanbaxter/shaders#approaching-circle-sha...

[2]: https://arxiv.org/abs/2109.14682

You can use circle c++ shader https://github.com/seanbaxter/shaders but it's limited to look linux afaik?

First we have Circle C++ shaders, which pretty much would tick all the boxes. Problem is it's closed source and only compiles host code on linux. Closed source isn't the biggest of issues actually, but prevents anyone from fixing the developers issue with interfacing with the windows ABI and getting the thing working on windows (which itself isn't something they are able to fix because windows doesn't provide the documentation to work with their ABI). However you could use it separately to compile your SPIR-V for windows since SPIR-V doesn't care about platform itself.

Yes, Vulkan GPU source is split, though technically in a way that makes it more similar to CUDA. Vulkan uses an intermediate format instead of consuming text code directly, meaning new features are easier to add and frontend code doesn't need to be passed to the vendors driver compiler. SPIR-V is like DXIL or PTX code for CUDA, basically LLVM IR for GPUs. The CUDA compiler compiles your device code into PTX code, and it's what enables you to have "non split" source code. There's even an option to have separate PTX code in CUDA. There are few projects that aim to bring Vulkan SPIR-V into source, including Rust GPU for rust (though it will still have to be in a separate file) and Circle C++ shader for C++.

My favorite use is putting user-defined attributes on data members, and using reflection to generate a UI to manipulate those values. I do it with these shadertoys:

https://github.com/seanbaxter/shaders#reflection-and-attribu...

Just mark your declarations up with custom attributes:

I'm confused what is novel about this paper. We already have unified shader programming with circle C++, with way more features, and instead of having an SPIR-V compiler, they made a source to source compiler... We have quite a few of those.

I think shader specialisation is handled pretty well in circle. Since you can essentially run arbitrary C++ code at compile time, selection and specialisation of a shader can even depend on hardware specific benchmarks. There is an extensive repo with examples here: https://github.com/seanbaxter/shaders. One example decodes a sprite sheet stored as a png at compile time and creates a specialised compute shader for it. You can also easily implement a control UI based on reflection of uniform shader parameters.

There's a project doing something similar for C++ called Circle which is pretty incredible. In its core Circle is an extension of standard C++ which adds a ton of metaprogramming facilities and other productivity enhancing features, things the base language sorely lacks like full compile-time execution of regular C++ code which lets you do anything you can normally do from runtime during compile-time (including file I/O and networking), reflection, typed enums, pattern matching, hygienic macros, list comprehensions and language-native ranges, first class paramater packs and much more.

I use them to automatically generate an ImGui interface for controlling a shadertoy here: https://github.com/seanbaxter/shaders/blob/master/README.md#user-attributes-and-dear-imgui