[Bug 204181] NULL pointer dereference regression in amdgpu
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Wed Aug 21 19:28:57 UTC 2019
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #39 from Alex Deucher (alexdeucher at gmail.com) ---
(In reply to Sergey Kondakov from comment #38)
>
> Thanks ! It's a shame, I've already begun believing in "The Silver Bullet of
> VSync". And it's completely "software" GPU-agnostic function, so
> alternatives like Wayland would have to just reimplement it the same way ?
> It always adds a buffer or "smart-enough" compositor can opt-out ? Or "the
> correct fix for latency" with TF is disabling vsync everywhere (such as
> kwin's GLPreferBufferSwap=n) else and let it handle it ?
>
> No matter how I previously tried, nothing other than TearFree guaranteed
> actual lack of tearing in all times in simple 2x1080p configuration but
> there is abundance of buffering as it is in apps and a compositor + latency
> of LCD displays. I'm sure, you're aware of
> https://gitlab.freedesktop.org/xorg/xserver/issues/244 too. Strange that
> "the magic" of TF isn't done directly in compositors or kernel then.
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.
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the dri-devel
mailing list