Re: Does gbm_bo_map() implicitly synchronise?

Am 17.06.24 um 09:32 schrieb Pierre Ossman:
> On 15/06/2024 13:35, Marek Olšák wrote:
>> It's probably driver-specific. Some drivers might need glFlush before
>> you use gbm_bo_map because gbm might only wait for work that has been
>> flushed.
>>
>
> That would be needed on the "writing" side, right? So if I'm seeing 
> issues when mapping for reading, then it would indicate a bug in the 
> other peer? Which would be gnome-shell in my case.
>
> Any way I could test this? Can I force extra syncs/flushes in some way 
> and see if the issue goes away?

Well the primary question here is what do you want to wait for?

As Marek wrote GBM and the kernel can only see work which has been 
flushed and is not queued up inside the OpenGL library for example.

> I tried adding a sleep of 10ms before reading the data, but did not 
> see any improvement. Which would make sense if the commands are still 
> sitting in an application buffer somewhere, rather than with the GPU.

Let me try to clarify a couple of things:

The DMA_BUF_IOCTL_SYNC function is to flush and invalidate caches so 
that the GPU can see values written by the CPU and the CPU can see 
values written by the GPU. But that IOCTL does *not* wait for any async 
GPU operation to finish.

If you want to wait for async GPU operations you either need to call the 
OpenGL functions to read pixels or do a select() (or poll, epoll etc...) 
call on the DMA-buf file descriptor.

So if you want to do some rendering with OpenGL and then see the result 
in a buffer memory mapping the correct sequence would be the following:

1. Issue OpenGL rendering commands.
2. Call glFlush() to make sure the hw actually starts working on the 
rendering.
3. Call select() on the DMA-buf file descriptor to wait for the 
rendering to complete.
4. Use DMA_BUF_IOCTL_SYNC to make the rendering result CPU visible.

Regards,
Christian.

>
> Regards