[Mesa-dev] [PATCH 17/17] i965: Disentangle batch and state buffer flushing.

Kenneth Graunke kenneth at whitecape.org
Wed Sep 6 15:26:53 UTC 2017


On Wednesday, September 6, 2017 4:23:37 AM PDT Chris Wilson wrote:
> Quoting Chris Wilson (2017-09-06 11:13:54)
> > Quoting Kenneth Graunke (2017-09-06 01:09:50)
> > > We now flush the batch when either the batchbuffer or statebuffer
> > > reaches the original intended batch size, instead of when the sum of
> > > the two reaches a certain size (which makes no sense now that they're
> > > separate buffers).
> > > 
> > > With this change, we also need to update our "are we near the end?"
> > > estimate to require separate batch and state buffer space.  I obtained
> > > these estimates by looking at the size of draw calls in the Unreal 4
> > > Elemental Demo (using INTEL_DEBUG=flush and always_flush_batch=true).
> > > 
> > > This will increase the batch size by perhaps 2-4x, which will almost
> > > certainly have a performance impact, and may impact overall system
> > > responsiveness.
> > > 
> > > XXX: benchmark, may need a lot of tuning.
> > 
> > What were you thoughts to not flushing the batch on swapping the state,
> > since that just needs to re-emit STATE_BASE?

With STATE_BASE_ADDRESS being a pretty heavy pipeline stall, I figured
that we may as well simply flush and kick some of the work off.  It's also
simpler to implement.

I don't expect growing to be very common - the hope is that the pre-draw
batch/state estimates will cause us to flush before we hit the end of the
original intended batch size, but if our estimates are off (say there's a
big draw at an inopportune time) we can survive.

Growing actually ended up being pretty cheap, though, except for the
memcpy...
 
> Also given the restriction upon the surface state that only allows it to
> grow once, why not just make it 64k and replace upon filling?
> -Chris

Not sure I follow - the batch is restricted to not grow forever, but the
state buffer should have no restrictions.  I'm also growing buffers by
1.5x rather than the usual 2x, though I guess that means 32k -> 48k ->
72k...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170906/f2dc15df/attachment.sig>


More information about the mesa-dev mailing list