[Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
nanhai.zou at intel.com
Sun May 16 18:59:22 PDT 2010
>>From: Daniel Vetter [mailto:daniel at ffwll.ch]
>>Sent: 2010年5月14日 23:03
>>To: Zou, Nanhai
>>Cc: Daniel Vetter; Anholt, Eric; Intel GFX
>>Subject: Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
>>On Fri, May 14, 2010 at 11:51:14AM +0200, Daniel Vetter wrote:
>>> So please explain the technical reasons we need this rather complex beast
>>> of code in the kernel?
>>Ok, I owe you my apologies (and a beer). I've read through the HD docs and
>>it looks like bsd decoding for avc/vc1 can't be done without the bsd
>>command stream. What a pain.
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.
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.
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.
Zou Nan hai
>>Mail: daniel at ffwll.ch
>>Mobile: +41 (0)79 365 57 48
More information about the Intel-gfx