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