[Bug 204181] NULL pointer dereference regression in amdgpu

[bugzilla-daemon@bugzilla.kernel.org]

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

--- Comment #42 from Michel Dänzer (michel@daenzer.net) ---
(In reply to Alex Deucher from comment #37)
> The TearFree option is there to deal with compositors that do not support
> sync to vblank.

Also for cases where a compositor cannot prevent tearing, in particular with
rotation and other transforms via RandR.


> The ddx allocates another front buffer and then that buffer
> is updated synchronized with vblank with the data from the real front
> buffer.  So it uses an additional buffer.

Right, that's one of the main reasons why TearFree isn't enabled in all cases
by default, another one being that it can incur (at least) one refresh cycle
output latency.


(In reply to Sergey Kondakov from comment #38)
> It's a shame, I've already begun believing in "The Silver Bullet of VSync". 

If TearFree was a silver bullet, it would be enabled by default in all cases.
:) (It already is in cases where a compositor cannot prevent tearing, per
above)


> And it's completely "software" GPU-agnostic function, so alternatives like
> Wayland would have to just reimplement it the same way ?

More like the other way around actually; I consider TearFree sort of a poor
man's Wayland compositor. The latter generally handle this better, or are at
least in a better position to handle it.


> It always adds a buffer or "smart-enough" compositor can opt-out ?

Currently the former. It would be possible to eliminate the additional buffers
while a compositor / other fullscreen client is using page flipping, but I
never got around to implementing that.


> Or "the correct fix for latency" with TF is disabling vsync everywhere (such
> as kwin's GLPreferBufferSwap=n) else and let it handle it ?

I doubt that'll help for latency, and will waste energy generating frames which
are never visible.


> Strange that "the magic" of TF isn't done directly in compositors or kernel
> then.

Compositors can do so, with some exceptions per above, but in cases where they
can prevent tearing, they're generally preferable to TearFree.

The kernel cannot do this transparently though.


(In reply to Alex Deucher from comment #39)
> 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.

That wouldn't necessarily make much if any visible difference though, as the
displays can still show inconsistent contents sometimes if their timings aren't
synchronized, and tearing within a display can be avoided even with a single
scanout buffer. The main benefit of separate scanout buffers is that the
application can re-use buffers for rendering new frames earlier, but OTOH
there's the overhead cost of compositing (because the client buffers can't be
used directly for page flipping like this). This is pretty much how TearFree
works, BTW (except due to the Xorg architecture, it can't actualy allow a
compositor / other fullscreen client to re-use buffers earlier when
sync-to-vblank is enabled for the client).


(In reply to Sergey Kondakov from comment #40)
> 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.

That's not possible with the current Xorg architecture. It only allows flipping
all displays (connected to a single GPU) together.

The way forward to solve this is Wayland.

-- 
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