[haxiomic]

The haxe-language project 'hxsl' takes a pretty good stab at improving the situation. With hxsl you write your GPU and CPU code in the same language (haxe) and it generates shader strings (in GLSL or AGAL) at compiletime along with CPU code for whatever platform you're targeting.

There's not a lot of documentation around it at the moment but the author explains a little about it in this video https://youtu.be/-WeGME_T9Ew?t=31m49s

Source code on github https://github.com/ncannasse/heaps/tree/master/hxsl

[ordinary]

Sounds like hxsl doesn't actually solve most of the problems described in the article, but just obscures them in a layer of indirection. If you're generating shader strings at compile-time, you still have to compile them at runtime, for instance, just like before, and the GPU/CPU gap is only marginally reduced.

It might solve some other problems with GPU programming, though?

[jdonaldson]

I wouldn't call it obscuring, you can see exactly what is getting passed to the card just the same as if you had written it manually.

The key is that you're dealing with the shader language by using a language, rather than strings. You can use static type information. You can refactor more easily. You can create abstractions over the minor variations in card behaviors more easily.

While hxsl doesn't directly address debugging, it greatly improves your ability to create code examples to isolate the problem.

hxsl does about as much as you could hope for with shader languages, without requiring changes to the cards themselves (e.g. using byte code, which hasn't been standardized yet, and I wouldn't hold my breath for).

In some sense, the arrangement between app logic and shader logic is still a bit like client-server serialization. You still have to pass the data and the commands in a payload, since the two platforms typically do not share memory or have useful common architecture.

[ordinary]

Yeah, you're right. I shouldn't have used that word.

[haxiomic]

That's correct, it makes the situation easier for the programmer rather than improving the pipeline directly, however there are benefits for the added layer of abstraction in terms of flexibility and optimization. When your target platform supports bytecode shaders you can serve those instead, but the developer doesn't have to think about it - the compiler can just choose the best option available. Since the compiler now knows how the shader integrates with the rest of the code it can start merging shaders where optimal and improving dead code elimination.

Ideally this sort of system would be part of the standard graphics pipeline but looks like we could be waiting a while to see that.

[k__]

Isn't this kinda normal with all the query-builders for DBs? Why isn't it used more excessively with shaders? Because they're Turing-complete?

[ufo]

I doubt it. SQL (with enough extensions) can also be Turing complete (or pretty close to it).