Sync & swap / vsync video playback issues

[dmfr]

Hi,

Prior to 2.6.35 sync & swap commits ( I guess ), video playback with or without compositing was tearfree and perfectly smooth.

Now from these commits, my viewer's feeling is that the framerate is, well, irregular. This is especially noticeable on slow motion HD 720p+ video, and even more in fullscreen mode. (i always disable "unredirect fullscreen" because of missing smplayer control and flickering issues).

Applying this patch :

--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -315,7 +315,7 @@ radeon_dri2_copy_region(DrawablePtr drawable,
}

vsync = info->accel_state->vsync;
- info->accel_state->vsync = TRUE;
+ //info->accel_state->vsync = TRUE;

(*gc->ops->CopyArea)(src_drawable, dst_drawable, gc,
0, 0, drawable->width, drawable->height, 0, 0);

video playback is now very smooth again, but tearing is back, especially on SD / low quality videos.

I guess it might be related to the vsync debate currently going on.
Any ideas ? any solution expected ?
I don't care about the FPS as I'm not gaming, I'm just looking for good desktop & video performance.

I use kwin compositing, r700 hardware. Same with drm-radeon-testing / drm-next.

Thanks in advance,

[agd5f]

Sounds like you are using GL for video rendering. Make sure you are using mesa from git.

[dmfr]

I'm running mesa / drm / ddx from git.

When compositing disabled or full screen unredirected, these "frame stall / drop" artifacts are only present through GL output (-vo gl)
If kwin compositing enabled, occurs whatever the output slave is ( x11 xv gl ...)

[dmfr]

No chances on that matter ?
Again, this is not "terribly" annoying, but compared to uncomposited ( no GL ) playback there's definitely something wrong with "motion smoothness"

Should I file a bug report ? The thing is I cannot provide much material to back it up.

[nanonyme]

Should I file a bug report ? The thing is I cannot provide much material to back it up.

Not necessarily a bad idea. Do try to find out if there's a bug on the issue open already though.

[agd5f]

Try setting the env var vblank_mode=0 before running your app.

[dmfr]

Same with vblank_mode=0, even at drirc level (using the "dri2" driver as workaround).

By the way, how (if possible) can I extract some data to report it accurately ?

[dmfr]

If I apply this patch to a current drm build tree

--- a/drivers/gpu/drm/radeon/radeon_kms.c 2010-08-14 14:17:09.670000013 +0200
+++ b/drivers/gpu/drm/radeon/radeon_kms.c 2010-08-14 14:59:16.446000066 +0200
@@ -130,21 +130,6 @@
else
value = rdev->accel_working;
break;
- case RADEON_INFO_CRTC_FROM_ID:
- for (i = 0, found = 0; i < rdev->num_crtc; i++) {
- crtc = (struct drm_crtc *)minfo->crtcs[i];
- if (crtc && crtc->base.id == value) {
- struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- value = radeon_crtc->crtc_id;
- found = 1;
- break;
- }
- }
- if (!found) {
- DRM_DEBUG_KMS("unknown crtc id %d\n", value);
- return -EINVAL;
- }
- break;
case RADEON_INFO_ACCEL_WORKING2:
value = rdev->accel_working;
break;

video playback is now perfectly smooth again.
So the "crtc hw id" query has definitely something to do with it.
It confirms my suspicions about that issue starting with mainline 2.6.35.

[dmfr]

Of course, about the above patch, I don't know which mesa/GL/vsync features it kills as a chain reaction...
But again I first experienced those issues when trying 2.6.35rc1 with build-in drm, a couple of months ago, with mesa/ddx status back then.

[nanonyme]

Out of curiosity: are you getting that debug message printed?