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.
