Strengthen the guarantees given by XR_KHR_vulkan_enable/XR_KHR_vulkan_enable2

[yshui]

In section "Swapchain Image Layout", it is stated that:

When an application acquires a swapchain image by calling xrAcquireSwapchainImage in a session created using XrGraphicsBindingVulkan2KHR, the OpenXR runtime must guarantee that:

• The image has a memory layout compatible with VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL for color images, or VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL for depth images.

Which means the application does not have full knowledge of the image layout, only that it is compatible with some layout. However, to perform layout transitions in Vulkan, one must guarantee that (emphasis mine):

The old layout must either be VK_IMAGE_LAYOUT_UNDEFINED, or match the current layout of the image subresource range.

This essentially means the application can't reliably perform image layout transition if it wants to. Can we strengthen the guarantee, and replace "compatible with" with "matching"?

[yshui]

From my knowledge, given how it's implemented at the moment, monado does have this guarantee.

[yshui]

Ah, so this is a problem for runtimes as well. Because the spec doesn't require the application to leave the images in a specific layout (again, only "compatible with"), the runtime can't reliably perform layout transition either. I think this is a bigger problem for runtimes, as the application can most likely get by without doing transitions, or can tolerant image content being discarded.

[rpavlik-bot]

An issue (number 2287) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2287 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.