[DP] [SKL] 5k tiled dual DP (two-pipe, two-port) display sync issues
Submitted by Tomas Bzatek
Assigned to Intel GFX Bugs mailing list
Description
Created attachment 125593
picture of the corruption
(this is a split-off from bug 95207 after solving modelines detection)
While modelines are properly detected now and native resolution can be set, the monitor shows corrupted image (see attached photo).
This is reproducible anytime with random level of corruption. So far I have never been able to get proper stable image. Lower resolutions (via single DP cable) work fine, so does Windows in native resolution (dual DP).
No interesting messages in the logs either, attached below.
This is Dell UP2715K, a 5k tiled monitor connected via two DP ports on a C236 board running Skylake Xeon.
I'll hang on IRC on #intel-gfx (nick: tbzatek) for direct debugging.
Attachment 125593, "picture of the corruption":
See also
Activity
added Community Enhancement feature: display/DP platform: SKL priority::medium + 1 deleted label
System boots up with lower resolution, the native 5120x2880 resolution set around 38.4 sec.
Attachment 125594, "dmesg drm.debug=0x1e (4.8.0-rc1-10779-g8ca71ca-dirty, drm-intel-nightly 2016y-08m-08d-09h-02m-24s UTC)":
dmesgXorg.0.log, xorg-server 1.18.4, xf86-video-intel git
Attachment 125595, "Xorg.0.log":
Xorg.0.log
After number of experiments I've managed to get proper image in native resolution. Hit rate is very low though, it takes about 20 tries fiddling with xrandr trying to get the right sync.
Here is my theory: the monitor is one physical panel taking data from two DP inputs making a final composited image from both, side by side. It probably takes one output as a reference and tries to synchronize scanlines from the other. It also probably expects equal timings and particular frames sent at the same moment on both outputs.
When I see tearing (e.g. scrolling a large image) it's consistent across whole image, on both outputs.
This was normally not the case when I had two monitors connected to each DP port in a clone mode - tearing was at different positions (perhaps not relevant, but worth to mention).
Related xf86-video-intel options:
Option "TearFree" "off"
Option "VSync" "on"
Option "DRI" "3"
Option "Present" "on"
Option "ReprobeOutputs" "off"
Option "HotPlug" "off"
Option "HWRotation" "off"
Option "DebugFlushCaches" "off"
Option "DebugWait" "on"
Option "DebugFlushBatches" "off"
Option "FallbackDebug" "off"
(basically random options but seem to help a little)
This is with 4.7.0 kernel (zen patchset), from drm point of view it's basically vanilla with the following patches:
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/skl: Fix redundant cursor update, fix cursor underruns
So yes, it is possible to drive the monitor with current SW, just the drivers need some tweaking. Hope this helps...Maybe looking at xinerama helps. Xinerama does not produce syncing issues.
btw. the issues are also the same on fedora 25 (kernel 4.8), dell up2715k and nouveau (gtx 960).
Same problem here with Dell 5K and a Skylake i915 cpu/gpu.
I think the problem is that the intel driver is assigning seperate PLLs for each port. The capability exists to share a common PLL clock source for both ports.
I suspect the Windows driver sees both ports have the same resolution and framerate and shares a PLL automatically.
Is there a way to force PLL sharing to test this theory?Same issue here as well. Tried on Fedora 25 on a Dell XPS 15 (9550) laptop and the Dell 5k monitor (up2715k). It looks exactly like the corruption image that Tomas Bzatek posted.
It freaked me out at first because the flickering that happened sort of "burned in" to the monitor. Even when I unplugged it from the laptop it was still flickering the same image. If anyone else runs into this, just leave it running at a 4k resolution (or any that doesn't have the corruption issues) and eventually it fixes itself.
I'm using Skylake i915 CPU/GPU (HD Graphics 530). I confirmed it wasn't hardware since it works on Windows. After years of Linux I had to revert back to Windows so that I can use the monitor at its real resolution. =<br>
Will be watching this issue so I can hopefully bounce back to Linux again. I can help test/debug as well.@david
The flickering und tiling issue is a problem of the UP2715k. See here:
http://www.dell.com/support/article/de/de/debsdt1/The_Left_and_Right_side_of_screen_do_not_sync/align
often after these distortions you have constant flickering for 30-60 Minutes. (see the DELL remarks)
I think it was too early for DELL, to jump into the 5K-market.Well for the time being I managed to make it run by using the buggy BFS scheduler (out-of-the-tree CFS process scheduler replacement) that somehow makes the whole drm subsystem laggy. Please disregard my findings in comment 3, it's more or less independent of Xorg settings. No luck with setting up Xinerama either (in reply to comment 4).
My theory is that the bug causes delaying the phase the outputs are set up and once the lag is over, it activates both outputs at the same moment. It's lame but it's a sufficient workaround for now :-)
And when the outputs are in sync, the monitor holds the sync for a whole day, without flickering. There are no issues with cursor or windows DP1<->DP2 transition either, it really feels like a single screen, even tearing is in sync. Good work on that front.
Unfortunately I didn't have much time to debug this issue, it's still on my TODO list though. Assigning common PLL clock source (as suggested in comment 6) could be the way to go. I've also tried patching the kernel to delay the second output to be in vsync with the first (as suggested by intel developers on irc), with no luck so far.Hey Tomas Bzatek,
Would you have any instructions on how I may get the same version of BFS running? Would really love to get a working Linux even if it is buggy in other ways. Also, when I plug the monitor in, it doesn't correctly configure both monitors together. I have to manually put in some xrandr commands:xrandr --output DP-1 --mode 2560x2880 --output DP-2 --mode 2560x2880 --right-of DP-1Something like this. Is this what you're doing, or do you have an xorg config? Or does your desktop just auto-detect?
As soon as I run the above command is when I get the really weird and glitchy tiling errors with flickering that stays for a while. I actually tried using the kernel in this repo (https://copr.fedorainfracloud.org/coprs/hubbitus/kernel-pf/) which uses MuQSS instead of BFS, but same issue. I may try compiling BFS into the kernel to see if that works instead.(In reply to Sebastian from comment 7)
I use a Dell UP2715K with Arch Linux.
And since last week (Update to nvidia Driver 375.10) it works like a charm.
----
Nvidia Driver Version: 375.10
Xorg: 1.18.4 (11804000)
Kernel: 4.8.6.1
UP2715K with Arch Linux, but I can't get 5k resolution in gnome, 5k seems to be stretched and I can only see half of the full screen.
Can you tell me some details?
Nvidia Driver Version: 375.20
Xorg: 1.18.4 (11804000)
Kernel: 4.8.10.1I also use Gnome. You have to set the display to its native resolution (5.120 x 2.880) in Gnome-Display-Settings. Or to 2x 2560x2888 in nVidia-Settings.
Both ways work. And the "two half displays" are handled as one by Gnome automatically.
Screenshot: http://www.naanoo.com/upstream/gnome-5k.pngAny news on this issue?
Is it worth trying a new version yet?
Last time I tested it my monitor was unusable for over 24 hours so I'm not keen to be a guinea pig.
But I would like to able to test my "PLL sharing" theory (https://bugs.freedesktop.org/show_bug.cgi?id=97244#c6)@janisaid:(In reply to Andrew Snow from comment 6)
Same problem here with Dell 5K and a Skylake i915 cpu/gpu.
I think the problem is that the intel driver is assigning seperate PLLs for
each port. The capability exists to share a common PLL clock source for
both ports.
I suspect the Windows driver sees both ports have the same resolution and
framerate and shares a PLL automatically.
If anyone does have the hardware and Windows readily available, dumping the PCI MMIO BAR on Windows would let us check how it configures the hardware in this case. Alas, I have no idea what the tool for dumping it is.
