https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #42 from Michel Dänzer (michel@xxxxxxxxxxx) --- (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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
