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. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
