Shared semaphores for amdgpu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I do wonder if we need the separate sem signal/wait interface, I think
> we should just add
> semaphore chunks to the CS interface.
Yeah, that's what I've said as well from the very first beginning.

Another question is if we should really create another implementation to 
share semaphores between processes.

In other words putting the current fences inside the semaphore into a 
sync_file with the signal_on_any bit set would have pretty much the same 
effect, except that the resulting object then had the sync_file 
semantics for adding new fences and can be used in the atomic IOCTLs as 
well.

Regards,
Christian.

Am 09.03.2017 um 08:00 schrieb zhoucm1:
> Hi Dave,
>
> We have already completed implementation as the attached for both 
> kernel and libdrm. We discuss it on top of this.
>
>
> Thanks,
> David Zhou
>
> On 2017å¹´03æ??09æ?¥ 12:24, Dave Airlie wrote:
>> I've attached two patches for RFC at the moment, I haven't finished
>> the userspace for these yet, but just wanted to get some
>> ideas/feedback.
>>
>> Dave.
>>
>> On 9 March 2017 at 13:52, Dave Airlie <airlied at gmail.com> wrote:
>>> On 28 February 2017 at 11:46, zhoucm1 <david1.zhou at amd.com> wrote:
>>>> Hi Dave,
>>>>
>>>> The attached is our semaphore implementation, amdgpu_cs.c is drm 
>>>> file, the
>>>> others are kernel file.
>>>> Any suggestion?
>>> Thanks,
>>>
>>> I've built a tree with all these in it, and started looking into the 
>>> interface.
>>>
>>> I do wonder if we need the separate sem signal/wait interface, I think
>>> we should just add
>>> semaphore chunks to the CS interface.
>>>
>>> I'm just playing around with this now.
>>>
>>> Dave.
>



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux