On 2024-06-24 21:08, James Jones wrote: > 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.
I've seen at least one webkitgtk issue report about gbm_bo_map not working as intended with nvidia. gbm_bo_map definitely has to handle tiling, that's one of its main purposes. It also really has to handle implicit synchronization, since there's no GBM API for explicit synchronization. Just doing a direct mmap for gbm_bo_map can be bad for other reasons as well. E.g. if the BO storage is in VRAM and the application does CPU reads, it'll fall down a performance cliff. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
