Vulkan validation issue in vkQueuePresentKHR() when changing from compositor workspace to dynamic cubemap compositor

[Hotshot5000]

I have a relatively simple scenario:

1. Set compositor to a basic compositor to render the loading screen.
2. After loading is finished disable basic compositor and immediately set compositor to the dynamic cubemap sample.

I get:
Ogre: ERROR: [Validation] Code 0 : vkQueuePresentKHR(): pPresentInfo->pSwapchains[0] images passed to present must be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR or VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR but is in VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.
The Vulkan spec states: Each element of pImageIndices must be the index of a presentable image acquired from the swapchain specified by the corresponding element of the pSwapchains array, and the presented image subresource must be in the VK_IMAGE_LAYOUT_PRESENT_SRC_KHR or VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout at the time the operation is executed on a VkDevice (https://vulkan.lunarg.com/doc/view/1.4. ... ices-01430)

I have modified the DynamicCubemap tutorial to exhibit this behavior and attached the source here. Make sure to overwrite the compositor file in Samples\Media\2.0\scripts\Compositors with the one from the archive.

In this case the rendering seems to continue just fine, while in my use case trying to get some dynamic cubemap from 2.1 to 3.0 the rendering seems borked (the compositor looks similar if not identical but I need to check further if something else isn't interfering). Still, I thought of getting rid of all validation errors.

The validation error happens on both AMD and nVidia.

EDIT: The rendering error on my side was because the cubemap used as SkyPostprocess was not exported correctly from Paint .NET. I forgot to check the "cubemap from crossed image" checkbox in the exporter. Also, I was passing the camera instead of the cubemap camera for the dynamic cubemap compositor. How was this working on 2.1... I don't know (it's the same buggy code)

[dark_sylinc]

Thanks for the repro, I'll check it out later.

The swapchain requiring to be in VK_IMAGE_LAYOUT_PRESENT_SRC_KHR has been a PITA.

Ideally OgreNext should hide this detail from you, but at least with the current architecture this is not always possible.

CompositorManager2::prepareRenderWindowsForPresent gets called every update and checks who is the last pass to render to a window, then set renderPassDesc->mReadyWindowForPresent where appropiate.

However if the compositor update is handled manually or somehow changed mid-render, prepareRenderWindowsForPresent not be handling your specific case and manual intervention might be necessary.

[dark_sylinc]

Mmmm I cannot repro the bug in latest master branch. I had to adapt your compositor btw:

Code: Select all

compositor_node HotshotDefaultRenderingNode
{
	in 0 rt_renderwindow

	target rt_renderwindow
	{
		pass render_scene
		{
			load
			{
				all				clear
				colour_value 0.5 0.5 0.5 1
			}

			store
			{
				//We only care about the contents of the colour target
				depth			dont_care
				stencil			dont_care
			}

			overlays	on
			//shadows		HotshotDefaultShadowNode
		}
	}
}

I remember seeing Eugene fixed something related to this functionality, so perhaps it's relevant and may be backported.
I'll have to check on 3.0 branch.

[dark_sylinc]

Fixed.

Fortunately, it could be easily backported from 4.0.
Thanks!