OpenXR: Fix Vulkan validation errors and get XR_META_foveation_eye_tracked working on Meta Quest devices#112994
Conversation
dsnopek
force-pushed
the
openxr-meta-foveation-eye-tracked-on-meta
branch
2 times, most recently
from
3e6b2b4 to
81af428
Compare
dsnopek
changed the title
XR_META_foveation_eye_tracked on Meta Quest devicesXR_META_foveation_eye_tracked working on Meta Quest devices
dsnopek
force-pushed
the
openxr-meta-foveation-eye-tracked-on-meta
branch
from
81af428 to
76bcc73
Compare
|
In trying to figure out why the FDM offsets weren't doing what they should on the Quest Pro, I tried enabling the Vulkan validation layers and found that we were generating a mess of validation errors! Fixing those turned out to be the key to getting eye-tracked foveation actually rendering sanely on the Quest Pro However, there is still one remaining issue on the Quest Pro: there's a flickering that happens every couple of seconds, but only when eye-tracked foveation is enabled; not when using fixed foveation :-( Still debugging! |
|
Hm, the flickering stopped happening! I'm going to write that up to a fluke, and take this PR out of draft :-) |
dsnopek
changed the title
XR_META_foveation_eye_tracked working on Meta Quest devicesXR_META_foveation_eye_tracked working on Meta Quest devices
BastiaanOlij
left a comment
BastiaanOlij
left a comment
There was a problem hiding this comment.
Code wise this looks good, my comment is purely one of understanding what textures need the offset flag set.
Not sure if I can test this today but I trust Davids testing enough to approve this and getting this merged.
| create_info.flags |= VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT; | ||
| }*/ | ||
|
|
||
| if (fdm_capabilities.offset_supported && (p_format.usage_bits & (TEXTURE_USAGE_COLOR_ATTACHMENT_BIT | TEXTURE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT | TEXTURE_USAGE_INPUT_ATTACHMENT_BIT))) { |
There was a problem hiding this comment.
Should we enable this for all these types, or just for TEXTURE_USAGE_VRS_ATTACHMENT_BIT ?
There was a problem hiding this comment.
It definitely needs to be on at least these ones, because not having it on them led to Vulkan validation errors in my testing. However, looking at the spec, it seems we probably need it on even more:
I probably didn't need it on TEXTURE_USAGE_VRS_ATTACHMENT_BIT in my testing, because I'm getting the FDM from the OpenXR runtime which presumably already created it with the right bit.
So, I guess I'll update this to add a few more to try and cover everything mentioned in the spec...
There was a problem hiding this comment.
Alright, I added it for a couple more usage types, which should theoretically cover everything mentioned in the spec
dsnopek
force-pushed
the
openxr-meta-foveation-eye-tracked-on-meta
branch
from
76bcc73 to
e4caa54
Compare
…racked` working on Meta Quest devices
dsnopek
force-pushed
the
openxr-meta-foveation-eye-tracked-on-meta
branch
from
e4caa54 to
fce47ac
Compare
clayjohn
left a comment
clayjohn
left a comment
There was a problem hiding this comment.
Rendering code looks good to me
|
Thanks! |
5 participants
This
very nearlyfixes #112988The most important changes are:
VkSubpassFragmentDensityMapOffsetEndInfoQCOMstruct at all. This fixes what's breaking rendering completely on Meta Quest 3, whereXR_META_foveation_eye_trackedisn't supportedxrUpdateSwapchainFB()beforexrGetFoveationEyeTrackedStateMETA()every time. This is actually mentioned in the spec - it says "Note that xrUpdateSwapchainFB should be called right before the xrGetFoveationEyeTrackedStateMETA function". While it says "should", the Meta runtime will only give us updated eye positions if we do, so it's more like a "must"VK_QCOM_fragment_density_map_offsetextension. This turned out to be the key to make eye-tracked foveated rendering actually render sanely on the Quest Pro! Previously, even with the correct offsets, it was behaving very strangely. But, also, fixing validation errors is good :-)