summaryrefslogtreecommitdiff
path: root/hw/xnest/Visual.c
diff options
context:
space:
mode:
authorErik Kurzinger <ekurzinger@nvidia.com>2024-04-26 13:44:56 -0700
committerMarge Bot <emma+marge@anholt.net>2024-04-30 13:18:30 +0000
commitd5192ba8eb87f5a36bc77a7b95d349ae74fd5a59 (patch)
tree224dd2efc6496839e1bc2b3755d5b50fd0725dca /hw/xnest/Visual.c
parenta4ed100c0cb8cb35a2e4dd837cd9eea80d2345f4 (diff)
xwayland: use write fence in xwl_glamor_dmabuf_import_sync_fileHEADmaster
The functions xwl_glamor_dmabuf_import_sync_file and xwl_glamor_dmabuf_export_sync_file are used to ensure proper synchronization between clients using PresentPixmapSynced and compositors that do not support the wp_linux_drm_syncobj_v1 protocol when presenting by flipping. The acquire point's fence will be imported as the DMA-BUF's implicit fence before handing it off to the compositor, and then, after the DMA-BUF has been released, its new implicit fence will be exported and become the release point's fence which the client is expected to wait for before re-using the buffer. Both functions currently set the flags arguments of their respective ioctls to DMA_BUF_SYNC_READ. When importing a sync file, this means that any subsequent implicitly synchronized reads from the buffer will not wait for the fence, and when exporting a sync file it means that the returned fence may be signaled before preceeding reads from the buffer have completed. While this is correct for xwl_glamor_dmabuf_export_sync_file since the compositor will never write to the buffer, it is incorrect for xwl_glamor_dmabuf_import_sync_file. To avoid corruption, we need any reads from the buffer by the compositor to wait on the acquire point's fence. As a fix, instead of setting the DMA_BUF_SYNC_READ flag in xwl_glamor_dmabuf_import_sync_file, we set the DMA_BUF_SYNC_WRITE flag. This *does* provide the necessary guarantees. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1509>
Diffstat (limited to 'hw/xnest/Visual.c')
0 files changed, 0 insertions, 0 deletions