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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
