mrsylvestre

22 ms corresponds to 45 fps. I suspect that what you are seeing being reported is the framerate of your headset, with retroprojection active (90 fps / 2). This suggests that the actual render time of the DCS engine with your settings is anywhere between 11+ ms and 22 ms. If it was less or equal to 11 ms, retroprojection could be inactive and you probably would see 11 ms being reported. Hence, while tweaking your settings will add or remove details & quality to the scene being rendered, it will only have a noticeable effect on the actual frametime on the headset if you manage to either drop at or below 11 ms (for the best) or above 22 ms (for the worst). Note: on a Pico 4, a good compromise can be to set the headset and VD to 72 fps, no retroprojection or 90 fps with retroprojection. 90 fps without retroprojection is usually not achievable without reducing details to the bare minimum and 72 fps with retroprojection produces a lot of ghosting, that is unbearable to many. Pick your poison

Yes. QVFR is probably the single most effective tool for performance increase in DCS VR. On my system, it helped me to find the missing 10 fps to run native 72 fps and say goodbye to retroprojection and ghosting.

Virtual Desktop 1.29.3 beta with built-in @mbucchia 's VDXR OpenXR runtime: solution to performance overlay displaying incorrect runtime. OK. VD app (beta) and VD streamer (beta) were up-to-date but in Virtual Desktop performance overlay, it would still indicate "Oculus" instead of VDXR (despite running an OpenXR runtime, confirmed by VDXR log and working QuadViews, and it for sure wasn't running SteamVR's OpenXR runtime because I had disabled SteamVR entirely). In case this helps anyone who would encounter the same issue (perhaps only cosmetic but you never know), the culprit turned out to be an "Oculus compatibility layer for OpenXR plugin" that somehow found its way in the OpenXR layers. Now where did that one come from and how did it end up on my PC, I have no idea. I just disabled it by going to SteamVR and the OpenXR layers list, then exit SteamVR, check again that VDXR is selected in the VD streamer on the PC, problem solved.

Thanks. Yes, I updated both the streamer (on the PC) and the headset app. After uninstalling the 'old' versions, for good measure. Time for me to double-check, I guess.

I did an uninstall of the beta VDXR 0.6.0. and current non-beta version of VD before doing a clean install of VD 1.9.3 beta with VDXR built-in. It works but still reports "Oculus" as runtime on my Pico 4, although it is clearly using an OpenXR runtime (QuadViews and OXR toolkit are active). Does anyone (@Qcumber?) see something else than "Oculus" being reported at this stage? Solved: for culprit and fixing, see solution a couple of posts below. Also tried the ST dcs.exe executable out of curiosity. I double checked that the shortcut contained the (sole) option --force_OpenXR but it starts SteamVR then opens in 2D on the desktop. Strange. Solved: launching DCS ST from the command line .\dcs.exe --force_OpenXR in the bin folder works as it should. There must be something fishy with my shortcuts. I am still trying to get rid of mild stutters that crept in after the DCS 2.9 update, all options being equal to 2.8. AMD GPU here, DLAA/DLSS is not an option and FSR2/TAA produces too much of a phoenix/ghosting effect behind bandits in WW2 dogfights.

Hi, @mbucchia, thanks for the quadviews update. Just in case this helps: QV 1.1.0, DCS 2.8 and SteamVR's OpenXR runtime or VDXR 0.6.0 -> OK QV 1.1.0, DCS 2.9 and SteamVR's OpenXR runtime -> OK QV 1.1.0, DCS 2.9 and VDXR 0.6.0 -> Crash on DCS start-up QV 1.3.0, DCS 2.9 and VDXR 0.6.0 -> OK (System specs in signature, QV in FFR mode, obviously) Happy camper this morning !

Making progress! DCS (MT and non-MT) running with Streaming Assistant again. The trick, on my PC, is apparently to simply start SteamVR before launching Streaming Assistant. Then connect the client on the Pico 4 to Streaming Assistant and then launch DCS (no command-line options needed). This may seem logical to some but it is counter-intuitive because it is Streaming Assistant that is supposed to launch SteamVR, and it does if SteamVR is not already running, but then when launching DCS it remains stuck on the DCS World logo window on the flat screen. Problem solved, even though the solution is not the most elegant.

Interesting. As one can change the battery saver settings on the Pico while streaming from DCS, there is indeed a visible effect. It seems that it changes the FOV and compensates by zooming in/out as the battery saver option is toggled. It is very visible if you do this while in the Mig Hangar looking at the main menu.

The plot thickens... But THIS works, at least for DCS non MT: The investigation continues.

Well, tried that (removing the pico_driver.log and copied your settings) and there is still not love between DCS and Streaming Assistant on my system. DCS remains stuck forever on the first loading screen (DCS World logo) on the desktop until I kill it. If I kill SteamVR instead, DCS resumes loading to a fake VR window on desktop. Very, very strange. It was working when I first installed the Pico 4 months ago, then started acting once in a while on an irregular basis and now it just refuses to go to stage of the Mig Hangar and main menu in the headset. DCS is the only program to act like that. Absolutely no issue on Virtual Desktop with DCS and on Streaming Assistant with other VR games. But thanks for the advice anyway. Hope it helps someone else.

I installed the latest preview drivers from AMD (23.30.01.02 from October 13, not the earlier version of which there are numerous rather unfavourable reviews on Youtube). I didn't expect much but someone on Reddit reported a significant improvement in iRacing so I decided to try these. These kinda work. On the other, civilian sim and on DCS, these allowed me to bump VR resolution one notch while still getting fluid gameplay. On busy scenes, there would be stuttering without AFMF that is now, with AFMF and for lack of a better word, smoothed out: there might be some inconsistency from one frame to another, as if time was contracting or expanding just a tiny bit, but it is only noticeable if you look for it. So, if this technology is "Fluid Motion", there might be a little bit of turbulence in it, but I'll take that over brutal stutters any day. I did not notice graphical artefacts. Three remarks: My DCS options were already tuned in such a way to get around 72 fps (native on my Pico 4, no ASW/SSW) before driver update. Don't expect to magically go from 50 fps to 90 fps just with these drivers. For AFMF to kick in, it could be that DCS has to be rendering also the 2D view (mirror of what you get in the headset) in full screen (you can check that AFMF is running by monitoring the AMD overlay activated by CTRL-SHIFT-O, on the flat screen). The AMD overlay is the only tool that will display the true FPS (also counting the interpolated frames). Game counters and utilities that work upstream of the driver may only count the frames that are actually rendered by the game engine. I didn't play with all options in the drivers, I just set the default profile to "performance" which includes AFMF and some kind of "super resolution" (driver level implementation of FSR upscaling) and disabled the latter as I run 2D native and the VR resolution is set by the streamer. I also did a proper driver clean-up before installing the preview driver, which may have helped. At this early stage, I am tempted to think that AFMF is a better driver-level alternative than the IQ-degrading RSR/FSR or the ghosts-inducing ASW/SSW to improve VR performance on flight and racing simulators (although it does not do miracles and will not replace an RTX 5090 or RX 9900 XT). These could be due to the fact that changes between successive frames in our sims is normally less drastic than in FPS shooters and we can also get by with a bit more latency. YMMV.

With the big cache of X3D you do get improvement with regards to stuttering, that's for sure. Just be prepared to also upgrade your cooling solution if needed. I had one that was overkill for my 5600X but proved to be marginal with the 5800X3D.

I went from a 5600X to a 5800x3d one and half year ago, but only because I could recycle the 5600X to another PC for the kids. Yes, there is some performance improvement in DCS so you can push the graphics settings just a bit more and fly missions with more active units while avoiding immersion-ruining (to me) stutters. But this performance comes at a cost. The 5800x3d is much more picky about cooling than the 5600X. I had to upgrade to a top-of-the line Noctua cooler to keep it under control. It undervolts well, which helps, but you also need to reduce its PPT/TDC/EDC from the default values unless you are prepared to run all case and cooler fans to a level that your will seat near a 747 on takeoff, which negates some of its advantages. It's also pretty fragile, with its delicate cache on top of the rest of the CPU. One bad move with a BIOS setting (inadvertent overvolting even so limited) or temperature excursion to 105°C can toast it. I had one die on the day of installation without trying to push it. I got a replacement for free, but YMMV. Because of the stacked cache/CPU design, a water cooling system will not alleviate much the issue, if any (the heat from the CPU still needs to diffuse through the cache, it is more an issue of power density, hotspot and internal thermal resistance than of raw heat dissipation capacity). Today, even though Zen 3 prices have dropped, I think I would be looking at Zen 4 CPUs and bite the bullet for a new MB and RAM, or even wait for the next generation. Having a wireless VR headset, my priority would be on getting the most capable GPU for rendering and encoding (even though I am not prepared to pay 4090 prices, so I'll wait for the next generation too and enjoy what I have for what it is - when you cease looking for the limitations in the rendering and focus on flying/fighting instead, your imagination can sometimes compensate for the lack of pixels ).

Indeed, SteamVR can use its OpenXR runtime even when it is launched by Streaming Assistant : I just checked that the other, civilian, sim was working well in OpenXR through SA. On a related note (somewhat out of this topic) For the sake of science, I reinstalled Streaming Assistant on my PC, crossing fingers for it not to break something else (thankfully it didn't). I normally use Virtual Desktop as streamer to the Pico 4. For some reason, Pico's Streaming Assistant and DCS (standalone) do not get along with each other anymore on my PC (it used to work back in May). DCS remains stuck on the first splash screen (the small one with the Eagle Dynamics indian logo at the bottom) until I kill SteamVR (even after waiting 20 minutes), then it continues loading and starts in 2D. This is with both versions of DCS, single- and multithreaded. Both work flawlessly in combination with Virtual Desktop. It seems that for some reason, when Streaming Assistant is used as streamer to the Pico 4, DCS gets into an endless loop attempting to open the VR rendering pipeline (it never gets to the Mig Hangar). Strange. Back to VD (performance tends to be better anyway)

Aha! Does that mean that the MT version of DCS.exe cannot work with Pico's streaming assistant? It is something that has been bugging me for some time, I think that back in May, I could run it with SA but when I tried recently, I could not make it work anymore (but then, perhaps I remember wrong and I used the single-threaded version at the time).

I do not have a Vive Pro but a Pico 4 so YMMV but on my system, the OpenXR feature is the default with the multithreading (MT) dcs.exe found in the bin-mt/ folder of the DCS installation. I do not have to use any kind of "force enable" anymore. I *think* that the single-threaded executable, on the other hand, defaults to vanilla SteamVR. I assume the same will apply with the Vive Pro. You can confirm which runtime has been used by looking into the dcs.log file. On my system the OpenXR runtime used is the one provided by SteamVR (the Pico 4 is not a native OpenXR headset for PCVR) but MBucchia's 3rd-party tools that depend on OpenXR, such as the OpenXT toolkit and QuadViews work flawlessly. From this VivePort page, I guess it should be the same with a Vive Pro.

Sadly, Virtual Desktop through USB is a no go (there are a couple of software hacks that make it somewhat possible with IP over USB but always at the cost of stability issues). Virtual Desktop through wired ethernet-over-USB is possible and reported as reliable but you will need an ethernet to USB adapter cable and to connect that one and your PC to a router by cable. Usually not worth the trouble unless you also want to power the Pico 4 that way for longer gameplay, but then you also need a suitable USB power supply (your PC USB ports won't deliver enough power) and an USB/Ethernet adapter that has an extra input for that too. Unless the Pico 4 is the only wifi peripheral in your home and you are gaming next to your ISP box, the "proper" way to use VD is to have a not-too-expensive dedicated wifi 6 router on top of or next to your PC. The PC is wired to a LAN port on the dedicated router, the router is wired through its WAN port to your ISP router (VD's annoying software license check requires the headset to have internet access). The PICO 4 connects to the dedicated wifi network of the dedicated router wirelessly and is granted exclusive access, ensuring a stable connection. There is no image quality penalty for using (good) wifi rather than some wired connection as the effective bandwidth of both exceed the Pico's max streaming rate.

Yes. Just start the streamer (Pico's free Streaming Assistant or Virtual Desktop if you have it) then launch the dcs.exe found in the bin-mt/ folder of your DCS installation. If it starts in 2D, check that "use VR HMD" or something like that is ticked in one of the tabs of the DCS settings screen then restart. You may also want to begin with the VR preset in DCS's graphics settings for a good experience, then go for higher settings if your system is up to it.

Sorry I can't help (I do not have a WMR headset) but if by "it just hangs on the first splash screen forever", it is meant that one: i.e. the very first one with the DCS logo, before the one with the clouds and then the VR hangar with the Mig, I'm curious about the cause of that too. It used to happen randomly on my system when using Pico's Streaming Assistant with the Pico 4 but now it is a permanent "feature". No issues with Virtual Desktop, thankfully, so it is only a minor annoyance to me as I have a working alternative, but I'd like to know what is broken. From the log file, it seems that DCS hangs just after the INFO APP (Main): option.graphics = { enum of graphics settings here }; bit. I guess that is where it tries to start the renderer. If I kill Streaming Assistant after waiting for, say, 10 minutes, the loading resumes and DCS starts in "Fake VR" on the flat screen. The log then shows INFO VIZUALIZER (Main): LAUNCH IN VR: ed_FakeVR : ed_FakeVR. The timestamp of that line is consistent with the 10 minutes apparent inactivity. Cleaning and repairing DCS + full uninstall + cleaning leftovers of SteamVR, Streaming Assistant and even VD (in case its driver would interfere somehow) followed by reinstall of SteamVR and Streaming Assistant did not fix it. No issues with Streaming Assistant and other VR flightsims or racing sims. What is particularly baffling is that when the issue started to appear, it was not systematic but since a couple of DCS updates it now is. When DCS is left in its "hung" state, it is also interesting to observe from the Windows Performance Monitor that DCS is actually doing something, with some CPU load being shifted between two cores every few seconds in a cyclic way. @ moderators, let me know if this should be moved to the bugs reporting section of the forum if it may help.

Tried it also and... on my system it's not really better than aiming for 72 fps native. It gives less additional headroom than I hoped for higher graphics settings in DCS or for increased resolution in VD/SteamVR. There are no hard stutters and it is free from the infamous "horizon ghosting" at 3 or 9 o'clock in a roll that I can see with retroprojection but in warbirds dogfights over the Channel map (my usual test), it definitely feels just a bit less smooth when going for the kill. Image quality also seems lower to me (perhaps the video stream is still optimized for 90 fps?). I'll keep my native 72 hz settings (until the next experiment ). On a related note, there has been an update of quadviews some time ago that I missed (1.0.1 -> 1.1.0). The new default settings work well on the Pico 4 (turbo mode is now turned off for steamVR headsets). I found that my custom settings were not really necessary anymore.

Interesting. Perhaps the reason for that could be related to the bitrate used for encoding? Assuming that the same bitrate was used, say 100 Mbits/s, each second the 100 Mbits are used to encode 72 images or 90 images. Hence less "Mbits/image" in the latter case which I imagine does affect image quality. Just an hypothesis, though. Regarding locking framerate below refresh rate (e.g. lock @ 60fps with the headset @ 72Hz), I am curious about what exactly happens in that case. Do we get to see some frames twice, reducing the display rate to 36Hz for a few of frames? Following that logic, could we try setting the headset @ 90Hz with framerate locked @ 45 fps to get true 45 fps without retroprojection (and no ghosting)? I'll try that for science

Yes, 72 Hz is currently the sweet spot too for my system. I prefer it to 90 Hz + SSW, mostly because of ghosting in dogfights and when looking sideways. After 4 months, I am rather pleased with the Pico 4 in DCS and MSFS but it has for been quite a ride / learning curve. Image quality is OK even though not comparable to what can be obtained in 2D but, to me, the immersion and improved situation awareness is worth it, there is no turning back. I doubt that VD can squeeze that much more performance for these titles. Now if AMD or NVidia could get us 4090+ performance at ~800€ or less by say, 2025... In the meantime, I fire up HL:Alyx now and then to remind me what less demanding games that have been fully optimized for VR from their inception can do on the Pico 4. But I am not complaining about what I have today.

Thank you, I learned something today. By last update, you mean the recently released beta (1.28.1)? It certainly works well in my case. I only tested with MSFS2020, however, and I had opted out of the MSFS beta the day before, so it is not a perfect comparison. An added benefit of 1.28.1 to me is that Godin (dev) managed to fix the issues with the HEVC codec on AMD GPUs. Compared to x.264, I can reduce bitrate by ~30% in x.265 while still getting better image quality for similar performance (reduced bitrate lowers latency but encoding/decoding is a tad slower so in the end latency is about the same).

I am curious about the references to OpenComposite and the OpenComposite switcher. The Pico 4 is *not* natively OpenXR compatible for PCVR (it might be for the standalone Pico games running directly on the Pico 4 android OS). For PCVR, it is by essence a SteamVR headset. My understanding is that the main purpose of OpenComposite is to bypass SteamVR for headsets with native support for OpenXR. Perhaps the persistence of OpenComposite in parallel to SteamVR's OpenXR layer is the reason for issues when you attempt to run DCS-MT. FWIW, the only two VR-related softwares pieces I first installed on my PC were SteamVR and Virtual Desktop. No OpenComposite, no WMR, or other runtimes, API's etc. DCS-MT then flawlessly runs by default with the OpenXR API through SteamVR. I then added the OXRTK and QVFR by MBucchia with no issues. I once messed with DLL's and a key in the registry to force use of the Oculus API in DCS but it broke everything else. Lesson learned : uninstall of all VR-related software tools and clean reinstall of the list above (starting with SteamVR, after getting rid of all leftovers of past "experiments") + cleanup and repair of DCS for good measure.

See here for a detailed technical explanation of Quad View Foveated Rendering : What is Quad Views Rendering? TL/DR, it combines a low resolution rendering of the wider field of view for each eye with an higher resolution rendering of just the fraction of the field of view you are focussing on (also for each eye, so 2 + 2 images are rendered in total, hence "quad views"). By rendering your peripheral vision at lower resolution while keeping the focussed vision high-res, it saves on the number of pixels that have to be pushed through the rendering pipeline, resulting in a lower GPU load and thus potentially more FPS (if not CPU limited) with little or negligible impact on perceived image quality if done right, as in MBucchia's / ED implementation. It was primarily designed for headsets with eye tracking hardware (that know which part of the FOV you are focussing on) but works surprisingly well with headsets without eye tracking but with a relatively large FOV and sweet spot like the Pico 4. For these headsets, it just assumes that you are focussing on the center of the image, which is most often the case and quite natural. You can download QVFR here : MBucchia's Quad-View-Foveated on github. If default settings don't work, be sure to read the instructions regarding the creation of a user-specified config file. In particular, for the Pico 4 turbo mode should be set to off.