mbucchia

I can't remember exactly what OpenKneeboard did, but I thought the latest version took extra care to not break OpenXR Tools. Better is to ask Fred on the OpenKneeboard Discord.

Most common cause for this is you have an OpenXR API layer such as OpenKneeboard, XRNS or OXRMC that is installed outside of your ProgramFiles folder. Check your registry at HKLM\Software\Khronos\OpenXR\1\ApiLayers\Implicit. There shouldn't be any key pointing to a file outside of ProgramFiles. Delete any offending key to resolve the issue.

It's always been like that. As edmuss mentioned, you need to have sufficient headroom at 60/90 for it to stay off. If too close to dropping frames, it will enable itself.

Auto is misleading and it only means enabled in FS2020. For other games you want to use Always on, which is a misnomer, Always on means Always on standby, and it only engages when you cannot hit the refresh rate 90 or 60 based on your WMR settings. So for short: use Always on, because it does exactly what you described you want it to do. Always on does what you want (only engaged when needed based on frame rate). This is the same exact behavior as OpenXR Toolkit Unlocked mentioned in your other comment. Having something called Auto was a huge mistake we made and I am going to remove it ASAP due to all the confusion in creates.

Not sure what "cut in" means, but today this is how MR works: it only engages if you cannot hit refresh rate.

Turbo Mode disables all v-sync (frame wait needed to reduce latency) and this means letting the game completely max out your GPU by just going as fast as possible without trying to reduce latency. Because the platform does a good job at late-stage reprojection (compensating the images for head movements), the extra latency is not that important, and the gain in framerate is well worth it. Your mileage may vary however: Turbo Mode can have as high as 20 FPS increase in some situations, but can also not give much in others.

Run DCS.exe with additional parameter --force_steam_VR

This isn't entirely correct. Turbo Mode will interfere with Motion reprojection, but it is being discussed as "turn it off" anyway in the conversation. Turbo Mode heavily relies on Spatial reprojection (something that is always on), it makes it work a little harder due to extra latency, but it's an essential part of the process. Without it, Turbo Mode would create a wobbly mess. Regarding WMR Motion reprojection, some significant improvements are currently in testing before release, and my tester with DCS claimed "it looks significantly better for me [on a 3080Ti]".

Look into the registry at HKEY_LOCAL_MACHINE\Software\Khronos\OpenXR\ApiLayers\1\Explicit. You probably have an entry to a file not under ProgramFiles, which would cause this error. Older versions of OpenKneeboard caused that IIRC. Or misinstalled versions of XRNS or OXRMC. Attach a screenshot if unsure.

Just to be clear, these are bugs of OpenComposite and nothing to do with your "$500 controllers", the vendors that made them, and the developers of the OpenXR platform software you are using.

Correct.

If you join the OpenXR Toolkit discord (see our website), then the link will become accessible.

There will be a public version available at some point, probably a week or two from now. I insist again this is an OpenComposite bug. I wish they could release a fix for it themselves since they don't have a release cycles (they just release whenever). OpenXR Toolkit however is on a release cycle that follows certain testing period, hence the delay.

Thanks for posting. This is purely an OpenComposite bug, which I have reported to the OpenComposite developer. I am not sure when/if they will address it. Next version of OpenXR Toolkit will implement a fix in case OpenComposite is not fixed by then.

That part I have to admit I am super confused about :D, not exactly sure how it could be different.

Here if you want the full explanation to clarify. I think we are both sort of on the same page, just mixing up different scenarios and terminology: - Standard openvr_api.dll is a simple loader to open the %LocalAppData%\openvr\openvrpaths.vrpath file to locate which underlying OpenVR runtime to use. As mentioned earlier, there is no complex logic to do so, it just exposes the generic OpenVR functions for the application to use, and then it forwards the calls to the selected OpenVR runtime. - By default, when you are not using OpenComposite at all, this will be the SteamVR runtime that is referenced in openvrpaths.vrpath, which actually lives in ...\Steam\steamapps\common\SteamVR\bin\vrclient_x64.dll. That is the IPC library that talks to SteamVR services. You can go look at this file, it is much bigger, about 4.5MB for me. It actually contains the logic to talk to SteamVR. - Note that each game could include this vrclient_x64.dll file instead of shipping the openvr_api.dll loader, however this would mean that every time SteamVR updates to fix a bug, every game would need to ship a patch to provide the new vrclient_x64.dll. So the loader here serves the purpose of decoupling the game from your version of SteamVR. When using OpenComposite, you have 2 options: 1) System-wide install, where you use the OpenComposite switcher app to replace the content of %LocalAppData%\openvr\openvrpaths.vrpath to use OpenComposite's own vrclient_x64.dll, as it is downloaded under your OpenComposite folder (under folder Runtime). This is the "about 1.2 MB" file you are talking about. In this scenario, there is no "replacing the openvr_api.dll with the one from OpenComposite". 2) Per-game install, where you download OpenComposite's vrclient_x64.dll mentioned in 1) except it is being renamed to openvr_api.dll, and when you replace the game's own openvr_api.dll (the trampoline DLL) and completely bypass the trampoline code (remove one level of indirection for the game to know which runtime to use). So in summary: - The openvr_api.dll that ships with the game is Valve's and it has nothing to do with OpenComposite. - When using OpenComposite per-game install, you replace Valve's openvr_api.dll trampoline DLL (something that does very little, hence the small size) with the OpenComposite OpenXR bridge implementation (something that does a lot, hence the bigger size). - Those 2 DLLs are definitely, 100% not the same thing. One is a thin loader, the other one is an OpenXR bridge, hence the difference in size. I hope this clarifies exactly how the process works, and why you should not be concerned by the size of these files being so different.

This DLL can be used in conjunction with the OpenComposite "switcher app" to go and "redirect" to the OpenComposite DLL, in its "vrclient.dll" form, as downloaded in the OpenComposite launcher folder. But in that case, the openvr_api DLL that comes with the game does not participate in any logic, it just acts as a trampoline (this is the actual technical term) to the "other" openvr_api DLL that is shipped by OpenComposite. So it doesn't "do great with OpenXR", it actually does nothing in that scenario but forward calls to that other openvr_api DLL that you are asking about.

It is not. OpenXR Toolkit app stats do not include OpenXR Toolkit overhead. SCL GPU is typically very small and it explains your 2-3 FPS difference between NIS/FSR/Override. The rest of your numbers are mostly "within noise band", 500us APP CPU difference is surprising but it is likely inaccuracies from test setup and test repeatability. There is no reason for NIS/FSR to interfere with APP stats. Also you are clearly GPU-bound so that difference in CPU numbers make no difference in terms of FPS.

The openvr_api DLL that comes with the game is the standard OpenVR loader to use the SteamVR runtime. It makes your game work with SteamVR. It doesn't contain a lot of logic, it just does communication with SteamVR, it's pretty small. That DLL has absolutely nothing to do with OpenComposite. It is written and distributed by Valve. The openvr_api DLL you get from the OpenComposite website is the OpenVR-to-OpenXR interoperability layer that contains all kinds of logic to make your game use OpenXR instead of SteamVR. There is a lot of complex logic involved in doing that, hence a bigger file. That DLL is OpenComposite. They have the same filename but they do 2 very very different things. EDITED: Rephrased "is the standard OpenVR IPC client to use SteamVR" to "is the standard OpenVR loader to use SteamVR" for clarity.

The "default" openvr_api.dll isn't OpenComposite, it is the OpenVR implementation to work with SteamVR. OpenComposite provide its own openvr_api.dll to bypass SteamVR and use OpenXR instead. This is the way OpenComposite "hacks" its way up into your game. So for short "openvr_api.dll" and "OpenComposite" = not the same thing.

After looking some more at your logs and your video, I'm sort of thinking that you are NOT using OpenXR, but your game is going through OVR (Legacy Oculus support). You don't seem to have OpenXR Toolkit actually working (per comment on your video) and the log you posted also doesn't show OpenXR initializing all the way. And if XRNS doesn't work, it also makes me think you are not actually going through OpenXR. This is great too (that you can run the game without SteamVR on your Pico), however I don't think you need OpenComposite (nor OpenXR Toolkit) to do that if using OVR mode.

Cool thank you. I'll have to look into how to use VD with the Oculus OpenXR runtime like you are doing, I've been told time and time that it only worked with SteamVR as your OpenXR runtime. PS: unrelated, but you have XRNS active twice on your setup. Probably a stale registry key from a past install under `HKEY_LOCAL_MACHINE\Software\Khronos\OpenXR\1\ApiLayers\Implicit`.

Hey! I'm kinda curious to hear more about your set up here. I was under the impression that Virtual Desktop only worked as a SteamVR output, and therefore you had to setup SteamVR as your OpenXR runtime system-wide. If you have a chance, can you send me your OpenXR Toolkit log file (you can open it from the Companion app). Thanks!

My point was that _either way_ you will end up going through SteamVR. The idea behind OpenComposite is mainly to remove the need for SteamVR. But you cannot do that with Pico. You had not mentioned that you were using OpenXR Toolkit so it wasn't clear. You can benefit from OpenComposite if you _prefer_ to use OpenXR Toolkit instead of vrperfkit. But if you are fine with just vrperfkit, then no need to use OpenComposite (keep things a little simpler). That choice is up to you: which tool do you prefer? You have 2 choices: 1) DCS (OpenVR) <-> vrperfkit <-> (OpenVR) SteamVR <-> Virtual Desktop <-> Pico headset 2) DCS (OpenVR) <-> OpenComposite (OpenXR) <-> OpenXR Toolkit <-> (OpenXR) SteamVR <-> Virtual Desktop <-> Pico headset I suspect the overhead is comparable between the two paths, but you might have to measure it to be sure.

https://mbucchia.github.io/OpenXR-Toolkit/other-features#turbo-mode