Missed FPS Target on Batumi when facing one direction

[Glide]

On my Batumi mission, I have a strange situation where I miss my FPS target, but it only happens when I'm facing one direction.  I can't seem to pin down the culprit.  Any ideas?

Caucasus Assault on Batumi Day 1 AM.miz

[Glide]

I removed the weather, and although I am hitting the target FPS, I can clearly see that facing north from that viewpoint takes 15% more GPU than facing south.  Something is odd about the Batumi airfield.

[Lange_666]

It happens on more places and not related to VR either.
You can check for instance the object count in the view direction + even if they don't differ that much, some of the objects can ask for a lot more PC power.

[Glide]

12 hours ago, Lange_666 said:

You can check for instance the object count in the view direction

Interesting.  I would have thought if the object was out of view range, only the CPU would be taxed with managing it.  I find it odd that the GPU takes a hit for objects that aren't in the viewport. 

[Glide]

So, I did more testing on this, and what I noticed was as I turned from South to North, the rdr CPU frame times would creep up from 8ms to 13ms+.  With my headset at 72hz, and my frames at a steady 72fps, the rdr CPU frame times would equal or exceed the app GPU frame times.  This would cause the de-scync.  My solution was to increase the load on the GPU so the rdr CPU times had more room to grow before exceeding the app GPU times.  I set the headset back to Maximum resolution, and since I was giving up frames for this, I switched to MSAA 4x (no more ghosting).  I also added Low Latency Mode = Ultra in the NCP, since this is where it really shines (GPU bound).  Finally, I set the headset to 120hz, since I knew I wasn't going to match the refresh rate.  The results were a steady 50fps with 20ms app GPU frame times, and the CPU did it's usual creep up of 5ms, but it had no impact on the GPU.  No Turbo Mode to interfere with Ultra Low Latency, and Quadviews enabled.  I have to say these are the best results yet.

Bonus: Since I am running MSAA, I can use the NCP to Enhance the MSAA to 8x, and even add some transparency AA.  Super sharp, no ghosting, 50fps in a dogfight.  I can live with a little jitter when looking at 3 and 9 oclock with these settings.

Edited May 6, 2024 by Glide

[LOW_Hitman]

Am 6.5.2024 um 04:48 schrieb Glide:

So, I did more testing on this, and what I noticed was as I turned from South to North, the rdr CPU frame times would creep up from 8ms to 13ms+.  With my headset at 72hz, and my frames at a steady 72fps, the rdr CPU frame times would equal or exceed the app GPU frame times.  This would cause the de-scync.  My solution was to increase the load on the GPU so the rdr CPU times had more room to grow before exceeding the app GPU times.  I set the headset back to Maximum resolution, and since I was giving up frames for this, I switched to MSAA 4x (no more ghosting).  I also added Low Latency Mode = Ultra in the NCP, since this is where it really shines (GPU bound).  Finally, I set the headset to 120hz, since I knew I wasn't going to match the refresh rate.  The results were a steady 50fps with 20ms app GPU frame times, and the CPU did it's usual creep up of 5ms, but it had no impact on the GPU.  No Turbo Mode to interfere with Ultra Low Latency, and Quadviews enabled.  I have to say these are the best results yet.

Bonus: Since I am running MSAA, I can use the NCP to Enhance the MSAA to 8x, and even add some transparency AA.  Super sharp, no ghosting, 50fps in a dogfight.  I can live with a little jitter when looking at 3 and 9 oclock with these settings.

 

how can you increase the gpu load? higher settings only? Is this "moving" workload from the cpu to the gpu? - have you ever tried cuda sysmem fallback on/off in this situation?

[5ephir0th]

Cant see the benefits of changing from 72hz and not achieving the target to go 120hz, kicking in ASW if you havent disable it and still not achieving the target as is 120 or 60 fps

[Glide]

Granted there is a bit of judder with 120hz pushing 50ish fps, but that is common to all vr apps and headset.  It's all about being GPU bound.  No smart smoothing or asw required.

Check out this video:

 

[Glide]

These settings are perfection for my system.  Note the rdr CPU and app GPU frame times.  No de-syncs.

[Glide]

Just to drill down a bit on this, I turned off Turbo Mode to see the correct frame times.  I'm set to 72hz, so the vsync time is 14.1ms.  This is why you want 72hz vs 90hz or 120hz.  The higher the refresh rate, the less time Directx and the GPU have to complete their tasks. 

Ignore the Headroom lines for now. 

app CPU is DCS, so DCS is taking 2.6ms to make a frame.

rdr CPU is DirectX which is taking 5.6ms to package up the frame for the GPU.

app GPU is the GPU processing the frame in 10.7ms.  This means the GPU has plenty of time to finish the frame before it has to sync again with the headset on the next 14.1ms mark.

The problem happens when the rdr CPU (directx) stage exceeds 14.1ms.  When this happens, directx can't finishing in time for the next vsync with the headset.  This causes a drop in FPS, and the spiky behavior you see in the FPS counter.

The goal is to have app GPU frame times with enough headroom so the GPU will always be able to send a frame at each vsync mark, and the rdr CPU DirectX calls never exceed the vsync interval.  This is exactly what was happening in the Apache mission on Caucasus map. 

On the Persian Gulf map, in the Viper, the rdr CPU stages stayed below the threshold consistently. 

What happens when you are GPU bound and app GPU frame times are say 20ms?  The system will send "old" frames to the headset, which will be slightly out of sync with your position in the game.  This causes the judder or double vision you get with the runway lights whizzing past you.

When everything is synced up like in the screenshot, the GPU will always have a new frame that matches exactly to your position, and everything will be smooth.

Edited May 13, 2024 by Glide

[Glide]

Interesting link:

https://learn.microsoft.com/en-us/windows/uwp/gaming/reduce-latency-with-dxgi-1-3-swap-chains#step-2-set-the-frame-latency

Note the part about setting frame latency to 2.  I believe he means VR prerendered frames from the NCP.  From the FPS counter above, you see the target is 14.1ms frames at 72hz.  rdr CPU and app GPU times are 5.6 + 10.7 = 16.3.  So, since that is more than 14.1, he is suggesting VR prerendered frames of 2.

Now, I don't know if any of this applies to how DCS works, but you get the idea.

[Glide]

I went back to testing CPU bound 72hz/72fps with DLSS/Performance, Quadviews (no Turbo Mode for the FPS counter).  This time I used VR prerendered frames = 2 as per the advice of the link above.  It makes sense if you are CPU bound to have a queue.

After further testing, it looks like you just need VR prerendered frames = 3, if you really push it.  I can't get my system to go past my 12GB VRAM limit, but if you had more VRAM you could push it down to 30fps and perhaps exceed 42ms combined time.  However, at 45fps I'm exceeding 28ms (2 vsyncs), so VR prefrendered =3 was as far as I could test.

This confirms my suspicion; I've never seen Reflex or Low Latency Mode recommended for VR by any official channel.  In VR, you almost always need one frame in the queue, most likely 2. 

Here's the issue, without a queue, the compositor will send an "old" frame when you miss the vsync time.  With a queue, you are always getting the next, correct frame, they are just a little bit behind your control inputs.  Not an issue in flight sims.  With a queue, the frames contain less Judder because the correct frames are ready when the GPU wants it. 

TLDR:

Want to sync at 72hz/72fps, VR Prerendered frames = 2 (most likely if you like like my 3080TI, I7-11gen)

Want to go GPU bound, VR Prefrendered frames = 3, but do the math.

No reason to use Low Latency Mode ever in a VR flight sim.

 

Edited June 5, 2024 by Glide

[Glide]

Low Latency Mode explained.  See Input Lag chapter.

 

Edited June 15, 2024 by Glide