The best I can do is frame time latency, not rate, based on FPSVR measurements.
DCS World varies between just under single frame time both CPU and GPU (Smart Smoothing should be off) with occasional multiplayer/netcode CPU spikes (forcing Smart Smoothing on) to GPU 90% of double frame time (Smart Smoothing on, nearly failing). CPU only reaches 90% of double frame time when very large numbers of custom objects have been added.
Elite Dangerous depends on which of my profiles of settings is used as documented by the two different spreadsheets - normal or āfastā. CPU frame time in both cases is well below single frame time (Smart Smoothing off). GPU frame time with the normal profile is, in empty space, just above single frame time (Smart Smoothing on), in stations and other crowded places, approaches 80% of double frame time (Smart Smoothing on, nearly failing). GPU frame time with the fast profile is intentionally always under single frame time (Smart Smoothing off).
Hopefully, I will eventually get around to producing some good quality videos showing the frame times through the various test cases I use.
Not sure where to put this but this thread seems to be fairly technical so⦠just a curious observation after forgetting steamvr on over night with the headset turned off. Iām guessing it is steamvr home that is running up the power bill, but steamvr crashed when I tried turning the headset on to see what it was doing.
Under the worst non-synthetic loads, my i9-9900k and RTX 2080 Ti system consumes <400W. Under synthetic load (overclock burn-in test), <650W.
Running 24h/day, this would cost ~$32/month.
Not great, but much smaller than lighting, HVAC, and similar loads. Moreover, the machine can be turned off when not in use.
I am much more concerned about how tenuous the whole SteamVR stack seems to be, and the resulting economic/ecological damage done by that, than the power directly consumed.
Ah, i wasnāt really worried about the power bill, i was just trying be a bit tongue in cheek that in this case it was steamvr home keeping busy over night.
It is actually more the memory use that is interesting, it suggests that there is an significant memory leak in steamvr home.
Latest DCS World OpenBeta update seems to have more bugs than anything. One of the tanker aircraft on the Aerobatics Online server has gone invisible. As in, everything but the model is there.
More relevant to Pimax headsets, GPU latency has bumped up a few milliseconds, and the latest shader mod should itself be modified to pass the integrity check (due to some of the other files being out of sync). Also, enabling conservative FFR will help in most scenarios.
Tested PiTool .255, latest NVIDIA Drivers, and 60Hz framerate on the Pimax Vision 8kX, with DCS World, Virtual Desktop, etc.
Overall, 60Hz is a good compromise for some applications. On the plus side, Virtual Desktop remains quite smooth. On the minus side, a tiny bit of tracking lag may be present, some slight choppiness arises with synthetic situations (ie. SteamVR background screen lines can double slightly), and Smart Smoothing artifacts become slightly larger as expected.
After an hour or two, the downsides become nearly if not completely unnoticeable, at least for me.
Much more serious nuisances come from DCS World itself. The current version shows some weird āmain:ā and āStatic1ā text - rejoining servers/missions may resolve this. Additionally, although shaders had already been compiled for the shader mod I had installed, there CPU latency was nearly double what it should have been on first launch.
After a performance issue with my most CPU heavy use case, switched back to PiTool 1.0.1.254_alpha . FPSVR statistics were similar, but it was clear that double-framing stopped by quite a wide margin. Since the odd stuttering the new version is supposed to fix was at most intermittent for me, I currently see no compelling reason to upgrade.
Flight sim users, consider staying with PiTool .254 .
I did not notice a substantial difference between .253 and .254, so I would pick .254. However, now that you mention it, in the next few days, I will do another rigorous measurement of the latency statistics between those two versions to be sure.
However, I am absolutely sure there is a far greater difference between, .254 and .255, which is definitely not tolerable for some use cases.
254 is the alpha version IIRC, the version that is known for locking up / crashing in between 45 & 60 minutes of VRāing.
I would personally prefer 253 if I should chose between 253, 254 & 255 due to performance.