Skip to content

Draft: lavapipe: Implement `VK_EXT_external_memory_dma_buf` & `VK_KHR_external_*_fd` extensions

Implement the VK_EXT_external_memory_dma_buf, VK_KHR_external_fence_fd, and VK_KHR_external_semaphore_fd extensions for lavapipe. Allowing systems that have access to a drm or vgem driver to import and export dmabufs and sync files. Dma bufs are imported a dumb buffers and to export lavapipe will use the drm API to allocate a dumb buffer and then export a dmabuf FD from that dumb buffer.

For sync files lavapipe will simply import a sync file directly as a file and then use poll to wait on it. For exporting it will use the dmabuf api to export a sync file from a dummy dumb buffer the driver keeps around. This approach might sound a little strange, but this approach seemed to be more portable, allowing sync file import/export to work with the vgem driver as the sync object API would always fail with a vgem device.

Looking for feedback on this approach, in case there is something wrong that I'm missing. The changes pass all the CTS for these extensions, but unfortunately CTS will just export and handle and re-import it, so it isn't the best for validating this extensions. I've lightly tested outside of CTS and I was able to import sync files or dmabufs created with amdgpu/radv and use them in lavapipe.

Merge request reports