sleighzy

With the latest releases of DCS both the bin\DCS.exe and the bin-mt\DCS.exe run multithreaded. As DCS could now be running the one in the bin directory (depending on what your shortcuts do) you’ll need to copy the dxgi.dll and .ini file to that dir as well.

I raised a post here asking what the Quad Views box does exactly, and if is required for runtimes like Varjo and Pimax. I largely understand what it means for the QVF api layer, but not what impacts this has for the likes of Varjo. Will be interesting to see what feedback (hopefully) we get from ED.

Ok. In DCS are the "Quad Views" and "Eye tracked" boxes ticked or unticked? Presumably ticked for "Quad Views". Firstly, QVF has turbo mode enabled by default, have you made any updates to that configuration? OpenXR Toolkit also has a turbo mode (I can't recall if this is on by default). Recommend you just remove OpenXR Toolkit in general. Secondly, download and install the latest version of https://github.com/fredemmott/OpenXR-API-Layers-GUI , this has been updated to provide a "Fix me" to provide suggestions for the ordering of the OpenKneeboard and NeckSafer API layers. Follow those suggestions. Once you've done that see if NeckSafer is still broken. Try ticking and unticking the "Eye tracked" box in DCS to see if you get different results. Thirdly, you'd responded to somebody that you were also experiencing a flickering? Go through the steps above first and then once those are sorted drop a comment here if you're still seeing the flickering and I'll drop a followup response.

EDIT: To clarify/correct myself. DCS has for a very long time now had quadviews support, ie, the ability to send 4 views when rendering. It is up to the OpenXR runtime to support this, like Pimax has recently. The Quad-Views-Foveated API layer we install (so we can enable quad views in DCS) is so that it can be used with other runtimes that don’t have this support natively, eg. Oculus.

It’s a known problem that’s been around for a long time, and is generally worse for VR given the performance impact. Some workarounds; always zoom back into your plane before getting into the cockpit view, decrease textures in your settings (not an awesome option for this one problem), try alt+tabbing out of the game for a few seconds and then back again (after going back to the cockpit view).

Not quite sure what you mean by that, you mean the Tallymouse QuadViews Companion app? That is just a configuration app for mbucchia's quad views api layer, it doesn't provide any quad views support itself so you still need QVF. If using Quad-Views then not really.

What exactly is it that the "Quad Views" checkbox in DCS does? I believe that DCS has supported quad views foveated rendering for Varjo headsets for some time (as its runtime supports quad views), but for other headsets we'd needed to use the Quad-Views-Foveated api layer to get the same quad views rendering results. The latest PimaxPlay and associated Pimax OpenXR runtime also support this now. My laymans understanding is that Quad-Views-Foveated API layer that a large number of us have installed is somewhat of a "shim" and is informing DCS that it is supporting "XR_VARJO_quad_views" so that DCS will render the frames that way (4 views), and the layer then carries out the necessary steps to compose that to a "stereo" 2 views for the runtimes that don't support it. For those of us using this api layer, without the box ticked the quad views logs say "XR_APILAYER_MBUCCHIA_quad_views_foveated layer will be bypassed" and the quad views rendering is not enabled. With the box ticked, the quad views log shows the normal information that it is being used, e.g. settings and pixel savings. By viewing this api layer within the OpenXR API Layers tool it is not disabling that layer per se, its just not actively doing anything. With the box not ticked does this mean that DCS is ignoring that indication from the api layer (or runtime) that it supports quad views, and is actively telling the layer (or runtime depending on support), that it won't be respecting that it supports this and just renders the normal "stereo" 2 views frames? Hence the Quad Views layer believes it is being bypassed, only receiving 2 views, and passes those onto the headset? Does this mean that this box is still mandatorily needed to be checked for those on the new Pimax OpenXR runtime (with quad views enabled in there) so that the quad views foveated rendering is still active in DCS and it is respecting this and sending the 4 views? Just wanting to clear up any confusion around what this does, and whether or not it is a requirement to be enabled for other runtimes, i.e. Varjo and Pimax which are using quad views. I've dropped in a picture here from Mbucchia around the differences between runtime vs. api layer support for this (ignore the sections re: OpenXR Toolkit as not relevant to this discussion), but wanting to clarify where the DCS Quad Views setting plays into this picture. EDIT: "...this mean that DCS is ignoring that indication from the api layer (or runtime) that it supports quad views, and is actively telling the layer (or runtime depending on support), that it won't be respecting that it supports this..." I've done some further investigation into the api layer and may be a side-effect of something else, v.s. specifically telling the layer/runtime that it's only sending 2 views etc.

If by "OpenXr" you mean the OpenXR Toolkit, then no nothing else needed. If you are using Quad-Views-Foveated, which based on your comment it doesn't seem like you are, then yes you will need to tick the box.

When the game starts it will compile all the textures/shaders it requires. This is a slow process so as it does this it caches them in that directory so it doesn’t need to repeat it each time. This is why you should delete those directories after an upgrade so it can rebuild them using the latest textures (and other stuff) from the new version. I believe sometimes this can cause a crash if not done so when it’s trying to use older cached textures with newer files.

What headset? If you have the "Eye-tracked" box ticked in the DCS VR settings try unticking that and see what happens.

In addition to this if you're using the new Pimax OpenXR runtime then you can uninstall PimaxXR which would have provided this runtime for you previously.

I've dropped your log file into the DCS log analyzer which has produced the following results. SSLR and SSAO can be particular performance hogs. There are obviously lots of other CPU factors, but you can probably review other forum posts, Discord channels etc. around tuning aspects of this, e.g. core parking, etc. for comparing against monitoring tools and approaches to this.

Correct.

I dropped the zip file from the crash into the log analzyer, results below re: possible crash issue with overclocking. Can't confirm if root cause. The dxdiag.txt file in there shows app hangs for DCS, as well as a couple for SR-RadioClient.exe which will be SRS. Aside from the memory overclock I'm not seeing a 100% smoking gun.

@Doggo, yup that's normal, it's just listing your current API layers, you can ignore it. Probably only helpful for us if things don't work...but we'd need to see a DCS log file anyway. So yeah, if it's working then all good, enjoy.

It probably won't as this is part of either the OpenXR API layer, e.g. Quad-Views-Foveated, or directly implemented within the runtime, e.g. the new Pimax OpenXR runtime.

Yes, make sure that VDXR is selected. No need to right click any monitor icons, just double-click your normal DCS shortcut.

ST has now been removed in the latest DCS update, everything is MT now (which is OpenXR) so you can just use your standard shortcuts.

Likely a duplicate of this, which is a known issue and being fixed at the moment:

Do you have the "eye-tracked" tick box enabled in the DCS settings (under the VR tab)? Numerous people have had issues with Necksafer and this. If so then untick this, restart DCS, and try again.

Do you have the "eye-tracking" box ticked in the DCS settings (under the VR tab)? Numerous people have had issues with Necksafer and this. Untick that box if you do have it ticked, restart DCS, and try again.

Do you mean OpenXR Toolkit and not "OpenXR"? Disable the OpenXR Toolkit and try again. You can install this tool to see all the API layers and untick the boxes for OpenXR Toolkit and OpenXR Motion Compensation (just leave quad_views) and see if that resolves the issue. https://github.com/fredemmott/OpenXR-API-Layers-GUI

Even after the exclusions and repair? Your DCS directories aren't owned by the administrator or anything and can't be written to? This is still confusing to me as well and should be resolved: " Local source: c:\program files (x86)\steam\steamapps\common\DCSWorld\" Is this via the new launcher, or running the dcs_updater.exe file within the bin directory? What happens if from the commandline you run the bin\DCS_updater.exe manually?

What are the new log files that were created in the Logs directory of the new Saved Games folder? Drop them here for further review in case the problem is different, or still the same.

I've dropped your crash log into the DCS log analyzer which has the attached output. My reference to installing the above files was from the VCRUNTIME error. Try the removal of the RAM overclocking first. Failing that, try the other options listed further down in that screenshot. null Cool, make sure you add the exclusions to Windows Defender as well and restart your PC before running a repair if/when you need to.