[Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
Owain Ainsworth
zerooa at googlemail.com
Fri May 14 19:43:50 CEST 2010
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,
-0-
--
People will do tomorrow what they did today because that is what they
did yesterday.
More information about the Intel-gfx
mailing list