FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
1) Don't do any synchronization against in-flight work. The assumption
is that if the content is going to be read, the API writing the data has
established that coherence. Likewise, if it's going to be written, the
API reading it afterwards does any invalidates or whatever are needed
for coherence.
2) We don't blit anything or format convert, because our GBM
implementation has no DMA engine access, and I'd like to keep it that
way. Setting up a DMA-capable driver instance is much more expensive as
far as runtime resources than setting up a simple allocator+mmap driver,
at least in our driver architecture. Our GBM map just does an mmap(),
and if it's not linear, you're not going to be able to interpret the
data unless you've read up on our tiling formats. I'm aware this is
different from Mesa, and no one has complained thus far. If we were
forced to fix it, I imagine we'd do something like ask a shared engine
in the kernel to do the blit on userspace's behalf, which would probably
be slow but save resources.
Basically, don't use gbm_bo_map() for anything non-trivial on our
implementation. It's not the right tool for e.g., reading back or
populating OpenGL textures or X pixmaps. If you don't want to run on the
NV implementation, feel free to ignore this advice, but I'd still
suggest it's not the best tool for most jobs.
Thanks,
-James
On 6/17/24 03:29, Pierre Ossman wrote:
On 17/06/2024 10:13, Christian König wrote:
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.
Thanks for the clarification!
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)
6. ioctl(DMA_BUF_IOCTL_SYNC, &{ .flags = DMA_BUF_SYNC_START |
DMA_BUF_SYNC_READ })
7. pixman_blt()
8. gbm_bo_unmap()
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.
What I want to do is implement the X server side of DRI3 in just CPU. It
works for every application I've tested except gnome-shell.
I would assume that 1. and 2. are supposed to be done by the X client,
i.e. gnome-shell?
What I need to be able to do is access the result of that, once the X
client tries to draw using that GBM backed pixmap (e.g. using
PresentPixmap).
So far, we've only tested Intel GPUs, but we are setting up Nvidia and
AMD GPUs at the moment. It will be interesting to see if the issue
remains on those or not.
Regards
