On 11/23/2011 05:42 AM, Marek Olšák wrote:
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke<kenn...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
