AST and source-to-source translation

I like the looks of this library, and it nicely solves some of the problems 
inherent in using GL's shader API.  Unfortunately, it can't solve some of the 
problems we have in our current project, which requires support for older 
versions of GL (and GL ES) that glfx cannot easily support.

This requires parsing a higher level shading language and generating metadata 
from it in order to create some data structures and other API calls.  For 
instance, instead of using layout location for attributes, it would require 
generating a list of attribute names and their desired positions and then 
calling glBindAttribLocation just before linking the program.  Uniform blocks 
are even trickier to work around (e.g. on GLES) but it's doable (requires 
abstractions in other parts of the graphics stack, but any decent application 
graphics architecture will have those anyway).

These kinds of features can be most easily supported by updating the glfx 
parser to build an AST instead of directly generating source strings, using 
that to build a list of declarations and properties (list of attributes, list 
of uniform blocks, list of entry points, etc.), and then writing multiple "code 
generators" for different target platforms.  This is essentially what Cg does, 
for instance, albeit in a non-Open way (and still without GL ES support, 
unfortunately).

What I'd like to see from glfx in future versions is a means of getting that 
metadata and then passing in a code generator (with at least the current 
4.20-based one being provided with the library, of course).  The higher level 
abstractions aren't necessary, but at least being able to get the metadata is 
essentially mandatory for supporting other GLSL versions.

It might also make it possible to compile the glfx shaders into HLSL, should 
someone find themselves needing to quickly port to a Direct3D-only platform 
like the Xbox.  (Or just to support Intel better, since their drivers happily 
support D3D10 even though they refuse to update the GL support to anything 
relatively recent.)

Original issue reported on code.google.com by Sean.Mid...@gmail.com on 4 Feb 2012 at 1:24

Thanks for your feedback.

Current versions are aimed towards newer glsl versions, mostly because it's 
simpler.
However, building an AST is a completely feasible option which I do plan to 
implement in the future if there will be demand for supporting lower GL 
versions (or GLES for that matter), or in general to support abstraction.

I'm already playing around with this idea for textures (and samplers). Though 
checked in, it's still a WIP and subject to major changes.

I think that before I actually sit down and write such code I need to 
understand what kind of interface the user wants and how to abstract the 
metadata well enough so that general usage of glfx won't become too difficult.

I'd be happy to get more input on this subject.

Original comment by max.snif...@gmail.com on 4 Feb 2012 at 5:08

revel8n / glfx

AST and source-to-source translation #1