[rfc repost] drm sync objects - a new beginning (make ickle happier?)

[Christian König]

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-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx