https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #38 from Sergey Kondakov (virtuousfox@xxxxxxxxx) --- (In reply to Alex Deucher from comment #37) > (In reply to Sergey Kondakov from comment #34) > > By the way, is there any disadvantage in forcing TearFree to be always on > > when it works ? Like additional frame of latency or something like that ? > > The TearFree option is there to deal with compositors that do not support > sync to vblank. 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. 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. -- 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
