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

From: "Christian König" <deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
To: Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	amd-gfx mailing list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)
Date: Fri, 16 Jun 2017 10:28:08 +0200	[thread overview]
Message-ID: <e8021851-d630-3cbd-40e2-58f83a366a29@vodafone.de> (raw)
In-Reply-To: <CAPM=9twtavgA+D+vgZYz7UagnjxX6pGFBBUycCs2ofGjhOcBrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Am 15.06.2017 um 05:59 schrieb Dave Airlie:
> On 1 June 2017 at 11:06, Dave Airlie <airlied@gmail.com> wrote:
>> From: Dave Airlie <airlied@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@amd.com>.

Patch #4 already has my rb.

Patch #5 in this Series is Reviewed-by: Christian König 
<christian.koenig@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.

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx