festr

in VR it insanely shakes its almost unbearable

Hello, DCS engine is still capped by the render thread in the VR setup - nvidia 4090 is about 70% utilised still not able to reach 90fps due to the CPU constrain. There is no CPU on the market currently which can handle specific VR setup. Is the render thread offloading planned? It does not seem that the CPU vendors will speed up single core performance signifficantly anytime soon.

13900k overclocked all pcores to 5.7, 64GB RAM (4 sticks) DDR 3200 overclocked timings, 4090, VR-3 varjo with foveated rendering Hyper threading OFF affinity for DCS set to 0-7 CPU (all pcores) varjo processes set to 8-12 (4 ecores) all other processes in windows 11 set to 13-23 (rest of ecores) testing - F18 cold and dark and apache hot start on runway. with MT.lua and without MT.lua I'm not able to percieve any change. When I monitored what CPU was utilised with MT.lua it jumped to core 3, without MT.lua it sticks on other core. 90FPS steady - fluctuates between 85-90, no major drops. for others - make sure that you have closed everything - like really everything in your system and do NOT run any performance monitoring like task manager or anything in the backround to not influence FPS fluctuations (I get -10fps variability when task manager is leaved on)

your motherboard is either overclocking your CPU or your cooling is not working properly. This has nothing to do with the DCS itself.

From the discord: atypicalarc: run OpenXR Explorer, check the "create XR session box" and then select "Reload Runtime data", then leave it up.

I have same issue but for me I can run the game after I boot the PC. But every other run I end up with: "2023-06-23 17:14:19.414 ERROR VISUALIZER (Main): OpenXR exception: runtime is not available" nothing helps other than full PC reboot and I can run MT in VR but only for the first time. I'm attaching mbuchas comment on discord regarding this issue.

Same here, after the latest patch the loading time is signifficantly longer. Using MT and VR. Around 150 seconds loading. When watching CPU and GPU - the GPU is on 50% during the starting and 2 CPU cores 100%. LOG attached. dcs.log

the game does not benefit from the hyperthread because it spawns 8 render threads and 8 main threads which is 16 threads on a 8 physical CPU cores and it gets ineffective. On my system it has impact losing 15 FPS. p.s.: I have 4090 lowering details - the GPU is not bottleneck - it is about 80% utilised. The CPU is bottleneck in my case (VR)

DCS automatically applies itself CPU affinity to Pcores only (0-7) but in the log IO cores are allocated on E-cores. But IO cores will be never utilised on E-cores if the affinity is set to 0-7 CPU cores. If I change CPU affinity manually to 0-23 CPU cores the side effect is that common cores and render cores are spread over E-cores and not P-cores which leads to lower FPS. 2023-06-25 22:51:31.185 INFO EDCORE (Main): common cores: {2, 3, 6, 7} 2023-06-25 22:51:31.185 INFO EDCORE (Main): render cores: {4, 5, 0, 1} 2023-06-25 22:51:31.185 INFO EDCORE (Main): IO cores: {8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23}

Without hyperthreading common cores and render cores allocates 4+4. When hyperthreading is enabled it allocates 8 cores for common cores and 8 cores for render cores which leads to decrease by 15 fps compared to 4+4 cores. (F18 instant action ready on ramp is my testing scenario) 2023-06-25 22:51:31.185 INFO EDCORE (Main): common cores: {2, 3, 6, 7} 2023-06-25 22:51:31.185 INFO EDCORE (Main): render cores: {4, 5, 0, 1} 2023-06-25 22:51:31.185 INFO EDCORE (Main): IO cores: {8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23}

with aero varjo I have tested this - I cannot see plain on 7nm with this mode I can see the dot

I can confirm that this new Mbucchia toolkit finally brings unprecedent sharpness to the VR-3 quad view. Not only the outer LCD panels has now full resolution but dynamic foveated rendering is working which brings much more FPS (90 FPS most of the time today in KA50 and MI8 on persian gulf multiplayer). There is so much headroom in GPU that I was able to set 1.2 multiplier for the focusing area which (its like 1.2x supersampling) and it looks amazingly sharp compared to what I had before.

and after you did solve it - what you see in the framerate window ? No main thread / render thread bound ? What is there instead?

confirming problem - flew in Harrier - no single spike from SA-5 launch on my RWR

Hello, There is Varjo 4 screen layout support for VR-3 and XR-3. What I'm asking here is if it would be possible to increase (or at least be able to set) higher PPD resolution for the outer larger two windows. Since the new multithreading and with the nvidia 4090 the engine should be able to handle it. Currently the 4 window mode on VR-3 and XR-3 has lower resolution for the outer (larger) LCDs than the native LCD panels. Or - is this somehow configurable already in some lua file? Edit: this is now fixed - https://github.com/mbucchia/Varjo-Foveated/wiki

close all programs in the background - like everything and retest

I have the same problem now with the ultraleap glowes - the head movement drags the pointer created by the ultraleap hand tracking. It is jumping as the ultraleap sets the cursor and whenever I move with my head it tries to drag the cursor away including the hand visualisation. Am I alone trying the ultraleap thing while its not possible to unlink VR cursor from the pointer movement?

I have exactly the same but it changes dramatically when there are no clouds. Seems like presence of any clouds + shadows enabled causes this (in 2.7 clouds did not cast shadows?)

Hi, I have bought 4090 asus. You have mentioned Aero varjo - I have big issue with my varjo on 4090 - I see a lot of ghosting when moving my head in all VR applications. When I swap back ot the 3090 the problem is gone. Have you already tested the Aero with 4090? Regarding FPS I had 40-45 fps with full details and 2xMSAA with my aero and 4090 is now peaking 80FPS - it is like 80-100% faster (Intel 12900 overclocked to 5.4 6 cores - all efficient cores disabled)

I would like to know this too. Seems like there is no cool down simulated?

This has been posted in another thread but I wanted to keep this isolated in separate thread. Since the latest beta version I'm not able to switch the VR into the native varjo mode. Before I was able to run it with --force_varjo_VR but as of the new patch it does not start in VR mode anymore - it falls back to 2D. Withouth the --foce_varjo_VR DCS starts normally in VR mode but not with the native 4 window rendering like it was with the native mode.

I have the same issue with the HMD display positioned too low in F16 and in apache it is lower than I would expect. I have VR-3 varjo

@Morphine windows version? Your varjo settings is? What happens when you run dcs.exe --force_varjo_VR ? (mine will fallback to 2D version - no VR at all)

With VARJO VR-3 If I run it with dcs.exe - it runs in normal steam vr mode (2 windows) If I run it with dcs.exe --force_enable_VR --force_varjo_VR - it runs in 2D mode (no VR at all) If I run it with dcs.exe --force_varjo_VR - it runs also in 2D mode (no VR at all)

I have VR-3 and DCS steam version. Before the patch I could enable the bionic dcs rendering by the --force_varjo_VR but I did not liked it anyway as the outside resolution was worse than not using the 4 window resolutions. Luckily I'm on a steam version which does not enable the varjo special rendering but I can not enable it either with option --fofce_varjo_VR anymore. I have tried standalone version and it does the same. There needs to be NOT autodetect of which mode should be used as me as VR-3 user can decide to not use the bionic mode for any reason. to be absolutely clear - there needs to be always switch which user can control if the VR rendering will use 4 window rendering or normal 2 screen rendering regardless on the VR model type