KhronosGroup
More video false positives with FFmpeg
Latest validation layer git main.
AMD on Mesa:
Validation Error: [ VUID-vkCmdDecodeVideoKHR-pDecodeInfo-07142 ] Objects: VkCommandBuffer 0x7faa0016e2d0, VkVideoSessionKHR 0xba04b100000000c9, VkImageView 0x2d0f10000000124, VkImage 0xc0c03f000000011a | MessageID = 0x79b1d0c3
vkCmdDecodeVideoKHR(): pDecodeInfo->dstPictureResource.imageViewBinding (VkImageView 0x2d0f10000000124 created from VkImage 0xc0c03f000000011a) is not compatible with the video profile the bound video session VkVideoSessionKHR 0xba04b100000000c9 was created with.
The Vulkan spec states: pDecodeInfo->dstPictureResource.imageViewBinding must be compatible with the video profile the bound video session was created with (https://docs.vulkan.org/spec/latest/chapters/videocoding.html#VUID-vkCmdDecodeVideoKHR-pDecodeInfo-07142)
It is compatible, as far as I can tell. Nothing errors out when checking.
NVIDIA on Linux:
Validation Error: [ VUID-VkVideoBeginCodingInfoKHR-pPictureResource-07240 ] Objects: VkCommandBuffer 0x7f0e10223ba0, VkVideoSessionKHR 0x8fd57200000000e5, VkImageView 0x70526c00000000f3, VkImage 0x7cbcba00000000ed | MessageID = 0xfd38b0b6
vkCmdBeginVideoCodingKHR(): pBeginInfo->pReferenceSlots[0].pPictureResource->imageViewBinding (VkImageView 0x70526c00000000f3 created from VkImage 0x7cbcba00000000ed) is not compatible with the video profile VkVideoSessionKHR 0x8fd57200000000e5 was created with.
The Vulkan spec states: If the pPictureResource member of any element of pReferenceSlots is not NULL, then the image view specified in pPictureResource->imageViewBinding for that element must be compatible with the video profile videoSession was created with (https://docs.vulkan.org/spec/latest/chapters/videocoding.html#VUID-VkVideoBeginCodingInfoKHR-pPictureResource-07240)
Validation Error: [ VUID-vkCmdDecodeVideoKHR-pDecodeInfo-07142 ] Objects: VkCommandBuffer 0x7f0e10223ba0, VkVideoSessionKHR 0x8fd57200000000e5, VkImageView 0x70526c00000000f3, VkImage 0x7cbcba00000000ed | MessageID = 0x79b1d0c3
vkCmdDecodeVideoKHR(): pDecodeInfo->dstPictureResource.imageViewBinding (VkImageView 0x70526c00000000f3 created from VkImage 0x7cbcba00000000ed) is not compatible with the video profile the bound video session VkVideoSessionKHR 0x8fd57200000000e5 was created with.
The Vulkan spec states: pDecodeInfo->dstPictureResource.imageViewBinding must be compatible with the video profile the bound video session was created with (https://docs.vulkan.org/spec/latest/chapters/videocoding.html#VUID-vkCmdDecodeVideoKHR-pDecodeInfo-07142)
Sure, @spencer-lunarg, I can help with this.
@cyanreg, can you please provide information about the way you create those image resources?
Are you using VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR? If yes, do you have the videoMaintenance1 feature enabled?
If not, can you provide me the VkVideoProfileListInfoKHR structure contents you create the image with and the VkVideoProfileInfoKHR you create the corresponding video session with?
I would be very surprised if we'd have a bug in the validation layers related to this, because otherwise pretty much all the video validation layer tests would fail.
Also, please note that just because nothing errors out does not mean that there isn't an issue. Drivers don't necessary check for preconditions already covered by valid usage and things may happen to work on any specific implementation or profile combination.
In particular, there could be mismatches in the codec profile indicator used for the session and the resources, or e.g. for AV1 decode, a mismatch between film grain settings for the video profile.
Also, can you please provide what version of the validation layers do you use? IIRC after the release of VK_KHR_video_maintenance1 there was some corner case issue with VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR that was fixed later.
VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR is not set, since this is purely for decoding.
Drivers most definitely lie about what they support. ANV for example still doesn't flag images with decode/dpb features, which causes the validation layer to warn on them. I omitted that since it's a driver issue after all.
I'm using latest validation layer git main. I did start off the first post with that.
I'm using latest validation layer git main. I did start off the first post with that.
Sorry, I overlooked that.
I'll also look into what we can do to print out more information about the mismatch without bloating the message, but in the meantime having the video profile information the image and the session were created with should help us root cause the issue.
@aqnuep
vkCmdBeginVideoCodingKHR(): pBeginInfo->pReferenceSlots[0].pPictureResource->imageViewBinding (VkImageView 0x1b500000001b5 created from VkImage 0x12f000000012f) was created with VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR but was not created with a video format supported by the video profile (AV1 Decode (4:2:0 8-bit) Main with film grain support) VkVideoSessionKHR 0x5e000000005e was created with.
Latest validation layer commit. I don't get it, isn't the point of INDEPENDENT to allow exactly that?
Latest validation layer commit. I don't get it, isn't the point of INDEPENDENT to allow exactly that?
VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT is only for allowing creating video image resources without having to specify an explicit list of video profiles it's supposed to be compatible with.
When you actually use the image with a specific video session (therefore video profile), the validation layer still checks that the image itself was created with parameters that are compatible with at least one of the video formats supported by the video profile (as queried using vkGetPhysicalDeviceVideoFormatPropertiesKHR.
This error indicates that no matching video format supported by the video profile was found.
Now this one could be due to incorrect video format properties being reported by the driver (which historically happened, not sure on the latest status of drivers), but generally it indicates that you created the image with parameters (e.g. image create or usage flags) that aren't reported as supported by the driver for the video profile.
Unfortunately, because this is an N:M comparison of all image create parameters with all parameters of supported video formats for the video profile, the validation layer does not output the reasons (as it cannot without dumping all supported video format properties).
If you can share your image creation parameters and the output of vulkaninfo -j (the JSON device capability output), I could help you root cause the mismatch here.