<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 04.11.24 um 22:32 schrieb Chia-I Wu: <blockquote type="cite" cite="mid:CAPaKu7TB30wvDvMW2FcYNcxjfDkOje358JNnRr2jJf=99-h-rg@mail.gmail.com"> <pre class="moz-quote-pre" wrap="">On Tue, Oct 22, 2024 at 10:24 AM Chia-I Wu <a class="moz-txt-link-rfc2396E" href="mailto:olvaffe@gmail.com"><olvaffe@gmail.com></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On Tue, Oct 22, 2024 at 9:53 AM Christian König <a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> Am 22.10.24 um 18:18 schrieb Chia-I Wu: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Userspace might poll a syncobj with the query ioctl. Call dma_fence_enable_sw_signaling to ensure dma_fence_is_signaled returns true in finite time. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Wait a second, just querying the fence status is absolutely not guaranteed to return true in finite time. That is well documented on the dma_fence() object. When you want to poll on signaling from userspace you really need to call poll or the wait IOCTL with a zero timeout. That will also return immediately but should enable signaling while doing that. So just querying the status should absolutely *not* enable signaling. That's an intentional separation. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">I think it depends on what semantics DRM_IOCTL_SYNCOBJ_QUERY should have.</pre> </blockquote> </blockquote> Well that's what I pointed out. The behavior of the QUERY IOCTL is based on the behavior of the dma_fence and the later is documented to do exactly what it currently does. <blockquote type="cite" cite="mid:CAPaKu7TB30wvDvMW2FcYNcxjfDkOje358JNnRr2jJf=99-h-rg@mail.gmail.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">If DRM_IOCTL_SYNCOBJ_QUERY is mainly for vulkan timeline semaphores, it is a bit heavy if userspace has to do a DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT before a query.</pre> </blockquote> </blockquote> Maybe you misunderstood me, you *only* have to call DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT and *not* _QUERY. The underlying dma_fence_wait_timeout() function is extra optimized so that zero timeout has only minimal overhead. This overhead is actually lower than _QUERY because that one actually queries the driver for the current status while _WAIT just assumes that the driver will signal the fence when ready from an interrupt. <blockquote type="cite" cite="mid:CAPaKu7TB30wvDvMW2FcYNcxjfDkOje358JNnRr2jJf=99-h-rg@mail.gmail.com"> <pre class="moz-quote-pre" wrap=""> I filed a Mesa issue, <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/mesa/mesa/-/issues/12094">https://gitlab.freedesktop.org/mesa/mesa/-/issues/12094</a>, and Faith suggested a kernel-side fix as well. Should we reconsider this? </pre> </blockquote> Wait a second, you might have an even bigger misconception here. The difference between waiting and querying is usually intentional! This is done so that for example on mobile devices you don't need to enable device interrupts, but rather query in defined intervals. This is a very common design pattern and while I don't know the wording of the Vulkan timeline extension it's quite likely that this is the intended use case. Regards, Christian. </body> </html>