ping. :) On 08/10/2015 11:48 AM, Matt Turner wrote: > On Mon, Aug 10, 2015 at 10:12 AM, Ian Romanick <i...@freedesktop.org> wrote: >> From: Ian Romanick <ian.d.roman...@intel.com> >> >> On many CPU-limited applications, this is *the* hot path. The idea is >> to generate per-API versions of brw_draw_prims that elide some checks. >> This patch removes render-mode and "is everything in VBOs" checks from >> core-profile contexts. >> >> On my IVB laptop (which may have experienced thermal throttling): >> >> Gl32Batch7: 3.70955% +/- 1.11344% > > I'm getting 3.18414% +/- 0.587956% (n=113) on my IVB, , which probably > matches your numbers depending on your value of n. > >> OglBatch7: 1.04398% +/- 0.772788% > > I'm getting 1.15377% +/- 1.05898% (n=34) on my IVB, which probably > matches your numbers depending on your value of n.
This is another thing that make me feel a little uncomfortable with the way we've done performance measurements in the past. If I run my test before and after this patch for 121 iterations, which I have done, I can cut the data at any point and oscillate between "no difference" or X% +/- some-large-fraction-of-X%. Since the before and after code for the compatibility profile path should be identical, "no difference" is the only believable result. Using a higher confidence threshold (e.g., -c 98) results in "no difference" throughout, as expected. I feel like 90% isn't a tight enough confidence interval for a lot of what we do, but I'm unsure how to determine what confidence level we should use. We could experimentally determine it by running a test some number of times and finding the interval that detects no change in some random partitioning of the test results. Ugh. > I'll review soon. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
