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

From: zhoucm1 <david1.zhou-5C7GfCeVMHo@public.gmane.org>
To: Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Mao, David" <David.Mao-5C7GfCeVMHo@public.gmane.org>,
	"He, Jacob" <jacob.he-5C7GfCeVMHo@public.gmane.org>
Cc: amd-gfx mailing list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)
Date: Fri, 12 May 2017 13:45:19 +0800	[thread overview]
Message-ID: <59154BEF.4030806@amd.com> (raw)
In-Reply-To: <CAPM=9tz5A9toCZAk10nOWub-qfiV6+aPBy9FDZANvAywfp8Vhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


On 2017年05月12日 12:17, Dave Airlie wrote:
> On 12 May 2017 at 13:34, zhoucm1 <david1.zhou@amd.com> wrote:
>> 1. generally, functions in amdgpu_cs.c should be with amdgpu_cs_ as prefix.
> Okay I've fixed this and previous patch up locally.
>
>> 2. If I'm not wrong to your proposal, SYNCOBJ_IN is to semaphore wait while
>> SYNCOBJ_OUT is to semaphore signal. SYNCOBJ_IN/OUT both are based on command
>> submission ioctl, that means user space must generate CS when using
>> semaphore?  but with my understand, they should not be dependent with that,
>> they can be used independently, right?
> Yes in is WAIT and out is signal, however OUT could also be used to
> write a syncobj as a fence if needed, hence why I moved away from
> semaphore naming.
>
> The only place I can see them being used independently is a possible
> signal operation after present, due not being able to pass the
> semaphores over dri3 yet. I think I've said this before and Christian
> has confirmed that doing anything with semaphores not via the command
> submission ioctl is going to be messy as they have to queue jobs in
> the scheduler, so if we need to tune the command submission ioctl to
> take empty CS or add a flag to just do semaphore operations we should
> do so in the future when we have a clear use case for it (and we see
> the need to optimise for it).
I see.
+David Mao and Jacob to aware, they are expert of Vulkan, if they have 
no concern, It's ok.

Regards,
David Zhou
>
> Dave.

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