Does gbm_bo_map() implicitly synchronise?

[Christian König]

Am 24.06.24 um 21:08 schrieb James Jones:
> 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.

That matches my assumption of what this function does, but is just the 
opposite of what Michel explained what it does.

Is it somewhere documented if gbm_bo_map() should wait for in-flight 
work or not?

Regards,
Christian.

>
> 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