this patch series reminder me my another thoughts recently, But I don't
know if my idea is appropriated:
sometimes one person could only need wait any of these fence array, but
it doesn't want to call fence_wait_any since which will block its
thread. if there is a mechanism let the person register a callback to
these fence array, then that will be very convenient.
So I want to add a event fence, which is a special kind of fence and
indicates this event is satisfied and is signalled by any of the fence
array.
What do you think of it?
Regards,
David Zhou
On 2016å¹´03æ24æ¥ 15:20, Maarten Lankhorst wrote:
> Hey,
>
> Op 23-03-16 om 19:47 schreef Gustavo Padovan:
>> From: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
>>
>> Hi,
>>
>> This is a first proposal to discuss the addition of in-fences support
>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>> in DRM drivers. The new struct fence_collection contains a array with all
>> fences that a atomic commit needs to wait on
>>
>> /**
>> * struct fence_collection - aggregate fences together
>> * @num_fences: number of fence in the collection.
>> * @user_data: user data.
>> * @func: user callback to put user data.
>> * @fences: array of @num_fences fences.
>> */
>> struct fence_collection {
>> int num_fences;
>> void *user_data;
>> collection_put_func_t func;
>> struct fence *fences[];
>> };
>>
>>
>> The fence_collection is allocated and filled by sync_file_fences_get() and
>> atomic_commit helpers can use fence_collection_wait() to wait the fences to
>> signal.
>>
>> These patches depends on the sync ABI rework:
>>
>> https://www.spinics.net/lists/dri-devel/msg102795.html
>>
>> and the patch to de-stage the sync framework:
>>
>> https://www.spinics.net/lists/dri-devel/msg102799.html
>>
>>
>> I also hacked together some sync support into modetest for testing:
>>
>> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>>
> Why did you choose to add fence_collection, rather than putting sync_file in
> state?
>
> There used to be a sync_fence_wait function, which would mean you'd have
> everything you need.
>
> ~Maarten
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
