Somnium VR-1 poor performance OpenXR

[matze140]

Hey there,

today I tried the new Somnium VR-1 in DCS using their OpenXR runtime.

i got extreme bad performance and heavy spiking frametimes. Also the Ingrame FPS overlay was totally off to the DCS FPS limiter or the VR-1 build in FPS counter.

in steamVR everything is just fine. 
maybe some OpenXR experts can have a look at the log file.

 

 

dcslogfile.log

[sleighzy]

You have a huge number of “XR_ERROR_CALL_ORDER_INVALID” errors in your log. I see you’re using the ultra leap OpenXR API layer so would be curious if this goes away if you disabled that.

You can use the https://github.com/fredemmott/OpenXR-API-Layers-GUI tool to do this. Just untick that ultra leap layer and restart DCS. 

[matze140]

Deactivating Ultra Leap has no effect. Still getting those weird Call_Order_Invalid errors.

Maybe this log snippet helps.
 

This are the two QVFR parts in the DCS log for Pimax Crystal and Somnium VR-1

QVFR VR-1.txt QVFR Pimax.txt

[Toge]

This happened to me too, with the VR1. I used https://github.com/fredemmott/OpenXR-Tracing/ to debug the issue together with the tool author, and his diagnosis was the following:

"this appears to be a DCS multithreading bug. DCS is literally making calls in an invalid order. This is funnily enough very similar to the Falcon BMS U5 + XRNS issue.

probably affecting you and not others because multithreading bugs are often just plain luck. "Works on my machine but not yours" is normal there's a reasonable chance that the performance issue you're seeing is just the overhead of logging these failures it's not failing every frame, just sometimes.

Specifically, games should go xrWaitFrame, xrBeginFrame, xrEndFrame in a loop.

DCS is sometimes choosing to do xrWaitFrame in another thread - this is fine - but sometimes it's doing it after the BeginFrame, so the order ends up being (frame n) xrWaitFrame, xrBeginFrame, xrEndFrame, (frame n+1) xrBeginFrame, xrWaitFrame, xrEndFrame, which is invalid.

The game and runtime recover, but it's not going to be flawless."

Edit: Fred (the author of the tool) provided a corrected explanation below. So seems not to be a DCS issue after all. Thank you Fred for the debugging!

Screenshot of the trace below, full .etl file (zipped) and dcs.log attached:

null

dcs.log MyTraceFile.zip

Edited December 6, 2024 by Toge

[actually_fred]

Sorry, I misread the trace and mislead you, I'm following up with Somnium. From the OpenXR spec

> A subsequent xrWaitFrame call must block until the previous frame has been begun with xrBeginFrame and must unblock independently of the corresponding call to xrEndFrame.

It looks like DCS gets into the situation I described to Toge because the VR1 runtime does not do this.

In this trace xrWaitFrame with predictedDisplayTime of 12388500800 is followed by xrWaitFrame with predictedDisplayTime of 12389312800, without a begin/end frame in between.

The runtime should not return from the second xrWaitFrame (12389312800) until xrBeginFrame has been called for 12388500800

Edited December 6, 2024 by actually_fred

[evanswillo]

Hi just received VR1 Titan so very interested in the current state of DCS and the Somnium runtime.

Can anyone give answer to this question 'Do we need to toggle Quadview Menu option in DCS'

 

[sleighzy]

2 hours ago, evanswillo said:

Can anyone give answer to this question 'Do we need to toggle Quadview Menu option in DCS'

If you want to try Quad Views (may help you with performance but will also depend on your CPU as it increases the load there) then yes. You will also need to install https://github.com/mbucchia/Quad-Views-Foveated as well.

[evanswillo]

I am not sure we will need to use the code developed by mbucchia, the code should be included inside the runtime, what VR1 version do you own ?

[sleighzy]

58 minutes ago, evanswillo said:

I am not sure we will need to use the code developed by mbucchia, the code should be included inside the runtime, what VR1 version do you own ?

My humble apologies. I’d thought at the time that only Varjo and PimaxPlay had native support in their runtimes for Quad Views. So yes Somnium does too. 

[evanswillo]

Absolutely no problem, we are all here to gather info and help everyone to get the best out the VR1.

In my DCS log and also in the one Torge originally provided I see the following, is this the DFR settings ?

null

 

[sleighzy]

On 12/23/2024 at 12:47 AM, evanswillo said:

Absolutely no problem, we are all here to gather info and help everyone to get the best out the VR1.

In my DCS log and also in the one Torge originally provided I see the following, is this the DFR settings ?

null

 

No, those line are common to all DCS VR launches regardless of the runtime used or whether or not Quad Views is used.

EDIT: I see views 0-3 listed here so yes looks to be Quad Views with the calculated values for each of the 4 views. Other logs without Quad Views show only views 0-1. I'll retest mine with Quad View disabled to verify that mine also drops from 0-3 down to 0-1.

Edited December 23, 2024 by sleighzy

[matze140]

vor 19 Stunden schrieb evanswillo:

Absolutely no problem, we are all here to gather info and help everyone to get the best out the VR1.

In my DCS log and also in the one Torge originally provided I see the following, is this the DFR settings ?

null

 

Yes. This is the actual Quad views setting. You can see the runtime mentions „vrgineers“ wich is the Somnium runtime.

But there is no quad views applied as you can see. 
you have to activate Eye tracking in VR-1 and apply foveated rendering values in the Sofrware tool.

[evanswillo]

There are some issues being currently resolved with the Somnium runtime, the next update should resolve them. For now I have been using the Steam runtime to showcase the huge potential of the VR1. The results are very impressive.

[evanswillo]

F16 4 Ship over Nellis 90fps

[mmike87]

Has anyone achieved decent performance and visual quality with the VR-1? I've had mine a week or so, and the only way I can have a good experience is using the Steam VR runtime with OXRTK fixed foveated rendering. Even then I'm locked at 45fps with motion smoothing.

I was getting 90 most of the time with my Aero, and it would seamlessly transition to 45 with MS. With Dlss 4, the Aero was working great. If only it had a better FOV.

The image is fantastic, bright, great fov. But when dialed up to look as good as the Aero, the performance is a low FPS, stuttery mess.

I realize for the wider field of view will have to be some compromises, but I wasn't expecting this level of image quality loss just to achieve a decent frame rate. To get 90 fps you basically have to dial it down to where the instrumentation is unreadable.

4090/13900k/64gb DDR 6800