<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/24 2:16, Christian König 写道: </div> <blockquote type="cite" cite="mid:ec405d48-cde7-907c-1eec-df4ac4e3a1e5@gmail.com"> <div class="moz-cite-prefix">Am 23.11.18 um 14:42 schrieb Chunming Zhou: </div> <blockquote type="cite" cite="mid:659c8ab4-2d30-be1b-2b96-62f33e2e4460@amd.com"> <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> In this case 6. If 9 or 12 wouldn't be signaled yet than those. <blockquote type="cite" cite="mid:659c8ab4-2d30-be1b-2b96-62f33e2e4460@amd.com"> <blockquote type="cite" cite="mid:dfd9476a-b4c1-951b-6cd9-62bfce3f62e0@amd.com"> <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. </blockquote> 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. </blockquote> 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 <blockquote type="cite" cite="mid:ec405d48-cde7-907c-1eec-df4ac4e3a1e5@gmail.com"> Christian. <blockquote type="cite" cite="mid:659c8ab4-2d30-be1b-2b96-62f33e2e4460@amd.com"> 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" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a> </pre> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ dri-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a> </pre> </blockquote> </blockquote> </body> </html>