Shared semaphores for amdgpu

Christian K├Ânig christian.koenig at amd.com
Fri Mar 10 09:12:45 UTC 2017


Am 10.03.2017 um 05:43 schrieb Dave Airlie:
> On 10 March 2017 at 14:27, Dave Airlie <airlied at gmail.com> wrote:
>> On 10 March 2017 at 13:25, Dave Airlie <airlied at gmail.com> wrote:
>>>> As far as I can see the only functionality we are missing here is:
>>>>
>>>> void sync_file_signal(struct sync_file *sync_file, struct dma_fence *fence)
>>>> {
>>>>      dma_fence_put(sync_file->fence);
>>>>      sync_file->fence = fence;
>>>> }
>>>>
>>>> We probably should do this atomically, but that is only a matter of taking
>>>> locks/atomic pointer operation.
>>>>
>>>> The waiting is done using the normal sync_file_get_fence() function.
>>>>
>>>> The rest is David's patch to import/export the fd handle into a local idr
>>>> based handle.
>>> Are you suggesting we start keeping track of sync_file objects in a local idr?

Yes, exactly.

>>> As currently they are only tracked as files, which is probably not what we want
>>> for every unshared semaphore, or are you thinking more that the amdgpu local
>>> sem should be just storing a sync_file pointer, rather than what it does now.
>> Okay here's a first pass at what I think you mean, it's missing
>> things, but the idea
>> should be what you said.

Yeah, that's pretty much what I had in mind.

If we can find consensus with the Intel guys on this we might want to 
move parts of the idr handling stuff into common code.

And I would give it another name, something like sync_handle or similar. 
As far as I can see it's just another representation of sync_file 
structures to userspace.

> (This version oopses of course due to NULL into sync_file_create,
> but that should be tirival to fix next week,)

Yeah, we of course need to figure out all the implementation details. 
But I think that won't be much trouble.

Christian.

>
> Dave.




More information about the amd-gfx mailing list