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

[James Jones]

On 04/19/2017 05:07 AM, Christian König wrote:
> 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.

This may introduce incompatibilities in userspace though, as the 
response to Dave's original series' pointed out.  For example, the 
Vulkan extensions that allow importing sync files expect them to behave 
as sync files currently do, not as these new objects do.  Introducing 
the new behavior would invalidate language in those specifications, 
causing problems with the very use case I suspect these changes are 
trying to address.  Those specs are not finalized, so it could be fixed, 
but I think that highlights the general concern.

> 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.

Agreed, this usage seems valuable too.  Sem files still have a fence in 
them, and that doesn't seem like an implementation detail that needs to 
be hidden from userspace.  Vulkan solved this very issue by letting 
applications directly extract the sync_file fd from a Vulkan semaphore 
so they could use it with native operations that specifically require a 
sync file, via the experimental external semaphore extensions.  Perhaps 
there could be a sem file -> sync file conversion operation with 
semantics similar to a Vulkan semaphore -> sync file export operation? 
Note the Vulkan semantics for this are in churn, so it might be worth 
holding off a bit on adding that interface if this is the path you use, 
but it shouldn't need to block this series from my high-level read.

Thanks,
-James

> Regards,
> Christian.
>
>>
>> Dave.
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel