Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> Just had a few exchanges with Chris about this.
> Chris suggests that if we're about to add a point to the timeline in
> an unordered fashion, actually better not add it at all.
>
> What's your take on this?
That is a clear NAK. See not adding a point at all means we lose some
synchronization and that is not something we can do here.
In other words syncing to much if userspace does something nasty is ok
and defensive programmed, but not syncing at all could have unforeseen
consequences.
Another idea would be to add the fence, but also set an error flag and
deny any further signaling on that syncobj.
Regards,
Christian.
> I'm fine with this, but rather than add another variant of add_point()
> maybe we change change the existing.
>
> Thanks,
>
> -Lionel
>
> On 29/07/2019 11:20, Chunming Zhou wrote:
>> It is normal that binary syncobj replaces the underlying fence.
>>
>> Signed-off-by: Chunming Zhou <david1.zhou@xxxxxxx>
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>> b/drivers/gpu/drm/drm_syncobj.c
>> index 929f7c64f9a2..bc7ec1679e4d 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -151,9 +151,6 @@ void drm_syncobj_add_point(struct drm_syncobj
>> *syncobj,
>> spin_lock(&syncobj->lock);
>> prev = drm_syncobj_fence_get(syncobj);
>> - /* You are adding an unorder point to timeline, which could
>> cause payload returned from query_ioctl is 0! */
>> - if (prev && prev->seqno >= point)
>> - DRM_ERROR("You are adding an unorder point to timeline!\n");
>> dma_fence_chain_init(chain, prev, fence, point);
>> rcu_assign_pointer(syncobj->fence, &chain->base);
>
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
