Nouveau - Oct 2017 - [Bug 103202] New: Tearing with reverse prime (intel primary, nouveau secondary)

https://bugs.freedesktop.org/show_bug.cgi?id=103202

            Bug ID: 103202
           Summary: Tearing with reverse prime (intel primary, nouveau
                    secondary)
           Product: xorg
           Version: 7.7 (2012.06)
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: post+fdo at ralfj.de
        QA Contact: xorg-team at lists.x.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171010/ee2a1d35/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=103202

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171010/5ad04337/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=103202

--- Comment #2 from Chris Wilson <chris at chris-wilson.co.uk> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171010/0e8253b6/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=103202

--- Comment #3 from post+fdo at ralfj.de ---
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171011/718801ae/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=103202

--- Comment #4 from Michel Dänzer <michel at daenzer.net> ---
(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)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171011/30cbb924/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=103202

--- Comment #5 from post+fdo at ralfj.de ---
> 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171011/87c5a881/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=103202

Michel Dänzer <michel at daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Driver/nouveau              |Driver/modesetting
           Assignee|nouveau at lists.freedesktop.o |xorg-team at lists.x.org
                   |rg                          |

--- Comment #6 from Michel Dänzer <michel at daenzer.net> ---
Please attach the corresponding Xorg log file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20171011/e13830bb/attachment.html>