• Philip Langdale's avatar
    vulkan: Suppress validation errors when binding imported image memory · dc1059b2
    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
    It's a simple mechanism that isn't thread safe, but could be made
    so if/when the need arises.