Explicit GPU Synchronization for DRI3, Present, and Xwayland
- Apr 09, 2024
-
-
When a present request is received, Xwayland will check if there is an existing request targeting the same window and msc and scrap the older request if so. Alas, this does not interact well the older fence-based or newer syncobj-based synchronization features of the Present extension. Since execution of a request may be delayed for an unknown length of time while waiting for a fence to be signaled, the target msc computed upon receiving a request may not match the actual msc at which the request is executed. Therefore, we cannot determine in advance whether a more recently received request will make an older request redundant. This change removes the code to scrap pending present requests. We must also ensure requests are executed in the correct order even if their fences are signaled out of order. To achieve this, whenever execution of a request needs to wait for a fence, execution of any later-received requests will be blocked until the earlier request is ready. The blocked requests will be added to a list tracked in the xwl_present_window struct. Once the earlier request's fence is signaled, any blocked requests will be re-executed. Signed-off-by:
Erik Kurzinger <ekurzinger@nvidia.com> Part-of: <!967>
-
This protocol allows for explicit synchronization of GPU operations by Wayland clients and the compositor. Xwayland can make use of this to ensure any rendering it initiates has completed before the target image is accessed by the compositor, without having to rely on kernel-level implicit synchronization. Furthermore, for X11 clients that also support explicit synchronization using the mechanisms exposed in the DRI3 and Present extensions, this Wayland protocol allows us to simply forward the timeline, acquire, and release points directly to the compositor, ideally avoiding any premature stalls in the presentation pipeline. Signed-off-by:
-
Together, DRI3 1.4 and Present 1.4 allow clients to explicitly synchronize GPU rendering with presentation using DRM syncobjs. Here we add the necessary support to Xwayland's glamor and Present infrastructure to enable this functionality. Signed-off-by:
-
Signed-off-by:
-
If a presentation request is delayed while waiting for a fence, the original target msc may no longer be correct. Instead, we should compute a new target msc in xwl_present_re_execute. Signed-off-by:
-
Signed-off-by:
-
Adds the required infrastructure in the core DRI3 code to support importing DRM synchronization objects from clients. This includes support for the two new protocol requests from DRI3 version 1.4, an internal representation of these objects in the form of the dri3_syncobj structure, and an import_syncobj screen info callback. The following operations are defined for dri3_syncobj objects * free - release any server-side resources associated with the object * has_fence - check if the fence for a timeline point is submitted * is_signaled - check if a timeline point is signaled * export_fence - return a sync fd corresponding to a timeline point * import_fence - submit a sync fd as the fence for a timeline point * signal - immediately signal a timeline point * submitted_eventfd and signaled_eventfd - register an eventfd to be signaled when the given timeline point is either submitted or signaled Implementations will be responsible for populating these function pointers when importing a syncobj. Signed-off-by:
-
DRI3 version 1.3 introduced a new request which allows clients to provide a hint to the server about which DRM device they are using, so that the server might return DRM format modifiers specific to that device. However, implementing such functionality, for Xwayland in particular, will require fairly significant architectural changes. To avoid blocking future versions of the DRI3 extension, we provide here a stub implementation for the request in question. The spec explicitly states that it is only a hint that the server is free to ignore, so strictly speaking this implementation is still correct. Signed-off-by:
-
Explicit sync support for Xwayland requires several updates to the Debian CI image. These include... xorgproto 2024.1 for DRI3 1.4 and Present 1.4 wayland-protocols 1.34 for wp-linux-drm-syncobj-v1 libdrm 2.4.116 for drmSyncobjEventfd linux-libc-dev from bullseye-backports for DMA_BUF_IOCTL_IMPORT/EXPORT_SYNC_FD Signed-off-by:
-
Without either implicit or explicit synchronization, the result of rendering is pretty much undefined, and many glitches can appear. This still doesn't synchronize buffer release, but it works around most glitches until explicit sync is supported. Signed-off-by:
Xaver Hugl <xaver.hugl@kde.org> Part-of: <!967>
-
Signed-off-by:
-
