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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
