I'm told that tearing with reverse prime is expected. Not really a nouveau issue. My guess is that if you were to flip them around and run the nvidia board as primary, you'd see tearing on the intel-connected screen.

Both DRI2 and DRI3 do prime by copying onto the slaves (though DRI3 should be quite capable of passing over scanout buffers fitting to the slave CRTC). This requires additional steps in the slave ddx to avoid the tear. -intel/radeon both offer the option to stage that copy into a back buffer for flipping to avoid the tear; but yes, X tears by default.

> I'm told that tearing with reverse prime is expected.

That would still be a bug then though?  Clearly some form of synchronization should be supported.

It seems there is some work on getting synchronization to work with PRIME <https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-prime-sync.pdf>; not sure what the current status of that is.  Some sites make it sound like using the NVidia card with the proprietary drivers as primary actually can get you V-sync on both screens, so is this just a matter of getting the nouveau DRM driver hooked up to that infrastructure?

> if you were to flip them around and run the nvidia board as primary, you'd see tearing on the intel-connected screen.

Possible; I would then also have really bad battery life with no external screen connected as the NVidia card would keep running.

> -intel/radeon both offer the option to stage that copy into a back buffer for flipping to avoid the tear

Given that the Intel card is the primary here, that wouldn't really help, right?  I would expect to need such an option for whatever drives the NVidia card.

> X tears by default.

Well, yes, but with reverse PRIME I get tearing even if the application uses V-Sync or if I use a compositor.  So, this is not about a lack of synchronization per default, it is about synchronization never happening even when using the appropriate APIs.

I wouldn't mind looking into Wayland, but found no indication that reverse PRIME is supported there at all.

(In reply to post+fdo from comment #3)
> It seems there is some work on getting synchronization to work with PRIME
> <https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-prime-sync.pdf>; [...]

FWIW, it's possible to avoid tearing between GPUs in a much less complicated way than that, if the drivers for both GPUs use the ScreenRec::SyncSharedPixmap hook. You can take a look at xf86-video-amdgpu/ati for an example. (The driver of the displaying GPU also needs to separately prevent tearing of the scanout process itself. xf86-video-amdgpu/ati do this by default for PRIME outputs)

> if the drivers for both GPUs use the ScreenRec::SyncSharedPixmap hook. You can take a look at xf86-video-amdgpu/ati for an example. (The driver of the displaying GPU also needs to separately prevent tearing of the scanout process itself. xf86-video-amdgpu/ati do this by default for PRIME outputs)

So this would be a matter of patching modesetting to do both of these things?  (I also wouldn't mind using the intel/nouveau Xorg drivers, but I got the impression that modesetting is actually preferred, at least for newer Intel cards.)

That talk btw says that modesetting supports both "PRIME sync output slave" and "PRIME sync output master", which makes me wonder why it is not able to sync with itself.  Either there's a bug in that (so I should reassign), or the underlying DRM lacks some support for something (so this bugreport would be in the right place).  How could I figure that out?

Please attach the corresponding Xorg log file.

Created attachment 134817 [details]
Xorg log file

Here you go.

 randr: falling back to unsynchronized pixmap sharing

indicates that the modesetting driver is indeed lacking something for this mechanism to work with itself as peer.

If I use nouveau instead of modesetting, the tearing is different:  Rather than having a more-or-less constant tearline, it tears all over the place.  That's much less visible, so I think I prefer this behavior.  The "falling back to unsynchronized pixmap sharing" still appears in the Xorg log.

I also tried installing the intel Xorg driver, but that one is not even used automatically -- it still uses modesetting.  I can configure it manually to enforce the Intel driver, and then I still get both tearing and the error in the log -- plus, unlike in the modesetting+nouveau constellation, it doesn't even do solid 60fps on the external screen.

Btw, there is an error shown by nouveau during boot, maybe that means anything?

Oct 15 11:49:25 r-thinktop kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 022554 [ IBUS ]
Oct 15 11:49:25 r-thinktop kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

Any update on this?

I'm also using a Lenovo P50 (intel primary, nouveau secondary) and there's a single huge tearline going diagonally over the monitor connected via DP.
I'm running Fedora 28.

Tried to force PRIME Synchronization for the DP, but that didn't work.

# xrandr --output DP-1-1-2 --set "PRIME Synchronization" 1
# xrandr --verbose
DP-1-1-2 connected primary 3840x2160+0+0 (0x4a) normal (normal left inverted right x axis y axis) 600mm x 340mm
[...]
        PRIME Synchronization: 0
                supported: 0, 1

In the xorg log
randr: falling back to unsynchronized pixmap sharing
shows up when trying to enable PRIME Synchronization.

FWIW, (something like) https://patchwork.freedesktop.org/patch/242720/ might help, once all the kinks have been ironed out (see the discussion there).

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/77.