On 2024-01-17 13:57, Xaver Hugl wrote: > Am Mi., 17. Jan. 2024 um 09:55 Uhr schrieb Pekka Paalanen <ppaalanen@xxxxxxxxx>: >> Is it important enough to be special-cased, e.g. to be always allowed >> with async commits? > > I thought so, and sent a patch to dri-devel to make it happen, but > there are some > concerns about untested driver paths. > https://lists.freedesktop.org/archives/dri-devel/2024-January/437511.html > >> Now that I think of it, if userspace needs to wait for the in-fence >> itself before kicking KMS async, that would defeat much of the async's >> point, right? And cases where in-fence is not necessary are so rare >> they might not even exist? >> >> So if driver/hardware cannot do IN_FENCE_FD with async, is there any >> use of supporting async to begin with? > > KWin never commits a buffer where IN_FENCE_FD would actually delay the > pageflip; it's really only used to disable implicit sync, as there's some edge > cases where it can wrongly delay the pageflip. The waiting for buffers to become > readable on the compositor side isn't really significant in terms of latency. > > If hardware doesn't support IN_FENCE_FD with async commits, checking if the > fence is already signaled at commit time would thus still make things work, at > least for KWin. That's how IN_FENCE_FD (and implicit sync) is handled anyway, in common code: It waits for all fences to signal before calling into the driver to commit the atomic commit. I can't see why this wouldn't work with async commits, the same as with synchronous ones, with any driver. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
