edmuss

4090 should be able to run full terrain shadows without too much hassle anyway. I'm currently getting between 9 and 15ms GPU with my 3080ti with a little help from upscaling.

Terrain shadows caused a big hit initially because the soft edges were applied to the flat shadows as well. Since the last hotfix the flat shadows are hard edged again and much less intensive (cost me about 1-2ms). There is a general reduction in performance due to the new lighting engine but it's not that big once you factor out the terrain shadows. The clear canopy mod by Taz can help with the slightly over fine canopy reflections and shadows of they're not to your taste (as well as saving a bit of performance).

That's what I thought, could it be something like corrupted shaders that need rebuilding? Worth a clear out of the metashaders folder? Truth be told I've not cleared them in ages I've seen it flying northwest out of Akrotiri, getting a fairly stable 14-15ms with the shvkal caged, uncage it and it's up to 17ms or so. Switched the trees out and I'm getting 13ms up to 14ms or there abouts. Obviously nothing scientific but the performance loss has been bugging me of late!

DFR (Dynamic Foveated Rendering) will only work on a G2 omnicept (or any other headset) which has compatible eyetracking. For the normal G2 you can use FFR (Fixed Foveated Rendering) to lower your GPU frametimes, I've seen 1-3ms saving depending on the setting. Typically I run the quality/wide preset with my G2, this give a small uplift with almost imperceptible loss of image quality

@Taz1004 I've been seeing some odd performance behaviour recently in BS3, specifically when I uncage the shvkal I suddenly gain 2-3ms GPU frametime. Tried all sorts of settings to no avail until I uninstalled this one as a test and suddenly the hit is far less. Is this something you've witnessed in 2.8 or something else that's not playing nice with my system?

I'm not sure what you're describing but openxr reprojection has always run at 1/2, 1/3 and 1/4 refresh rate fractions - it's always implicitly linked to the refresh rate. What you may have been seeing is framerate counter hysteresis whereby when the reprojection jumps from fraction to fraction it averages out the FPS counter for a few seconds. At 90Hz refresh rate the FPS will lock to 90/45/30/22 and at 60Hz refresh rate the FPS will lock to 60/30/20/15.

To date the reprojection in openxr has always been behind that of steamvr, I understand that it's because of how opencomposite operated in conjunction with openvr (steamvr) it was very difficult to accurately predict the reprojected frames, hence the increased artifacting. Now that we have native openxr support without the translation layer to complicate things it should be possible to improve the accuracy of the reprojection, hopefully up to the level at which steamvr operates. One huge advantage that openxr has over steamvr is that it is able to reproject at smaller fractions of the refresh rate, running at 90Hz it's able to produce a smooth reprojected image at 45, 30 and 22 Hz. Essentially with steamvr, if your framerates are below 50 fps (half refresh rate + a couple of ms GPU overhead) then reprojection will disengage and you will have a very stuttery image; in openxr it will simply step down to the next refresh rate fraction of one third refresh rate.

That will work, I've not got the --force_enable_VR switch, it does the same as the enable headset in the VR tab. I only play in VR so I don't need to have a pancake shortcut.

Although you don't technically I just have the use VR headset box checked in options.

None of that is required to stop using open composite, just use the --force_OpenXR switch on the DCS executable. Also your frametimes aren't tieing up with you FPS 10ms is 100 FPS, 20ms is 50 FPS. Something isn't adding up?

Your answer is on the very first post of my openxr tuning guide that I wrote last year Reprojection in openxr needs to be set to always on or disabled, auto only works for MSFS and I think is something of a legacy design choice that isn't utilised anymore. If you're using native openxr then reprojection may well not work, however if you're using open composite then it will work ok but with the artifacts normally associated with the openxr runtime (in other words it's not as good as steamvr or oculus).

It doesn't matter which way you slide it, the further you get from 100% (in either direction) the more it will reduce the render resolution. The further you upscale, the more overhead it costs the GPU (measured by sclGPU on the toolkit developer overlay) and the more it will introduce aliasing and artifacts. For me to upscale to 3300 (overridden target resolution) using NIS 75% (which gives a render resolution of arrived 2500 I think?) costs me about 0.6ms GPU frametime.

Showing 1.5-3ms less CPU, both with turbo off

Healthy boost to CPU times though Come back turbo! Cured pork? Headset mask, DCS has its own but it's suspect that the toolkit HAM is a little more aggressive and culls a few more pixels.

My experience with upscaling in DCS has shown that if you start with a lower resolution then the upscaling will add a LOT of shimmer and aliasing. You will get a healthy performance uplift but at the expense of a lot of image quality, however the uplift from upscaling is generally more than the uplift from simply reducing the resolution. I run 3300 (around 105% on the G2) wide target resolution and use NIS 75% which reduces the render down to around 2600 which is than upscaled back up to the 3300. I've found that this gives a very good balance of clarity, performance and lack of shimmer when coupled with MSAA2x.

It's fairly straight forward with the first question, you adjust the override and it alters the upscaled render resolution. NIS doesn't use tensor cores, that's DLSS which is limited to RTX only cards; NIS is driver based and is purely software only and will run on a GTX card as well.

Yes. Default (as in override check box unchecked) will set a recommended render resolution based upon your VRAM. If you override the resolution via either the desktop tools app or ingame with the toolkit then it will ignore the default. You can see what actual resolution is being rendered on the second tab of the desktop tools. 100% depends on your headset, for my G2 it's 3160x3050 or something along those lines. It takes the target resolution (what you have set by override or from the default as above) and reduces that by the value set in the upscaler and then upscales back to the target resolution. The actual rendered resolution is shown in the toolkit when you adjust the upscaling value. Note that values above and below 100% reduces the render resolution, pay attention to the actual rendered resolution as displayed by toolkit. If you want to improve image quality, increase the target resolution above 100% with overrides and then apply the upscaling; it may take a couple of restarts to get the settings all nailed in to what you want. Currently the CAS upscaling component isn't implemented but I believe that it is planned or at least has been worked on. Personal preference really, they handle colours and sharpening in different ways so it's up to you. I must say that the CAS sharpening is superior to either NIS or FSR in my opinion. I think it's applied before, I'd recomment leaving it at 1.0 as you have far more granular control on resolution overrides in the toolkit. Unsure, I would imagine that it would be before as it's a DCS integration rather than a seperate tool applied afterwards. Just need to restart the VR app, in this case DCS Hope that helps

I think my GPU frametimes have dropped slightly but I've not done any scientific or in depth testing yet.

Headset mask, DCS has it's own so the toolkit one shouldn't make any difference unless it's a little more agressive and culls more pixels?

Essentially you're simply bypassing the native openxr and reverting to using openvr with open composite; should be an acceptable workaround until the code is fixed for reprojection with native openxr

Turbo mode is situational. I think in laymans terms if you miss the refresh target (60Hz in my case) then openxr forces the compositor to hold the frame, I believe in order to reduce potential sync issues. The value that it's waiting by is shown on the toolkit developer overlay under waitGPU, turbo mode forces openxr to disregard the frame timing and just allow the GPU to generate frames as fast as possible. This means that your GPU frametime can be 15ms (66 FPS) but your actual framerate would be closer to 55 FPS - when you're borderline on the refresh rate, this can be the difference between smooth and stuttery. Hopefully it will make a return as for my usage it's very helpful

My methodology to get it all working was as follows: - Ensure that reprojection is set to off in the openxr tools desktop app. Enable openxr toolkit safe mode from the companion app. Start up DCS. Enter the openxr toolkit ingame menu and navigate to the tab with restore defaults on it, do that. Disable safe mode from the companion app. Restart DCS. Enable whichever settings you want apart from reprojection and turbo mode for now as they're currently bugged by the new DCS code. Typically beaten by @mbucchia

Yeah turbo is a no go at the moment, I think it's linked to the same code that has broken reprojection. All being well it will be reinstated soon when the next update (hotfix?) comes through. Until then I'll seeth silently at WMR only giving me 52 fps when the GPU is feeding it 65 In the meantime, although not documented I think I'm getting slightly lower frametimes than before, maybe 1-1.5ms but it's all cumulative. Really looking forward to seeing what DLSS will bring to the table over the current upscalers available!

I'm in the same boat, works fine just run DCS as normal and it should just open. One telltale if you have WMR is that with open composite, the WMR home would shatter into triangles twice before starting DCS, now it only happens once.

Leap motion supports openxr natively, there's an option within the Gemini drivers for openxr support. I don't think there's ever been a requirement of steamvr to actually use leap motion in DCS.