Jump to content

actually_fred

Members
 View Profile  See their activity

  • Posts

    166

  • Joined

  • Last visited

 Content Type 

Everything posted by actually_fred

  1. actually_fred
    Make sure you have the windows installer service running. If not, set it to start automatically and reboot. if you don’t have the windows installer service or it won’t start, you need to reinstall windows - it’s broken, usually due to an over eager attempt to “de-bloat” it.
  2. actually_fred
    Yep, and the current nvidia driver has a known issue in that it often crashes in D3D12 games with HAGS off.
  3. actually_fred
    HAGS is *usually* best left on nowadays but it’s still a “can vary - try it and see” thing. For people holding back on win10 or old versions of win11 it’s more likely to be good to turn it off
  4. actually_fred
    Two contrasting approaches: RTSS is 'delay stuff', Turbo Mode is 'remove delays'. Both can increase latency, but 'remove delays' is usually the better of the two Reason that 'remove delays' can be bad for latency is say you want 1 frame per second, and it takes 100ms to render a frame. Say your next frame is due at exactly 10:00:00 The theoretical ideal time to start that frame is 09:59:59.900 - in practice, most runtimes will aim to start a little earlier, say .895. If the game says 'ready to start the next frame' at .801, the runtime may introduce a .094 delay. Turbo mode gets rid of that delay, so your frame will be ready at .901, but it will still be displayed at the next panel refresh at 10:00:00.000 - so it will be 99ms out of date. Another frame will be ready at 10:00:00.101, but that will be discarded, with the goal of making another for 10:00:01 With RTSS or non-VR tools, when they have any effect on VR, you'll still have whatever delay the runtime wants (which will change), but also whatever delay RTSS inserts, and RTSS has no idea about when the next panel refresh rate is. Usually this is either 'no effect' or 'adds an extra 1 frame of delay'.
  5. actually_fred
    You seem to have skipped or misread this section twice - note 'non-placebo effect': RTSS is not capable of modifying framerate in a way that respects VR panel timing; all it can do is delay the game loop based on non-VR data. If you are getting a smoother result with RTSS, it is because is most likely it's delaying it enough to entirely miss a panel refresh, effectively adding a 1 frame delay with out-of-date headtracking. If this is the case, the root cause would either be DCS having unpredictable CPU load or over-optimistic wait time prediction in the pimax software. For this kinds of issues, Turbo mode has its' own problems, but is a often a better workaround, at the cost of increased GPU load (but not higher per-frame load) - the 'real' fix is to report the problems you're having to pimax and ask them to improve their runtime - in particular the implementation of xrWaitFrame.
  6. actually_fred
    Anyway, the actual way to limit the game to 72hz in VR: - set headset to 72hz - turn off 'turbo mode', 'prefer framerate over latency', and any similar options in the headset software and any third-party mods. Note that if you're using mbucchia's quad views layer (you probably don't need it on the pimax), it turns on turbo mode by default If that's not sufficient, test disabling all mods with https://github.com/fredemmott/OpenXR-API-Layers-GUI. If you have > 72hz with all mods disabled and it set to 72hz in the pimax software, contact pimax support. The *only* way to get correct frame pacing is for it to be dictated by the headset/runtime, not the game or any third-party software, as it should match the display panel timing.
  7. actually_fred
    RTSS and similar tools literally modify the 'send this to my *monitor*' thing, which is not used for VR. The game will usually render to the mirror window in a way that just tells windows "here's a frame, display it whenever you're ready, or don't" - the game doesn't wait for it to display. A forced limit or forced vsync forces the game render to wait for the next permitted frame time *when sending to the monitor*. When not placebo, this limits the entire game, so it ties your VR headset to your monitor's behavior, which is bad. It's placebo when the game more thoroughly decouples VR from the monitor behavior.
  8. actually_fred
    RTSS affects your mirror window - it does not directly affect your headset. There’s a fair chance it’s placebo, but if not and the mirror window ends up somehow linked to the VR display, it likely varies depending on your vsync settings, your monitor refresh rate, and if your monitor supports Variable Refresh Rate when RTSS and similar non-VR tools have any non-placebo effect on VR, it’s by tying the game to your monitor timing rather than the headset timing, leading to at a minimum microstutters, but can also lead to motion prediction issues, and larger stuttering and tracking issues.
  9. actually_fred
    For openxr, capframex, RTSS, presentmon and others may be easier, but the numbers they give are wrong, and they can actively harm the VR experience because they work on the “send to mirror window” part of the game, not the VR part. https://github.com/fredemmott/xrframetools?tab=readme-ov-file#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games If you go beyond monitoring with these into framerate limiting, vsync, or other modifications, these will either do nothing to VR beyond placebo, or tie your headset to your monitor's timing rather than the runtime's timing, often leading to stutters, motion misprediction, and other tracking issues. Edit: for example, accurate support for OpenXR has been an open feature request for CapFrameX for over a year: https://github.com/CXWorld/CapFrameX/issues/277 While Google's AI and a guest post on Pimax's blog say PresentMon support OpenXR, this is incorrect. This is obvious from the fact that it does not have an API layer. The only other way it could provide accurate numbers would be if it integrated with the runtimes - given PresentMon itself is open source, it would be an unusual choice for them to integrate with some runtimes, but none of the open source ones (like VDXR) - and another bad choice to display incorrect information on other runtimes rather than a 'runtime not supported' message which woudl require an API layer. PresentMon can hint about your load, but this says nothing about timings/bottlenecks unless something is at 100%. I'm also not seeing any trace of OpenXR-related code in PresentMon's source code.
  10. actually_fred
    While I don't have a workaround or solution, please let Varjo know the bug in v4.4 and above is important to you; despite it not being in their 'known issues' list, they've been aware of it since at least November. It also affects other world-locked OpenXR overlays. I've been keeping track of the details over on https://github.com/OpenKneeboard/OpenKneeboard/issues/698 as Varjo do not appear to have a public bug tracker.
  11. actually_fred
    Has something changed with this campaign recently to add spaces to the end of the mission names? I've had several reports of like Farside's. While this crashing OpenKneeboard is a bug in OpenKneeboard (https://github.com/OpenKneeboard/OpenKneeboard/issues/774), this seems strange and undesirable. For whatever reason, this is mostly being reported with mission 5 of 6.
  12. actually_fred
    You also received instructions on how to collect logs and ask for help, which you have not followed. It is not possible to provide any concrete suggestions if you do not follow the steps you have already been provided.
  13. actually_fred
    The original crystal supports the module. The light and super might not.
  14. actually_fred
    New version with bugfixes: https://github.com/fredemmott/XRFrameTools/releases/tag/v0.2.0 Also worth noting that https://github.com/fredemmott/XRFrameTools?tab=readme-ov-file#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games applies to the several non-VR tools mentioned in this thread.
  15. actually_fred
    You can also find various guides online to move Saved Games via other techniques such as the registry or various NTFS features - DO NOT USE THEM, they break things. The way described by others above is the only way to move Saved Games without subtly breaking some windows internals.
  16. actually_fred
    This is true - it uses the OpenVR *driver* API, which is separate to the OpenVR game API. However, every other OpenXR runtime except for the simulators (e.g Meta's XR simulator, or the simulator built into varjo base to allow testing their runtime without a headset) also talks to the headset with their own internal driver/API (or in some cases, Windows.Devices.Display.Core - this is documented as a UWP API, but is not limtied to UWP), not with OpenXR. While early OpenXR presentations mentioned an OpenXR device interface (a.k.a. driver), this was never actually specified or implemented. As a developer working with and on OpenXR, I would like to see more (good) runtimes. As a consumer interested in niche headsets from small manufacturers, I'd much rather have one with a mandatory complex piece of software developed by Valve rather than the small manufacturer. I have more trust in Valve to keep delivering a reliable runtime for my expected lifetime for a headset. My definition of a 'good' runtime is: - publicly released versions pass a recent version of the freely-available OpenXR test suite - performant Sadly the majority of runtimes fail the first point - i.e. they do not work correctly. Most vendors seem to test with common games, and maybe run the test suite every year or two, but mostly leave it to users to discover issues that the manufacturer already has access to nice, isolated, reproducible examples with clear pass/fail definitions. I personally consider it misleading to call something an 'OpenXR runtime' if it does not pass a recent version of the OpenXR test suite. Khronos have their own definition which overlaps, but is in some ways weaker (e.g. Meta's PC software is considered conformant, but the tested version is from 2020 on a rift S, and Valve's is from 2021), and some ways stronger (formal process and review, membership, and IP framework rather than just 'tests pass')
  17. actually_fred
    SteamVR supports OpenXR natively. Other runtimes from hardware manufacturers are generally substantially worse than steamvr, and I’m talking about correctness, not just performance. Valve did recently introduce some openxr correctness bugs, and when I reported them, they fixed them within two days - Meta is the only other hardware vendor to actually fix openxr correctness issues when I’ve reported them (but sadly seem to pretty much never fix issues reported in PTC before rolling out to stable), even when I point at failing tests in the openxr conformance test suite. Openxr isn’t a magic wand for lockin - using your own example, WMR had its own OpenXR runtime, and Microsoft abandoned it. The crystal is similarly tied to Pimax’s software, quests are tied to Metas (or when using the alternative to Link, still Metas firmware), etc. That said, I’m 100% with you on *game* adoption of openxr being a good thing. On a minor note, OpenComposite (the openvr to Openxr translation layer) is not one of mbuchhia’s projects, and for most of his VR projects, he explicitly did not support them when used with opencomposite. Edit: While it is possible, this doesn't necessarily mean what you think it means; several other vendors ship additional OpenXR integrations as API layers which require SteamVR - for example, HTC have done this for several of their headsets, adding face and hand tracking via OpenXR on top of SteamVR.
  18. actually_fred
    SteamVR supports OpenXR, and is one of the best OpenXR runtimes - but only when used for SteamVR-native headsets, like the BigScreen Beyond and the Valve Index. It tends to have issues/overhead when the headset is *not* SteamVR-native (e.g. when SteamVR is just wrapping other software from the manufacturer like Oculus Link or WMR). Most hardware manufacturers with their own runtime have done a substantially worse job than Valve have with SteamVR - especially the smaller manufacturers - and it takes engineering time from other things that are more useful. By asking BigScreen to create/support an alternative OpenXR runtime, you're asking BigScreen to spend significantly more time on software development for no concrete benefits, and a likely worse overall result. I understand some of you may dislike SteamVR, but that doesn't mean that SteamVR is technically bad or the wrong choice for all headsets.
  19. actually_fred
    Neither of those tools are suitable for OpenXR: https://github.com/fredemmott/XRFrameTools?tab=readme-ov-file#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games
  20. actually_fred
    Running things as administrator is a *really* bad idea, and can *create* issues that can only practically be fixed by re-installing windows (or chasing down a lot of undocumented filesystem locations and registry keys), as it can change things that should be owned by your user to require administrator permissions. It also puts your system security at severe risk when joining multi-player servers. It can help with OBS specifically because OBS contains explicit code to try and get high priority on the GPU, which requires administrator; running *everything* as administrator will not have the same effect as: - most software does not contain the code that attempts to use the only-available-to-administrator high GPU priority - even if it did, if everything has priority, effectively nothing does - it always takes away from *somewhere* - when you run OBS as administrator and it uses that to give itself higher GPU priority, this is taking away GPU resources from other things, including DCS
  21. actually_fred
    OpenKneeboard prepares the kneeboard images in VRAM regardless of whether or not it's visible - all that showing/hiding it affects is whether or not the result (a single image which is already in VRAM) is passed on to the runtime; this is *extremely* cheap compared to everything the game (and the main openkneeboard process) is doing. If your numbers are reliable, it means either: - your system is horribly overloaded - your OpenXR runtime is terribly optimized for composition quad layers, and you should report this as a bug to your OpenXR runtime vendor > OBS If you're using Jabbah's OpenXR API layer, that must do additional work when overlays are present (i.e. when OpenKneeboard is visible); I've not looked at how well it works or how well it is optimized. This would be an alternative to 'the runtime is terribly optimized'. > Reduce amount of images in the Kneeboard to reduce VRAM. (thanks Fred for the tip) To be clear, this was not a performance tip, just a statement that images stay in VRAM in OpenKneeboard. 'use less VRAM' does not improve performance unless you are reaching 100% full VRAM. When this happens, the game will generally crash or you'll get somewhere between single-digit FPS and 'seconds per frame'
  22. actually_fred
    Please keep in mind project is still in the 'early testing' stages Download: https://github.com/fredemmott/XRFrameTools/releases/latest Documentation: https://github.com/fredemmott/XRFrameTools/blob/main/README.md Summary: Every time someone uses any framerate measurement tool that was not specifically built for OpenXR, the numbers are not accurate, and are likely misleading. That said, it's not been entirely productive for me to keep saying that without offering an alternative, so... here we are OpenXR Toolkit's numbers are accurate; I had 3 things in mind when I started making this: OpenXR Toolkit is no longer maintained, and some games are incompatible I wanted to include power management data: "GPU time is 99% of frame time" has different meaning and implications if your GPU is running at maximum performance, vs when it's throttled, e.g. for thermal management More powerful logging: the option for 'every frame'; the binary logs are logged at every frame, but you can choose how many frames go into each row when exporting to CSV I wanted 'always-on' to be a reasonable option. Currently, the binary logging consumes 104 bytes per frame, which is 26mb/hour at 72FPS, or 43mb/hour at 120fps. Download: https://github.com/fredemmott/XRFrameTools/releases/latest More information: https://github.com/fredemmott/XRFrameTools/blob/main/README.md
  23. actually_fred
    If you're able to reach 90 non-VR that's a good starting point, but: - you might not be able to at all, depending on your monitor, and driver settings (especially vsync and related technologies) - if you are able to, you won't be getting the same performance with the VR1 - it is harder to produce the same framerate in VR than non-VR - the issues you're seeing might not actually occur in VR Of course, aiming to get things working non-VR first is good - just the target ends up being somewhat arbitrary and potentially unreachable. If that's fine with you, great If you're happy to sink in more time, you could also install varjo base; skip the headset setup, then click 'analytics window', then 'simulate' - you can now launch DCS in OpenXR, inside Varjo's simulator without a headset. Won't be entirely accurate for the VR1, but is as close as you can do without a headset.
  24. actually_fred
    Tools that are not specifically made for OpenXR can not produce absolute numbers that are meaningful for framerate/interval targets: https://github.com/fredemmott/XRFrameTools/blob/main/README.md#why-should-i-use-this-instead-of-my-favorite-tool-for-non-vr-games It can show when the mirror window framerate is spiking which can correlate with XR issues, but they're measuring the wrong thing (specifically 'Present' is not part of the OpenXR frame loop - it's used to show the mirror window on the screen)
  25. actually_fred
    Sorry, I misread the trace and mislead you, I'm following up with Somnium. From the OpenXR spec > A subsequent xrWaitFrame call must block until the previous frame has been begun with xrBeginFrame and must unblock independently of the corresponding call to xrEndFrame. It looks like DCS gets into the situation I described to Toge because the VR1 runtime does not do this. In this trace xrWaitFrame with predictedDisplayTime of 12388500800 is followed by xrWaitFrame with predictedDisplayTime of 12389312800, without a begin/end frame in between. The runtime should not return from the second xrWaitFrame (12389312800) until xrBeginFrame has been called for 12388500800
×
×
  • Create New...