On 12 December 2012 00:02, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> writes:<br>
<br>
> This patch series adds varying packing to Mesa, so that we can handle<br>
> varyings composed of things other than vec4's without using up extra<br>
> varying components.<br>
<br>
</div>Results for glbenchmark 2.7 at 320x240 (units of fps):<br>
<br>
    N           Min           Max        Median           Avg        Stddev<br>
x 109            86            87            86     86.027523    0.16435709<br>
+ 109            86            87            87     86.963303    0.18888589<br>
Difference at 95.0% confidence<br>
        0.93578 +/- 0.0470052<br>
        1.08777% +/- 0.0546397%<br>
        (Student's t, pooled s = 0.177047)<br>
<br>
I chose a tiny resolution here to try and focus on the path that we<br>
think this will help in (clipping overhead reduction).  The stupid app<br>
prints an integer fps, so it can be hard to get any signal out of small<br>
changes at higher resolutions.<br></blockquote><div><br></div><div>I'm not certain that clipping overhead reduction is going to be significant for Gen6+.  On Gen4-5, the clipper has to write out new VUE entries whenever it generates new vertices, and it has to adjust the interpolation of all the varyings, so definitely there should be a reduction of overhead there.  But on Gen6+, varyings are interpolated using barycentric coordinates, so the clipper doesn't have to adjust any varyings or write out any VUE entries--it just modifies the topology, the gl_Position values, and the barycentric coordinates being sent to the SF, and the overhead for doing that should be independent of the number of varying slots used.</div>
<div><br></div><div>The place where I'm expecting overhead to be reduced is in writing to the VUE at the end of the vertex shader, and reading from the VUE at the start of the fragment shader.  I don't know whether the effect will be more significant in the fragment shader or the vertex shader, so it might be worth trying a large window size too.</div>
</div></div>