[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)

Christian König deathsimple at vodafone.de
Fri Jun 16 08:28:08 UTC 2017


Am 15.06.2017 um 05:59 schrieb Dave Airlie:
> On 1 June 2017 at 11:06, Dave Airlie <airlied at gmail.com> wrote:
>> From: Dave Airlie <airlied at redhat.com>
>>
>> This creates a new command submission chunk for amdgpu
>> to add in and out sync objects around the submission.
>>
>> Sync objects are managed via the drm syncobj ioctls.
>>
>> The command submission interface is enhanced with two new
>> chunks, one for syncobj pre submission dependencies,
>> and one for post submission sync obj signalling,
>> and just takes a list of handles for each.
>>
>> This is based on work originally done by David Zhou at AMD,
>> with input from Christian Konig on what things should look like.
>>
>> In theory VkFences could be backed with sync objects and
>> just get passed into the cs as syncobj handles as well.
>>
>> NOTE: this interface addition needs a version bump to expose
>> it to userspace.
>>
>> TODO: update to dep_sync when rebasing onto amdgpu master.
>> (with this - r-b from Christian)
> Hey Christian,
>
> did you have a chance to re-review this, I think this
> has the last changes you asked for done properly.

Sorry for the delay, holidays and dentist visits seem to eat up all my 
time at the moment.

Patches #1-#3 in this series are Acked-by: Christian König 
<christian.koenig at amd.com>.

Patch #4 already has my rb.

Patch #5 in this Series is Reviewed-by: Christian König 
<christian.koenig at amd.com>.

> If so I'd like to get Alex to get drm-next + pull these in on top at some
> point, or if I already have the dep_sync changes in my tree I can just
> fix it up and apply them there.

Any approach works for me as long as Alex is fine with it.

Additional to your set I synced up two more ideas with out internal 
Vulkan team which seem to make a lot of sense to upstream as well:

1. An IOCTL to reset a sync object to it's initial state. E.g. reset the 
fence the sync objects wraps back to NULL.

2. The ability to merge multiple sync objects into one. Essentially the 
same thing we have for the sync file, but handle based instead of fd.

I'm going to work on that in the next week or so. Shouldn't be to much 
of a problem to come up with some sane code, but probably finding use 
cases for this in the open source userspace might be challenging.

Regards,
Christian.

>
> Dave.




More information about the dri-devel mailing list