I've tested things a bit further. RandR 1.2 is not needed to produce the problem, but having two output enabled worsens the problem.

Things work fine with the nv driver, so you do not need to compare with the closed one.

I've confirmed that all three test cases (nv, nouveau "normal", nouveau "randr") use the same mode line. The RandR code path selects a different one by default, but I switched it to get a valid comparison.

This card does not have any overlay, so it's the blitter that's involved.

I think you're using the texture adapter, which doesn't have sync to vblank yet (it still has to be reverse engineered). But can you confirm that the tearing is diaginal? And that xvinfo shows the texture adapter first?

The tearing is horisontal, not diagonal. But the texture adaptor is indeed first in xvinfo.

But I believe I'm using the blitter. The driver does syncing, it just fails ever so slightly. :)

If I disable XV_SYNC_TO_VBLANK, things go south really badly. Keeping it on, it is almost in sync but with constant, slight glitches. I've been trying to put together a simple test case but it has proven to be very difficult. So far I can only reproduce it consistently with mplayer.

Ah, I see what is happening now, and you were right.

mplayer, where I'm seeing the tearing, uses the first port found. But my tests were using the last port. So one used the texture adapter, and one the blitter. If I change my tests to use the texture adapter, the problem is apparent. It also explains why nv works as it doesn't have the texture adapter.

So I have a couple of questions:

1. What's the difference between the two? Judging from the names I'd guess the texture adapter uses the 3D engine and the blitter the 2D engine.

2. Why two? I.e. why is the blitter insufficient?

3. Why is the texture adapter the first (and therefore picked by programs) if it is inferior to the blitter when it comes to displaying video?

4. Why does vsync need rev.eng.? I tested adding a simple FIRE_RING()/NVWaitVSync() and it removed the tearing.

1. Indeed.
2. The blitter doesn't support YV12 which is a very common color space.
3. It gives people reason to improve it ;-) (also defaults get better feedback)
4. This does not work well for me and many others. It is believed that the 3d engine has it's own sync.

For the time being, could we get an config option that reverses the order of the ports? Or disables the texture adapter? :)

Hello,

is this still an issue?

Can you please retry with current git. Please keep in mind that the composited case may not be perfect, but it should improve.

I removed the potentionally problematic workaround for composite situations, please make sure you try without composite.

The latest additions correctly vsyncs for the texture adapter on both CRTCs here. Closing bug.