[Mesa-dev] RFC: Haswell resource streamer/hw-generated binding tables (v2)

[Abdiel Janulgue]

On Monday, October 14, 2013 10:50:24 AM Eric Anholt wrote:
> Abdiel Janulgue <abdiel.janulgue at linux.intel.com> writes:
> > 
> > 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.

Why not use a sufficiently-sized surface cache buffer and as soon as it 
approaches the wrap limit either (1) do a clear_relocs then flush batch or (2) 
just throw it away and reallocate a new one? To reduce overhead, it has to be 
sufficiently sized so that the wrap limit does not get reached too often.

Aside from video player case, this would help games that does not upload 
textures every frame. But I guess most games should do that already, no?

> 
> There's a bunch of overhead you get into when doing this, which is why
> we moved away from surface state caching originally.