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
