[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