[Mesa-dev] mis-counting varying vars in the linker

[Ian Romanick]

On 10/26/2011 11:11 AM, Brian Paul wrote:
>
> I think the linker is mis-counting gl_TexCoord[] varying vars when linking.
>
> For example, if we have this vertex/fragment shader combination:
>
> // vs
> void main()
> {
> gl_Position = ftransform();
> gl_TexCoord[6] = gl_MultiTexCoord[0];
> }
>
> // fs
> void main()
> {
> gl_Color = gl_TexCoord[6];
> }
>
>
> the varying_vectors counter in assign_varying_locations() will be 7, not
> 1. It seems the gl_TexCoord var is being seen as an array of 7 elements
> and we're counting the whole array rather than the individual elements
> used.

This is correct behavior.  Page 54 (page 60 of the PDF) of the GLSL 1.20 
spec says:

     "As with all arrays, indices used to subscript gl_TexCoord must
     either be an integral constant expressions, or this array must
     be re-declared by the shader with a size. The size can be at
     most gl_MaxTextureCoords. Using indexes close to 0 may aid the
     implementation in preserving varying resources."

The last sentence is the most important bit.

> This is causing a link failure in an app here because the vs/fs shader
> pair uses several user-defined varying vars plus gl_TexCoord[4]. The
> varying count exceeds GL_MAX_VARYING_FLOATS even though we're really not
> using that many varying slots.

We do have other problems with varyings that may be the actual cause of 
the failure.  We don't currently pack multiple variables into a vec4, so 
even using 17 float varyings will fail today.  This is the topic of bug 
#34201.

I believe that Paul is going to work on this as part of his work to 
implement the new 1.30 interpolation qualifiers.  There were also some 
patches by Vincent Lejeune posted to the mesa-dev list a couple months 
ago.  These patches had some significant issues, and Vincent never 
responded to the review comments.

I think this will need to be implemented in at least two parts. 
Something like Vincent's code should be used in the linker to pack 
varyings with identical interpolation modes.  This should cover 90% of 
cases.  Each driver will need some device-specific code to handle 
packing varyings with differing interpolation modes.  I don't know about 
other hardware, but it looks like i965-like GPUs will have some issues 
with mixing "flat" with either "smooth" or "noperspective".  Mixing 
"smooth" and "noperspective" shouldn't be a problem, but the driver 
still needs to know that they've been mixed.