Bug 103202

Summary: Tearing with reverse prime (intel primary, nouveau secondary)
Product: xorg Reporter: post+fdo
Component: Driver/modesettingAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: sam, sassmann
Version: 7.7 (2012.06)   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log file none

Description post+fdo 2017-10-10 20:00:19 UTC
I have a Lenovo P50 and I am using Debian testing with Xorg 7.7 and Linux 4.12.  The machine has its HDMI connector wired to the built-in NVidia card GM107GLM (Quadro M2000M).  I am calling `xrandr --setprovideroutputsorce` to make the connectors on the NVidia card available in my Xorg session.  On the Xorg side, both cards are using the modesetting driver.  My DE is Gnome 3.26.

With this setup, I am seeing no tearing when I run full-screen OpenGL applications on the internal screen.  However, when I do the same on a screen connected via HDMI, there is tearing.  I am seeing the tearing both in my little test application (https://git.ralfj.de/gltest.git) and when scrolling in Firefox.
Comment 1 Ilia Mirkin 2017-10-10 21:06:40 UTC
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.
Comment 2 Chris Wilson 2017-10-10 21:16:29 UTC
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.
Comment 3 post+fdo 2017-10-11 08:45:45 UTC
> 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.
Comment 4 Michel Dänzer 2017-10-11 08:58:04 UTC
(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)
Comment 5 post+fdo 2017-10-11 09:06:32 UTC
> 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?
Comment 6 Michel Dänzer 2017-10-11 09:11:57 UTC
Please attach the corresponding Xorg log file.
Comment 7 post+fdo 2017-10-12 17:42:14 UTC
Created attachment 134817 [details]
Xorg log file

Here you go.
Comment 8 Michel Dänzer 2017-10-13 08:31:55 UTC
 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.
Comment 9 post+fdo 2017-10-15 10:02:49 UTC
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 ]
Comment 10 sassmann 2018-08-22 09:53:01 UTC
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.
Comment 11 sassmann 2018-08-22 10:11:44 UTC
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.
Comment 12 Michel Dänzer 2018-08-22 10:17:16 UTC
FWIW, (something like) https://patchwork.freedesktop.org/patch/242720/ might help, once all the kinks have been ironed out (see the discussion there).
Comment 13 GitLab Migration User 2018-12-13 18:13:33 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.