Philip Langdale authored
Importing image memory is a funny thing; there's no core mechanism to communicate the layout of the image. Depending on how exactly the memory was imported, and where it was imported from, it might be possible to manage without explicit knowledge of layout, or out-of-band mechanisms might exist to communicate it. Today, we specifically can handle importing of memory via dma_buf fds. While there is a Vulakn extension defined that could help to communicate layout (VK_EXT_image_drm_format_modifier), this extension isn't actually implemented in any driver and it doesn't look like it will happen any time soon. Without it, we have to hope that imported memory has the same layout that Vulkan expects, based on the declared image format. In practice, this has proven to be true for the real world scenario we care about - which is importing decoded video from VAAPI - there are only a couple of relevant formats, and the drivers for both Vulkan and VAAPI are written by the same sets of people following the same hardware driven recommendations for layout. However, just because layouts match in practice, doesn't mean that they pass validation. What we see is that, for some formats, validation will fail when binding memory, saying that the memory segment is smaller than the vulkan-calcuated memory size. I assume this happens due to a difference in memory alignment (pretty much any other cause would lead to visible errors). As we would like to be able to use VAAPI imported surfaces without sacrificing validation, we need a way to filter out these expected errors, and let validation proceed as normal elsewhere. The mechanism we've decided on is to provide a way to ignore errors on a specified vulkan object (in our specific case, the VkImage). We store the object ID before the bind call, and clear it afterwards. While it is set, errors on that object will be suppressed. It's a simple mechanism that isn't thread safe, but could be made so if/when the need arises.