Please elaborate on the compositor’s architecture and how the VK render target is being transferred to the compositor as a texture? Please point us to the code that creates the images for the rendering swapchain and where does the transfer of the layout is happening from the render target to a sampled image.
Apologies for the slow reply.
I have narrowed our issue with GL_RGBA16F down and extended the fixed example code.
The depth issue does NOT play into this issue at all. Note that in this version of the example code the depth textures are generated in plain GL without interop. This time only the color textures are using vulkan interop. But the crux seems to still be dedicated allocation.
tl;dr: Using VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT for RGBA16F color texture reports that dedicated allocation is preferred but not required, here using dedicated allocation doesn’t work.
Hopefully the code isn’t too messy and the issue is visible:
With image usage flags VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_TRANSFER_SRC_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT (or just VK_IMAGE_USAGE_SAMPLED_BIT) we get requiresDedicatedAllocation == 0 | prefersDedicatedAllocation == 0 and we do not use dedicated allocation.
When adding VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT to the VkImage usage flags, then requiresDedicatedAllocation == 0 | prefersDedicatedAllocation == 1 and we do use dedicated allocation and get a black window with a kernel hang (it recovers fine after few seconds. Good job on that!)
If I ignore prefersDedicatedAllocation and don’t use dedicated unless requiresDedicatedAllocation == 1, then everything works.
color_attachment.c (35.0 KB)
The call that actually causes the hang is glBlitNamedFramebuffer on the shared texture. If this call is commented out the window (obviously) stays uninitialized, and the hang does not happen.
In the case of OpenXR applications with Monado (without MR 882), the textures rendered in the Monado compositor are also just black.
This Monado MR 882 (“Sorry you cannot post a link to that host.”) fixes openxr-simple-example when modified to use GL_RGBA16F, and vanilla Stereokit:
Oh this has been marked as solution? I don’t really see this as solved. If the driver says dedicated allocation is preferred, but not required, then I would expect to be able to use dedicated allocation without these ill effects.
Unrelated, but not really unrelated, my Monado fix/workaround for this issue caused an issue on desktop nvidia this time, not on tegra. Also not involving OpenGL interop, only Vulkan external memory export/import.
hello_xr -G Vulkan2 wants Monado to create VkImages with VK_FORMAT_R8G8B8A8_SRGB. Here again the desktop nvidia driver tells us for dedicated allocation: preferred: 1, required: 0. Due to the tegra fix/workaround, we do NOT use dedicated allocation when it is not required.
Unfortunately when we do not use dedicated allocation here, then this vkWaitForFence
called from here
returns VK_ERROR_DEVICE_LOST.
edit:
There is a kernel message for this VK_ERROR_DEVICE_LOST
[25270.737155] NVRM: Xid (PCI:0000:01:00): 13, pid=6, Graphics Exception on GPC 0: 3D-C MEMLAYOUT Violation. Coordinates: (0x0, 0x0)
[25270.737164] NVRM: Xid (PCI:0000:01:00): 13, pid=6, Graphics Exception: ESR 0x500420=0x80000400 0x500434=0x0 0x500438=0x1900 0x50043c=0x10000
[25270.737174] NVRM: Xid (PCI:0000:01:00): 13, pid=6, Graphics Exception on GPC 1: 3D-C MEMLAYOUT Violation. Coordinates: (0x8, 0x0)
[25270.737181] NVRM: Xid (PCI:0000:01:00): 13, pid=6, Graphics Exception: ESR 0x508420=0x80000400 0x508434=0x8 0x508438=0x1900 0x50843c=0x10000
[25270.737295] NVRM: Xid (PCI:0000:01:00): 13, pid=13744, Graphics Exception: ChID 003c, Class 0000c197, Offset 00000fb4, Data 00000000
This is on GTX 1050 Ti, 460.91.03
If I change the code back to use dedicated allocation if it is preferred || required, then it works fine on desktop nvidia, but will break on tegra (see the attached example code color_attachment.c from the previous post that causes such a break).
Another application, our xrgears example (plain Vulkan without OpenGL interop too), wants Monado to create VkImages with VK_FORMAT_R16G16B16A16_UNORM. The nvidia desktop driver again tells us for dedicated allocation preferred: 1, required: 0 for this format. If we do not use dedicated allocation again, the same vkWaitForFences fails again, but this time with error code VK_TIMEOUT.