On 11 April 2017 at 17:50, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
>> From: Dave Airlie <airlied@xxxxxxxxxx>
>>
>> This object can be used to implement the Vulkan semaphores.
>>
>> The object behaviour differs from fence, in that you can
>> replace the underlying fence, and you cannot merge semaphores.
>>
>> Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx>
>> ---
>> +/**
>> + * sync_file_replace_fence - replace the fence related to the sync_file
>> + * @sync_file: sync file to replace fence in
>> + * @fence: fence to replace with (or NULL for no fence).
>> + * Returns previous fence.
>> + */
>> +struct dma_fence *sync_file_replace_fence(struct sync_file *sync_file,
>> + struct dma_fence *fence)
>> +{
>> + struct dma_fence *ret_fence = NULL;
>> +
>> + if (sync_file->type != SYNC_FILE_TYPE_SEMAPHORE)
>> + return NULL;
>> +
>> + if (fence)
>> + dma_fence_get(fence);
>> +
>> + mutex_lock(&sync_file->lock);
>> +
>> + ret_fence = sync_file_get_fence_locked(sync_file);
>> + if (ret_fence) {
>> + if (test_bit(POLL_ENABLED, &ret_fence->flags))
>> + dma_fence_remove_callback(ret_fence, &sync_file->cb);
>> + }
>
> Fails when sync_file_replace_fence is passed sync_file->fence.
Not sure what the best semantics are there, any opinions on barring
wakeups/polling on semaphore sync_files, and just punting this
until we need it.
It would definitely simplify things.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
