Codegen - Handle case where extension needs A or B extension as dependency

[dabrain34]

Environment:

• OS: Linux
• GPU and driver version:
• SDK or header version if building from repo: 1.4.304
• Options enabled (synchronization, best practices, etc.):

Describe the Issue

In the case of a decode operation such as dEQP-VK.video.decode.h264.inline_session_params_layered_dpb, the validation layer complains that the maintenance2 extension requires VK_KHR_video_encode_queue which should not be mandatory.

Expected behavior

No validation layer issue if vk_khr_video_queue is enabled

Valid Usage ID
VUID-vkCreateDevice-ppEnabledExtensionNames-01387

Additional context

VUID-vkCreateDevice-ppEnabledExtensionNames-01387(ERROR / SPEC): msgNum: 307460652 - Validation Error: [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object 0: handle = 0x55555b309110, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x12537a2c | vkCreateDevice(): pCreateInfo->ppEnabledExtensionNames[3] Missing extension required by the device extension VK_KHR_video_maintenance2: VK_KHR_video_encode_queue.

[aqnuep]

@spencer-lunarg, there seems to be some code-gen issue, if that is indeed the case, because VK_KHR_video_maintenance2 requires VK_KHR_video_decode_queue OR VK_KHR_video_encode_queue, see the vk.xml not using +, but ,.

It looks like this is the first time or logic is used between two extensions and not an extension + a core version, and probably the general code-gen of VVL doesn't handle that correctly.

[spencer-lunarg]

1. Why does VK_KHR_video_maintenance1 just depend on VK_KHR_video_queue then? (There a reason or just oversight)
2. I see a lot of depends="VK_KHR_get_physical_device_properties2,VK_VERSION_1_1" but couldn't find another example where an extension needs one of 2 other extensions as a dependency
3. @dabrain34 what was the combo of things that hit this (aka, a test would be helpful here) NVM, see you stated it in the issue well

[aqnuep]

Why does VK_KHR_video_maintenance1 just depend on VK_KHR_video_queue then? (There a reason or just oversight)

Because it requires at least decode or encode. Sure, as a workaround, we could change to that in the vk.xml and maybe it'll just work. It was, however intentional, and was sort of the requirement for spec CI due to the way ratification packages are constructed.

I see a lot of depends="VK_KHR_get_physical_device_properties2,VK_VERSION_1_1" but couldn't find another example where an extension needs one of 2 other extensions as a dependency

Yes, I noticed that too, that's why I realized that we're the first to hit the case that isn't properly handled by VVL code-gen.
If it's too involving to fix this in the VVL code-gen, sure, let's try to work it around in the vk.xml, but I expect that sooner or later we will run into this limitation again.

[spencer-lunarg]

If it's too involving to fix this in the VVL code-gen, sure, let's try to work it around in the vk.xml, but I expect that sooner or later we will run into this limitation again.

I hope it isn't too hard, I just won't have a second to look today

[aqnuep]

I hope it isn't too hard, I just won't have a second to look today

Understood, I don't object against working this around in the vk.xml though. I wasn't anticipating this to be an issue and we were blind-sided in the VVL tests because we opportunistically enable the base video extensions in the framework and therefore this didn't show up as an issue so far.

[spencer-lunarg]

So we fixed the XML, keeping issue open, will look into this code gen problem so it doesn't do this for the next extension with this pattern

[spencer-lunarg]

update - this was added in the 1.4.309 headers, so when those get pulled in, the Validation Layers will be "fixed" for this case