@dsnopek I haven't tested this yet but as a completion of the fallback logic, you may want to test this yourself as well :)

Ok, looks like I hit a snag with this.

Because of the way we're creating our depth buffer in the OpenXR module, we can't write into it with the resolve shader. It's the wrong format, and has the wrong attachment type.

I'm looking into verifying those findings but it leaves us with a problem because we have no knowledge or access to the viewport with which we're about to render our XR content, and on which we can detect that MSAA is applicable and we need to change the format.

After a bunch of testing I was able to validate what I thought.
If MSAA is used and the fallback resolve is used, we need to create the depth swapchain with different settings.

I've hardcoded the changes to make it work, this is not a solution but:

In openxr_api.cpp:1271 note the usage of XR_SWAPCHAIN_USAGE_COLOR_ATTACHMENT_BIT and VK_FORMAT_D32_SFLOAT:

if (depth_swapchain_format != 0 && submit_depth_buffer && OpenXRCompositionLayerDepthExtension::get_singleton()->is_available()) {
	if (!render_state.main_swapchains[OPENXR_SWAPCHAIN_DEPTH].create(0, XR_SWAPCHAIN_USAGE_SAMPLED_BIT | XR_SWAPCHAIN_USAGE_COLOR_ATTACHMENT_BIT, VK_FORMAT_D32_SFLOAT, render_state.main_swapchain_size.width, render_state.main_swapchain_size.height, sample_count, view_configuration_views.size())) {
		return false;
	}

	...

And in openxr_vulkan_extension.cpp:327:

case VK_FORMAT_D32_SFLOAT:
	format = RenderingDevice::DATA_FORMAT_D32_SFLOAT;
	// usage_flags |= RenderingDevice::TEXTURE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT;
	usage_flags |= RenderingDevice::TEXTURE_USAGE_COLOR_ATTACHMENT_BIT;
	break;

(this code should really switch on the usage_flags given to our create function).

But as I mentioned in my previous message, we don't have access to the MSAA configuration of the viewport here.

@clayjohn if you have any suggestions on the above, whether we can somehow combine these...