[Cogl] [PATCH v2] cogl-gles2-context: Append wrapper shader to user shaders

[Robert Bragg]

On Fri, Aug 17, 2012 at 2:37 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> The SGX GLSL compiler refuses to accept shaders of the form:
>     void foo();
>     void bar() {
>         foo();
>     }
> where foo is undefined at glShaderSource() time, left for definition at
> link time.  To work around this, simply append the wrapper shader to
> user shaders, rather than building a separate shader that's always
> linked with user shaders.

Thanks for the patch, and sorry for the delay in replying.

Hmm that's a bit awkward. The reason it was done this way was to hide
the trick from the application. If we append to the user's shader then
we probably need to think about removing the wrapper if the
application queries back its source. Since we'd like to be able to use
Cogl's GLES 2.0 integration to support WebGL we'd like to be quite
careful not to leak things through the abstraction if possible.

Something that doesn't look right is that the patch is appending not
just to every user vertex shader but instead to every string-fragment
of every vertex shader. I.e. glShaderSource lets you specify the
source of a single shader by passing a vector of strings that are
effectively concatenated by the compiler and this patch adds a wrapper
to each string in the vector instead of extending the vector to point
to the prelude at the beginning and the wrapper at the end.

Something I'm a bit unsure about is what happens for applications that
are creating multiple vertex shaders to be linked together with one
main function (with non SGX drivers) and how we can be sure to only
append to the shader containing the main function instead of appending
multiple wrappers which I suspect will lead to a link failure.

I have a patch can forward to the list to ensure the wrapper is only
added once per shader which we can squash back into your patch, though
I didn't add any code to strip the wrapper when an application queries
back the source.

I don't really know what we should do at this point since we have two
approaches that both work and fail in different circumstances but
neither works in all cases :-/

If we had a reliable way to know which shader has a main function then
we could reliably switch to the concatenation approach always but that
sounds like we need bring in a glsl compiler front-end either from
Angel or Mesa to manage that.

Another option is that we use the cogl-gpu infrastructure so we can
black-list your SGX + driver combo and then apply the concatenation
approach only as a bug workaround; this seems like it would be the
most straightforward in the short term.

Finally, although I can guess the answer, I wonder if you are in a
position to submit a bug to whomever is responsible for your SGX
driver and double check that there really is no chance of it being
fixed for you.

kind regards,
- Robert