Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 19:18 schrieb Pierre Ossman:
> On 17/06/2024 18:09, Michel Dänzer wrote:
>>>
>>> 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.
>>
>
> It does not (except the driver libgbm loads). We're trying to use this 
> in Xvnc, so it's all CPU. We're just trying to make sure the 
> applications can use the full power of the GPU to render their stuff 
> before handing it over to the X server. :)

That whole approach won't work.

When you don't have a HW driver loaded or at least tell the client that 
it should render into a linear buffer somehow then the data in the 
buffer will be tilled in a hw specific format.

As far as I know you can't read that vendor agnostic with the CPU, you 
need the hw driver for that.

Regards,
Christian.

>
>>
>>> 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.
>>
>
> Hmm... The source of the blit is CopyWindow being called as a result 
> of the window moving. But I would have expected that to be inhibited 
> by the fact that a compositor is active. It's also surprising that 
> this only happens if DRI3 is involved.
>
> I would also have expected something similar with software rendering. 
> Albeit with a PutImage instead of PresentPixmap for the correct data. 
> But everything works there.
>
> I will need to dig further.
>
> Regards,