layers: Improve profile error messages

[spencer-lunarg]

This an attempt at #8625

@aqnuep I agree with Mike that just saying IsImageCompatibleWithVideoSession failed doesn't help the user narrow things down. I was going to try and add some more helper to print things out (without wasting cycles when things are valid) but realize I don't know enough about Video to know what information would be helpful, so making this PR in hope you can come up with something similar to solve the issue

A new error message now looks like

Validation Error: [ VUID-VkVideoBeginCodingInfoKHR-pPictureResource-07240 ] ... 
vkCmdBeginVideoCodingKHR(): pBeginInfo->pReferenceSlots[0].pPictureResource->imageViewBinding (VkImageView 0xd10d270000000018[] created from VkImage 0xd897d90000000016[]) is not compatible with the video profile VkVideoSessionKHR 0xe7f79a0000000005[] was created with.
The image was create without VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR and could not find an profile for the image supported with the profile:
videoCodecOperation = VK_VIDEO_CODEC_OPERATION_ENCODE_AV1_BIT_KHR
chromaSubsampling = VK_VIDEO_CHROMA_SUBSAMPLING_422_BIT_KHR
lumaBitDepth = VK_VIDEO_COMPONENT_BIT_DEPTH_8_BIT_KHR
chromaBitDepth = VK_VIDEO_COMPONENT_BIT_DEPTH_8_BIT_KHR
VkVideoEncodeUsageInfoKHR::videoUsageHints = VkVideoEncodeUsageFlagsKHR(0)
VkVideoEncodeUsageInfoKHR::videoContentHints = VkVideoEncodeContentFlagsKHR(0)
VkVideoEncodeUsageInfoKHR::tuningMode = VK_VIDEO_ENCODE_TUNING_MODE_DEFAULT_KHR

(Note, we had this same issue with showing why two pipeline layers were not compatible, see DescribePipelineLayoutSetNonCompatible)

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build queued with queue ID 342446.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build # 18611 running.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build # 18611 passed.

[aqnuep]

Sure, one could print out the basic video profile parameters, but that also doesn't narrow it down.

First of all, the application already knows what it attempted, that is, what is the current video profile and whether it passed in VIDEO_PROFILE_INDEPENDENT or not, so I don't see too much value in this change.

The issue is that there's really not a whole lot of information what could be printed out in these cases, unless one goes really "crazy".

Video profile image format compatibility is a complex problem.

What we're really asking is whether there is one entry, as reported by vkGetPhysicalDeviceVideoFormatPropertiesKHR where all corresponding parameters are matching (i.e. one does not try to attempt to use a format, or flags that aren't supported), so you really can't print much out, unless you print out every single video format (potentially for every single video profile, when profile independent resources are created) and every single reason why that particular video format does not match the provided parameters (which parameters mismatch).

TLDR; I don't think this change adds much value, one really has to look into how the image parameters compare to the video format list of the video profile in question.

[aqnuep]

Also, the profile info you're outputting is misleading because it doesn't actually contain a lot of info that participate in the video profile matching, particularly the codec-specific parameters of the video profile, so this change will just be even more misleading.

[aqnuep]

So if we want to be really descriptive, we'd have to output the following:

If VIDEO_PROFILE_INDEPENDENT_BIT is not used:

1. Print the video profile the video session was created with (not just the VkVideoProfileInfoKHR, but its entire pNext chain).
2. Print the video profile list the image was created with (all video profiles specified in the VkVideoProfileListInfoKHR included in the pNext chain of VkImageCreateInfo)

If VIDEO_PROFILE_INDEPENDENT_BIT is used:

1. Print the image create info parameters the image was created with
2. Print the VkVideoFormatPropertiesKHR structures (and potentially their pNext chain) returned by vkGetPhysicalDeviceVideoFormatPropertiesKHR for the video profile the session was created with and the image usage flags used for the image creation

That's potentially pages of information.

[spencer-lunarg]

Thanks @aqnuep for the information - closing (its tied to the issue which you added more information on)