Tearing with 8600GTS, 256.35, xine-lib-1.2 when avoiding XLockDisplay()

rnissl · 07-11-10, 04:36 PM

Hi,

xine-lib's video_out_vdpau.c uses XLockDisplay() when calling VDPAU functions. This is due to some issues caused by xine-ui. I was trying to fix those xine-ui issues so that these XLockDisplay() calls can be avoided (these calls synchronize decoding and displaying and may be the reason for some other issues).

After fixing the issues and disabling those XLockDisplay() calls, tearing appeared. Reenabling the XLockDisplay() calls removed tearing again.

Bye.

**Stephen Warren** · 07-14-10, 12:09 PM

rnissl, Can you please describe the tearing a little? In particular, does it simply look like typical tearing one gets when blitting an image to the screen without syncing to vblank, or something else, e.g. more persistent decoding corruption? Are you using the blit or overlay-based presentation queue; see the README for details on what X configurations allow/cause one to be used over the other (e.g. disable the X composite extension). Or, just move a window around, and see if you see flashes of the chroma key color as you move the window; if so, then you're already using the overlay.

Can you supply complete details on how to reproduce this (e.g. patches to remove the xine-ui problems you mentioned, which svn/... version to apply them against, do I simply comment out every single XLockDisplay call that I see in the xine-lib source or ... etc.) Thanks.

rnissl · 07-14-10, 04:50 PM

Hi,

Quote:

Originally Posted by Stephen Warren

rnissl, Can you please describe the tearing a little? In particular, does it simply look like typical tearing one gets when blitting an image to the screen without syncing to vblank, or something else, e.g. more persistent decoding corruption?

Well, I'd say typical tearing. I've recognized it while watching a soccer game when the camera was panning. The upper "halve" of the image showed a horizontal offset to the lower "halve" of the image.

Quote:

Originally Posted by Stephen Warren

Are you using the blit or overlay-based presentation queue; see the README for details on what X configurations allow/cause one to be used over the other (e.g. disable the X composite extension). Or, just move a window around, and see if you see flashes of the chroma key color as you move the window; if so, then you're already using the overlay.

I've always used overlay based presentation queue. Occasionally I use blit based presentation queue to be able to take screen shots of the window. With overlay based presentation queue, I get just a unique colored screen shot (i. e. chroma key color). So I'd say overlay based presentation queue is active and working.

Quote:

Originally Posted by Stephen Warren

Can you supply complete details on how to reproduce this (e.g. patches to remove the xine-ui problems you mentioned, which svn/... version to apply them against, do I simply comment out every single XLockDisplay call that I see in the xine-lib source or ... etc.) Thanks.

Meanwhile my fixes have been commited. Just pull xine-lib-1.2 HEAD and xine-ui HEAD. Then change one define in xine-lib-1.2/src/video_out/video_out_vdpau.c. Near the beginning you'll find the define LOCKDISPLAY. Just comment out this define. It will disable all X(Un)LockDisplay() calls.

I wonder whether this tearing is related to my other issue (what does these errors mean). After having recognized tearing for the first time I thought it was a matter of my changes regarding XLockDisplay(). So I reverted that changes and tearing went a way. Then I enabled my changes again, but I couldn't reproduce the tearing. I was watching soccer games for hours (usually I'm not that interested in soccer) just to find some tearing. It didn't appear. Today I think I had tearing again and I think the only difference to watching the soccer games is that I did switch to full screen (1920x1200) today while I was watching the soccer games in a window (when I recognized the tearing for the first time I think I had resized the window too). Stream resolution for the soccer games was 1280x720 and the output window was of size 1024x576. The today's stream had a resolution of 720x576 @ 16:9. I've to prove this further in case you cannot reproduce.

Bye.

**Stephen Warren** · 07-15-10, 09:27 AM

One thought on this: Decode->display interlock is performed within the VDPAU driver. That is, if you decode to a given surface and then display it, VDPAU internally guarantees that display of that surface won't start until the decode has completed. However, the driver performs no display->decode interlock; the application must wait until the presentation queue has completed displaying the image (i.e. its status is IDLE) before requesting that a new decode operation begin on that surface. If the application doesn't do this, the decoder might write to a surface while it's still being displayed, which could look like tearing. Given the presentation queue errors mentioned in the other thread, this could well be the cause of the problems.

07-14-10, 12:09 PM	#2
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	Re: Tearing with 8600GTS, 256.35, xine-lib-1.2 when avoiding XLockDisplay() rnissl, Can you please describe the tearing a little? In particular, does it simply look like typical tearing one gets when blitting an image to the screen without syncing to vblank, or something else, e.g. more persistent decoding corruption? Are you using the blit or overlay-based presentation queue; see the README for details on what X configurations allow/cause one to be used over the other (e.g. disable the X composite extension). Or, just move a window around, and see if you see flashes of the chroma key color as you move the window; if so, then you're already using the overlay. Can you supply complete details on how to reproduce this (e.g. patches to remove the xine-ui problems you mentioned, which svn/... version to apply them against, do I simply comment out every single XLockDisplay call that I see in the xine-lib source or ... etc.) Thanks.

07-15-10, 09:27 AM	#4
Stephen Warren Moderator Join Date: Aug 2005 Posts: 1,327	Re: Tearing with 8600GTS, 256.35, xine-lib-1.2 when avoiding XLockDisplay() One thought on this: Decode->display interlock is performed within the VDPAU driver. That is, if you decode to a given surface and then display it, VDPAU internally guarantees that display of that surface won't start until the decode has completed. However, the driver performs no display->decode interlock; the application must wait until the presentation queue has completed displaying the image (i.e. its status is IDLE) before requesting that a new decode operation begin on that surface. If the application doesn't do this, the decoder might write to a surface while it's still being displayed, which could look like tearing. Given the presentation queue errors mentioned in the other thread, this could well be the cause of the problems.