Performance improvement for all VR Headsets: Quad View Foveated rendering

Emir_de_Passy

Active member
Please consider implementing Quad View Foveated rendering in LMU as it would be beneficial for ALL VR HEADSETS. (Not just eye tracked or expensive ones).

For those who are unfamiliar, it is a form of Foveated rendering that involves two small high-resolution focus areas and two low-resolution peripheral areas, with the focus areas in the center, where the gamer is looking directly.
It is the same principle as the foveated rendering we have been using with the OXR toolkit or VRperfkit, except it reduces pixel count while the variable shading rate (VRS) method used in OXR toolkit and VRperfkit adjusts the level of detail within a pixel block without changing the overall pixel count, which is why QVFR is significantly more powerful. People sometimes believe that it's exclusive to eye-tracked headsets, but it's beneficial for all types. The only difference is that, with an eye-tracked headset, you can make the focus areas smaller. QVFR is more CPU intensive (4 views to render instead of 2) but saves a lot of GPU workload. For example, Pimax could go from 5 to 55fps using DCS with a Crystal and an RTX 2060. According to the modder who implemented it in Richard Burns Rally, it was easy,
Here is a link that explains more; hopefully, you can determine if it is easy to implement in LMU.
https://github.com/mbucchia/Quad-Views-Foveated/wiki


- Foveated rendering is great for performance
- VRS is easy and cheap on the CPU
- QVFR involves doing a second render pass for the foveated part at a higher resolution then merging, which is a cpu cost, but greatly reduces GPU load
- both the above techniques work with both Fixed Foveated rendering and eye-tracked foveated rendering.
- On the headsets that support it, eye-tracked foveated rendering is a great way to go

A second render pass for the foveated part' is the same high-level thing that's done with XR_VARJO_quad_views but in no way requires it. If this is done in the engine, it works everywhere, it can be always on, and because it works everywhere and is always on, doesn't increase the amount of different configurations that needs to be tested.



If you want to do the composition yourself, here is a link: https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XR_EXT_eye_gaze_interaction
This also makes it work on every headset without an API layer, but is more involved than what the RBR dev did.

Quad view foveated rendering is also available as an extension in OpenXR 1.1 (under the name Stereo with Foveated Rendering) https://www.khronos.org/news/press/...ther-streamline-cross-platform-xr-development


Another way to implement would be to support quad views in an API layer as the RBR modder did.

This would be easier than doing the composition yourself but this would only make it work with the list of headsets below (already quite extensive). This also requires an API layer whereas the first option doesn't.


Quad view foveated rendering in LMU would make it the de facto best VR sim racing implementation by a significant margin. It would guarantee to attract new VR users, many of whom use other titles mostly because they run well in VR. (e.g. AMS2, Iracing). QVFR would make LMU easier to run in VR than on triple screens and even on Ultrawide screens and, therefore, accessible to people with more modest PC configurations.

Here is a link to a discussion about various possible implementations:

www.reddit.com/r/Pimax/comments/1gisyv8/comment/lvdy3o2/

P.S. Apologies if I wrote any inaccuracies, as I am not a specialist.

UPDATE APRIL 2025: Microsoft Flight Simulator 2024 now supports QVFR and is the first current sim to do so not by accident. (Richard Burns Rally supports QVFR but is done by a modder)
Their implementation works on every headset without the need for any mod or special headset software, just like I wrote it could be done above. The GPU performance gain is about 30% and hopefully will improve when out of beta status. This is done at the cost of CPU performance, as expected.
Here is a technical summary of how they did it, from Mbucchia, the QVFR God.


UPDATE MAY 2025: IRACING now supports QVFR with their Season 3 2025 update. And is the second current sim to do so not by accident. The method used is a 2018 Nvidia API called Multi View Rendering which expands on Single Pass Stereo, which was already implemented. It's extremely effective and has a small CPU cost. However it only works with nvidia GPU.

 
Last edited:
HEADSET COMPATIBILITY if using Mbucchia's implementation. (If own implementation is done, all headsets are compatible)

NON EYE TRACKED HMD's

HP Reverb G2Yes
Oculus Quest 2/3Yes
Oculus RiftYes
Pimax 4K/5K/8KYes
Pimax Crystal LightYes
HTC ViveYes
HTC Vive ProYes
HTC Vive CosmosYes
HTC Vive FocusYes
Valve IndexYes
Pico Neo 3/4Yes
Bigscreen BeyondYes


EYE TRACKED HMD's

Meta Quest ProOculus OpenXRYes
Meta Quest ProVirtualDesktopXR (VDXR)Yes
Meta Quest ProSteamVR with Virtual DesktopYesRequires OpenXR-Eye-Trackers
Meta Quest ProSteam LinkYesRequires OpenXR-Eye-Trackers
Meta Quest ProSteamVR with Oculus LinkNo [1]
Pimax CrystalPimaxXRYes
Pimax CrystalSteamVR OpenXRYesRequires OpenXR-Eye-Trackers
Pimax 5K/8K (w/ Droolon Pi1)PimaxXRYes
Pimax 5K/8K (w/ Droolon Pi1)SteamVR OpenXRNo
Varjo AeroVarjo OpenXRYesYou may also use Varjo's own implementation of quad views (included in Varjo Base) [2]
Varjo AeroSteamVR OpenXRYesRequires OpenXR-Eye-Trackers
Varjo VR-3/XR-3Varjo OpenXRYesThis implementation does not support Bionic Display: you may instead use Varjo's own implementation of quad views (included in Varjo Base) [2]
Varjo VR-3/XR-3SteamVR OpenXRYesRequires OpenXR-Eye-Trackers
HP Reverb G2 Omnicept EditionWMR OpenXRYesRequires OpenXR-Eye-Trackers
HP Reverb G2 Omnicept EditionSteamVR OpenXRYesRequires OpenXR-Eye-Trackers
Vive Pro EyeSteamVR OpenXRYesRequires Vive Console for SteamVR
Pico Neo Pro 3/4SteamVR OpenXR
 
Last edited:
According to the modder who implemented it in Richard Burns Rally, it was easy

Have you mentioned this to the Devs in discord? VR is high on the list at the mo and if this is as easy to implement as it has in RBR it might be something that can shoe horn in.

Not heard of it to be honest, I've not booted RBR for some months. Is this something that appears in the OpenXR tools kit if the software supports?
 
Does it also work non eye tracked for Rift S? Would assume so, it's just not in your table so wondered if something stops it working.
 
Dynamic foveated rendering (DFR) based on quad view rendering technique can't work without eye tracking.

But, fixed foveated rendering (FFR) based on quad view rendering can work without eye tracking. It's just that higher resolution area won't follow your focus area but will stay in the middle of the display.
With is still a great improvement you barely notice if applied moderately.
 
Dynamic foveated rendering (DFR) based on quad view rendering technique can't work without eye tracking.

But, fixed foveated rendering (FFR) based on quad view rendering can work without eye tracking. It's just that higher resolution area won't follow your focus area but will stay in the middle of the display.
With is still a great improvement you barely notice if applied moderately.
it can. its fixed then. but still great fps performance .
 
Have you mentioned this to the Devs in discord? VR is high on the list at the mo and if this is as easy to implement as it has in RBR it might be something that can shoe horn in.

Not heard of it to be honest, I've not booted RBR for some months. Is this something that appears in the OpenXR tools kit if the software supports?
That's the first thing I did. :)
Hopefully they look at it at some point. And we need native OpenXR support as well for this.
 
Does it also work non eye tracked for Rift S? Would assume so, it's just not in your table so wondered if something stops it working.
There are two ways to approach this:
The easier one is to use Mbucchia's implementation. It's probably quicker and already covers most headsets but it's deprecated as he stopped his work on this. Better than nothing and would be a good start.
The best way is for S397 to do their own composition. That way, all headsets are supported as it would be an in game feature (if I understand correctly)
 
Last edited:
It won't work using composite?
It might work but I wouldn't build a game feature based on a mod that may break or become unsupported one day. Besides, OpenXR is the future and OpenVR seems to be deprecated (somebody can confirm). And OpenXR 1.0 could open the door to OpenXR 1.1 which includes quad views as a core extension (called stereo with foveated rendering)

 
Back
Top