mbucchia

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

Pico on PC only supports OpenXR via SteamVR (like HTC Vive and Valve Index). You won't gain from OpenComposite, unless you want to use OpenXR Toolkit (but then you can also use vrperfkit without using OpenComposite). (Pico does support OpenXR "natively" but only for Android apps running on the headset, not for PC apps).

Read this and it will answer all your questions and more https://mbucchia.github.io/OpenXR-Toolkit/other-features#motion-reprojection

For clarity, that thread isn't about native OpenXR support in the sim, it's about adding a few lines of code to tag left/right views during rendering and enable OpenXR Toolkit to do DFR.

The point of DFR isn't to help with performance, it's to minimize the visual impact of FFR. So this observation is basically what is expected.

If only the DCS devs cared to make a 10 minutes change to their engine: https://forum.dcs.world/topic/299598-trying-to-connect-the-individuals-that-made-the-performance-enhancement-in-vr-to-the-dcs-devs/

For general awareness where the stats are stored: Other | OpenXR Toolkit (mbucchia.github.io) However, beware that Turbo Mode will interfere with the app CPU/GPU frame time measurements as explained on that same page: Turbo mode can also have undesired side effects: * Any statistics or performance measuring tool might now present incorrect data The frame rate will be correct, and I'm pretty sure app GPU time will be correct most of the time, but app CPU will be altered. For example if you are below 11.1ms/frame, you will read 11.1ms app CPU. Basically, the way Turbo Mode alters the frame timing, it makes it not possible to correctly measure app frame times correctly.

This update only includes one change which is needed for Minecraft and only affects Minecraft.

Thank you @edmuss for bringing to my attention your framerate issue and sharing the necessary logs and traces, which led to the design of the Turbo mode. Hopefully others also see the benefits.

There are some upcoming changes to the Motion Reprojection algorithm in the WMR OpenXR runtime that will help reduce artifacts. No release date unfortunately since the end of the year is always very busy with the holidays.

Try resetting all to defaults (via Menu tab, Restore Defaults). You can also turn on Expert settings (Also in Menu tab) then Developer overlay. Would be great to see all those values. Thanks.

Can you send me one of those csv files? Are you leaving recording on for the whole test? Edit: It looks like I misunderstood. You are seeing values in csv file? You can do the average yourself, or even plot them. That's the whole point of having all the data. You can do what you want with it. It takes 10s to do an average in Excel. Edit 2: but really tho, average is a terrible metric to look at. You can have really good looking average values but horrible lows or spikes. Average literally looses information. Don't look at average. Use Excel to plot the values.

Capture trace is not at all the option being mentioned in the release notes. Capture trace is for advanced debugging. The performance recording is accessible from the OpenXR Toolkit in-game menu in the Performance tab, called Record statistics On/Off. That one will create a .csv file that you will have no problem to open.

But Pico is not WMR. It never was and never will be WMR is a standard for hardware/drivers so that headsets can work within the WMR ecosystem (the "Mixed Reality Portal"). The most recent WMR device is the HP Reverb G2. Pico does support OpenXR, but only through SteamVR. AFAIK Pico does not provide any PC SDK for developers, so it's not even possible to make a native Pico OpenXR runtime (like what PimaxXR is to Pimax). That's quite unfortunate indeed, I hope Pico boards the train eventually.

That is not correct. The Pico is not a WMR headset and it will not work with OpenXR for WMR. As a matter of fact, Pico does not provide a native OpenXR runtime, and you must use the SteamVR OpenXR runtime. So people thinking about using OpenComposite with DCS will likely be disappointed. There is a HUGE catch with the Pico: they don't provide an SDK for developers to use their eye tracker on PCVR. They only provide eye tracking support for applications running on the headset (Android). OpenXR Toolkit (which is AFAIK the only solution for eye tracking foveated rendering in games like Microsoft Flight Simulator and iRacing) will not support Pico 4 eye tracking, simply because it is not possible, and Pico are not enabling developers to use the eye tracker on PC.