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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
