Here is a standalone example that demonstrates the issue, compilation instructions at the top. Excuse the quick and dirty code, not exactly my favorite pastime.
Actual result vs expected result:
I’m also not exactly a graphics expert, so if there is anything wrong with the code, please feel free to point that out. I can only say that it works on every driver combination I know except tegra. There are no vulkan validation warnings and the only gl debug output seems like it would not cause something like this
GL CALLBACK: type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK: type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 1 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), and GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use VIDEO memory as the source for buffer object operations.
edit: To clarify, the depth textures aren’t actually used by the application. They are only attached to the framebuffer to enable the gl depth test (it seems this is a requirement when rendering to a texture). The only interaction of the application with the depth texture is clearing it before rendering: glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);. In the OpenXR case it will also be given to the OpenXR runtime where it can be read to help with reprojection, but in this example code, it’s completely unused other than for the gl depth test.
See also the #if 0 block in the code to toggle between exporting textures from vulkan and simply creating them in gl (which makes it render fine on tegra).