[rfc repost] drm sync objects - a new beginning (make ickle happier?)
airlied at gmail.com
Wed Apr 19 19:14:39 UTC 2017
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.
More information about the dri-devel