modesetting TearFree / VSYNC aware rotation pageflipping

Carsten Behling carsten.behling at googlemail.com
Wed Oct 3 14:22:16 UTC 2018


Hi Michel,

thanks for responding.

> Basically you're comparing apples (TearFree, the amdgpu/radeon driver
> changes above) and oranges (DRI page flipping, the modesetting change
> above).
>
> DRI page flipping is an old mechanism (supported by the amdgpu/radeon
> drivers as well, "forever", since long before TearFree) for direct
> scanout from buffers whose contents were produced with direct rendering
> by the client. Because it scans out directly, output transformations
> such as rotation are traditionally not supported with DRI page flipping.
>
I see. So I have to double buffer the rotated buffer and flip it on vsync.

According to this discussion

https://bugs.freedesktop.org/show_bug.cgi?id=32789

it should be able to double-buffer the rotated frontbuffer and let a
'damage'
trigger rendering to the offscreen buffer and wait for vsync to flip. Right?

> TearFree uses separate dedicated scanout buffers, to which the "main"
> buffer contents are copied on demand.
>
> Originally, these three things (DRI page flipping, rotation and
> TearFree) were separate and mutually exclusive. However, the
> amdgpu/radeon drivers support all of them the same time these days; this
> still requires an extra copy in some cases, but that could be eliminated
> at least in the non-rotated DRI page flipping case.
>
> https://gitlab.freedesktop.org/xorg/xserver/merge_requests/24 has the
> start of TearFree support for the modesetting driver, but it's still
> mutually exclusive with rotation (DRI3 page flipping should work with
> TearFree, but may still exhibit tearing if the client/user disables
> sync-to-vblank).

Couldn't we extend modesetting in addition to Martin's TearFree patch the
same way you did here for Radeon?:

https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=798c4fd16d339b1ad5fd729cc884be084c60e38b

Best regards
-Carsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20181003/ec0da15c/attachment.html>


More information about the xorg mailing list