[Bug 204181] NULL pointer dereference regression in amdgpu - bugzilla-daemon

From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 204181] NULL pointer dereference regression in amdgpu
Date: Wed, 21 Aug 2019 21:39:29 +0000	[thread overview]
Message-ID: <bug-204181-2300-xiWjycJ6LR@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-204181-2300@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=204181

--- Comment #40 from Sergey Kondakov (virtuousfox@gmail.com) ---
(In reply to Alex Deucher from comment #39)
> (In reply to Sergey Kondakov from comment #38)
> Here is your issue: "simple 2x1080p"
> 
> multiple display are really hard to deal with.  The display timing may be
> different, the blanking periods may not align, etc.  X uses a single surface
> for each multi-display desktopso when you are updating multiple displays, if
> the timings are not aligned, one display will show older content.  For this
> to work smoothly, you really need the compositor to have each display using
> it's own set of buffers and doing vsynced rendering to each display
> separately.

I little bit strange to call 2x1080p on AMD's fancy 5-port GPU (+ possible DP
multiplexing) "my issue". If anything is an issue with AMD's modern output
controllers it's the lack of analogue signal in DVI port for my proper
1280x1024@89 CRT monitor with majestic >10k:1 contrast. Timing on both outputs
is definitively different, though.

I still cannot fathom how is it still that all outputs are lumped together like
that. Anyway, I was searching on my suspicion about kwin's vsync behaviour and
stumbled on this treat: https://bugs.kde.org/show_bug.cgi?id=395632#c45 - new
kwin developer working on that and multi-threaded per-output vsync _right now_,
wants testers. Surely, this new version of kwin will "blow up" kernel module
with this page-flipping bug ! And he would really benefit from your advices.
Then we might not even need TearFree anywhere anymore !
https://phabricator.kde.org/T11071 - quite a progress already. Aims to make
double-only per-output mandatory vsync via GLX_OML_sync_control.

Right now `qdbus-qt5 org.kde.KWin /KWin supportInformation` says:
…
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glStrictBinding: false
glStrictBindingFollowsDriver: true
…
Screens
=======
Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 2

Screen 0:
---------
Name: DVI-D-0
Geometry: 0,0,1920x1080
Scale: 1
Refresh Rate: 72.9249

Screen 1:
---------
Name: HDMI-A-0
Geometry: 1920,0,1920x1080
Scale: 1
Refresh Rate: 71.8263

glxgears shows proper FPS (~72.923) but, judging by that bug, it's either
mistiming updates or "cutting out" some frames. It will not tear if it would
let apps render at their pace and then limit its own output to 60, isn't it ?
And I'm as clueless as those bug-reporters on how to check its real rate on
currently released version.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel