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

[Daniel Vetter]

On Fri, Nov 23, 2018 at 01:40:16PM +0100, Christian König wrote:
> Am 23.11.18 um 13:26 schrieb Daniel Vetter:
> > On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote:
> > > Am 23.11.18 um 12:03 schrieb Christian König:
> > > > Am 23.11.18 um 11:56 schrieb zhoucm1:
> > > > > 
> > > > > On 2018年11月23日 18:10, Koenig, Christian wrote:
> > > > > > Am 23.11.18 um 03:36 schrieb zhoucm1:
> > > > > > > On 2018年11月22日 19:30, Christian König wrote:
> > > > > > > > Am 22.11.18 um 07:52 schrieb zhoucm1:
> > > > > > > > > On 2018年11月15日 19:12, Christian König wrote:
> > > > > > > > > > Implement finding the right timeline point in
> > > > > > > > > > drm_syncobj_find_fence.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Christian König 
> > > > > > > > > > ---
> > > > > > > > > >     drivers/gpu/drm/drm_syncobj.c | 10 +-
> > > > > > > > > >     1 file changed, 9 insertions(+), 1 deletion(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/drivers/gpu/drm/drm_syncobj.c
> > > > > > > > > > b/drivers/gpu/drm/drm_syncobj.c
> > > > > > > > > > index 589d884ccd58..d42c51520da4 100644
> > > > > > > > > > --- a/drivers/gpu/drm/drm_syncobj.c
> > > > > > > > > > +++ b/drivers/gpu/drm/drm_syncobj.c
> > > > > > > > > > @@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct 
> > > > > > > > > > drm_file
> > > > > > > > > > *file_private,
> > > > > > > > > >     return -ENOENT;
> > > > > > > > > >       *fence = drm_syncobj_fence_get(syncobj);
> > > > > > > > > > -    if (!*fence) {
> > > > > > > > > > +    if (!*fence)
> > > > > > > > > >     ret = -EINVAL;
> > > > > > > > > > +
> > > > > > > > > > +    if (!ret && point) {
> > > > > > > > > > +    dma_fence_chain_for_each(*fence) {
> > > > > > > > > > +    if (!to_dma_fence_chain(*fence) ||
> > > > > > > > > > +    (*fence)->seqno <= point)
> > > > > > > > > > +    break;
> > > > > > > > > This condition isn't enough to find proper point.
> > > > > > > > > For two examples:
> > > > > > > > > a. No garbage collection happens, the points in chain are
> > > > > > > > > 136912---18---20, if user wants to get 
> > > > > > > > > point17, then
> > > > > > > > > we should return node 18.
> > > > > > > > And that is exactly what's wrong in the original logic. In this 
> > > > > > > > case
> > > > > > > > we need to return 12, not 18 because point 17 could have 
> > > > > > > > already been
> > > > > > > > garbage collected.
> > > > > > > I don't think so, the 'a' case I already assume there isn't 
> > > > > > > garbage
> > > > > > > collection. If user wants to get point17, then we should return
> > > > > > > node 18.
> > > > > > > timeline means point[N]  must be signaled later than point[N-1].
> > > > > > > Point[12] just can make sure point[1] ~point[12] are signaled.
> > > > > > > Point[18] signal can make sure point[17] is signaled.
> > > > > > > So this case we need to return 18, not 12, which is key timeline
> > > > > > > concept.
> > > > > > No, exactly that's incorrect. When we ask for 17 and can't find it 
> > > > > > then
> > > > > > this means it either never existed or that it is signaled already.
> > > > > > 
> > > > > > Returning a lower number in this case or even a stub fence is 
> > > > > > perfectly
> > > > > > fine since we only need to wait for that one in this case.
> > > > > > 
> > > > > > If we return 18 in this case then we add incorrect synchronization 
> > > > > > when
> > > > > > there shouldn't be any.
> > > > > No, That will make timeline not work at all and break timeline
> > > > > semantics totally.
> > > > > 
> > > > > If there aren't point18 and point20, the chain is
> > > > > 136912, if user wants to get point 17, you also
> > > > > return 12? if yes, which absolutely is incorrect. The answer should
> > > > > be NO, right? point17 should be waited on there until a bigger point
> > > > > is coming.
> > > > Correct, but this is a different case. In this situation we either
> > > > return an error or wait for point 17 (or something >=17) to show up.
> > > > 
> > > > The key difference is if point 17 shows up then we return point 17,
> > > > but if point 18 shows up then we need to return point 12.
> > > > 
> > > > > For chain is 136912---18---20, if user wants to wait
> > > > > on any one of points 13,14,15,16,17,18, we must wait for point 18,
> > > > > this is timeline semantic.
> > > > Ah, now I understand. You are still sticking with the assumption of a
> > > > fence number, right?
> > > > 
> > > > In other words what you imply here is that we have the same semantic
> > > > as when somebody waits for a memory location to be written by number
> > > > 17, right? In this case the semantics you describe here indeed applies.
> > > > 
> > > > But that is certainly not what we want to implement or otherwise we
> > > > will never be able to garbage collect the numbers in between.
> > > > 
> > > > So if Vulkan has this 

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

[Chunming Zhou]

在 2018/11/24 2:16, Christian König 写道:
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:

136912---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  136912---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.
But that will lead timeline not monotonically increasing, won't it? Seems it's 
not good.
Which could result in some problems, e.g. if timeline is already up to 18, then 
userA think he can wait on 18, another signal point17 comes, the new sequence 
is changed to 17, but userA still send its command by appending wait on 
point18, which would never be signaled if no more signal comes, right?

-David

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



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

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

[Christian König]

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:

136912---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  136912---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


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

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

[Chunming Zhou]

在 2018/11/23 21:27, Koenig, Christian 写道:

Am 23.11.18 um 14:15 schrieb Zhou, David(ChunMing):



在 2018/11/23 20:02, Koenig, Christian 写道:


Am 23.11.18 um 12:03 schrieb Christian König:


Am 23.11.18 um 11:56 schrieb zhoucm1:


On 2018年11月23日 18:10, Koenig, Christian wrote:


Am 23.11.18 um 03:36 schrieb zhoucm1:


On 2018年11月22日 19:30, Christian König wrote:


Am 22.11.18 um 07:52 schrieb zhoucm1:


On 2018年11月15日 19:12, Christian König wrote:


Implement finding the right timeline point in
drm_syncobj_find_fence.

Signed-off-by: Christian König 

---
 drivers/gpu/drm/drm_syncobj.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
 return -ENOENT;
   *fence = drm_syncobj_fence_get(syncobj);
-if (!*fence) {
+if (!*fence)
 ret = -EINVAL;
+
+if (!ret && point) {
+dma_fence_chain_for_each(*fence) {
+if (!to_dma_fence_chain(*fence) ||
+(*fence)->seqno <= point)
+break;


This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are
136912---18---20, if user wants to get point17, then
we should return node 18.


And that is exactly what's wrong in the original logic. In this case
we need to return 12, not 18 because point 17 could have already been
garbage collected.


I don't think so, the 'a' case I already assume there isn't garbage
collection. If user wants to get point17, then we should return
node 18.
timeline means point[N]  must be signaled later than point[N-1].
Point[12] just can make sure point[1] ~point[12] are signaled.
Point[18] signal can make sure point[17] is signaled.
So this case we need to return 18, not 12, which is key timeline
concept.


No, exactly that's incorrect. When we ask for 17 and can't find it then
this means it either never existed or that it is signaled already.

Returning a lower number in this case or even a stub fence is perfectly
fine since we only need to wait for that one in this case.

If we return 18 in this case then we add incorrect synchronization when
there shouldn't be any.


No, That will make timeline not work at all and break timeline
semantics totally.

If there aren't point18 and point20, the chain is
136912, if user wants to get point 17, you also
return 12? if yes, which absolutely is incorrect. The answer should
be NO, right? point17 should be waited on there until a bigger point
is coming.


Correct, but this is a different case. In this situation we either
return an error or wait for point 17 (or something >=17) to show up.

The key difference is if point 17 shows up then we return point 17,
but if point 18 shows up then we need to return point 12.



For chain is 136912---18---20, if user wants to wait
on any one of points 13,14,15,16,17,18, we must wait for point 18,
this is timeline semantic.


Ah, now I understand. You are still sticking with the assumption of a
fence number, right?

In other words what you imply here is that we have the same semantic
as when somebody waits for a memory location to be written by number
17, right? In this case the semantics you describe here indeed applies.

But that is certainly not what we want to implement or otherwise we
will never be able to garbage collect the numbers in between.

So if Vulkan has this requirement then we need to reject that.


Backing of and reconsidering this I came to the conclusion that what you
suggest here is actually the most defensive solution.

In other words it is the solution where it's most likely that nothing
goes wrong because the worst thing that can happen is that we
synchronize to much, but never to less.

Going to think about it how we can bring that into alignment with the
proposed garbage collection.


Yeah, for garbae collection, I came up an idea this morning, we can pass
the signaled stub fence when chain node is created, when you walk out
all chain node, you can replace chain->fence with stub fence, that way,
there is no redudant fence referenced in chain node, and we can keep the
signal point in there.



That would still not allow to garbage collect the chain node itself.

only middle chain nodes are need, so the chain shouldn't be too long, right?




But I've came up with something which should work. Assume the original
chain is:

136912---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 

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

[Koenig, Christian]

Am 23.11.18 um 14:15 schrieb Zhou, David(ChunMing):
>
> 在 2018/11/23 20:02, Koenig, Christian 写道:
>> Am 23.11.18 um 12:03 schrieb Christian König:
>>> Am 23.11.18 um 11:56 schrieb zhoucm1:
 On 2018年11月23日 18:10, Koenig, Christian wrote:
> Am 23.11.18 um 03:36 schrieb zhoucm1:
>> On 2018年11月22日 19:30, Christian König wrote:
>>> Am 22.11.18 um 07:52 schrieb zhoucm1:
 On 2018年11月15日 19:12, Christian König wrote:
> Implement finding the right timeline point in
> drm_syncobj_find_fence.
>
> Signed-off-by: Christian König 
> ---
>      drivers/gpu/drm/drm_syncobj.c | 10 +-
>      1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c
> b/drivers/gpu/drm/drm_syncobj.c
> index 589d884ccd58..d42c51520da4 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
> *file_private,
>      return -ENOENT;
>        *fence = drm_syncobj_fence_get(syncobj);
> -    if (!*fence) {
> +    if (!*fence)
>      ret = -EINVAL;
> +
> +    if (!ret && point) {
> +    dma_fence_chain_for_each(*fence) {
> +    if (!to_dma_fence_chain(*fence) ||
> +    (*fence)->seqno <= point)
> +    break;
 This condition isn't enough to find proper point.
 For two examples:
 a. No garbage collection happens, the points in chain are
 136912---18---20, if user wants to get point17, then
 we should return node 18.
>>> And that is exactly what's wrong in the original logic. In this case
>>> we need to return 12, not 18 because point 17 could have already been
>>> garbage collected.
>> I don't think so, the 'a' case I already assume there isn't garbage
>> collection. If user wants to get point17, then we should return
>> node 18.
>> timeline means point[N]  must be signaled later than point[N-1].
>> Point[12] just can make sure point[1] ~point[12] are signaled.
>> Point[18] signal can make sure point[17] is signaled.
>> So this case we need to return 18, not 12, which is key timeline
>> concept.
> No, exactly that's incorrect. When we ask for 17 and can't find it then
> this means it either never existed or that it is signaled already.
>
> Returning a lower number in this case or even a stub fence is perfectly
> fine since we only need to wait for that one in this case.
>
> If we return 18 in this case then we add incorrect synchronization when
> there shouldn't be any.
 No, That will make timeline not work at all and break timeline
 semantics totally.

 If there aren't point18 and point20, the chain is
 136912, if user wants to get point 17, you also
 return 12? if yes, which absolutely is incorrect. The answer should
 be NO, right? point17 should be waited on there until a bigger point
 is coming.
>>> Correct, but this is a different case. In this situation we either
>>> return an error or wait for point 17 (or something >=17) to show up.
>>>
>>> The key difference is if point 17 shows up then we return point 17,
>>> but if point 18 shows up then we need to return point 12.
>>>
 For chain is 136912---18---20, if user wants to wait
 on any one of points 13,14,15,16,17,18, we must wait for point 18,
 this is timeline semantic.
>>> Ah, now I understand. You are still sticking with the assumption of a
>>> fence number, right?
>>>
>>> In other words what you imply here is that we have the same semantic
>>> as when somebody waits for a memory location to be written by number
>>> 17, right? In this case the semantics you describe here indeed applies.
>>>
>>> But that is certainly not what we want to implement or otherwise we
>>> will never be able to garbage collect the numbers in between.
>>>
>>> So if Vulkan has this requirement then we need to reject that.
>> Backing of and reconsidering this I came to the conclusion that what you
>> suggest here is actually the most defensive solution.
>>
>> In other words it is the solution where it's most likely that nothing
>> goes wrong because the worst thing that can happen is that we
>> synchronize to much, but never to less.
>>
>> Going to think about it how we can bring that into alignment with the
>> proposed garbage collection.
> Yeah, for garbae collection, I came up an idea this morning, we can pass
> the signaled stub fence when chain node is created, when you walk out
> all chain node, you can replace chain->fence with stub fence, that way,
> there is no redudant fence referenced in chain node, and we can keep the
> signal point in there.

That would still not allow to garbage 

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

[Chunming Zhou]

在 2018/11/23 20:02, Koenig, Christian 写道:
> Am 23.11.18 um 12:03 schrieb Christian König:
>> Am 23.11.18 um 11:56 schrieb zhoucm1:
>>>
>>> On 2018年11月23日 18:10, Koenig, Christian wrote:
 Am 23.11.18 um 03:36 schrieb zhoucm1:
> On 2018年11月22日 19:30, Christian König wrote:
>> Am 22.11.18 um 07:52 schrieb zhoucm1:
>>> On 2018年11月15日 19:12, Christian König wrote:
 Implement finding the right timeline point in
 drm_syncobj_find_fence.

 Signed-off-by: Christian König 
 ---
     drivers/gpu/drm/drm_syncobj.c | 10 +-
     1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_syncobj.c
 b/drivers/gpu/drm/drm_syncobj.c
 index 589d884ccd58..d42c51520da4 100644
 --- a/drivers/gpu/drm/drm_syncobj.c
 +++ b/drivers/gpu/drm/drm_syncobj.c
 @@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
 *file_private,
     return -ENOENT;
       *fence = drm_syncobj_fence_get(syncobj);
 -    if (!*fence) {
 +    if (!*fence)
     ret = -EINVAL;
 +
 +    if (!ret && point) {
 +    dma_fence_chain_for_each(*fence) {
 +    if (!to_dma_fence_chain(*fence) ||
 +    (*fence)->seqno <= point)
 +    break;
>>> This condition isn't enough to find proper point.
>>> For two examples:
>>> a. No garbage collection happens, the points in chain are
>>> 136912---18---20, if user wants to get point17, then
>>> we should return node 18.
>> And that is exactly what's wrong in the original logic. In this case
>> we need to return 12, not 18 because point 17 could have already been
>> garbage collected.
> I don't think so, the 'a' case I already assume there isn't garbage
> collection. If user wants to get point17, then we should return
> node 18.
> timeline means point[N]  must be signaled later than point[N-1].
> Point[12] just can make sure point[1] ~point[12] are signaled.
> Point[18] signal can make sure point[17] is signaled.
> So this case we need to return 18, not 12, which is key timeline
> concept.
 No, exactly that's incorrect. When we ask for 17 and can't find it then
 this means it either never existed or that it is signaled already.

 Returning a lower number in this case or even a stub fence is perfectly
 fine since we only need to wait for that one in this case.

 If we return 18 in this case then we add incorrect synchronization when
 there shouldn't be any.
>>> No, That will make timeline not work at all and break timeline
>>> semantics totally.
>>>
>>> If there aren't point18 and point20, the chain is
>>> 136912, if user wants to get point 17, you also
>>> return 12? if yes, which absolutely is incorrect. The answer should
>>> be NO, right? point17 should be waited on there until a bigger point
>>> is coming.
>> Correct, but this is a different case. In this situation we either
>> return an error or wait for point 17 (or something >=17) to show up.
>>
>> The key difference is if point 17 shows up then we return point 17,
>> but if point 18 shows up then we need to return point 12.
>>
>>> For chain is 136912---18---20, if user wants to wait
>>> on any one of points 13,14,15,16,17,18, we must wait for point 18,
>>> this is timeline semantic.
>> Ah, now I understand. You are still sticking with the assumption of a
>> fence number, right?
>>
>> In other words what you imply here is that we have the same semantic
>> as when somebody waits for a memory location to be written by number
>> 17, right? In this case the semantics you describe here indeed applies.
>>
>> But that is certainly not what we want to implement or otherwise we
>> will never be able to garbage collect the numbers in between.
>>
>> So if Vulkan has this requirement then we need to reject that.
> Backing of and reconsidering this I came to the conclusion that what you
> suggest here is actually the most defensive solution.
>
> In other words it is the solution where it's most likely that nothing
> goes wrong because the worst thing that can happen is that we
> synchronize to much, but never to less.
>
> Going to think about it how we can bring that into alignment with the
> proposed garbage collection.
Yeah, for garbae collection, I came up an idea this morning, we can pass 
the signaled stub fence when chain node is created, when you walk out 
all chain node, you can replace chain->fence with stub fence, that way, 
there is no redudant fence referenced in chain node, and we can keep the 
signal point in there.

Another use case, I'm not sure if you considered:
if chain is  136912---18, a wait operation is on point 
17, then we return 18, another signal point 17 comes, then we still wait 
on 

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

[Christian König]

Am 23.11.18 um 13:26 schrieb Daniel Vetter:

On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote:

Am 23.11.18 um 12:03 schrieb Christian König:

Am 23.11.18 um 11:56 schrieb zhoucm1:


On 2018年11月23日 18:10, Koenig, Christian wrote:

Am 23.11.18 um 03:36 schrieb zhoucm1:

On 2018年11月22日 19:30, Christian König wrote:

Am 22.11.18 um 07:52 schrieb zhoucm1:

On 2018年11月15日 19:12, Christian König wrote:

Implement finding the right timeline point in
drm_syncobj_find_fence.

Signed-off-by: Christian König 
---
    drivers/gpu/drm/drm_syncobj.c | 10 +-
    1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
    return -ENOENT;
      *fence = drm_syncobj_fence_get(syncobj);
-    if (!*fence) {
+    if (!*fence)
    ret = -EINVAL;
+
+    if (!ret && point) {
+    dma_fence_chain_for_each(*fence) {
+    if (!to_dma_fence_chain(*fence) ||
+    (*fence)->seqno <= point)
+    break;

This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are
136912---18---20, if user wants to get point17, then
we should return node 18.

And that is exactly what's wrong in the original logic. In this case
we need to return 12, not 18 because point 17 could have already been
garbage collected.

I don't think so, the 'a' case I already assume there isn't garbage
collection. If user wants to get point17, then we should return
node 18.
timeline means point[N]  must be signaled later than point[N-1].
Point[12] just can make sure point[1] ~point[12] are signaled.
Point[18] signal can make sure point[17] is signaled.
So this case we need to return 18, not 12, which is key timeline
concept.

No, exactly that's incorrect. When we ask for 17 and can't find it then
this means it either never existed or that it is signaled already.

Returning a lower number in this case or even a stub fence is perfectly
fine since we only need to wait for that one in this case.

If we return 18 in this case then we add incorrect synchronization when
there shouldn't be any.

No, That will make timeline not work at all and break timeline
semantics totally.

If there aren't point18 and point20, the chain is
136912, if user wants to get point 17, you also
return 12? if yes, which absolutely is incorrect. The answer should
be NO, right? point17 should be waited on there until a bigger point
is coming.

Correct, but this is a different case. In this situation we either
return an error or wait for point 17 (or something >=17) to show up.

The key difference is if point 17 shows up then we return point 17,
but if point 18 shows up then we need to return point 12.


For chain is 136912---18---20, if user wants to wait
on any one of points 13,14,15,16,17,18, we must wait for point 18,
this is timeline semantic.

Ah, now I understand. You are still sticking with the assumption of a
fence number, right?

In other words what you imply here is that we have the same semantic
as when somebody waits for a memory location to be written by number
17, right? In this case the semantics you describe here indeed applies.

But that is certainly not what we want to implement or otherwise we
will never be able to garbage collect the numbers in between.

So if Vulkan has this requirement then we need to reject that.

Backing of and reconsidering this I came to the conclusion that what you
suggest here is actually the most defensive solution.

In other words it is the solution where it's most likely that nothing
goes wrong because the worst thing that can happen is that we
synchronize to much, but never to less.

Going to think about it how we can bring that into alignment with the
proposed garbage collection.

Should we implement the tests first (either as in-kernel unit tests, like
we have some, or in igt on top of vgem), agree on the semantics we want,
then work on the implementation?

All these discussions and gotchas and "oops another corner case we missed"
when only looking at the implementation feels like it could work out
better if we attack this from the other side of the uapi barrier ...


Well I agree that this "oops another corner case we missed" is exactly 
the key problem here.


But when the kernel developers implement the test cases we just move the 
issue to another place and not fundamentally solve it.


What we should do is to push the anv/radv/amdvlk devs to go ahead and 
implement test cases for all the ugly corner cases they have in mind.


Additional to that I really think that the UAPI David(ChunMing) came up 
with is actually pretty solid, so everything should actually be good to 
go to do this.


Regards,
Christian.

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

[Daniel Vetter]

On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote:
> Am 23.11.18 um 12:03 schrieb Christian König:
> > Am 23.11.18 um 11:56 schrieb zhoucm1:
> >>
> >>
> >> On 2018年11月23日 18:10, Koenig, Christian wrote:
> >>> Am 23.11.18 um 03:36 schrieb zhoucm1:
> 
>  On 2018年11月22日 19:30, Christian König wrote:
> > Am 22.11.18 um 07:52 schrieb zhoucm1:
> >>
> >> On 2018年11月15日 19:12, Christian König wrote:
> >>> Implement finding the right timeline point in 
> >>> drm_syncobj_find_fence.
> >>>
> >>> Signed-off-by: Christian König 
> >>> ---
> >>>    drivers/gpu/drm/drm_syncobj.c | 10 +-
> >>>    1 file changed, 9 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_syncobj.c
> >>> b/drivers/gpu/drm/drm_syncobj.c
> >>> index 589d884ccd58..d42c51520da4 100644
> >>> --- a/drivers/gpu/drm/drm_syncobj.c
> >>> +++ b/drivers/gpu/drm/drm_syncobj.c
> >>> @@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
> >>> *file_private,
> >>>    return -ENOENT;
> >>>      *fence = drm_syncobj_fence_get(syncobj);
> >>> -    if (!*fence) {
> >>> +    if (!*fence)
> >>>    ret = -EINVAL;
> >>> +
> >>> +    if (!ret && point) {
> >>> +    dma_fence_chain_for_each(*fence) {
> >>> +    if (!to_dma_fence_chain(*fence) ||
> >>> +    (*fence)->seqno <= point)
> >>> +    break;
> >> This condition isn't enough to find proper point.
> >> For two examples:
> >> a. No garbage collection happens, the points in chain are
> >> 136912---18---20, if user wants to get point17, then
> >> we should return node 18.
> > And that is exactly what's wrong in the original logic. In this case
> > we need to return 12, not 18 because point 17 could have already been
> > garbage collected.
>  I don't think so, the 'a' case I already assume there isn't garbage
>  collection. If user wants to get point17, then we should return 
>  node 18.
>  timeline means point[N]  must be signaled later than point[N-1].
>  Point[12] just can make sure point[1] ~point[12] are signaled.
>  Point[18] signal can make sure point[17] is signaled.
>  So this case we need to return 18, not 12, which is key timeline 
>  concept.
> >>> No, exactly that's incorrect. When we ask for 17 and can't find it then
> >>> this means it either never existed or that it is signaled already.
> >>>
> >>> Returning a lower number in this case or even a stub fence is perfectly
> >>> fine since we only need to wait for that one in this case.
> >>>
> >>> If we return 18 in this case then we add incorrect synchronization when
> >>> there shouldn't be any.
> >> No, That will make timeline not work at all and break timeline 
> >> semantics totally.
> >>
> >> If there aren't point18 and point20, the chain is 
> >> 136912, if user wants to get point 17, you also 
> >> return 12? if yes, which absolutely is incorrect. The answer should 
> >> be NO, right? point17 should be waited on there until a bigger point 
> >> is coming.
> >
> > Correct, but this is a different case. In this situation we either 
> > return an error or wait for point 17 (or something >=17) to show up.
> >
> > The key difference is if point 17 shows up then we return point 17, 
> > but if point 18 shows up then we need to return point 12.
> >
> >> For chain is 136912---18---20, if user wants to wait 
> >> on any one of points 13,14,15,16,17,18, we must wait for point 18, 
> >> this is timeline semantic.
> >
> > Ah, now I understand. You are still sticking with the assumption of a 
> > fence number, right?
> >
> > In other words what you imply here is that we have the same semantic 
> > as when somebody waits for a memory location to be written by number 
> > 17, right? In this case the semantics you describe here indeed applies.
> >
> > But that is certainly not what we want to implement or otherwise we 
> > will never be able to garbage collect the numbers in between.
> >
> > So if Vulkan has this requirement then we need to reject that.
> 
> Backing of and reconsidering this I came to the conclusion that what you 
> suggest here is actually the most defensive solution.
> 
> In other words it is the solution where it's most likely that nothing 
> goes wrong because the worst thing that can happen is that we 
> synchronize to much, but never to less.
> 
> Going to think about it how we can bring that into alignment with the 
> proposed garbage collection.

Should we implement the tests first (either as in-kernel unit tests, like
we have some, or in igt on top of vgem), agree on the semantics we want,
then work on the implementation?

All these discussions and gotchas and "oops another corner case we missed"
when only looking at the implementation feels like it could work out
better if we attack this from 

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

[Koenig, Christian]

Am 23.11.18 um 12:03 schrieb Christian König:
> Am 23.11.18 um 11:56 schrieb zhoucm1:
>>
>>
>> On 2018年11月23日 18:10, Koenig, Christian wrote:
>>> Am 23.11.18 um 03:36 schrieb zhoucm1:

 On 2018年11月22日 19:30, Christian König wrote:
> Am 22.11.18 um 07:52 schrieb zhoucm1:
>>
>> On 2018年11月15日 19:12, Christian König wrote:
>>> Implement finding the right timeline point in 
>>> drm_syncobj_find_fence.
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>    drivers/gpu/drm/drm_syncobj.c | 10 +-
>>>    1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>>> b/drivers/gpu/drm/drm_syncobj.c
>>> index 589d884ccd58..d42c51520da4 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
>>> *file_private,
>>>    return -ENOENT;
>>>      *fence = drm_syncobj_fence_get(syncobj);
>>> -    if (!*fence) {
>>> +    if (!*fence)
>>>    ret = -EINVAL;
>>> +
>>> +    if (!ret && point) {
>>> +    dma_fence_chain_for_each(*fence) {
>>> +    if (!to_dma_fence_chain(*fence) ||
>>> +    (*fence)->seqno <= point)
>>> +    break;
>> This condition isn't enough to find proper point.
>> For two examples:
>> a. No garbage collection happens, the points in chain are
>> 136912---18---20, if user wants to get point17, then
>> we should return node 18.
> And that is exactly what's wrong in the original logic. In this case
> we need to return 12, not 18 because point 17 could have already been
> garbage collected.
 I don't think so, the 'a' case I already assume there isn't garbage
 collection. If user wants to get point17, then we should return 
 node 18.
 timeline means point[N]  must be signaled later than point[N-1].
 Point[12] just can make sure point[1] ~point[12] are signaled.
 Point[18] signal can make sure point[17] is signaled.
 So this case we need to return 18, not 12, which is key timeline 
 concept.
>>> No, exactly that's incorrect. When we ask for 17 and can't find it then
>>> this means it either never existed or that it is signaled already.
>>>
>>> Returning a lower number in this case or even a stub fence is perfectly
>>> fine since we only need to wait for that one in this case.
>>>
>>> If we return 18 in this case then we add incorrect synchronization when
>>> there shouldn't be any.
>> No, That will make timeline not work at all and break timeline 
>> semantics totally.
>>
>> If there aren't point18 and point20, the chain is 
>> 136912, if user wants to get point 17, you also 
>> return 12? if yes, which absolutely is incorrect. The answer should 
>> be NO, right? point17 should be waited on there until a bigger point 
>> is coming.
>
> Correct, but this is a different case. In this situation we either 
> return an error or wait for point 17 (or something >=17) to show up.
>
> The key difference is if point 17 shows up then we return point 17, 
> but if point 18 shows up then we need to return point 12.
>
>> For chain is 136912---18---20, if user wants to wait 
>> on any one of points 13,14,15,16,17,18, we must wait for point 18, 
>> this is timeline semantic.
>
> Ah, now I understand. You are still sticking with the assumption of a 
> fence number, right?
>
> In other words what you imply here is that we have the same semantic 
> as when somebody waits for a memory location to be written by number 
> 17, right? In this case the semantics you describe here indeed applies.
>
> But that is certainly not what we want to implement or otherwise we 
> will never be able to garbage collect the numbers in between.
>
> So if Vulkan has this requirement then we need to reject that.

Backing of and reconsidering this I came to the conclusion that what you 
suggest here is actually the most defensive solution.

In other words it is the solution where it's most likely that nothing 
goes wrong because the worst thing that can happen is that we 
synchronize to much, but never to less.

Going to think about it how we can bring that into alignment with the 
proposed garbage collection.

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 

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

[Christian König]

Am 23.11.18 um 11:56 schrieb zhoucm1:



On 2018年11月23日 18:10, Koenig, Christian wrote:

Am 23.11.18 um 03:36 schrieb zhoucm1:


On 2018年11月22日 19:30, Christian König wrote:

Am 22.11.18 um 07:52 schrieb zhoucm1:


On 2018年11月15日 19:12, Christian König wrote:
Implement finding the right timeline point in 
drm_syncobj_find_fence.


Signed-off-by: Christian König 
---
   drivers/gpu/drm/drm_syncobj.c | 10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
   return -ENOENT;
     *fence = drm_syncobj_fence_get(syncobj);
-    if (!*fence) {
+    if (!*fence)
   ret = -EINVAL;
+
+    if (!ret && point) {
+    dma_fence_chain_for_each(*fence) {
+    if (!to_dma_fence_chain(*fence) ||
+    (*fence)->seqno <= point)
+    break;

This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are
136912---18---20, if user wants to get point17, then
we should return node 18.

And that is exactly what's wrong in the original logic. In this case
we need to return 12, not 18 because point 17 could have already been
garbage collected.

I don't think so, the 'a' case I already assume there isn't garbage
collection. If user wants to get point17, then we should return node 
18.

timeline means point[N]  must be signaled later than point[N-1].
Point[12] just can make sure point[1] ~point[12] are signaled.
Point[18] signal can make sure point[17] is signaled.
So this case we need to return 18, not 12, which is key timeline 
concept.

No, exactly that's incorrect. When we ask for 17 and can't find it then
this means it either never existed or that it is signaled already.

Returning a lower number in this case or even a stub fence is perfectly
fine since we only need to wait for that one in this case.

If we return 18 in this case then we add incorrect synchronization when
there shouldn't be any.
No, That will make timeline not work at all and break timeline 
semantics totally.


If there aren't point18 and point20, the chain is 
136912, if user wants to get point 17, you also return 
12? if yes, which absolutely is incorrect. The answer should be NO, 
right? point17 should be waited on there until a bigger point is coming.


Correct, but this is a different case. In this situation we either 
return an error or wait for point 17 (or something >=17) to show up.


The key difference is if point 17 shows up then we return point 17, but 
if point 18 shows up then we need to return point 12.


For chain is 136912---18---20, if user wants to wait 
on any one of points 13,14,15,16,17,18, we must wait for point 18, 
this is timeline semantic.


Ah, now I understand. You are still sticking with the assumption of a 
fence number, right?


In other words what you imply here is that we have the same semantic as 
when somebody waits for a memory location to be written by number 17, 
right? In this case the semantics you describe here indeed applies.


But that is certainly not what we want to implement or otherwise we will 
never be able to garbage collect the numbers in between.


So if Vulkan has this requirement then we need to reject that.

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

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

[zhoucm1]

On 2018年11月23日 18:10, Koenig, Christian wrote:

Am 23.11.18 um 03:36 schrieb zhoucm1:


On 2018年11月22日 19:30, Christian König wrote:

Am 22.11.18 um 07:52 schrieb zhoucm1:


On 2018年11月15日 19:12, Christian König wrote:

Implement finding the right timeline point in drm_syncobj_find_fence.

Signed-off-by: Christian König 
---
   drivers/gpu/drm/drm_syncobj.c | 10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
   return -ENOENT;
     *fence = drm_syncobj_fence_get(syncobj);
-    if (!*fence) {
+    if (!*fence)
   ret = -EINVAL;
+
+    if (!ret && point) {
+    dma_fence_chain_for_each(*fence) {
+    if (!to_dma_fence_chain(*fence) ||
+    (*fence)->seqno <= point)
+    break;

This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are
136912---18---20, if user wants to get point17, then
we should return node 18.

And that is exactly what's wrong in the original logic. In this case
we need to return 12, not 18 because point 17 could have already been
garbage collected.

I don't think so, the 'a' case I already assume there isn't garbage
collection. If user wants to get point17, then we should return node 18.
timeline means point[N]  must be signaled later than point[N-1].
Point[12] just can make sure point[1] ~point[12] are signaled.
Point[18] signal can make sure point[17] is signaled.
So this case we need to return 18, not 12, which is key timeline concept.

No, exactly that's incorrect. When we ask for 17 and can't find it then
this means it either never existed or that it is signaled already.

Returning a lower number in this case or even a stub fence is perfectly
fine since we only need to wait for that one in this case.

If we return 18 in this case then we add incorrect synchronization when
there shouldn't be any.
No, That will make timeline not work at all and break timeline semantics 
totally.


If there aren't point18 and point20, the chain is 
136912, if user wants to get point 17, you also return 
12? if yes, which absolutely is incorrect. The answer should be NO, 
right? point17 should be waited on there until a bigger point is coming.


For chain is 136912---18---20, if user wants to wait on 
any one of points 13,14,15,16,17,18, we must wait for point 18, this is 
timeline semantic.


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

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

[Koenig, Christian]

Am 23.11.18 um 03:36 schrieb zhoucm1:
>
>
> On 2018年11月22日 19:30, Christian König wrote:
>> Am 22.11.18 um 07:52 schrieb zhoucm1:
>>>
>>>
>>> On 2018年11月15日 19:12, Christian König wrote:
 Implement finding the right timeline point in drm_syncobj_find_fence.

 Signed-off-by: Christian König 
 ---
   drivers/gpu/drm/drm_syncobj.c | 10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_syncobj.c 
 b/drivers/gpu/drm/drm_syncobj.c
 index 589d884ccd58..d42c51520da4 100644
 --- a/drivers/gpu/drm/drm_syncobj.c
 +++ b/drivers/gpu/drm/drm_syncobj.c
 @@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file 
 *file_private,
   return -ENOENT;
     *fence = drm_syncobj_fence_get(syncobj);
 -    if (!*fence) {
 +    if (!*fence)
   ret = -EINVAL;
 +
 +    if (!ret && point) {
 +    dma_fence_chain_for_each(*fence) {
 +    if (!to_dma_fence_chain(*fence) ||
 +    (*fence)->seqno <= point)
 +    break;
>>> This condition isn't enough to find proper point.
>>> For two examples:
>>> a. No garbage collection happens, the points in chain are 
>>> 136912---18---20, if user wants to get point17, then 
>>> we should return node 18.
>>
>> And that is exactly what's wrong in the original logic. In this case 
>> we need to return 12, not 18 because point 17 could have already been 
>> garbage collected.
> I don't think so, the 'a' case I already assume there isn't garbage 
> collection. If user wants to get point17, then we should return node 18.
> timeline means point[N]  must be signaled later than point[N-1].
> Point[12] just can make sure point[1] ~point[12] are signaled.
> Point[18] signal can make sure point[17] is signaled.
> So this case we need to return 18, not 12, which is key timeline concept.

No, exactly that's incorrect. When we ask for 17 and can't find it then 
this means it either never existed or that it is signaled already.

Returning a lower number in this case or even a stub fence is perfectly 
fine since we only need to wait for that one in this case.

If we return 18 in this case then we add incorrect synchronization when 
there shouldn't be any.

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

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

[zhoucm1]

On 2018年11月22日 19:30, Christian König wrote:

Am 22.11.18 um 07:52 schrieb zhoucm1:



On 2018年11月15日 19:12, Christian König wrote:

Implement finding the right timeline point in drm_syncobj_find_fence.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/drm_syncobj.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c 
b/drivers/gpu/drm/drm_syncobj.c

index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file 
*file_private,

  return -ENOENT;
    *fence = drm_syncobj_fence_get(syncobj);
-    if (!*fence) {
+    if (!*fence)
  ret = -EINVAL;
+
+    if (!ret && point) {
+    dma_fence_chain_for_each(*fence) {
+    if (!to_dma_fence_chain(*fence) ||
+    (*fence)->seqno <= point)
+    break;

This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are 
136912---18---20, if user wants to get point17, then 
we should return node 18.


And that is exactly what's wrong in the original logic. In this case 
we need to return 12, not 18 because point 17 could have already been 
garbage collected.
I don't think so, the 'a' case I already assume there isn't garbage 
collection. If user wants to get point17, then we should return node 18.

timeline means point[N]  must be signaled later than point[N-1].
Point[12] just can make sure point[1] ~point[12] are signaled.
Point[18] signal can make sure point[17] is signaled.
So this case we need to return 18, not 12, which is key timeline concept.

-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

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

[Christian König]

Am 22.11.18 um 07:52 schrieb zhoucm1:



On 2018年11月15日 19:12, Christian König wrote:

Implement finding the right timeline point in drm_syncobj_find_fence.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/drm_syncobj.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c 
b/drivers/gpu/drm/drm_syncobj.c

index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file 
*file_private,

  return -ENOENT;
    *fence = drm_syncobj_fence_get(syncobj);
-    if (!*fence) {
+    if (!*fence)
  ret = -EINVAL;
+
+    if (!ret && point) {
+    dma_fence_chain_for_each(*fence) {
+    if (!to_dma_fence_chain(*fence) ||
+    (*fence)->seqno <= point)
+    break;

This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are 
136912---18---20, if user wants to get point17, then 
we should return node 18.


And that is exactly what's wrong in the original logic. In this case we 
need to return 12, not 18 because point 17 could have already been 
garbage collected.


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

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

[zhoucm1]

On 2018年11月15日 19:12, Christian König wrote:

Implement finding the right timeline point in drm_syncobj_find_fence.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/drm_syncobj.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
return -ENOENT;
  
  	*fence = drm_syncobj_fence_get(syncobj);

-   if (!*fence) {
+   if (!*fence)
ret = -EINVAL;
+
+   if (!ret && point) {
+   dma_fence_chain_for_each(*fence) {
+   if (!to_dma_fence_chain(*fence) ||
+   (*fence)->seqno <= point)
+   break;

This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are 
136912---18---20, if user wants to get point17, then we 
should return node 18.
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.


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?



-David

+   }
}
+
drm_syncobj_put(syncobj);
return ret;
  }


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