Does gbm_bo_map() implicitly synchronise?

[Michel Dänzer]

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