[Mesa-dev] [PATCH] i965: Compute VS attribute WA bits earlier and check if they changed.
Kenneth Graunke
kenneth at whitecape.org
Wed Dec 3 22:36:24 PST 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141203/b8e28668/attachment.sig>
More information about the mesa-dev
mailing list