On 20 April 2017 at 04:42, Dave Airlie <airlied at gmail.com> wrote: > On 19 April 2017 at 22:07, Christian König <deathsimple at vodafone.de> 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. >> >> 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. > > Well ideally atomic modesetting should be moved to using syncobjects > as an option. > > I'd rather sync_files were limited in scope to interaction with non-drm drivers, > and possibly interprocess operations, consuming fd's is bad and merging doesn't > really fix that. > > I'm starting to narrow down to what I think the sync_obj needs to do, and I'm > contemplating a bit more something like the following: > > a) no file backing, a simple kref object that gets tracked in an idr > (like a gem object). > This object can have an optional fence attached to it. If there is no > fence, it's unsignalled, > if there is a fence it's signalled. This should say, if there's a fence, the status of the fence. Thanks to Andres for pointing it out, it is 5am. Dave.
