Am 26.05.21 um 13:31 schrieb Daniel Stone:
Hi Christian,
On Wed, 26 May 2021 at 12:02, Christian König <christian.koenig@xxxxxxx> wrote:
Am 25.05.21 um 23:17 schrieb Jason Ekstrand:
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.
Regarding that, why do we actually use a syncfile and not a drm_syncobj
here?
The later should be much closer to a Vulkan timeline semaphore.
How would we insert a syncobj+val into a resv though? Like, if we pass
an unmaterialised syncobj+val here to insert into the resv, then an
implicit-only media user (or KMS) goes to sync against the resv, what
happens?
Well this is for exporting, not importing. So we don't need to worry
about that.
It's just my thinking because the drm_syncobj is the backing object on
VkSemaphore implementations these days, isn't it?
Christian.
Cheers,
Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
