diff options
author | Erik Kurzinger <ekurzinger@nvidia.com> | 2024-04-26 13:44:56 -0700 |
---|---|---|
committer | Marge Bot <emma+marge@anholt.net> | 2024-04-30 13:18:30 +0000 |
commit | d5192ba8eb87f5a36bc77a7b95d349ae74fd5a59 (patch) | |
tree | 224dd2efc6496839e1bc2b3755d5b50fd0725dca /hw/kdrive/ephyr/ephyr_glamor_xv.c | |
parent | a4ed100c0cb8cb35a2e4dd837cd9eea80d2345f4 (diff) |
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/kdrive/ephyr/ephyr_glamor_xv.c')
0 files changed, 0 insertions, 0 deletions