On 2024-06-17 17:27, Pierre Ossman wrote: > On 17/06/2024 16:50, Michel Dänzer wrote: >> On 2024-06-17 12:29, Pierre Ossman wrote: >>> >>> Just to avoid any uncertainty, are both of these things done implicitly by >>> gbm_bo_map()/gbm_bo_unmap()? >>> >>> I did test adding those steps just in case, but unfortunately did not see >>> an improvement. My order was: >>> >>> 1. gbm_bo_import(GBM_BO_USE_RENDERING) >>> 2. gbm_bo_get_fd() >>> 3. Wait for client to request displaying the buffer >>> 4. gbm_bo_map(GBM_BO_TRANSFER_READ) >>> 5. select(fd+1, &fds, NULL, NULL, NULL) >> >> *If* select() is needed, it needs to be before gbm_bo_map(), because the >> latter may perform a blit from the real BO to a staging one for CPU access. >> > > Can I know whether it is needed or not? Or should I be cautious and always do > it?
Assuming GBM in the X server uses the GPU HW driver, I'd say it shouldn't be needed. > A recording of the issue is available here, in case the behaviour rings a > bell for anyone: > > http://www.cendio.com/~ossman/dri3/Screencast%20from%202024-06-17%2017-06-50.webm Interesting. Looks like the surroundings (drop shadow region?) of the window move along with it first, then the surroundings get fixed up in the next frame. As far as I know, mutter doesn't move window contents like that on the client side; it always redraws the damaged output region from scratch. So I wonder if the initial move together with surroundings is actually a blit on the X server side (possibly triggered by mutter moving the X window in its function as window manager). And then the surroundings fixing themselves up is the correct output from mutter via DRI3/Present. If so, the issue isn't synchronization, it's that the first blit happens at all. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer