[Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure

[Daniel Vetter]

On Mon, May 17, 2010 at 09:59:22AM +0800, Zou, Nanhai wrote:
> H.264 HW decoding is a huge amount of work, 
> I can image much more works needed later. 
> Gem may need some more changes if we continue to improve H.264 decoding work.
> e.g currently we found H.264 decoding used too much GPU memory cause 
> 2 HD H.264 video decoding slow, we are tring optimize gem GPU memory usage.
> 
> Even some works we may do with current ring buffer, 
> We'd better split it to maximum utilize GPU power.

You might want to try out the fair-lru-eviction patch by Chris Wilson.
When you're pushing gtt usage to the limit, this should behave much better
than the current code.

> E.g. on Gen6, we have blitter ring buffer. Though blitter can be done 
> in render ring buffer, implement and using blitter may improve throughput. 
> 
> >>I'm currently crawling through the docs. It looks like we also need a new
> >>gpu domain (something like I915_GEM_DOMAIN_BSD) in addition to a new
> >>execution domain to properly support flushing and coherency. This way
> >>round my concerns about userspace synchronization and the flush-both-rings
> >>semantics would be void, too.
> >>
> 
> Actually we have considered adding BSD_DOMAIN when we first design the patch,
> Synchronize BSD ring will done at mapping time of media ring buffer.
> Since BSD ring will always write, media ring will always read. 
> No multiple client need to refer to one ring buffer.

Well, the bsd(write) -> render(read) is exactly the kind of cache
coherency transition gem is supposed to handle. Differentiating between
these two by the ring the object is sitting on looks hackish to me. We're
not really short on bits for domains after all.

> We decided to keep this simple at the beginning till we need to do some additional optimize on that.
> 
> We almost do not flush both rings in hot path. If you check the code, 
> Flush both ring will only happen at slow path, e.g gpu_idle.

Add it to the list of things I've got wrong while trying to read your
patches ;)

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48