Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4293 bytes --]

Am 23.11.18 um 14:42 schrieb Chunming Zhou:
>
>> But I've came up with something which should work. Assume the original
>> chain is:
>>
>> 1----3----6----9----12---18
>>
>> And we garbage collect everything but 6 and 18 then all we need to know
>> to return the correct node is what the original previous sequence number
>> was.
>>
>> 6 (3)----18 (12)
>>
>> When then somebody asks for 17 we can still return 18 and if somebody
>> asks for 9 we would return 6.
> then what point we return when somebody asks for 11?

In this case 6. If 9 or 12 wouldn't be signaled yet than those.

>
>>> Another use case, I'm not sure if you considered:
>>> if chain is  1----3----6----9----12---18, a wait operation is on point
>>> 17, then we return 18, another signal point 17 comes, then we still wait
>>> on 18(assume 18 takes very long time), that looks not reseonable, but
>>> this is just performance problem potientially. Seems the way of timeline
>>> sw_sync.c with comparing point for signal status can sovle it.
>> Well I thought that we declared that signaling lower numbers is illegal?
> Sorry, I forgot it, quote from spec: "
>
> *RESOLVED*: A 64-bit unsigned integer that can only be set to 
> monotonically
>
> increasing values by signal operations and is not changed by wait 
> operations."
>
> Can we think signaling lower numbers is forbidden?
>
> If that's true, we can directly ignore lower number and return without 
> error, keep the larger signal point.

I've considered this as well, but came to the conclusion that we then 
would lose some sync fence.

Starting a new sequence when userspace does that is the better 
alternative, cause then we again always sync to much but never to less.

Christian.

>
> Thanks,
> David
>> My current solution to that is when userspace messes up the sequence
>> numbers and submit 1-3-6-9-12-18-17 we start a new chain with 17 and
>> never look back.
>>
>> E.g. when somebody then asks for anything below 17 we always return 17
>> and if somebody asks for 18 we return an error because that is handled
>> as not signaled yet.
>>
>> Regards,
>> Christian.
>>
>>> -David
>>>
>>>> Thanks,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>> You can also check sw_sync.c for timeline meaning.
>>>>>>
>>>>>> -David
>>>>>>> Christian.
>>>>>>>
>>>>>>>> -David
>>>>>>>>>> b. garbage collection happens on point6, chain would be updated to
>>>>>>>>>> 1---3---9---12---18---20, if user wants to get point5, then we
>>>>>>>>>> should return node 3, but if user wants to get point 7, then we
>>>>>>>>>> should return node 9.
>>>>>>>>> Why? That doesn't seem to make any sense to me.
>>>>>>>>>
>>>>>>>>>> I still have no idea how to satisfy all these requirements with your
>>>>>>>>>> current chain-fence. All these logic just are same we encountered
>>>>>>>>>> before, we're walking them again. After solving these problems, I
>>>>>>>>>> guess all design is similar as before.
>>>>>>>>>>
>>>>>>>>>> In fact, I don't know what problem previous design has, maybe there
>>>>>>>>>> are some bugs, can't we fix these bugs by time going? Who can make
>>>>>>>>>> sure his implementation never have bugs?
>>>>>>>>> Well there where numerous problems with the original design. For
>>>>>>>>> example we need to reject the requirement that timeline fences are in
>>>>>>>>> order because that doesn't make sense in the kernel.
>>>>>>>>>
>>>>>>>>> When userspace does something like submitting fences in the order 1,
>>>>>>>>> 5, 3 then it is broken and can keep the pieces. In other words the
>>>>>>>>> kernel should not care about that, but rather make sure that it never
>>>>>>>>> looses any synchronization no matter what.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Christian.
>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>> +        }
>>>>>>>>>>>           }
>>>>>>>>>>> +
>>>>>>>>>>>           drm_syncobj_put(syncobj);
>>>>>>>>>>>           return ret;
>>>>>>>>>>>       }
>>>>>> _______________________________________________
>>>>>> dri-devel mailing list
>>>>>> dri-devel@lists.freedesktop.org
>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[-- Attachment #1.2: Type: text/html, Size: 6955 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel