On 27 October 2011 10:20, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 10/26/2011 11:11 AM, Brian Paul wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the linker is mis-counting gl_TexCoord[] varying vars when linking.<br>
<br>
For example, if we have this vertex/fragment shader combination:<br>
<br>
// vs<br>
void main()<br>
{<br>
gl_Position = ftransform();<br>
gl_TexCoord[6] = gl_MultiTexCoord[0];<br>
}<br>
<br>
// fs<br>
void main()<br>
{<br>
gl_Color = gl_TexCoord[6];<br>
}<br>
<br>
<br>
the varying_vectors counter in assign_varying_locations() will be 7, not<br>
1. It seems the gl_TexCoord var is being seen as an array of 7 elements<br>
and we're counting the whole array rather than the individual elements<br>
used.<br>
</blockquote>
<br></div>
This is correct behavior. Page 54 (page 60 of the PDF) of the GLSL 1.20 spec says:<br>
<br>
"As with all arrays, indices used to subscript gl_TexCoord must<br>
either be an integral constant expressions, or this array must<br>
be re-declared by the shader with a size. The size can be at<br>
most gl_MaxTextureCoords. Using indexes close to 0 may aid the<br>
implementation in preserving varying resources."<br>
<br>
The last sentence is the most important bit.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is causing a link failure in an app here because the vs/fs shader<br>
pair uses several user-defined varying vars plus gl_TexCoord[4]. The<br>
varying count exceeds GL_MAX_VARYING_FLOATS even though we're really not<br>
using that many varying slots.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
</blockquote><div><br>FTR, I don't have any immediate plans to work on varying packing, since it's not required to implement the new 1.30 interpolation qualifiers. I may tackle it in the long term, but I think I need to get my feet wet with some simpler linker features first.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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.<div>
<div></div><div class="h5"><br>
______________________________<u></u>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br>