[Mesa-dev] [PATCH] i965: Compute VS attribute WA bits earlier and check if they changed.

Chris Forbes chrisf at ijw.co.nz
Wed Dec 3 22:43:20 PST 2014


Either way,

Reviewed-by: Chris Forbes <chrisf at ijw.co.nz>

On Thu, Dec 4, 2014 at 7:36 PM, Kenneth Graunke <kenneth at 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


More information about the mesa-dev mailing list