-
This change introduces new capabilities to allow for external memory to imported and bound to textures. The specific use-case is supporting interop with vaapi hardware decoding, where dma_buf is used to export decoded video surfaces. The API basically involves passing a `pl_shared_mem` when creating a texture, to describe the external memory to be used. When this is done, the external memory is imported and used instead of making a normal memory allocation. Past that point, the texture behaves like a normal one, and destroying the texture will free the imported allocation. Note that we will repeatedly import a single allocation if it is passed for separate textures. This happens in the vaapi case because each surface is a single allocation but each plane must be imported as a separate texture. The Vulkan spec explicitly required multiple-import to work, so this is safe. I have a corresponding mpv change that demonstrates this all works. Note that this implementation is more fragile than you'd want because we can't use `VK_EXT_image_drm_format_modifier`. This extension has yet to be enabled in the Mesa vulkan drivers, and until it is enabled, we cannot communicate detailed format information from vaapi to Vulkan. Examples of this include the pitch, tiling configuration and exact image format. For the common cases we deal with in vaapi, this is not fatal - it happens to be the case that pitch and tiling work out, and mpv is able to pick a compatible format based on its existing format mapping code. Note that this code may not pass validation, as a result. In my mpv tests, I see validation failures when mpv is doing format probing, reflecting that some of the more exotic formats cannot be matched up without `VK_EXT_image_drm_format_modifier`. However, once probing is complete, they decode and display run without validation errors.
b38e65cc
