Validation errors when enabling unsupported instance or device extensions

[johannesherschel]

Creating an instance or device with unsupported extensions causes a validation error with VUID-vkCreateInstance-ppEnabledExtensionNames-01388 or VUID-vkCreateDevice-ppEnabledExtensionNames-01387, respectively. However, according to the Vulkan specification, it is perfectly valid to request unsupported extensions; they are guaranteed to cause a VK_ERROR_EXTENSION_NOT_PRESENT. The VUIDs only require that required extensions of enabled extensions are also enabled, which is ensured by Vulkano even with the unchecked functions for instance or device creation.

I think the current checks for extension support on creation should be removed. They are redundant since the Vulkan implementation is required to do them anyway, and I would not expect any validation error if no VUID is violated.

[Rua]

What extensions and features are you enabling, and what validation error do you get?

[johannesherschel]

Sorry for the late reply, I somehow lost track of this issue.

This is not about any particular extension or feature. The Vulkan specification allows an application to request unavailable extensions/features and requires the implementation to check them and return VK_ERROR_EXTENSION_NOT_PRESENT or VK_ERROR_FEATURE_NOT_PRESENT in that case. So I think vulkano should not validate requested extensions/features.

Basically I would expect I can write

let instance = Instance::new(library, create_info).map_err(Validated::unwrap);

and then handle the VulkanError, even if a requested extension is unsupported. Currently this causes a validation error and thus panics, even though it does not violate the specification. Vulkano returns VUID-vkCreateInstance-ppEnabledExtensionNames-01388, which is misleading; this VUID only requires that extensions required by the enabled extensions are also enabled, but that is ensured by vulkano anyway.

The situation is similar for device extensions and device features (though the vulkano validation error does not mention any VUID for the latter).

[Rua]

The Vulkan error is not very useful to the user, though. It says that something isn't present, but not what. Vulkano's error gives more information.

[johannesherschel]

That is a good point, though I would argue that you can always query supported extensions/features manually if required.

I would suggest to at least document this behavior, i.e. state that enabled extensions/features must be supported for InstanceCreateInfo::enabled_extensions, DeviceCreateInfo::enabled_extensions and DeviceCreateInfo::enabled_features, and remove the reported VUIDs. Alternatively, this could be handled with a dedicated error type similar to buffer or image creation.

In general, my expectation with vulkano is that as long as I comply with the Vulkan specification, I can safely ignore any validation errors. Perhaps I am just wrong with this assumption.

[Rua]

If you comply with the Vulkan specification, there shouldn't be any validation errors to begin with.

[johannesherschel]

That's what I thought, but there are - that's the whole point of this issue. The specification allows requesting unsupported extensions/features, but if you do, you get a validation error.