Am 13.04.2017 um 03:41 schrieb Dave Airlie:
Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.
This means the drm_syncobj are currently only useful for semaphores,
the flags field could be used in future to use it for other things,
and we can reintroduce some of the API then if needed.
This refactors sync_file first to add some basic rcu wrappers
about the fence pointer, as this point never updates this should
all be fine unlocked.
It then creates the sem_file with a mutex, and uses that to
track the semaphores with reduced fops and the replace and
get APIs.
Then it reworks the drm stuff on top, and fixes amdgpu bug
with old_fence.
Let's see if anyone prefers one approach over the other.
Yeah, I clearly prefer keeping only one object type for synchronization
in the kernel.
As I wrote in the other mail the argument of using the sync file for
semaphores was to be able to use it as in fence with the atomic mode
setting as well.
That a wait consumes a previous signal should be a specific behavior of
the operation and not the property of the object.
In other words I'm fine with using the sync_file in a 1:1 fashion with
Vulkan, but for the atomic API we probably want 1:N to be able to flip a
rendering result on multiple CRTCs at the same time.
Regards,
Christian.
Dave.
_______________________________________________
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
