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

[Paul Berry]

On 27 October 2011 10:20, Ian Romanick <idr at freedesktop.org> wrote:

> 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.
>

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.


>
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111028/71d449df/attachment.htm>