On 27 October 2011 10:20, Ian Romanick <i...@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@lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
