Iris should make use of JCPP for preprocessing GLSL source files & ID mappings
coderbot16 opened this issue ยท 7 comments
JCPP is a Java library that implements a C preprocessor: https://github.com/shevek/jcpp
This is needed for properly parsing comment & const directives (like DRAWBUFFERS) and parsing block ID mappings. For block ID mappings we currently have a basic preprocessor implementation that works for most files in the wild, but obviously it would be preferable to use a proper preprocessor.
We could also fully preprocess source files before sending them to the driver. This would allow for more robust injection of non-preprocessor code fragments into shaders without accidentally injecting them before #extension directives, like what currently happens with Spectrum (#533).
Even better, we could hoist #extension directives to the top of the file, so that shader packs are more likely to compile on Mac & Mesa drivers. Most drivers don't enforce the positioning of #extension drivers, but these drivers do. IMO, it's likely best to just accept the fact that shader authors put #extension directives in the middle of files, and fix those shaders up ourselves. This would avoid requiring Linux users to make weird changes to their global system configuration like with #391.
After a bit of reading, it seems JCPP hasn't been updated in almost 2 years (and still uses Gradle 4). Is there any updated alternative, or do we plan to pick it up?
Normally that would be a bad sign, but for something implementing a standard that's only had small tweaks in the past few decades, it's not a huge concern.
One challenge is retrofitting JCPP to support (and pass through) the extra directives in GLSL, since it was only designed to work with C as far as I know. That shouldn't be super hard though.
Main issue I'm worried about is the process of vendoring JCPP (such as we did with JOML.) JCPP seems to use some external dependencies for logging and other weirdness, so that will have to be solved first.
JCPP's code is a bit messier than I'd like, yes. I imagine some overall cleanup will be needed before vendoring it in - including trimming down any external dependencies and similar things.
It also appears to have its own expression parser and evaluator included in the source code for preprocessing purposes - a longer term goal (after everything is actually working and more critical things are fixed) would be merging that with Kroppeb's expression code so we don't have two expression evaluator engines in the same overall codebase.