Shader issue: #extension repeated in shader

[Jim Graham]

Yes, we should look to have a separate header block that various shader 
program pieces can append to independently of the code they insert into 
the main body of the shader.  I've been through it a few times and could 
probably come up with something if needed, but do you feel confident 
trying to modify that particular piece of how the shader programs are 
assembled in the CompileJSL code?  It should only really involve coming 
up with a separate StringBuilder for the extensions section and then 
splitting the various substitutions into a substitution and an append.

The code can be found in:

buildSrc/src/main/java/com/sun/scenario/effect/compiler

In particular, the ES2Backend.java file is responsible for the 
construction of the GLSL files...

			...jim

On 12/30/2015 4:33 AM, Johan Vos wrote:
> When upgrading a Nexus 6 from Android 5.1.1 to Android 6, the JavaFX 3D
> stopped working.
> The relevant error is this:
>
> java.lang.RuntimeException: Error creating fragment shader
> in
> com.sun.prism.es2.ES2Shader.createFromSource
>
> The shader compilation failed with this error:
> GLSL compile error:  Extension directives must occur before any
> non-preprocessor tokens.
> which occurs in
>
> When debugging this, it seems the fragment shader passed
> to glCtx.compileShader is created by ES2PhongShader.getShader() which
> starts from main1Light.frag and which will do a replaceAll for a number of
> statements which will replace those statements with other shader code that
> also contains an #extension directive.
>
> As a result, the resulting shader source contains a number of identical
> #extension directives. It seems the latest drivers on Android are much more
> strict in compiling shaders, and they complain about the position of the
> extension directives.
>
> It seems to me some post-processing needs to be done on the result of the
> replaceAll() statements when creating the fragment shader in
> ES2PhongShader.getShader(ES2MeshView meshView, ES2Context context)
>
> I did a quick and dirty workaround for this in the 8u-dev-tree on
> javafxports:
> https://bitbucket.org/javafxports/8u-dev-rt/commits/a84eb188c73ff60b68c016f14b6ebf85449a6bbe
>
> With this patch, JavaFX 3D works again on Android, but it is not the best
> post-processing solution.
>
> Another solution might be to remove the extension directives from the
> individual files in glsl and add them at the end of the processing chain?
>
> - Johan
>