Constant terrain stutter on MT

[PinkCube]

13 minutes ago, Glide said:

I set the max fps setting in graphics.lua, but I am not sure exactly what that does.  Is this the same as setting max framerate in the NCP?

It's not the same, I have tested both and each has a different effect. My theory this also helps limit the CPU but I could be wrong on that.

Edited August 28, 2023 by PinkCube

[Rapierarch]

11 hours ago, Glide said:

 

I set the max fps setting in graphics.lua, but I am not sure exactly what that does.  Is this the same as setting max framerate in the NCP?

 

All game engines have a handbrake like that. 

In case that user does not use Vsync and also does not put any frame rate cap than there is nothing stopping your computer to overheating itself unnecessarily to oblivium at 1000fps on main menu screaming coil whine from your gpu. 

default in DCS is 180 because when they have written it there was no screen capable of going above 144hz. 

Edited August 29, 2023 by Rapierarch

[Glide]

So, my theory is busted.  I used Nvidia FrameView to capture stats taking off from Al Minhad and flying low over Dubai.  Zero frames dropped during that capture even though I could see some terrain stuttering.  (2d mode). 

It did capture Avg FPS at 59.47 (likely because I had maxfps set in graphics.lua), and the 1% Low FPS was 24.282. 

Looks like it's all about the time spent in the GPU doing API calls.

Edited August 30, 2023 by Glide

[PinkCube]

9 hours ago, Glide said:

So, my theory is busted.  I used Nvidia FrameView to capture stats taking off from Al Minhad and flying low over Dubai.  Zero frames dropped during that capture even though I could see some terrain stuttering.  (2d mode). 

It did capture Avg FPS at 59.47 (likely because I had maxfps set in graphics.lua), and the 1% Low FPS was 24.282. 

Looks like it's all about the time spent in the GPU doing API calls.

 

You need to limit framerate with in nvidia control panel AS WELL to stop the terrain stuttering. 

Edited August 30, 2023 by PinkCube

[Glide]

I only fly in VR, and I've got my sim running smoothly enough for my taste.  If I was a developer and had more insight into the API calls in the GPU, I would identify the longest API calls and see if they can be optimized in any way.  To drop from 60fps to 24 is a jump from 16ms to 41ms frames.  You eyes would notice that kind of jump.  Are some frames making more calls than others, or are some frames making the same number but more longer calls?  I know they are moving along to the next gen graphics engine, but these things would be good to review.

[MoleUK]

On 8/28/2023 at 6:46 AM, Rapierarch said:

Dear this is a problem with the engine, you cannot solve it with the settings. 

Lagging screen, lagging and transporting plane contacts are all the same bug. Those are different render layers having mismatched fps with the cockpit. Game reports cockpit fps and mismatched terrain, active object, and mirror fps causing stuttering experience and screen tearing on pancake.

In VR you can see the problem clearly. I have tried it in Dubai between the skyscrapers in MI-8 cockpit in VR. Cockpit is rendered at 72fp full refresh rate which is also reported to the headset. I can see perfectly fluent movement in the cockpit when I look at the engineer and copilot but in the same view the scenery out of the cockpit windows were stuttering. 

It was definitely lower fps than reported refresh rate but since Oculus see reported fps is 72fps it does not engage the motion smoothing even...

Nothing you can do with NVCP or game settings can fix this. 

There is only one thing you as a user can do: Cap your FPS at 60 and lower your graphics options / resolution. So that all render threads can render at the same fps. 

 

After having done some of pinks suggested tweaks, something has changed re: game performance.

All I did was force prefer refreshed rate to app controlled (had to use profile inspector for that), and limited the fps to 72 via nvidia control panel and the graphics lua.

The FPS graph ever since the rollout of MT has always said I was CPU limited when running at the headsets refresh rate. 72 fps at 72hz. It is now reporting I am GPU limited when running at 72fps at 72hz, terrain stutter is lessened and I no longer get head movement stutter when I drop below 72 fps.

I don't think it's a placebo effect. I have certainly have never had the FPS graph in green with GPU limited while running at the refresh rate with GPU overhead left over.

[Rapierarch]

11 hours ago, MoleUK said:

After having done some of pinks suggested tweaks, something has changed re: game performance.

All I did was force prefer refreshed rate to app controlled (had to use profile inspector for that), and limited the fps to 72 via nvidia control panel and the graphics lua.

The FPS graph ever since the rollout of MT has always said I was CPU limited when running at the headsets refresh rate. 72 fps at 72hz. It is now reporting I am GPU limited when running at 72fps at 72hz, terrain stutter is lessened and I no longer get head movement stutter when I drop below 72 fps.

I don't think it's a placebo effect. I have certainly have never had the FPS graph in green with GPU limited while running at the refresh rate with GPU overhead left over.

No you cannot get placebo effect on it. You see it or it is not there. I have tired both setting all refresh rates in game same as oculus but had no effect. It might still looking at screen refresh rate probably. Profiler might have done the trick

[Rapierarch]

@MoleUK

Well, thanks it worked.

Did not use the profiler but set ingame 72fps and nvcp max framerate 72fps. Nope

I kept NVCP as 72 and ingame raised it up to 144fps.

Well for the first time since the release yes it holds most of the time green gpu limited. And CPU limited exist here and there but that catastrophic stutter is almost gone. 

Lovely smooth stable line (but I don't know why this fixes it): 

 

 

 

[MoleUK]

9 hours ago, Rapierarch said:

@MoleUK

Well, thanks it worked.

Did not use the profiler but set ingame 72fps and nvcp max framerate 72fps. Nope

I kept NVCP as 72 and ingame raised it up to 144fps.

Well for the first time since the release yes it holds most of the time green gpu limited. And CPU limited exist here and there but that catastrophic stutter is almost gone. 

Lovely smooth stable line (but I don't know why this fixes it): 

 

 

 

No need to thank me on this one, this was all Pinks work.

It's definitely done something. I thought it was just the fps caps that did it, also had success with another person getting the same green GPU limit now.

Everything is significantly smoother atm. Especially on VD when dropping below headset refresh, it actually stays feeling smooth which is a big change.

I always thought the FPS graph saying CPU limited despite hitting headset refresh was some quirk of DCS, but looks like it was indicating a problem.

Edited September 3, 2023 by MoleUK

[Sile]

Very interesting. Can't wait to try the tips later today. Thank you all.

In my case, despite a frametime way below the required frametime for my VR headset (72 Hz) the terrain stuttered with the MT Client.
(ST Client  OR  OXR toolkit turbo mode -> no stuttering).
So I felt the MT client to have some problem with the correct timing of the rendering of the terrain/outside of the cockpit. Also visible in 2D when looking at plane contacts.

@Rapierarch is dead on with his comment: "Lagging screen, lagging and transporting plane contacts are all the same bug. Those are different render layers having mismatched fps with the cockpit. Game reports cockpit fps and mismatched terrain, active object, and mirror fps causing stuttering experience and screen tearing on pancake."

So might it be the case that the "render layers" are distributed accross multiple render threads and some of this threads (terrain) are not in sync with the others?

What some commited users found out and suspect might be VERY helpful for the developers. I really hope this get's passed on to the devs.

Edited September 3, 2023 by Sile

[Rapierarch]

12 hours ago, Sile said:

Very interesting. Can't wait to try the tips later today. Thank you all.

In my case, despite a frametime way below the required frametime for my VR headset (72 Hz) the terrain stuttered with the MT Client.
(ST Client  OR  OXR toolkit turbo mode -> no stuttering).
So I felt the MT client to have some problem with the correct timing of the rendering of the terrain/outside of the cockpit. Also visible in 2D when looking at plane contacts.

@Rapierarch is dead on with his comment: "Lagging screen, lagging and transporting plane contacts are all the same bug. Those are different render layers having mismatched fps with the cockpit. Game reports cockpit fps and mismatched terrain, active object, and mirror fps causing stuttering experience and screen tearing on pancake."

So might it be the case that the "render layers" are distributed accross multiple render threads and some of this threads (terrain) are not in sync with the others?

What some commited users found out and suspect might be VERY helpful for the developers. I really hope this get's passed on to the devs.

 

Do not judge the current mt-preview build with those quirks. What ED did is putting vulkan in a kind of emulation under DX11. Vulkan render cannot work correctly under these conditions. Asynchronous compute is a feature of vulkan and it works there. You cannot emulate this correctly on a cpu. 

If ED pulls this correctly when that dx11 container is removed and we move to vulkan we should see almost 100% FPS uplift based on current mt-preview. I don't believe devs are trying to solve this issue, they  should be moving on for finalizing vulkan instead of fixing the temporary dx11 container. I hope we don't get stuck here for years.

[Qcumber]

23 hours ago, MoleUK said:

No need to thank me on this one, this was all Pinks work.

It's definitely done something. I thought it was just the fps caps that did it, also had success with another person getting the same green GPU limit now.

Everything is significantly smoother atm. Especially on VD when dropping below headset refresh, it actually stays feeling smooth which is a big change.

I always thought the FPS graph saying CPU limited despite hitting headset refresh was some quirk of DCS, but looks like it was indicating a problem.

 

I tried this yesterday and it did not make any difference for me. I still get small stuttering of the terrain even when at a steady 72 fps. It's not a major issue, just slightly annoying. 

[Hoirtel]

I also tried changing fps limits. I set it to my VR refresh (80fps) in graphics lua alongside the 80fps I already had set in the NVCP. I can't force change the refresh rate of my monitor to 80hz as its only an 60hz screen. Not sure if that is an essential part of this tweak or not. I saw no difference, but actually did observe something odd. When in the DCS menu I could see that the stats total CPU use would flicker quickly between 0.4-0.6 ish. However, every 3-4 seconds it would build to 11.X which then would peak and show on the frametime graph as a wobbly line. At this time it would flick from CPU bound (main thread) to very briefly CPU bound (render thread), shown in yellow, then the whole thing would settle and do it again. Using the open XR tools to throttle at 80fps reduced this behaviour massively, but opening up all framerate throttling stopped it completely and returned to a flat uninterrupted 0.X total use.

For me, I cannot get rid of the minor stutter but I can reduce it with vsync=fast and low latency mode on ultra, pre-rendered frames to 1. Its not fully consistent as this will be great in some of my low flying test tracks, but then I will get bigger stutters in actual missions when things are a bit more dynamic. 

 @Rapierarch What you say makes a lot of sense. I don't know much about render pipelines but the general point of current MT preview being a sort of stop gap before the Vulkan integration makes a lot of sense, and the devs are just focusing on the next stage rather than a repair of what we have now. Having seen the videos of this same terrain stutter in 2D (although less obvious) just means it is a current part of the MT preview.

As will all DCS tweaks, different things will work for different people to reduce this. It will depend on what your system is and where its bottlenecks are. I run a 7800X3D and found it to actually work a bit smoother with CPU intensive settings increased, like view distance and cockpit shadows (This is along with the latency setting above) I assume this is reducing my top FPS at the same time, but as I mostly run to 40fps with reprojection I can't tell, and haven't done any proper testing to find out.

Thanks to everyone posting in this thread, its quite interesting to follow. 

[Sile]

That's some really interesting info about the vulkan under dx11 emulation. Where can i find that info?

If this is the case, then yes. Don't bother fixing the current state and move on asap.

 

Edited September 4, 2023 by Sile

[LucShep]

2 hours ago, Sile said:

That's some really interesting info about the vulkan under dx11 emulation. Where can i find that info?

If this is the case, then yes. Don't bother fixing the current state and move on asap.

Speaking of Vulkan emulation, did anyone try latest DXVK with DCS?

Download https://github.com/doitsujin/dxvk/releases/download/v2.2/dxvk-2.2.tar.gz (it opens like a .ZIP)
It's installed by placing the .DLL files (64bit ones) on the game's executable directory.

It usually solves a lot of performance issues with most CPU restricted games in Windows (not just Linux).
...maybe it could help people until this problem in DCS is solved by ED? 

I reverted back to an older DCS version (2.5.6 in my sig, which actually runs awesome in VR) so can't test this myself right now with DCS 2.8 MT, sorry.
FWIW, I remember testing an older DXVK version with DCS 2.7 over two years ago, and it did run much better, but there were issues with contrails and smoke.   

Edited September 4, 2023 by LucShep

[Rapierarch]

9 hours ago, Sile said:

Where can i find that info?

It was in one of the big yearly newsletter. There was a little bit of explanation how they will roll out the MT. First stage they will rollout a built running under dx11 masking Vulkan processes behind (That one we have now) to test and debug it. Than they will roll out the full version of their render frame which has 2 pipelines one real vulkan the other one is the same that we have now (dx11 container). This build will be longer alive with both Vulkan and DX11 until Vulkan is fully mature and they drop DX11 completely.

I think 2.9 should be vulkan along DX11, and 3.0 would be the goodbye dx11 release. (I cross my fingers and hoping that this 15th year anniversary is really a big thing).

Maybe I'm just stupid hoping this but, logically this should be the case. 

[Dogmanbird]

On 8/27/2023 at 6:33 AM, PinkCube said:

It seems that this thread has been hi-jacked with users experiencing a different problem.

This issue is very specific to the terrain moving badly as viewed from your own cockpit. I experience this while having a constant 180FPS. The following recording is only in 60FPS, and doesn't necessarily show the full detriment of this issue, however it still highlights the issue.

Here is a video of the issue that needs to be resolved.
 

 

Thanks for sharing this video. Seeing there's been  no replies for some time, I'm guess everyone came to a solution?

I had been experiencing exactly this when first trying MT (with turbo mode on or off) and the in game gfx settings set to absolute minimum. It not only affected DCS but other games also. In DCS I would see it on both the Quest 3 and reverb G2.

I'm using amd 5800x3d with either 4090 or 3080 so maybe the cause was different to intel users?

What appears to have cured it for me was to set the NCP "pre rendered frames" and "vertical sync" settings to "application controlled".  Manually setting them to anything else would produce the above tiny random stutters

[Hoirtel]

19 hours ago, Dogmanbird said:

Thanks for sharing this video. Seeing there's been  no replies for some time, I'm guess everyone came to a solution?

I had been experiencing exactly this when first trying MT (with turbo mode on or off) and the in game gfx settings set to absolute minimum. It not only affected DCS but other games also. In DCS I would see it on both the Quest 3 and reverb G2.

I'm using amd 5800x3d with either 4090 or 3080 so maybe the cause was different to intel users?

What appears to have cured it for me was to set the NCP "pre rendered frames" and "vertical sync" settings to "application controlled".  Manually setting them to anything else would produce the above tiny random stutters

set the NCP "pre rendered frames" setting to "application controlled". 

The one thing I never tried... Considering this is not default it never occured to me to set this to application controlled. Its has helped a lot with getting ASW back to being smooth as it used to be. Still not quite perfect but this was a good tip. Thanks

[Aluminum Donkey]

On 9/4/2023 at 2:24 AM, Rapierarch said:

Do not judge the current mt-preview build with those quirks. What ED did is putting vulkan in a kind of emulation under DX11. Vulkan render cannot work correctly under these conditions. Asynchronous compute is a feature of vulkan and it works there. You cannot emulate this correctly on a cpu. 

If ED pulls this correctly when that dx11 container is removed and we move to vulkan we should see almost 100% FPS uplift based on current mt-preview. I don't believe devs are trying to solve this issue, they  should be moving on for finalizing vulkan instead of fixing the temporary dx11 container. I hope we don't get stuck here for years.

That's what I was thinking. MT is awesome but why don't they go whole-hog and fully develop it with Vulkan API and then just release the whole thing ready-to-rock instead of years of wanking around?

Once the fundamental sim engine is working great THEN they can focus on new modules & other content. No point in re-painting your classic car if you don't even have an engine, driveline and suspension for it.

DCS 2.9 has great potential but why is it still running under DX11 when even "generic" games (shooters) are written for DX12 or Vulkan? (I know ED is a fairly small team and are really busy all the time)

AD

[Rapierarch]

6 hours ago, Aluminum Donkey said:

DCS 2.9 has great potential but why is it still running under DX11 when even "generic" games (shooters) are written for DX12 or Vulkan? (I know ED is a fairly small team and are really busy all the time

They are porting an existing game which still has bits and pieces from 25 year ago as a matter of speaking. They are also adding new features to the core meanwhile. 

And above all they are not working 5 years on it. Work probably started much sooner and probably last 2-2.5 years it is going with full momentum. 

Since they are not building something new. There is a lot of lost work due to port fails. And also unforseen tasks like rewriting huge portions which they thought they could port without a problem. 

You can imagine that they are restoring the colosseum to a modern sports arena without losing its soul aesthetics and quality. 

 

Edited November 28, 2023 by Rapierarch