Either way, Reviewed-by: Chris Forbes <chr...@ijw.co.nz>
On Thu, Dec 4, 2014 at 7:36 PM, Kenneth Graunke <kenn...@whitecape.org> wrote: > On Thursday, December 04, 2014 03:13:59 PM Chris Forbes wrote: >> What's the perf impact on a platform which actually needs this? >> >> I think there would be some further substantial gains to be had by >> giving this its own dirty bit -- piles of other atoms listen to >> BRW_NEW_VERTEX_PROGRAM, but don't care about the workaround bits. > > Well...it looks like there are only 5: > > gen6_sol_surfaces > brw_texture_surfaces > brw_vs_samplers > brw_vs_pull_constants > gen7_vs_state > > The last two already listen to BRW_NEW_VS_PROG_DATA (CACHE_NEW_VS_PROG), > which is pretty much guaranteed to be flagged if you're switching WA bits. > > gen6_sol_surfaces only happens on Gen6; I haven't measured perf there yet. > > brw_texture_surfaces and brw_vs_samplers are definitely not necessary, but > also get flagged on BRW_NEW_BATCH. The test I was measuring does lots of > small batches, so they pretty much happen all the time anyway. > > So, at least on Haswell, using a separate dirty bit doesn't actually help > this benchmark much - I re-measured and got very similar numbers. > > But you're right, three of those dependencies are totally unnecessary, and I > do hate adding bogus reasons to re-emit surfaces and sampler state. I'm happy > to send a V2 that uses a separate dirty bit - it's a lot less confusing that > way, anyhow... > > --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
