Clarification regarding re-exporting of imported external memory (especially DMA BUF)

[Icenowy]

The Imagination proprietary driver forbids re-exporting of imported external DMA BUFs, see [1], and experimentation on the Vulkan blob shows that it's really failing (the Vulkan blob is just a shim over the pvrsrvkm routine here); however Mesa Zink does this kind of behavior for imported memory for creating fences [2] (the code only checks whether it's a aux plane of a multi-plane memory object).

Reading about related Vulkan extensions (I checked VK_KHR_external_memory_capabilities, VK_KHR_external_memory, VK_KHR_external_memory_fd, VK_EXT_external_memory_dma_buf) shows no evidence for accepting/rejecting such behavior, but as it's already imported DMA BUF. it's structure should be eligble for exporting.

Note that the mainline Linux PRIME code will just re-export the DMA-BUF it's already imported [3], and drivers as part of Mesa naturally support this. Place similar code around [1] will allow DMA BUF re-exporting on Imagination proprietary Vulkan driver (a working sample is at [4]), however I still want this question to be clarified and the behavior to be determined.

[1] https://github.com/TexasInstruments/ti-img-rogue-driver/blob/linuxws/scarthgap/k6.12/25.2.6850647/services/server/env/linux/physmem_dmabuf.c#L1868
[2] https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/zink_screen.c?ref_type=heads#L2405
[3] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_prime.c#L453
[4] revyos/th1520-linux-kernel#40

[oddhack]

This should be assigned to @gfxstrand @JarredHDavies once they finished getting added to the Vulkan group. Using James as a placeholder since this is an SI-adjacent topic even if vendor-specific.

[gfxstrand]

Generally, this should work and it's a bit odd that IMG doesn't support it. From a Vulkan spec PoV, I don't think there's a real problem here as long as they're reporting the right thing in VkExternalMemoryProperties::exportFromImportedHandleTypes. As long as they're not advertising re-export there, they are technically allowed to deny it. However, like I said, it's a bit odd.

[JarredHDavies]

It looks to me our Vulkan driver is (incorrectly) reporting that the driver supports it through exportFromImportedHandleTypes. I've raised the question with our Kernel team of why we're forbidding since it seems the client driver team expected it to just work as well.

[cubanismo]

Yup, nothing to add. exportFromImportedHandleTypes was added mostly for corner cases where importing from one type of handle would preclude exporting to another, but it technically allows banning of export to the same handle type as well, even though I agree it doesn't make much sense for dma-buf specifically.

[oddhack]

We plan to add additional CTS tests, but believe the original question has been answered above. @Icenowy if you agree, please close this.