fixed 2.9.6 quad views foveated Varjo Aero issue under 90fps

[Chief_Biv]

3 minutes ago, mbucchia said:

To be very clear, the unsigned DLL will screw up ALL OpenXR games that have anti-cheat, regardless of whether these games use or not use quad views.

It will make them fail in a way that will also pop up my name on the screen "failed to load XR_MBUCCHIA_quad_views...." aka pointing fingers at me

This is why I'm not distributing the unsigned DLL.

Some examples of games using OpenXR and Anti-cheat that will break with an unsigned DLL system-wide: Pavlov, WRC, Contractors Showdown, Roblox...

So the best work-a rounds are either?:

1. Turn Quadviews off; or
2. Turn eye-tracking off but leave Quadviews on??; or
3. Leave on Quadviews and eye tracking, but run in ST but with the "-force OpenXR" [sic] argument in the execution string?

I am not sure if option 2 would work. Please advise someone?

[Werewolf_fs]

@bucchia
I am a regular user of QVF with Quest Pro and seeing that it has been broken with the new version 2.9.6 I returned to OpenXR Toolkit and what is my surprise that now the toolkit detects eye tracking now! and I get a dinamic foveated  that works with better performance than the QVF. How is this possible?

* Possible changes in meta software/firmware v67?

Edited July 12, 2024 by Werewolf_fs

[mbucchia]

Just now, Werewolf_fs said:

@bucchia
I am a regular user of QVF with Quest Pro and seeing that it has been broken with the new version 2.9.6 I returned to OpenXR Toolkit and what is my surprise that now the toolkit detects eye tracking now! and I get a dinamic foveated  that works with better performance than the QVF. How is this possible?

It's possible (but unlikely) that the game engine is now rendering left and right eye in a different order. I highly doubt this really works, all of the previous experiments with this showed that either FR wasn't really applied (no gain) or FR was incorrectly applied in certain situations (unexplained blurriness in the middle of the screen).

For VRS to perform better than QVFR, you must have had extremely low CPU headroom, which isn't the case of the large majority of QVFR users.

[YoYo]

1 minute ago, Werewolf_fs said:

@bucchia
I am a regular user of QVF with Quest Pro and seeing that it has been broken with the new version 2.9.6 I returned to OpenXR Toolkit and what is my surprise that now the toolkit detects eye tracking now! and I get a dinamic foveated  that works with better performance than the QVF. How is this possible?

As announced, Mbucchia stopped supporting further development of OXR Toolkit and Quad views, I wouldn't expect a solution, although he visits here sometimes, maybe he can be convinced?

For me everything is ok. 2.9.6 only reset my OXR Toolkit, I set it again and everything is ok, but I don't use Quad views because it caused problems for me.

[mbucchia]

6 minutes ago, Chief_Biv said:

So the best work-a rounds are either?:

1. Turn Quadviews off; or
2. Turn eye-tracking off but leave Quadviews on??; or
3. Leave on Quadviews and eye tracking, but run in ST but with the "-force OpenXR" [sic] argument in the execution string?

I am not sure if option 2 would work. Please advise someone?

All of the above would resolve your issue, but of course with the potential to reduce performance.

[YoYo]

2 minutes ago, mbucchia said:

It's possible (but unlikely) that the game engine is now rendering left and right eye in a different order. I highly doubt this really works, all of the previous experiments with this showed that either FR wasn't really applied (no gain) or FR was incorrectly applied in certain situations (unexplained blurriness in the middle of the screen).

For VRS to perform better than QVFR, you must have had extremely low CPU headroom, which isn't the case of the large majority of QVFR users.

And yet surprise :).

[markturner1960]

57 minutes ago, nikoel said:

Woah. We have some high rollers in ere'

I am also going to constructively say that I really hope that the feedback that you're passing on @BIGNEWY is taken onboard rather than "yes dear; thank you dear"

Quadviews is as much of an advancement for VR as Multithreading - this is a big deal to many of us

I have fixed this with the patch made by @sandboxcode - so from the bottom of my heart thank you mate. It would be good to have something a little more official from DCS as this fix screws up all other games that rely on anticheat and QuadViews

 

Hi, what is this patch you refer to and is it available to us? 

[Mainstay]

9 hours ago, Glide said:

I'm on the Crystal as well, and I say give it a try without QV.  With my 3080Ti and the headset at 66% resolution I'm getting 60fps with everything turned up max.  Perfection.

No QV, no Turbo Mode, no Low Latency, 120hz refresh rate, no smoothing or headset foveated rendering.  I even turn off eye tracking and position reminder.

Hi Glide thnx for the tips but thats not an option for me. I will wait for the fix same goes for the FC3 bug.

[mbucchia]

@BIGNEWY

I am going to write this up one more time, especially since it looks like my message from March 2023 was partially lost.

The following trace is captured today with DCS MT and quad views enabled on a Varjo. But it doesn't matter, it's the same issue with Pimax, Quest Pro, etc.

The trace shows 2 consecutive OpenXR frames (xrBeginFrame -> xrEndFrame).

As reminder, with quad views, per OpenXR 1.0 spec section 12.143.1

> The first two views (XrViewConfigurationView) will be for the left and right eyes for the outer viewport. The views 2 and 3 are for the left and right eyes for the inner viewport.

This means in the trace below, when you are seeing 4 consecutive "xrEndFrame_View", the bottom two are for the inner viewport (the region that moves with your eye gaze).

This trace clearly exhibits the bug in DCS frame submission code.

The order of operation might look confusing at first: this is because in MT mode, the processing (on CPU) of frame N+1 begins before the processing (on both CPU and GPU) of frame N ends.

1) The top of the trace corresponds to frame N's pre-processing. Frame N has a predicted display time of 1000084542856849400, and the tracking data needed in order to render that frame is queried through the xrLocateViews() API call. This call returns the data necessary to compute projection matrices for all 4 viewports that need to be rendered. We observe, circled in green, the values for the FOV of the inner viewports.

2) Meanwhile, DCS performs rendering and submission of frame N-1, with a "display time" of 1000084542846147700. This is the xrEndFrame() call that we see in between the green and red annotations. We sort of don't care about frame N-1 here, so let's just move on to frame N and N+1 to understand the problem.

3) The engine is now going to perform two things in quick succession: it will begin pre-processing of frame N+1, through a call to xrLocateViews() similar to what we've already described, and it will render and submit frame N. Remember frame N: the one we pre-processed earlier, at the very top of the trace in 1).

a) We see the call to xrLocateViews() for frame N+1, annotated in red, with a predicted time of 1000084542868214700, and that returns a new set of FOV values for the inner viewport: this is because the eye gaze moved between frame N and N+1.

b) Right after that, the succession of xrBeginFrame+xrEndFrame() corresponds to frame N being rendered and submitted. You can see a jump in time of about 8ms... that's our frame time. We can tell this is the submission for frame N because we look at the value of "displayTime" circled in green, and it is the same value 1000084542856849400 that we saw being used in step 1).

4) Now here is the bug: when you look at the FOV values that DCS was returned in step 1) and computed its projection matrices with, and you compare them to the "UnpatchedFov" values that DCS is submitting in step 3)b), they are not the same. DCS is telling OpenXR: "you know the inner viewport you gave me earlier to render into? well I didn't use that! I used other values instead, so you will have to perform reprojection from the viewport I used into the viewport you need to display on screen". This reprojection causes the freaky glitches we are seeing.

You can also observe next to these "UnpatchedFov" values, the "Fov" values that are the correct ones: this is the workaround that Varjo-Foveated and Quad-Views-Foveated implement to mask this bug. It keeps track of the displayTime used in 1), then it stores the FOV value and retrieve them in step 3)b) based on that same displayTime. This is the workaround that today is only enabled when XrInstanceCreateInfo.applicationInfo.applicationName is set to "DCS World" - the value you were passing for 1.5yr, and that today you changed to "DCS", which causes the workaround to not turn itself on.

 

But what we need really, is DCS to submit the correct values here.

Now to go even further into it, and to tell you exactly what line of code you need to look into, here the other observation: in step 3)b), instead of submitting the FOV values acquired for frame N in step 1), you are instead submitting the FOV values acquired in step 3)a) for frame N+1. This is the result of a very simple bug.

As you can see looking at the Thread column, there are two threads working here: thread 32252 which is doing the pre-processing (xrLocateViews) and thread 27000 which is doing the rendering and submission. My guess is that your code is using a single set of a shared variable between the two threads to "carry" the XrPosef/XrFovf values from the calls to xrLocateViews() into the calls to xrEndFrame(). This approach is fine when you are doing single-threaded, sequential frame processing. But since here you get started on frame N+1 before frame N is submitted, you overwrite the content of the XrPosef/XrFovf that you have stashed between your two threads. Note that you do not have this problem for the value of the displayTime: you are correctly retrieving this value from xrWaitFrame(), passing it to xrLocateViews() on your pre-processing thread, and eventually carrying it into xrEndFrame(). So whatever logic you are doing today for the predictedDisplayTime/displayTime between your two threads, you want to replicate that logic for the XrPosef/XrFovf values as well. You need a latching mechanism for these values between the moment you use them for computing your projection matrices and to carry them along with your rendering into your submission thread, WITHOUT overwriting these values with the "most recent" values when you start pre-processing frame N+1.

 

 

Edited July 12, 2024 by mbucchia

[zildac]

9 minutes ago, mbucchia said:

@BIGNEWY

I am going to write this up one more time.

The following trace is captured today with DCS MT and quad views enabled on a Varjo. But it doesn't matter, it's the same issue with Pimax, Quest Pro, etc.

The trace shows 2 consecutive OpenXR frames (xrBeginFrame -> xrEndFrame).

As reminder, with quad views, per OpenXR 1.0 spec section 12.143.1

> The first two views (XrViewConfigurationView) will be for the left and right eyes for the outer viewport. The views 2 and 3 are for the left and right eyes for the inner viewport.

This means in the trace below, when you are seeing 4 consecutive "xrEndFrame_View", the bottom two are for the inner viewport (the region that moves with your eye gaze).

This trace clearly exhibits the bug in DCS frame submission code.

The order of operation might look confusing at first: this is because in MT mode, the processing (on CPU) of frame N+1 begins before the processing (on both CPU and GPU) of frame N ends.

1) The top of the trace corresponds to frame N's pre-processing. Frame N has a predicted display time of 1000084542856849400, and the tracking data needed in order to render that frame is queried through the xrLocateViews() API call. This call returns the data necessary to compute projection matrices for all 4 viewports that need to be rendered. We observe, circled in green, the values for the FOV of the inner viewports.

2) Meanwhile, DCS performs rendering and submission of frame N-1, with a "display time" of 1000084542846147700. This is the xrEndFrame() call that we see in between the green and red annotations. We sort of don't care about frame N-1 here, so let's just move on to frame N and N+1 to understand the problem.

3) The engine is now going to perform two things in quick succession: it will begin pre-processing of frame N+1, through a call to xrLocateViews() similar to what we've already described, and it will render and submit frame N. Remember frame N: the one we pre-processed earlier, at the very top of the trace in 1).

a) We see the call to xrLocateViews() for frame N+1, annotated in red, with a predicted time of 1000084542868214700, and that returns a new set of FOV values for the inner viewport: this is because the eye gaze moved between frame N and N+1.

b) Right after that, the succession of xrBeginFrame+xrEndFrame() corresponds to frame N being rendered and submitted. You can see a jump in time of about 8ms... that's our frame time. We can tell this is the submission for frame N because we look at the value of "displayTime" circled in green, and it is the same value 1000084542856849400 that we saw being used in step 1).

4) Now here is the bug: when you look at the FOV values that DCS was returned in step 1) and computed its projection matrices with, and you compare them to the "UnpatchedFov" values that DCS is submitting in step 3)b), they are not the same. DCS is telling OpenXR: "you know the inner viewport you gave me earlier to render into? well I didn't use that! I used other values instead, so you will have to perform reprojection from the viewport I used into the viewport you need to display on screen". This reprojection causes the freaky glitches we are seeing.

You can also observe next to these "UnpatchedFov" values, the "Fov" values that are the correct ones: this is the workaround that Varjo-Foveated and Quad-Views-Foveated implement to mask this bug. It keeps track of the displayTime used in 1), then it stores the FOV value and retrieve them in step 3)b) based on that same displayTime. This is the workaround that today is only enabled when XrInstanceCreateInfo.applicationInfo.applicationName is set to "DCS World" - the value you were passing for 1.5yr, and that today you changed to "DCS", which causes the workaround to not turn itself on.

 

But what we need really, is DCS to submit the correct values here.

Now to go even further into it, and to tell you exactly what line of code you need to look into, here the other observation: in step 3)b), instead of submitting the FOV values acquired for frame N in step 1), you are instead submitting the FOV values acquired in step 3)a) for frame N+1. This is the result of a very simple bug.

As you can see looking at the Thread column, there are two threads working here: thread 32252 which is doing the pre-processing (xrLocateViews) and thread 27000 which is doing the rendering and submission. My guess is that your code is using a single set of a shared variable between the two threads to "carry" the XrPosef/XrFovf values from the calls to xrLocateViews() into the calls to xrEndFrame(). This approach is fine when you are doing single-threaded, sequential frame processing. But since here you get started on frame N+1 before frame N is submitted, you overwrite the content of the XrPosef/XrFovf that you have stashed between your two threads. Note that you do not have this problem for the value of the displayTime: you are correctly retrieving this value from xrWaitFrame(), passing it to xrLocateViews() on your pre-processing thread, and eventually carrying it into xrEndFrame(). So whatever logic you are doing today for the predictedDisplayTime/displayTime between your two threads, you want to replicate that logic for the XrPosef/XrFovf values as well. You need a latching mechanism for these values between the moment you use them for computing your projection matrices and to carry them along with your rendering into your submission thread, WITHOUT overwriting these values with the "most recent" values when you start pre-processing frame N+1.

 

 

 

This is great, I hope it's taken onboard and the devs get it fixed as it seems to be something that is rather fundamental to the DCS engine and VR! And with this level of detail the only real excuse would be "time", but that can be addressed with "priority"

[VR Flight Guy in PJ Pants]

just come across this, hope it is not already mentioned.

 

[ColinM9991]

51 minutes ago, mbucchia said:

@BIGNEWY

I am going to write this up one more time, especially since it looks like my message from March 2023 was partially lost.

The following trace is captured today with DCS MT and quad views enabled on a Varjo. But it doesn't matter, it's the same issue with Pimax, Quest Pro, etc.

I've cross-posted this in the dev Q&A thread to see if it's something they're aware of. At the very least, it may put it on their radar.

[nikoel]

1 hour ago, markturner1960 said:

Hi, what is this patch you refer to and is it available to us? 

It is. You replace a file in Quadviews Program Files folder

The video has been linked above. Remember what Mbucchia has said, it will break anticheat for OpenXR games. We are under strict instructions to keep our fingers tightly clenched

[VR Flight Guy in PJ Pants]

Patched with the file mentioned in the video above (disclaimer: not mine), it works. Forgot to mention, mine is a QPro.

Edited July 12, 2024 by VR Flight Guy in PJ Pants

[VirKoV]

hace 2 horas, mbucchia dijo:

It's possible (but unlikely) that the game engine is now rendering left and right eye in a different order. I highly doubt this really works, all of the previous experiments with this showed that either FR wasn't really applied (no gain) or FR was incorrectly applied in certain situations (unexplained blurriness in the middle of the screen).

For VRS to perform better than QVFR, you must have had extremely low CPU headroom, which isn't the case of the large majority of QVFR users.

It works for me as well. (oculus pro)

This morning I uninstalled QVFR. In openxr Toolkit, enabled eye tracking and voila! it works like a charm, no visible square boxes and now lens flare and dust come back to my option list, they work now.

 

Edited July 12, 2024 by VirKoV

[gonvise]

1 minute ago, VirKoV said:

It works for me as well. (oculus pro)

This morning I uninstalled QVFR. In openxr Toolkit, enabled eye tracking and voila! it works like a charm, no visible square boxes and now lens flare and dust come back to my option list, they work now.

 

 

Are you sure that the increase in performance is maintained? How are you sure Foveated dinamic rendering is working?

[markturner1960]

21 minutes ago, nikoel said:

It is. You replace a file in Quadviews Program Files folder

The video has been linked above. Remember what Mbucchia has said, it will break anticheat for OpenXR games. We are under strict instructions to keep our fingers tightly clenched

Thanks, i dont have any other games on my sim PC apart from DCS, so should not be an issue

[VirKoV]

hace 11 minutos, gonvise dijo:

Are you sure that the increase in performance is maintained? How are you sure Foveated dinamic rendering is working?

I can see pixeled image in my peripheal vision, when I move my eyes to this zone, it's cristal clear. Dinamic renderinig is working, confirmed.

I have to do more tests with complex/bad weather missions.

If you have Oculus pro, give it a try.

[gonvise]

15 minutes ago, VirKoV said:

I can see pixeled image in my peripheal vision, when I move my eyes to this zone, it's cristal clear. Dinamic renderinig is working, confirmed.

I have to do more tests with complex/bad weather missions.

If you have Oculus pro, give it a try.

Yes, I have Quest PRO, As soon as I get home I'll try it

[VirKoV]

hace 53 minutos, gonvise dijo:

Yes, I have Quest PRO, As soon as I get home I'll try it

Night mission, populated carrier, bad weather: very smooth asw 36 fps in the carrier, 72 fps above the clouds, lens flare enabled, rain hitting in the glass... very good performance with openxrtoolkit + Eye tracking, quad views uninstalled.

MSAA x2, almost any option maxed.

 

In the options tab capture you can see pixelated foveated image (left side). The first image is not blurry, it is the rainwater in the cockpit

 

4090 + 13900k here, maybe other systems struggles with this configuration. I'm very, very pleased, this morning the news that quad views was not working had me worried.

Edited July 12, 2024 by VirKoV

[gonvise]

3 hours ago, mbucchia said:

It's possible (but unlikely) that the game engine is now rendering left and right eye in a different order. I highly doubt this really works, all of the previous experiments with this showed that either FR wasn't really applied (no gain) or FR was incorrectly applied in certain situations (unexplained blurriness in the middle of the screen).

For VRS to perform better than QVFR, you must have had extremely low CPU headroom, which isn't the case of the large majority of QVFR users.

This is mbucchia explanation... I no longer believe in miracles ;-), but above all we will have to see if it presents a similar increase in performance. 

[VirKoV]

hace 17 minutos, gonvise dijo:

This is mbucchia explanation... I no longer believe in miracles ;-), but above all we will have to see if it presents a similar increase in performance. 

I am just as surprised, and mbuccia for me is a prophet =).  The vr community owes this man thousands of beers. I'm looking forward to him being able to try it and comment on his impressions.

[gonvise]

I agree, what mbucchia has done in terms of performance improvement in VR is incredible, and I cannot understand why DCS does not allow itself to be advised more by him, not to mention that they should hire his services in some way. I only have words of gratitude for him, and I understand ED less and less, because the fact that QVFR is not integrated directly into DCS is something that is difficult to understand... honestly, the support that ED is giving to VR is very below the speed at which this technology is growing. But hey, we have a new map that doesn't make me want to fly since it's uglier than the Caucasus with a texture mod, and soon a transport helicopter, yahoo!

[Tucano Branco]

1 hour ago, gonvise said:

I agree, what mbucchia has done in terms of performance improvement in VR is incredible, and I cannot understand why DCS does not allow itself to be advised more by him, not to mention that they should hire his services in some way. I only have words of gratitude for him, and I understand ED less and less, because the fact that QVFR is not integrated directly into DCS is something that is difficult to understand... honestly, the support that ED is giving to VR is very below the speed at which this technology is growing. But hey, we have a new map that doesn't make me want to fly since it's uglier than the Caucasus with a texture mod, and soon a transport helicopter, yahoo!

I agree 100% with you except last comment on new map etc... of course de gustibus no est disputandum, so I understand that you might not like the new enhancements. Beside I could not fly Afganistan because of the QVFR issue... and in general the VR situation is real for me so, since I fly mainly FY16, I will switch to BMS for a while... I am kind of done with downward compromises that workaround solutions bring.

Edited July 12, 2024 by Tucano Branco

[gonvise]

21 minutes ago, Tucano Branco said:

I agree 100% with you except last comment on new map etc... of course de gustibus no est disputandum, so I understand that you might not like the new enhancements. Beside I could not fly Afganistan because of the QVFR issue... and in general the VR situation is real for me so, since I fly mainly, I will switch to BMS for a while... I am kind of done with downward compromises that workaround solutions bring.

;-)... maybe I've gone too far with my comment about the map, but I'm a little tired, I know I should kiss the ground where ED steps because without them I won't be enjoying my greatest passion, but yesterday before the update I had a sim totally smooth and stutter-free in VR, with everything maxed out, and after the update I had lost the QVFR and, without it, the carriage turned into a pumpkin again ;-). I was very excited about the new map because of the images seen, but I don't know if it is because of the VR, I see poorly worked textures (in the finished part of course) and, in general, lighting that seems artificial to me, I don't know why. I know, is an early access, and that ED needs money, like anyone else, and that's why I've been buying modules and terrains for years that I don't even use, but what happened yesterday caught me already tired. Let's hope that QVFR problem will be resolved via ED.

Edited July 12, 2024 by gonvise