<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">在 2018/11/23 21:27, Koenig, Christian 写道: </div> <blockquote type="cite" cite="mid:dfd9476a-b4c1-951b-6cd9-62bfce3f62e0@amd.com"> <pre wrap="">Am 23.11.18 um 14:15 schrieb Zhou, David(ChunMing): </pre> <blockquote type="cite"> <pre wrap=""> 在 2018/11/23 20:02, Koenig, Christian 写道: </pre> <blockquote type="cite"> <pre wrap="">Am 23.11.18 um 12:03 schrieb Christian König: </pre> <blockquote type="cite"> <pre wrap="">Am 23.11.18 um 11:56 schrieb zhoucm1: </pre> <blockquote type="cite"> <pre wrap="">On 2018年11月23日 18:10, Koenig, Christian wrote: </pre> <blockquote type="cite"> <pre wrap="">Am 23.11.18 um 03:36 schrieb zhoucm1: </pre> <blockquote type="cite"> <pre wrap="">On 2018年11月22日 19:30, Christian König wrote: </pre> <blockquote type="cite"> <pre wrap="">Am 22.11.18 um 07:52 schrieb zhoucm1: </pre> <blockquote type="cite"> <pre wrap="">On 2018年11月15日 19:12, Christian König wrote: </pre> <blockquote type="cite"> <pre wrap="">Implement finding the right timeline point in drm_syncobj_find_fence. Signed-off-by: Christian König <a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a> --- 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; </pre> </blockquote> <pre wrap="">This condition isn't enough to find proper point. For two examples: a. No garbage collection happens, the points in chain are 1----3----6----9----12---18---20, if user wants to get point17, then we should return node 18. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">No, That will make timeline not work at all and break timeline semantics totally. If there aren't point18 and point20, the chain is 1----3----6----9----12, 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. </pre> </blockquote> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap="">For chain is 1----3----6----9----12---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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> That would still not allow to garbage collect the chain node itself.</pre> </blockquote> only middle chain nodes are need, so the chain shouldn't be too long, right? <blockquote type="cite" cite="mid:dfd9476a-b4c1-951b-6cd9-62bfce3f62e0@amd.com"> <pre wrap=""> 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.</pre> </blockquote> then what point we return when somebody asks for 11? <blockquote type="cite" cite="mid:dfd9476a-b4c1-951b-6cd9-62bfce3f62e0@amd.com"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Well I thought that we declared that signaling lower numbers is illegal?</pre> </blockquote> 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. Thanks, David <blockquote type="cite" cite="mid:dfd9476a-b4c1-951b-6cd9-62bfce3f62e0@amd.com"> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap=""> -David </pre> <blockquote type="cite"> <pre wrap="">Thanks, Christian. </pre> <blockquote type="cite"> <pre wrap="">Regards, Christian. </pre> <blockquote type="cite"> <pre wrap="">You can also check sw_sync.c for timeline meaning. -David </pre> <blockquote type="cite"> <pre wrap="">Christian. </pre> <blockquote type="cite"> <pre wrap="">-David </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Why? That doesn't seem to make any sense to me. </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap="">-David </pre> <blockquote type="cite"> <pre wrap="">+ } } + drm_syncobj_put(syncobj); return ret; } </pre> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> <pre wrap="">_______________________________________________ dri-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a> </pre> </blockquote> </blockquote> </blockquote> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>