[espadrine]

The "compiler in the driver" part of this post sounds awfully like the "asm.js vs. NaCl" debate.

Sure, building an IR from scratch is fun. But making it truly cross-platform and ready for many usages is really hard. Also, the GLSL source is an IR between the programmer's intent and the driver's behaviour. Code is just another type of binary. It is just slightly harder to parse, but not by much; without performance comparisons, a complaint about how hard it is to parse code is invalid.

Feeding the driver GLSL can also yield much clearer error messages for programmers. I can only imagine what kinds of error messages the IR compiler would produce. Sure, hopefully, our cross-platform IR would be accepted by all GPUs without pain, but that's improbable.

Regardless, starting from a clean slate is much harder than working our way from the current state to an improved OpenGL. Just like few browsers are on board with NaCl, few GPU makers would be on board with a brand new design.

[fzltrp]

> Sure, building an IR from scratch is fun. But making it truly cross-platform and ready for many usages is really hard.

It's not that hard, as long it remains as close as possible to the source language (ie. GLSL). Iow, as the OP is advocating for, an AST of the shaders. This removes the cost of parsing the source code (but requires on the other hand to validate the AST, so this isn't exactly a complete gain, but definitely an progress compilation wise). However, I suppose that what motivated the choice of using GLSL source directly is the simplicity of the approach: no need to build the GLSL scripts separately. When working with interactive tools, it's a non negligible comfort, imho. Another interesting aspect is the ability to build the scripts dynamically, like people do with SQL. I wonder if this approach is used by professional game studios.