Re: libdrm amdgpu semaphores questions

2016-12-02 Thread Christian König 
Mhm, with that design there is only a minor difference any more to the 
sync_file implementation.


Guys, what about the idea to change the behavior of the sync_file 
implementation with a flag so that it matches what Vulkan expect?


As far as I can see the only difference is that when you can have a 
Vulkan semaphore object which isn't signaled, but at the moment you 
can't have a sync_file without any fence in it.


Regards,
Christian.

Am 02.12.2016 um 02:41 schrieb zhoucm1:

Thanks Dave, got your suggestion.

Regards,
David Zhou

On 2016年12月02日 03:44, Dave Airlie wrote:

Hi David,

Some one major review suggestion, don't use file descriptors for
semaphore, as fd's are a limited resource and we don't want to use
them all up.

You create semaphore objects and use them in a single process without
them being fds, then when userspace wants to share with another
process
you convert the semaphore object to an fd, pass it to the other
process and have it convert it back into a semaphore object.

Dave.

On 1 December 2016 at 16:11, zhoucm1  wrote:

Hi Dave,

As the attached, our Vulkan team is verifying it.

Thanks,
David Zhou


On 2016年12月01日 13:44, Dave Airlie wrote:

On 1 Dec. 2016 15:22, "zhoucm1"  wrote:
Yes, the old implementation which is already in upstream libdrm is 
out of
data, there isn't other user, so we want to drop it when new 
semaphore is

verified OK.
Could you post some patches for the new one? Otherwise I'll have to 
write

one for radv.

Dave.

Thanks,
David Zhou


On 2016年12月01日 10:36, Mao, David wrote:

Hi Dave,
i believe your first attempt is correct.
The export/import semaphore needs refine of the semaphore 
implementation.

We are working on that.

Thanks.
Best Regards,
David

On 1 Dec 2016, at 10:12 AM, Dave Airlie  wrote:

Hey all,

So I've started adding semaphore support to radv but I'm not really
sure what the API to the semaphore code is.

the Vulkan API is you get a command submission of a number of submit
units which have a 0-n wait semaphore, 0-n command buffers and 0-n
signal semaphores.

Now I'm not sure how I should use the APIs with those.

My first attempt is

call amdgpu_cs_wait_semaphore on all the wait ones, call the cs 
submit
API, then call the amdgpu_cs_signal_semaphore on all the signal 
ones?


or should I be up front calling wait/signal then submitting the 
command

streams?

Also upcoming work requires possibly sharing semaphores between
processes, is there any indication how this might be made work with
the libdrm_amdgpu semaphore implementation?

Thanks,
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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






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



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

Re: libdrm amdgpu semaphores questions

2016-12-01 Thread zhoucm1 

Thanks Dave, got your suggestion.

Regards,
David Zhou

On 2016年12月02日 03:44, Dave Airlie wrote:

Hi David,

Some one major review suggestion, don't use file descriptors for
semaphore, as fd's are a limited resource and we don't want to use
them all up.

You create semaphore objects and use them in a single process without
them being fds, then when userspace wants to share with another
process
you convert the semaphore object to an fd, pass it to the other
process and have it convert it back into a semaphore object.

Dave.

On 1 December 2016 at 16:11, zhoucm1  wrote:

Hi Dave,

As the attached, our Vulkan team is verifying it.

Thanks,
David Zhou


On 2016年12月01日 13:44, Dave Airlie wrote:

On 1 Dec. 2016 15:22, "zhoucm1"  wrote:

Yes, the old implementation which is already in upstream libdrm is out of
data, there isn't other user, so we want to drop it when new semaphore is
verified OK.

Could you post some patches for the new one? Otherwise I'll have to write
one for radv.

Dave.

Thanks,
David Zhou


On 2016年12月01日 10:36, Mao, David wrote:

Hi Dave,
i believe your first attempt is correct.
The export/import semaphore needs refine of the semaphore implementation.
We are working on that.

Thanks.
Best Regards,
David

On 1 Dec 2016, at 10:12 AM, Dave Airlie  wrote:

Hey all,

So I've started adding semaphore support to radv but I'm not really
sure what the API to the semaphore code is.

the Vulkan API is you get a command submission of a number of submit
units which have a 0-n wait semaphore, 0-n command buffers and 0-n
signal semaphores.

Now I'm not sure how I should use the APIs with those.

My first attempt is

call amdgpu_cs_wait_semaphore on all the wait ones, call the cs submit
API, then call the amdgpu_cs_signal_semaphore on all the signal ones?

or should I be up front calling wait/signal then submitting the command
streams?

Also upcoming work requires possibly sharing semaphores between
processes, is there any indication how this might be made work with
the libdrm_amdgpu semaphore implementation?

Thanks,
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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






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

Re: libdrm amdgpu semaphores questions

2016-12-01 Thread Dave Airlie 
Hi David,

Some one major review suggestion, don't use file descriptors for
semaphore, as fd's are a limited resource and we don't want to use
them all up.

You create semaphore objects and use them in a single process without
them being fds, then when userspace wants to share with another
process
you convert the semaphore object to an fd, pass it to the other
process and have it convert it back into a semaphore object.

Dave.

On 1 December 2016 at 16:11, zhoucm1  wrote:
> Hi Dave,
>
> As the attached, our Vulkan team is verifying it.
>
> Thanks,
> David Zhou
>
>
> On 2016年12月01日 13:44, Dave Airlie wrote:
>
> On 1 Dec. 2016 15:22, "zhoucm1"  wrote:
>>
>> Yes, the old implementation which is already in upstream libdrm is out of
>> data, there isn't other user, so we want to drop it when new semaphore is
>> verified OK.
>
> Could you post some patches for the new one? Otherwise I'll have to write
> one for radv.
>
> Dave.
>>
>> Thanks,
>> David Zhou
>>
>>
>> On 2016年12月01日 10:36, Mao, David wrote:
>>>
>>> Hi Dave,
>>> i believe your first attempt is correct.
>>> The export/import semaphore needs refine of the semaphore implementation.
>>> We are working on that.
>>>
>>> Thanks.
>>> Best Regards,
>>> David

 On 1 Dec 2016, at 10:12 AM, Dave Airlie  wrote:

 Hey all,

 So I've started adding semaphore support to radv but I'm not really
 sure what the API to the semaphore code is.

 the Vulkan API is you get a command submission of a number of submit
 units which have a 0-n wait semaphore, 0-n command buffers and 0-n
 signal semaphores.

 Now I'm not sure how I should use the APIs with those.

 My first attempt is

 call amdgpu_cs_wait_semaphore on all the wait ones, call the cs submit
 API, then call the amdgpu_cs_signal_semaphore on all the signal ones?

 or should I be up front calling wait/signal then submitting the command
 streams?

 Also upcoming work requires possibly sharing semaphores between
 processes, is there any indication how this might be made work with
 the libdrm_amdgpu semaphore implementation?

 Thanks,
 Dave.
 ___
 amd-gfx mailing list
 amd-gfx@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: libdrm amdgpu semaphores questions

2016-12-01 Thread Emil Velikov 
On 1 December 2016 at 06:11, zhoucm1  wrote:
> Hi Dave,
>
> As the attached, our Vulkan team is verifying it.
>
David, please read through the following documents when designing
ioctls [1] and [im]porting the UABI to libdrm [2].

Thanks
Emil

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt
"Prerequisites#1"

[2] https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README
"When and how to update these files" and "amdgpu_drm.h"
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: libdrm amdgpu semaphores questions

2016-12-01 Thread Christian König 

Hi Dave,

the problem with that approach is that it duplicates the effort done 
with android fences but moves some of the logic found in there into the 
kernel.


E.g. you could do the same with in/out fences on command submission, 
just not share the handle itself with other process before it is 
signaled (which is actually desirable).


Regards,
Christian.

Am 01.12.2016 um 07:11 schrieb zhoucm1:

Hi Dave,

As the attached, our Vulkan team is verifying it.

Thanks,
David Zhou

On 2016年12月01日 13:44, Dave Airlie wrote:


On 1 Dec. 2016 15:22, "zhoucm1" > wrote:

>
> Yes, the old implementation which is already in upstream libdrm is 
out of data, there isn't other user, so we want to drop it when new 
semaphore is verified OK.


Could you post some patches for the new one? Otherwise I'll have to 
write one for radv.


Dave.
>
> Thanks,
> David Zhou
>
>
> On 2016年12月01日 10:36, Mao, David wrote:
>>
>> Hi Dave,
>> i believe your first attempt is correct.
>> The export/import semaphore needs refine of the semaphore 
implementation.

>> We are working on that.
>>
>> Thanks.
>> Best Regards,
>> David
>>>
>>> On 1 Dec 2016, at 10:12 AM, Dave Airlie > wrote:

>>>
>>> Hey all,
>>>
>>> So I've started adding semaphore support to radv but I'm not really
>>> sure what the API to the semaphore code is.
>>>
>>> the Vulkan API is you get a command submission of a number of submit
>>> units which have a 0-n wait semaphore, 0-n command buffers and 0-n
>>> signal semaphores.
>>>
>>> Now I'm not sure how I should use the APIs with those.
>>>
>>> My first attempt is
>>>
>>> call amdgpu_cs_wait_semaphore on all the wait ones, call the cs 
submit

>>> API, then call the amdgpu_cs_signal_semaphore on all the signal ones?
>>>
>>> or should I be up front calling wait/signal then submitting the 
command streams?

>>>
>>> Also upcoming work requires possibly sharing semaphores between
>>> processes, is there any indication how this might be made work with
>>> the libdrm_amdgpu semaphore implementation?
>>>
>>> Thanks,
>>> Dave.
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org 
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org 
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>





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



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

Re: libdrm amdgpu semaphores questions

2016-11-30 Thread zhoucm1 

Hi Dave,

As the attached, our Vulkan team is verifying it.

Thanks,
David Zhou

On 2016年12月01日 13:44, Dave Airlie wrote:


On 1 Dec. 2016 15:22, "zhoucm1" > wrote:

>
> Yes, the old implementation which is already in upstream libdrm is 
out of data, there isn't other user, so we want to drop it when new 
semaphore is verified OK.


Could you post some patches for the new one? Otherwise I'll have to 
write one for radv.


Dave.
>
> Thanks,
> David Zhou
>
>
> On 2016年12月01日 10:36, Mao, David wrote:
>>
>> Hi Dave,
>> i believe your first attempt is correct.
>> The export/import semaphore needs refine of the semaphore 
implementation.

>> We are working on that.
>>
>> Thanks.
>> Best Regards,
>> David
>>>
>>> On 1 Dec 2016, at 10:12 AM, Dave Airlie > wrote:

>>>
>>> Hey all,
>>>
>>> So I've started adding semaphore support to radv but I'm not really
>>> sure what the API to the semaphore code is.
>>>
>>> the Vulkan API is you get a command submission of a number of submit
>>> units which have a 0-n wait semaphore, 0-n command buffers and 0-n
>>> signal semaphores.
>>>
>>> Now I'm not sure how I should use the APIs with those.
>>>
>>> My first attempt is
>>>
>>> call amdgpu_cs_wait_semaphore on all the wait ones, call the cs submit
>>> API, then call the amdgpu_cs_signal_semaphore on all the signal ones?
>>>
>>> or should I be up front calling wait/signal then submitting the 
command streams?

>>>
>>> Also upcoming work requires possibly sharing semaphores between
>>> processes, is there any indication how this might be made work with
>>> the libdrm_amdgpu semaphore implementation?
>>>
>>> Thanks,
>>> Dave.
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org 
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org 
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>



>From 9110b529019fbac27a95ce3090d305c528e0999b Mon Sep 17 00:00:00 2001
From: Chunming Zhou 
Date: Thu, 22 Sep 2016 14:50:16 +0800
Subject: [PATCH 1/2] amdgpu: add new semaphore support

Change-Id: Iae7e4157d6184dab1cd4a944ae9cb803f9b11670
Signed-off-by: Chunming Zhou 
---
 amdgpu/amdgpu.h  | 74 +++
 amdgpu/amdgpu_cs.c   | 90 
 include/drm/amdgpu_drm.h | 29 
 3 files changed, 193 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 525bf8e..bd6265d 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -137,6 +137,12 @@ typedef struct amdgpu_va *amdgpu_va_handle;
  */
 typedef struct amdgpu_semaphore *amdgpu_semaphore_handle;
 
+/**
+ * Define handle for sem file
+ */
+typedef int amdgpu_sem_handle;
+
+
 /*--*/
 /* -- Structures -- */
 /*--*/
@@ -1529,6 +1535,74 @@ int amdgpu_cs_wait_semaphore(amdgpu_context_handle ctx,
 int amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle sem);
 
 /**
+ *  create sem
+ *
+ * \param   dev- [in] Device handle. See #amdgpu_device_initialize()
+ * \param   sem	   - \c [out] sem handle
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_cs_create_sem(amdgpu_device_handle dev,
+			 amdgpu_sem_handle *sem);
+
+/**
+ *  signal sem
+ *
+ * \param   dev- [in] Device handle. See #amdgpu_device_initialize()
+ * \param   context- \c [in] GPU Context
+ * \param   ip_type- \c [in] Hardware IP block type = AMDGPU_HW_IP_*
+ * \param   ip_instance- \c [in] Index of the IP block of the same type
+ * \param   ring   - \c [in] Specify ring index of the IP
+ * \param   sem	   - \c [out] sem handle
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_signal_sem(amdgpu_device_handle dev,
+			 amdgpu_context_handle ctx,
+			 uint32_t ip_type,
+			 uint32_t ip_instance,
+			 uint32_t ring,
+			 amdgpu_sem_handle sem);
+
+/**
+ *  wait sem
+ *
+ * \param   dev- [in] Device handle. See #amdgpu_device_initialize()
+ * \param   context- \c [in] GPU Context
+ * \param   ip_type- \c [in] Hardware IP block type = AMDGPU_HW_IP_*
+ * \param   ip_instance- \c [in] Index of the IP block of the same type
+ * \param   ring   - \c [in] Specify ring index of the IP
+ * \param   sem	   - \c [out] sem handle
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_cs_wait_sem(amdgpu_device_handle dev,
+		   amdgpu_context_handle ctx,
+		   uint32_t ip_type,
+		   uint32_t ip_instance,
+		   uint32_t ring,
+

Re: libdrm amdgpu semaphores questions

2016-11-30 Thread zhoucm1 
Yes, the old implementation which is already in upstream libdrm is out 
of data, there isn't other user, so we want to drop it when new 
semaphore is verified OK.


Thanks,
David Zhou

On 2016年12月01日 10:36, Mao, David wrote:

Hi Dave,
i believe your first attempt is correct.
The export/import semaphore needs refine of the semaphore implementation.
We are working on that.

Thanks.
Best Regards,
David

On 1 Dec 2016, at 10:12 AM, Dave Airlie  wrote:

Hey all,

So I've started adding semaphore support to radv but I'm not really
sure what the API to the semaphore code is.

the Vulkan API is you get a command submission of a number of submit
units which have a 0-n wait semaphore, 0-n command buffers and 0-n
signal semaphores.

Now I'm not sure how I should use the APIs with those.

My first attempt is

call amdgpu_cs_wait_semaphore on all the wait ones, call the cs submit
API, then call the amdgpu_cs_signal_semaphore on all the signal ones?

or should I be up front calling wait/signal then submitting the command streams?

Also upcoming work requires possibly sharing semaphores between
processes, is there any indication how this might be made work with
the libdrm_amdgpu semaphore implementation?

Thanks,
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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


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

Re: libdrm amdgpu semaphores questions

2016-11-30 Thread Dave Airlie 
On 1 Dec. 2016 15:22, "zhoucm1"  wrote:
>
> Yes, the old implementation which is already in upstream libdrm is out of
data, there isn't other user, so we want to drop it when new semaphore is
verified OK.

Could you post some patches for the new one? Otherwise I'll have to write
one for radv.

Dave.
>
> Thanks,
> David Zhou
>
>
> On 2016年12月01日 10:36, Mao, David wrote:
>>
>> Hi Dave,
>> i believe your first attempt is correct.
>> The export/import semaphore needs refine of the semaphore implementation.
>> We are working on that.
>>
>> Thanks.
>> Best Regards,
>> David
>>>
>>> On 1 Dec 2016, at 10:12 AM, Dave Airlie  wrote:
>>>
>>> Hey all,
>>>
>>> So I've started adding semaphore support to radv but I'm not really
>>> sure what the API to the semaphore code is.
>>>
>>> the Vulkan API is you get a command submission of a number of submit
>>> units which have a 0-n wait semaphore, 0-n command buffers and 0-n
>>> signal semaphores.
>>>
>>> Now I'm not sure how I should use the APIs with those.
>>>
>>> My first attempt is
>>>
>>> call amdgpu_cs_wait_semaphore on all the wait ones, call the cs submit
>>> API, then call the amdgpu_cs_signal_semaphore on all the signal ones?
>>>
>>> or should I be up front calling wait/signal then submitting the command
streams?
>>>
>>> Also upcoming work requires possibly sharing semaphores between
>>> processes, is there any indication how this might be made work with
>>> the libdrm_amdgpu semaphore implementation?
>>>
>>> Thanks,
>>> Dave.
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: libdrm amdgpu semaphores questions

2016-11-30 Thread Mao, David 
Hi Dave,
i believe your first attempt is correct.
The export/import semaphore needs refine of the semaphore implementation. 
We are working on that. 

Thanks. 
Best Regards,
David
> On 1 Dec 2016, at 10:12 AM, Dave Airlie  wrote:
> 
> Hey all,
> 
> So I've started adding semaphore support to radv but I'm not really
> sure what the API to the semaphore code is.
> 
> the Vulkan API is you get a command submission of a number of submit
> units which have a 0-n wait semaphore, 0-n command buffers and 0-n
> signal semaphores.
> 
> Now I'm not sure how I should use the APIs with those.
> 
> My first attempt is
> 
> call amdgpu_cs_wait_semaphore on all the wait ones, call the cs submit
> API, then call the amdgpu_cs_signal_semaphore on all the signal ones?
> 
> or should I be up front calling wait/signal then submitting the command 
> streams?
> 
> Also upcoming work requires possibly sharing semaphores between
> processes, is there any indication how this might be made work with
> the libdrm_amdgpu semaphore implementation?
> 
> Thanks,
> Dave.
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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