Bug 99128 - External monitor ("reverse PRIME", Output Sink) updates very slowly (1fps) when laptop screen is off
Summary: External monitor ("reverse PRIME", Output Sink) updates very slowly (1fps) wh...
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-17 16:29 UTC by Peter Wu
Modified: 2016-12-17 17:47 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Wu 2016-12-17 16:29:14 UTC
Scenario:
Hybrid graphics laptop with an laptop screen (eDP-1, Intel) and an external monitor connected to the Nvidia GPU (DP-1, nouveau).
DP-1 (nouveau) is linked as output slave to the Intel GPU.
(When Intel renders a picture, it is shown on the external screen connected to the Nvidia GPU.)

Problem:
When the lid is closed (and no outputs are active for Intel), stuff on the external monitor updates only every one second.

Steps to reproduce:
1. Enable output source:

    xrandr --setprovideroutputsource nouveau Intel
    xrandr --output DP-1 --mode 2560x1440 --left-of eDP-1
2. Run "glxgears" and drag it to the external monitor.
3. Turn off Intel screen (e.g. xrandr --output eDP-1 --off or by closing the lid).

Expected behavior:
glxgears should be updating normally with 60fps.

Actual behavior:
glxgears updates with 1fps.

Other information:
A similar problem existed in the modesetting driver, fixed in Xorg 1.19 with
https://lists.x.org/archives/xorg-devel/2016-August/050797.html
I think that a similar fix can be developed for sna_display.c (sna_covering_crtc).

Environment:
Arch Linux x86_64
Intel i7-6700HQ, Nvidia GT 965M
xorg-server 1.19.0-3 (but it occurred with 1.18.4 too)
xf86-video-intel 1:2.99.917+746+g169c74f-2
xf86-video-nouveau 1.0.13+7+g1516d35-2
Comment 1 Chris Wilson 2016-12-17 16:38:33 UTC
(In reply to Peter Wu from comment #0)
> Other information:
> A similar problem existed in the modesetting driver, fixed in Xorg 1.19 with
> https://lists.x.org/archives/xorg-devel/2016-August/050797.html
> I think that a similar fix can be developed for sna_display.c
> (sna_covering_crtc).

That is what sna_covering_crtc has been doing that for the last few years. The problem is that you don't have any Intel CRTCs from which we can use as a vblank source and so you suffer from the woeful present fallback, as we don't seem to be able to offload the vblanks onto the slave outputs.
Comment 2 Chris Wilson 2016-12-17 17:32:31 UTC
To speed up the fake timer, just use

diff --git a/present/present_fake.c b/present/present_fake.c
index 2350638ea..faff0e310 100644
--- a/present/present_fake.c
+++ b/present/present_fake.c
@@ -128,10 +128,7 @@ present_fake_screen_init(ScreenPtr screen)
      *
      * Otherwise, pretend that the screen runs at 60Hz
      */
-    if (screen_priv->info && screen_priv->info->get_crtc)
-        screen_priv->fake_interval = 1000000;
-    else
-        screen_priv->fake_interval = 16667;
+    screen_priv->fake_interval = 16667;
 }
 

The real challenge would be to recognise that the window is only on the slave output (on a different Screen than PresentPixmap was called for) and pass along the request. Then you have the challenge to make sure that any drawing operations go back to the master/slave again.
Comment 3 Peter Wu 2016-12-17 17:38:14 UTC
Another challenge would be handling the case where a drawable overlaps two screens... how would that work?
Comment 4 Chris Wilson 2016-12-17 17:47:10 UTC
Whoever claims it first. At the moment the rule is user desired crtc, primary output->crtc, greatest covering, anything.

Flips between monitors are not coordinated - from the plls up. That drift will only be worse with multiple drivers trying to coordinate the flip. The current solution is that one crtc is chosen as the magic timing source and we hope the others are close enough that no one complains.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.