Behaviour of layers providing device_extensions with features without ICD support

[JamesRumble-IMG]

Unless I'm mistaken if a layer provides a device extension with a VkPhysicalDeviceFeatures2 extended feature structure and the underlying ICD does not support the given extension/feature then at device creation time, if the extension feature is enabled by an application, the layer must remove the extension feature structure from the VkDeviceCreateInfo-pNext chain to avoid the ICD returning VK_ERROR_FEATURE_NOT_PRESENT (VK_LAYER_KHRONOS_shader_object does this here: https://github.com/KhronosGroup/Vulkan-ExtensionLayer/blob/7ce8ed4eda613a1e80f5d3e21c6295558c6676c6/layers/shader_object/shader_object.cpp#L2190).
The result of this is that other layers after the current layer cannot additionally support or interact with the same extension/feature.

This is mostly fine for extensions where you'd expect the layer to take ownership of the extension/feature for example VK_LAYER_KHRONOS_shader_object (https://github.com/KhronosGroup/Vulkan-ExtensionLayer/blob/main/docs/shader_object_layer.md) but for other layers it may not be ideal i.e. VK_EXT_frame_boundary.
VK_EXT_frame_boundary mostly allows an application to provide more information than it otherwise would and layers/tools/ICDs are just consuming this information.

Is this expected/correct?

For some context we have a layer which provides "support" for VK_EXT_frame_boundary so that it if an application supports VK_EXT_frame_boundary then it will be able to use it even if the ICD doesn't support the extension/feature so that the layer can be given more information than would otherwise be available.
The usecase is for offscreen rendering where no calls will be made to vkQueuePresentKHR (which would be a canonical frame delimiter). The application in this case can support VK_EXT_frame_boundary to provide frame delimiters in the absence of vkQueuePresentKHR.
Our layer benefits from having frame information/delimiters so it made sense for us to advertise support for VK_EXT_frame_boundary so that the application can use the extension even without ICD support. Unfortunately by doing so other layers after ours will not benefit from the improved frame delimiters.

For certain extensions this behaviour doesn't seem ideal. Should there be a mechanism whereby the loader removes feature structures from VkDeviceCreateInfo-pNext after all layers but before the chain reaches the ICD?
As far as I can tell this is only a problem for device extensions which use a feature structure.

I've had a quick scan through the spec and there are a couple of extensions which somewhat match VK_EXT_frame_boundary in that multiple layers may want to interact with the extension and which have VkPhysicalDeviceFeatures2 extended feature structures.

• VK_EXT_frame_boundary
• VK_KHR_pipeline_executable_properties
• VK_KHR_present_id
• VK_EXT_device_address_binding_report
• VK_EXT_device_memory_report

As mentioned there are way more examples of extensions for which it makes more sense for a layer to consume full responsibility for extension support:

• VK_EXT_shader_object
• VK_KHR_timeline_semaphore
• etc.