[Intel-gfx] xf86-video-intel: src/xvmc/intel_xvmc.c

[Zou, Nanhai]

>-----Original Message-----
>From: Barry Scott [mailto:barry.scott at onelan.co.uk]
>Sent: 2008年12月18日 23:07
>To: Zou, Nanhai
>Cc: Wang, Zhenyu Z; intel-gfx
>Subject: Re: [Intel-gfx] xf86-video-intel: src/xvmc/intel_xvmc.c
>
>Zou, Nanhai wrote:
>>> -----Original Message-----
>>> From: Wang, Zhenyu Z
>>> Sent: 2008年12月18日 16:07
>>> To: Zou, Nanhai
>>> Cc: intel-gfx
>>> Subject: Re: xf86-video-intel: src/xvmc/intel_xvmc.c
>>>
>>> On 2008.12.17 13:55:41 +0800, Nan hai Zou wrote:
>>>
>>>>  src/xvmc/intel_xvmc.c |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> New commits:
>>>> commit 555eea5411cf8c725df5f1b4cb80198fa6a1225b
>>>> Author: Zou Nan hai <nanhai.zou at intel.com>
>>>> Date:   Wed Dec 17 13:55:07 2008 +0800
>>>>
>>>>      wait vblank before render to fix tearing
>>>>
>>>> diff --git a/src/xvmc/intel_xvmc.c b/src/xvmc/intel_xvmc.c
>>>> index dbde22f..c197e35 100644
>>>> --- a/src/xvmc/intel_xvmc.c
>>>> +++ b/src/xvmc/intel_xvmc.c
>>>> @@ -757,7 +757,7 @@ _X_EXPORT Status XvMCPutSurface(Display
>>>>
>>> *display,XvMCSurface *surface,
>>>
>>>>      }
>>>>      intel_surf->last_draw = draw;
>>>>      /* fill intel_surf->data */
>>>> -    if (0)
>>>> +    if (1)
>>>>      {
>>>>  	drmVBlank vbl;
>>>>  	vbl.request.type = DRM_VBLANK_RELATIVE;
>>>>
>>> This is broken as no care is taken for vblank pipes (e.g I have to
>>> add DRM_VBLANK_SECONDARY for my GM965 LVDS on pipe B).
>>> As XvMC uses Xv port for video playback, we should just fix
>>> Xv port for vblank sync. My suggest is to add a Xv port attribute
>>> for texture video, that can flip vblank wait on or off. Or we
>>> might steal some idea from radeon driver. But doing this in XvMC
>>> lib is wrong to me anyway.
>>>
>>>
>> Wait in server context is not a good idea, either busy wait or sleep, user
>experience will not be good when server stall for vblank.
>> So let's do it in client context.
>>
>
>I agree in principle. But we found that only one app on a host can wait
>for VBLANK. If, for example OpenGL has the vblank
>when you try for it in XvMC VBLANK will be delivered late and cause tearing.
>
>In our application we had to ensure only one process waited for VBLANK
>and then use futext to send a pulse to all our
>other apps that need to be in sync with VBLANK.
>
>We believe that you will need to fix DRM for intel to allow multiple
>clients to wait for VBLANK if you wish to make this work.
>There is code in DRM that changes notification delivery based on the
>number of clients waiting. When there is 1 it works
>great, 2 or more it delivers about ~10ms late. (We see a tear between
>1/3 and 2/3 down the screen).
>

I had a patch that use scheduled buffer swap which basically remove the tearing here. However because there is no way for drm to wait for back buffer render done, 
There is still some race condition, so Eric remove the vblank_swap ioctl call.

However I think do vblank swap asynchronize is better than let client synchronize on vblank, because client can do more thing in the former way. 
Otherwise some cpu time is wasted on waiting for vblank, which is not very good for some high contend video.

I will disable the vblank wait code, and see if I can find a way to fix asynchroize vblank swao.

Thanks
Zou Nan hai

>Barry