[Mesa-dev] RFC: Haswell resource streamer/hw-generated binding tables (v2)
eric at anholt.net
Mon Oct 14 10:50:24 PDT 2013
Abdiel Janulgue <abdiel.janulgue at linux.intel.com> writes:
> On Friday, October 11, 2013 11:39:53 AM Eric Anholt wrote:
>> As a general rule, we don't land code whose purpose is performance
>> improvement if it doesn't actually improve performance. If more work is
>> needed to make it actually improve performance, then we wait until then.
>> As I understand it, the thing that you think will make this eventually
>> actually improve performance is state flagging that indicates which
>> individual surfaces need updating. Since that should improve
>> performance even in the non-resource-streamer case, it can be pursued
> One optimization idea that I had in mind a few months ago was to find a way to
> reduce emission of surface state objects. Currently, we rebuild surface states
> every time we generate binding tables. The idea is to basically relocate the
> surface state indirect state objects on a separate buffer object from the
> command batch. Using the resource streamer, we can then publish the deltas
> when indices referring to them needs to be changed.
> So whenever a surface needs to be used, instead of rebuilding the whole
> binding table structure the driver can essentially say on a per-slot basis
> "hey a surface got activated but it it was previously bound to index 10, lets
> rebind it to index 12".
> This potentially reduces the CPU overhead of generating and uploading binding
> tables. I did a previous experiment and found out that it reduced generation
> of surfaces states to as much as 99% with this approach. What do you think?
This has the downside that new batches implicitly reference the surfaces
that were referenced by old batches. Imagine a video player that's
uploading a new frame to a new BO every time -- until the surface cache
BO wraps, the old BO stays referenced and app memory usage just goes up
and up. The workaround is to have hash table you look into at BO free
time that tells you what relocations to rip out of the surface cache.
There's a bunch of overhead you get into when doing this, which is why
we moved away from surface state caching originally.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the mesa-dev