Jump to content

actually_fred

Members
 View Profile  See their activity

  • Posts

    148

  • Joined

  • Last visited

3 Followers

About actually_fred

  • Birthday 03/01/1987

Personal Information

  • Flight Simulators
    FSX, DCS World
  • Location
    Austin, TX
  • Interests
    VR
  • Occupation
    Software Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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'
  4. 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
  5. 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.
  6. 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)
  7. 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
  8. actually_fred
    No, OpenXR Toolkit was never strictly required for anyone, regardless of headset/runtime. Some people may have been unable to get performance they were happy with without it though. The unrelated but similarly-named "OpenXR Tools for Windows Mixed Reality" is also not theoretically required, even for people with WMR headsets -the WMR openxr runtime is installed automatically when you plugin in the headset - but if the default OpenXR runtime had changed since installation, WMR users may need it or another runtime switching tool. For non-WMR headsets, it was widely incorrectly described as mandatory on these forums and elsewhere on the internet, but it was never a good idea for non-WMR headsets - it is unnecessary and frequently misleading.
  9. actually_fred
    This is just an ultraleap dev unit (https://www.ultraleap.com/product/stereo-ir-170/) in a custom case; any improvements here need to come from either Ultraleap or Eagle Dynamics. That said, install the latest drivers for it from leap motion rather than the obsolete ones that Pimax link to.
  10. actually_fred
    VDXR over link is primarily a development tool, not intended for actual use. being able to switch between link and VD as the backend helps isolate problems: if a bug only exists with VDXR using VD, it’s likely a VD bug, if exists with both VD and link as the backend it’s probably a VDXR bug.
  11. actually_fred
    The original rift shipped with an Xbox controller and PC dongle for a start - touch controllers didn’t exist yet
  12. actually_fred
    There have never been *any* reports of Openkneeboard’s lua *ever* causing a DCS crash. If the rest of openkneeboard isn’t installed, it deals with that fine. if you’re aware of any with evidence beyond “oh there’s a mod in the log, must be that”, please report it and I’ll be happy to investigate.
  13. actually_fred
    XRNS has some issues with overlays; you might want to try reordering it to be above openkneeboard. If that doesn’t work , try disabling both, and if that works , enable one at a time. https://gitlab.com/NobiWan/xrnecksafer/-/issues/15 And https://gitlab.com/NobiWan/xrnecksafer/-/issues/16 in particular make it impossible for the combination to work fully correctly.
  14. actually_fred
    Only API layers that depend on querying what extensions are available are broken. HTCC specifically has a workaround in the latest version and works fine. Some are broken, some are not. If things are broken, turn them all off, then *try turning them all on one at a time* - they're not all vulnerable to the bug, some are.
  15. actually_fred
    Sorry, I don't use XRNS, and I'm unable to support other peoples' software.
×
×
  • Create New...