mbucchia

Hey! Can you follow these steps to capture a trace of the problem (start capturing, reproduce the issue in-game - I only need like a minute of data showing the problem - then save the trace and ZIP it up). https://github.com/microsoft/OpenXR-MixedReality/wiki/Troubleshooting-for-developers#capture-a-diagnostics-trace-from-the-command-line The file will be big, we can organize you sharing it with me through DM. Thanks.

Not having it at 0 will indeed make things worse.

I've been looking at improving the quality of motion reprojection with AMD cards, but it's a dead end it looks like. The video encoder block (needed to compute motion vectors, an essential component of motion reprojection) on AMD cards is just far inferior to the competition. On 5000 series, it does not support 16x16 optimal block sizes (which requires us to downsample the input), creating a big loss of quality leading to "warping effects". On 6000 series, I have measured it to be 3 times slower than on Nvidia RTX cards, barely able to drive 90 Hz reprojection, causing added latency contributing to the "water effect". I've been looking for alternatives to accelerate and improve the motion estimation and even asked AMD developers on the AMF project (their video SDK). They told me what I need is just not supported. I've mostly run out of things to try for AMD. Nvidia on the other end, has delivered great innovation through their NVENC and NVOF...

Check out the top post here: https://forums.flightsimulator.com/t/reminder-this-is-how-wmr-openxr-updates-work/539112 This should help a bit.

There is a bug in OpenXR Toolkit that makes anti-shake interfere with motion reprojection. Hoping to fix that eventually.

**The ZIP file contains samples for developers and nothing else.** You do not need to download anything from that website. You get updates from the Microsoft Store. Good to hear that yesterday's update resolved your problems.

The latest OpenComposite build broke a few things on the controllers side. Revert to that older version instead: https://ci.appveyor.com/project/ZNix/openovr/builds/44353680/job/ab9sh3fntl2pn57v/artifacts

Hmm interesting. My bad I should've asked you to write down all your settings before returning to default...

This option was removed a few versions ago, it wasn't doing anything since Feb 2022

Thanks. I know you said you tried disabling FFR and FSR, but there must be another setting interfering then. Safe mode disables reading all settings, which means no features are enabled. Most features don't need a restart (except for upscaling, which you have already tested with and without). I would suggest next to try resetting all to default (via restore defaults menu option or ctrl+f1+f2+f3), then re-enable all settings while looking for the issue to appear.

Thanks. Any chance you could try enabling OpenXR Toolkit Safe Mode?

Take a look at your registry at "HKLM\Software\Khronos\OpenXR\1\ApiLayers\Implicit". Make sure there is no stale (uninstalled) API layer referenced there. Also, it is important that all your API layers are installed somewhere in a system folder like "C:\Program Files". Otherwise you will get this error.

A couple of hours is ridiculous. Are you sure they weren't developers using Unity or Unreal Engine? In which case it's a fairly simple migration clicking a couple of buttons. For a custom engine, it's work quantified in weeks at least, and will highly depend on how experienced the developers are.

AFAIK there is just no support for OBS with OpenComposite.

I just realized that if you are getting the dialogbox, the error is downstream of openvr_api.dll. Are you using any OpenXR API layers mods, like OpenXR Toolkit, XRNeckSafer, OpenKneeboard or OpenXR-MotionCompensation? If so you should try disabling them. If one of them is the cause then do the DependenciesGui thing on that one.

-32 typically means a missing dependency DLL. I suggest you download this dependencies visualizer tool: https://github.com/lucasg/Dependencies/releases/download/v1.11.1/Dependencies_x64_Release.zip Then open the openvr_api.dll with DependenciesGui.exe, and look for one or more DLL marked red with errors. Hopefully the issue will be apparent.

You want all this data only to reduce it to a global average that loses an incredible amount of data and its significance... you can average a higher FPS with constant stuttering (because the average literally acts as a low-pass filter). You can average a higher FPS with low dips that make the experience unplayable for several seconds. You can average a higher FPS because the game decided to spawn less entities (non-deterministic AI and game logic). Higher average FPS does not mean better. This is exactly what I mean with comparing apples to oranges and why I personally won't make the effort to put this data in everyone's hands. If I do that, I'm going to start receiving "bug" reports here and there because of people misusing the data. I already get those every time I release new software. Version A was higher FPS than version B... and 95% of the time this is again because of user error, people not able to compare apple to apple or using the relevant input data correctly. I've literally had people tell me how there is a huge performance issue between OpenXR Toolkit 1.1.3 and 1.1.4 on their HP Reverb... yet the only change between the two is 1 line of code that is only used with Pimax headset... These destroy the productivity of us developers, and I have no intention to shoot myself in the foot by offering this data (a loaded gun in the hands of every user)

Not quite, OpenXR Toolkit overlay only has info on app + OpenXR Toolkit itself. Nothing about the OpenXR runtime (the pre/post in the WMR overlay). There is no capability in OpenXR to query general runtime statistics, hence impossible for the toolkit to include these metrics. I have to disagree here, unless you are going to run exactly the same mission, assuming there is no randomness in the game (all clouds and objects are always at the same place), and your head always follows the exact same pattern of movement. That seems... unlikely. IMO giving this type of capability is allow people to compare apples to oranges and peaches to bananas. That's why I don't encourage it. The "feel" is all that matters, given that you will never be able to compare apples to apples, unless you use a professional benchmark (because these actually strive to be fully deterministic). Giving the whole CSV file thing is encouraging people to report differences and issues that aren't there. If you are on WMR, and persist with this idea, you can use the ETL tracing (Troubleshooting for developers · microsoft/OpenXR-MixedReality Wiki (github.com)) and then write an ETL parser that will extract this information. We have such tool internally, but we only use it for scenarios that are deterministic as I described, because otherwise it provides more false information than it provides true information. Performance & measurement is not a trivial problem that can be summarized to "look at FPS over time".

You should be able to tell that by looking at the overlay in real time?

You are mixing up a few things here. OP asked about OpenXR Toolkit stats, which are explained here: https://mbucchia.github.io/OpenXR-Toolkit/overlay.html You seem to be relating to the WMR overlay stats. There is no sharpening and colors processing there. Also there is no stat for FFR anywhere, since FFR doesn't really cost anything and is applied during processing (so it's effectively part of app stats). In the WMR overlay, pre/post are statistics of the OpenXR compositor, which in most cases will only include reprojection and some very small overhead for copying textures from a buffer to another, or things like MSAA resolve (that most apps do themselves anyway).

No there is no option. Don't get why people are obsessed with it at some point y'all have to forget the stats and play the game!!

For the record, I'm not the one behind OpenComposite. You want to thank ZNix and Jabbah for that!

There are many potential bottlenecks in the GPU pipeline, and FFR (using VRS) is only helping at the Pixel Shader stage. So you bottleneck is likely somewhere else and FFR does not help with it.

Have you checked this? https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html#checking-if-you-are-cpu-or-gpu-limited

I'm not the developer doing OpenComposite (which is the OpenVR to OpenXR bridge). I do OpenXR Toolkit, which is another add-on to improve OpenXR features. Not quite sure what the issue being discussed is, and whether OP is using OpenXR Toolkit at all. Please provide some more details to make this actionable. Try without OpenXR Toolkit if you have it installed, to isolate whether the issue is with OpenComposite or OpenXR Toolkit. If the issue is seen without OpenXR Toolkit, then you need to report it to the OpenComposite developers instead. Edit: my best guess, given the lack of any information at all in this thread and the other threads linked, is that either 1) the issue is specific to OpenComposite, or 2) it is caused by FFR in the OpenXR Toolkit. If the issue is 1) there is nothing I can do about it. If the issue is 2) there is a whole thread about asking the developer of this game to add 2 function calls to their engine to make it easier to achieve FFR (and even DFR): Last time I checked on that thread, the developer did not want to commit to making the necessary change. This change would likely resolve the issue, if the issue is indeed 2).