[Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker

Ian Romanick idr at freedesktop.org
Wed Nov 23 10:27:29 PST 2011


On 11/23/2011 05:42 AM, Marek Olšák wrote:
> On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke<kenneth at whitecape.org>  wrote:
>> So, again, if the interest is in making more apps succeed, we should
>> start with varying packing.  That's useful all around, and I doubt
>> anyone can dispute that it's necessary.
>
> No, that's not the problem. Varying packing is indeed important, but
> it's far less important that the problem this discussion is all about.
> We should start with breaking arrays into elements when possible when
> doing those checks. Consider this shader:
>
> varying vec4 array[5];
> ...
> gl_TexCoord[7] = ...; /* adds 8*4 varyings components */
> array[4] = ...; /* adds 5*4 varying components */
>
> /* linker stats: 13*4 varying components used -->  FAIL */
> /* r300g stats: 2*4 components used ->  PASS */

Do you have any concrete, real-world examples of this?  If so, can you 
name the applications?  I'd like to add tests that model their behavior 
to piglit.

Every example that I have seen has looked more like:

varying vec2 array[4];  // should be 8 varying components

gl_TexCoord[2] = ...;
gl_TexCoord[5] = ...;   // should be at most 24 varying components

for (i = 0; i < array.length(); i++)
     array[i] = ...;

In this case, array gets stored as 4 vec4s using 16 varying components. 
  As a result, 16+24 doesn't fit when 8+24 would have.

> It's the exact same problem with uniforms. The thing is r300g has
> these optimizations already implemented for varyings and for uniforms.
> Disabling not just one, but two optimizations at the same time just
> because they should be done in the GLSL compiler and not in the
> driver, seems quite unfriendly to me, almost like you didn't want me
> to enable them. I would probably implement them in the GLSL compiler,

That's overstating things quite a bit.  The optimizations aren't 
disabled.  I'm sure that r300g still gets significant performance 
benefits from this, and nothing has changed that.  The resource counting 
has always existed, so nothing has changed there either.

> say, next year (I don't and can't have deadlines), but there is no
> reason for me to do so, because I already have them.
>
> Marek


More information about the mesa-dev mailing list