OpenXR Quest 3 VSync Not Honored

[SoapSpangledGames]

Tested versions

4.2 Stable

System information

Oculus Quest 3 Vulcan

Issue description

When running my games on the Quest 3 using OpenXR and forward_plus, disabling VSync isn't honored, resulting in anywhere from mild to massive flicker. The game still runs, but it's not very pleasant. This happens if I disable VSync from the projects settings or though GDScript. The Android log issues this warning:

USER WARNING: The requested V-Sync mode Disabled is not available. Falling back to V-Sync mode Enabled.

Steps to reproduce

Create any minimal OpenXR project, and disable vsync.

Minimal reproduction project (MRP)

N/A

[Calinou]

When running my games on the Quest 3 using OpenXR and forward_plus

Forward+ is very slow on mobile platforms, which is why the .mobile override of the rendering method project setting is set to Mobile by default. This means that even if your editor displays Forward+, the project will use the Mobile rendering method when it's running on a mobile platform (including Quest standalone, which is Android).

Can you reproduce this after switching the .mobile override of the rendering method project setting to gl_compatibility, then exporting the project again?

[SoapSpangledGames]

The flickering goes away with gl_compatibility, but so do all colors. Everything in my project is now black. This project is in the proof-of-concept phase, so I have simply blocked in a couple scenes with solid-color meshes. Those blocks all turn solid black with gl_compatibility. I have also used a bunch of untextured, but simply-colored, OBJ meshes in the scenes, and they are also completely solid black.

I switched back to forward_plus, and I'm relieved that my colors have returned.

[SoapSpangledGames]

A video is worth a million words:

https://youtube.com/shorts/gFYdTfYfV14?feature=share

[SoapSpangledGames]

I was probably confusing everyone when I said I was using forward_plus. I hadn't noticed that Godot 4.x defaults to the mobile renderer for mobile devices, even if forward_plus is selected as the rendering method. So I was using the mobile renderer prior to forcing gl_compatibility. At no time was I using forward_plus on the Quest.

As an aside, I forced forward_plus on the .mobile renderer once I realized I had been using the mobile renderer at the time of my original posting, and it was indeed horrendously slow and painful.

[BastiaanOlij]

For Quest Godots v-sync is ignored completely. We're entirely depending on OpenXR for synching.

We're still investigating the flickering bug but it's not related to v-sync, our best guess at the moment is that it is a driver issue specifically related to the XR2 gen 2 chip on the Quest 3 where the driver is not waiting for the first subpass that renders geometry to finish before the second subpass on the tile is run. So far the Quest 3 seems to be the only device effected by this issue.

A workaround at the moment seems to be to enable MSAA (3D) and set it to x2, which on this hardware has minimum to no impact. This causes the first subpass to finish before a resolve is applied and the second subpass runs.

That said, we highly recommend using the compatibility renderer with the Quest for the time being, especially as 4.2 lacks a number of important fixes that are coming in 4.3 and as the compatibility renderer properly supports foveated rendering.

[SoapSpangledGames]

I tried changing the rendered to gl_compatibility, but it makes all the geometry for my entire game a single, solid black. You can see it in the video I posted in my prior post.