MoleUK

Not if you are hitting max refresh, and not if you are using reprojection. Using VD on my settings and hardware I am either hitting 72fps at 80-90% usage (I try and aim for 72fps, no reprojection with some free overhead), or if things get particularly busy I drop below 72fps and GPU pegs at 98-99% usage. That's expected. VD is far better at just maxing out the GPU load than Meta link is mind, as link likes to cut down to half refresh rate if it can't maintain the full refresh rate even with ASW disabled.

You can monitor GPU usage quite easily and see when it can't keep up. DCS VR being primarily CPU bound hasn't been true for over 2 years, since the introduction of MT. Before MT it was heavily CPU bound while still heavy on the GPU. Now it's vastly more likely to be GPU (or vram/ram) bound, except for unusual missions. Many VR users are also using quad view, which increases the CPU load and decreases GPU load. The only reason quadview gives such performance gains is because we have the available CPU overhead to exchange for GPU gains. Even a 5800X3D which is fairly dated will not struggle to keep up with DCS VR atm for the most part, even with quad view enabled. This is why I've been saying the FPS graph in DCS is misleading, if you've been led to believe you were CPU bottlenecked when you were not.

It's unfortunately not reliable in my experience. If running in VR at 72hz and maintaining 72 fps, and just relying on the games internal FPS cap (or your headsets) it will report as CPU render thread limited as you say. But when the GPU struggles to maintain that 72hz/fps, and you dip below 72, it will still report as CPU render thread limited. Despite the GPU being definitively the limiting factor. Additionally, if you have enabled reprojection and your GPU can;t keep up and you end up at half refresh rate being reprojected to hit 72fps, it will also list you as render thread limited. Despite the GPU again being the limiting factor there. In the same scenario, with NVCP being used to cap the game to 72FPS: when maintaining 72 FPS it will report you as GPU limited. But more importantly, when you dip below 72 if the GPU can't keep up, it will correctly report the game as being GPU limited. With the external cap in place, if you run into main sim thread bottlenecks it will still accurately point towards the main sim thread being a problem. But the render thread will no longer be inaccurately reported as the problem when the GPU can't keep up. Additionally to all of this, DCS' internal FPS cap appears to have frame pacing problems in my experience. This isn't entirely uncommon in games, which is why it's often recommended to use an external tool to cap FPS for better frame-pacing generally. The FPS graph being incorrect could be a quirk of my particular VR setup. Given that Quest/Pico headsets can sometimes run the PC at 99% GPU usage instead of 100%, and use additional encode. Maybe the game is misinterpreting that as having some GPU overhead leftover idk, I don't currently have a wired displayport headset to compare to atm.

Yeah the in-game FPS counter will lie like that. Essentially if it can't tell what is bottlenecking you, it will default to saying the CPU render thread is the problem. Capping the FPS externally via nvidia control panel can change this behavior and get it listing you as GPU limited.

This one definitely isn't fixed, as it routinely shows up when mouse polling is set to above 125hz. But only for some users. I don't know of any fix other than lowering the polling rate for affected users. Though generally speaking, some more CPU intensive games can struggle with polling rates above 1000hz. And mouse polling issues in DCS did seem to disappear for years until it's (somewhat) recent return.

These issues still remain with shadows off afaik. Not just in the F-5 but in many modules.

Settings/Options > Gameplay. It's on the right side of the screen: Spotting dots. Just under labels and above birds.

Yep just gotta hope it arrives in a somewhat timely manner. Some of the assets in DCS (trees in particular were really bad for shimmer) just really benefit from anti-aliasing. It's particlarly bad in VR, where the jaggies are extremely in your face and you have to pump the resolution to absurd numbers to get past it. Or you just enable DLAA and take the tradeoffs. It doesn't help that MSAA has never worked particularly well in DCS in my experience either, some have said it's due to the switch they made from forward rendering to deferred.

J and K both harm the spotting dots considerably with DLSS enabled. Particularly as those dots fly in front of cloud cover, as DLSS doesn't like that contrast at all. With just DLAA enabled, the impact isn't anywhere near as severe. Rolling back to the older non-transformer presets (C or F iirc) will also help the dots appear a bit better, but with obvious visual tradeoffs. Ultimately ED should give us the option to disable DLSS/DLAA from running on the spotting dots altogether, in the same way they have the MFD's. That's the only real 'fix' for this one. In the meantime, try settling for just DLAA. If that's still too negative an impact, go back to MSAA.

Others have run into this problem before. There's another recent thread floating around on it but can't find it. There is also a VR specific problem where the opposite happens, where opening F10 leads to the lighting going way too bright for a while. It appears to be HDR misfiring at a guess. Not the type of HDR found in monitors or in the system settings etc, it's the lighting technique used in gaming to brighten/darken scenes as you transition between light/dark areas. The kind of adaptive lighting/gamma system they have has always had some odd quirks imo, I wish we could disable it in the options.

Cheers, that's a good tweak to have available.

On some quick testing, it appears the spotting dot cap was increased from 100 to 1000. Compare the track with 900 ground assets in the distance vs 1000. This is a massive improvement, though I would have liked to seen it raised to 9999 (or several thousand) if possible to avoid any potential problems. Still, for most missions this should be more than fine. The only edge cases are likely to be missions with lots of infantry, as afaik each individual infantry model is assigned a dot. So hitting 1000+ units within a 80km by 80km square and hitting the dot cap becomes a bit easier if using mass infantry. Something for mission makers to keep in mind at least. new co alt test 900 abrams 70km behind air dots.trk new co alt test 1000 abrams 70km behind air dots.trk

For anyone following along, from ED's newsletter on the 18th: "Spotting dot rendering is being reworked to change the maximum number of dots that can be rendered simultaneously." https://www.digitalcombatsimulator.com/en/news/newsletters/b975d20c465e6c77afbdea6bce7a2b59/ Good to hear a fix is in the works. When it arrives, I will do some test runs and update the thread with the results.

That option is already available, just set them to off. There's a reason none of the larger MP servers force it to off, mind. Customers don't want to fly it that way in MP for the most part, and those that do can already launch 0 spotting servers. All that aside, it would be nice to see a fix arrive for the spotting dot cap bug/issue eventually. As my 'fix' is far from ideal.

Keep your LOD slider at 1.0 or above, setting it below 1.0 will result in disappearing ground and air assets. Also follow the steps to reduce global object draw distance here: Doing that will keep spotting dots appearing properly for the most part.