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

[Zou, Nanhai]

>>-----Original Message-----
>>From: Owain Ainsworth [mailto:zerooa at googlemail.com]
>>Sent: 2010年5月15日 1:44
>>To: Zou, Nanhai
>>Cc: Daniel Vetter; Intel GFX; Anholt, Eric
>>Subject: Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
>>
>>On Fri, May 14, 2010 at 09:39:22AM +0800, Zou, Nanhai wrote:
>>> Hi,
>>>
>>> Thanks for reviewing the patch.
>>>
>>> To clarify,
>>> This patch is used for H.264/VC1 decoding.
>>> Abstract ring buffer is also needed for our later generation GPUs,
>>> Because there are more types of ring buffer to come.
>>>
>>> H.264/VC1 HW decoding is a bigger requirement than mepg2.
>>> XvMC VLD can only support mpeg2. It is rendering in server context
>>> and lack of post processing features.
>>> We are not going to support it later, our later media work will be
>>> based on vaapi.
>>
>>The need for the multiple rings is ring by me. I've checked the ironlake
>>docs and I see how this works.
>>
>>>
>>> Synchronize between BSD and render ring will be done by VAAPI client.
>>
>>On the other hand, I have a problem with this particular situation.
>>Without a description of exactly how this works I can not be entirely
>>sure, but this sounds very unsafe to me.
>>
>>It looks almost like this is going the way of the DRI1 lock, where
>>userland is in control of mutual exclusion. I'm glad those days are gone
>>and I do not wish to go back there.
>>
>>Look at the rework of xvmc, see how much cleaner it is when it uses GEM
>>to arbitrate and control caches instead of trying to reinvent it badly
>>in userland.
>>
>>Also, (this again is just speculation since I can't see code for
>>userland), doing this sync in userland means *unprivileged clients*,
>>i.e. anyone in userland who can speak to the xserver, get the option to
>>lock the gpu hard trivially. I know our protection against that isn't so
>>good right now (I am mulling over ideas for how to fix this better), but
>>openly depending on behaviour that allows this strikes me as wrong.
>>
>>So, Nanhai, could you please explain how the synchronisation works in
>>VAAPI? I'll have more comments when I can see how this fits and I see if
>>it is in fact safe. As usual, seeing an interface without the user means
>>you only get half the picture and makes review half useless at best.
>>
>>> Let's get simple code works first then we can optimize it.
>>
>>Let's make sure the interface is right before we event think about
>>optimising it.
>>
>>Cheers,
>>

Hi,
	You may check how user space works in VAAPI code, if you have an Ironlake system.
We have install guide at http://intellinuxgraphics.org/h264.html.
We have some customer requests for H.264 decoding, so we point to an early kernel and a similar patch on that page.

Actually no additional synchronize was add to user space, after BSD decoding is done, we map the BSD output for media pipe input command stream, at this point
kernel will wait BSD decoding done before it begin media pipe.

so unprivileged client can not damage GPU with this.

Though this is not the most efficient way to do the work, 

One of our optimize plan is to have double ring buffer for H.264 decoding later, 
e.g. while BSD is decoding to one buffer, media pipe may consume another buffer,

So media and BSD ring can work in parallel. Once we begin to do that, we may need to design a better synchronize method.

Thanks
Zou Nan hai

>>-0-
>>--
>>People will do tomorrow what they did today because that is what they
>>did yesterday.