im on 283 and its still an issue,honestly idk why they even enabled 1/3 at all,just let it be 1/2 or nothing like always
1 Like
The fact is at some point: after .263 the Oculus timings went off the rails such that your GPU will only use 70-80% of the GPU - this is what I believe to be a frame-timing issue, which @mbucchia similarly discovered when working with getting motion smoothing working properly in his PimaxXR runtime. I believe it got worse when they enabled 1:3 motion smoothing in .27x - and I honestly think the issues are related. At some point Pimax made a critical error in regards to their handling of timings and - as long as you’re not running an Oculus game, or a motion smoothed game in SteamVR - it’s fine.
You could just revert to .263 and all is well and it’s true! It does work! I’ve reverted countless times. Suddenly Oculus games have stellar performance and there’s no such thing as the 1:3 motion smoothing going into peanut butter 1:3 mode all the time. But .263 is of course missing compulsive smoothing which is useful. So I found a third-party frame rate limiter to solve that problem.
I have recently updated the ticket on their website. They have indicated on more than one occasion that they will send it to their developers.
The following are from .280 from the game Lone Echo
Now we all know that if there’s unused GPU - there shouldn’t be anything less than full frame rate in this case 75 FPS as I was running on 75hz
These are from same scene/settings in .263
Voila! 100% GPU use or 100% of Hz in FPS.
Please note that I have also tested this on multiple machines, with differing GPUs and noted the same result in multiple games. It is VERY reproducible.
The GPU is never allowed to reach 100% because it in my estimation has the wrong timings.
When @mbucchia tried to glean some understanding of their timings for the purpose of making PimaxXR, he was somewhat mislead by their information and at last report - if I may speak for him for a second - become utterly frustrated and lost. Either they (Pimax devs) don’t understand it themselves, there’s translation issues, or they haven’t discovered this error for themselves. - I feel it’s likely the latter.
If they really want to fix the above referenced timing-related issues they should have a very serious conversation regarding this topic with other devs - get open with their code as much as possible perhaps.
I believe @mbucchia has taken a pause on developing PimaxXR at the moment - an understandable one given the holidays.
Here is the link to the original issue with Oculus games Pimax Low GPU Utilization on Oculus Games
@PimaxQuorra @hammerhead_gal Please ensure someone is actively pursuing rectifying the issue cited above as I believe it is holding motion smoothing and Oculus games from reaching full performance.
The ticket in Pimax’s web system is #29542.
I feel that if you really delve into this and work closely with other developers - or invest a good deal of time with it yourselves - you may find that a relatively simple error as the development progressed may have resulted in this performance issue sneaking into your Pitool.
3 Likes
Addendum: If you want to use .263 and have it’s benefits - with the addition of compulsive smoothing : Use rivatuner and set the frame rate of your HMD to that of the frame rate limit as shown below
This provides a fix for the “jumping around display” that was occurring with games such as Vader Immortal and Asgard’s Wrath as the problem was a - you guessed it - timing issue. So now you don’t have to use Revive for Vader Immortal.
The above method can also be used to set compulsive smoothing to half your HMD Hz - so for example if I want 37.5 FPS - I would just put that in the slot for the frame rate limit.
There may be even more utility to the vsync parameter just below it, but it for some reason trips to the monitors’ refresh rate (60FPS) whenever I use that.
2 Likes
I don’t know what the technical term is but the timings involve reprojection - somehow either it gets applied twice - the result is as you move your head the next image gets doubly rotated. I’ve referred to it as lag-loop, or “bouncy screen” but not sure if that’s correct. I think it’s best described as if your HMD screen was suddenly suspended by a rubber-band. In any case, I hope more attention can be paid to the timings in the software to fix these interrelated problems moving forward
Thank you Djslanr，I do forward your every post about this issue to our technician.
We will continue to urge the software team to schedule a resolution as soon as possible…
Well, it seems my original intuition post may have been partially correct! I’m excited to find what may be rather exactly the issue: Let me share what I’ve found so far.
Using a method from @mbucchia I’ve been testing his way to change what’s being reported to the SteamVR as far as the most recent frame-time. Currently Motion smoothing shunts to 1:3 mode at a frame time above 22222 microseconds, which corresponds to 45 FPS, which is inappropriate in 75hz mode.
So the reason people like myself are experiencing motion smoothing problems at least in part because the programming is 90hz specific. 1:3 mode should only engage when at 25FPS or less - or more specifically when a frametime is reported above 33333 microseconds - not 22222 microseconds as it currently behaves,
In other words: Currently motion smoothing is only made for 90hz mode.
This should help immensely and I hope could be fixed in future versions.
To be specific in 75hz mofe, if I would set a maximum of 22223 microseconds to the reported frame time. 1:3 mode would engage - if I set it to 22222 microseconds 1:3 mode would never engage.
I have further testing I can do with @mbucchia, particularly in 90hz mode. but I’m afraid I couldn’t wait to share. Please get this to the devs ASAP.
Also thank you @hammerhead_gal and @PimaxQuorra for the assistance!
I can confirm that @DJSlanr is onto something. I personally only use 90 Hz so I never noticed this problem.
But for the technical details, instrumenting how the Pimax SteamVR driver reports the frame times (via setting internal property openvr_client_render_ms), it looks like Pitool is assumming 22.222ms (45 FPS) as the threshold for 1/3 smart smoothing while the headset is running 75 Hz. The expected threshold here is 26.666ms instead (37.5 FPS). Therefore any frame time between 22.222ms and 26.666ms could in theory use 1/2 rate, but incorrectly uses 1/3 instead.
EDIT: With a fresh look this morning, it looks like the numbers above might be off, and the threshold I am seeing now is different. Will need to re-evaluate. Lesson: do not do mathematic analysis at 1 AM.
2 Likes
Replying to myself: it looks like the numbers we looked at yesterday with @DJSlanr were off due to a misconfiguration. After carefully reviewing data, I concluded that:
- the threshold for 1/3 rate is correctly set at 26.666ms for 75 Hz.
- the likely issue that kicks people out of 1/2 and into 1/3 “too soon” is not the frame timing being incorrect, but it sounds like the heuristic for choosing the smart smoothing rate is too aggressive.
It looks like only a single spike in frame times may cause smart smoothing to kick out of 1/2 and into 1/3, and then it takes many frames to recover from it. Perhaps it would be better to have a low-pass filter to “forget” about a few spikes instead.
I will provide some plots to support these observations, which hopefully will be less error-prone than the rough tests we did with DJSlanr last night.
1 Like
Apparently there was a “master reference variable” as well and my testing was simply skewed. I apologize for posting prematurely out of excitement. We will continue testing with an intent to improve motion smoothing across all modes.
2 Likes
This is how I explain the current issue that @DJSlanr is seeing:
pi_service seems to aggressively get out of 1/2 rate and into 1/3 rate upon spikes above the 1/2 frame rate threshold, while in fact the majority of frames are within acceptable timings for 1/2 rate.
What @DJSlanr played with earlier was clamping the frame times reported to pi_service to 26.666ms (and not 22.222ms as we previously miscalulated). This effectively completely cut-off all spikes, which forced to remain in 1/2, but it also had the negative effect to stay out of 1/3 even when falling back to 1/3 would have been appropriate.
The better suggestion here is to perhaps add a low-pass filter to smooth out the frame times reported by the SteamVR driver to pi_service and cut-off those small spikes to avoid the fall over. The length of such filter will determine how robust to frame time variations the heuristic will be. It should probably have a few presets, like “Aggressive” (no filter) or “Gentle” (long filter, perhaps 0.5 frame, ie 18 samples in the 75 Hz example above). In Aggressive, you have the behavior we see today, we often regress to 1/3 even for small glitches, in Gentle, the smoothing would remain in 1/2 for longer, but it might also make transitions to 1/3 more visible. This is a trade-off that I believe users on this thread are asking for.
3 Likes
Ultimately what would be best would be for the 1/3 rate to be completely removed as it’s unusably bad anyway. It looks like absolutely crap. Just getting rid of it completely, or at least allowing it to be disabled, would be fantastic. A game locked at 90/45 with Smart Smoothing turned on runs really nicely. A game with random fluctuations between 90/45 and 90/30 is a nightmare.
The mod I developed and that we’re currently testing with @DJSlanr lets you do that for SteamVR games:
- Disable 1/3 and force it to stay in 1/2
OR - Creates a larger opportunity to stay in 1/2 before entering 1/3
It should also be possible to disable 1/3 and skip directly to no smart smoothing, though I haven’t added that (but it’s easy).
It’s a bit early to say whether the results are good forcing 1/2 when pi_service thinks it’s not appropriate.
7 Likes
Hi, any update on this mod?
Tis the holidays, I’m not working on it right now.
I also want people to manage expectations that it will probably not solve all the problems, but will try 
1 Like
Hey all,
This is still a little bit rough around the edges, but @DJSlanr has been getting good results with the tool.
Hence I’m sharing the first version here:
Right now, we have only created one preset to “skip” the 1/3 mode entirely, so that if you cannot maintain 1/2, you will fallback to no smart smoothing (which I believe is the top ask at this time).
Thanks!
8 Likes
thanks, you and your associates do some really great useful work, it’s really appreciated 
Thank you, and here my associate is @DJSlanr, thanks to him for bringing his perspective and iterating with me.
Hopefully this version gives good results for others too! Looking forward to hearing some feedback!
3 Likes
Is this only for SteamVR? Does it work with OpenComposite?
I’ll be giving this a try soonish (hopefully this weekend). I’m not sure though, that disabling smart-smoothing if it drops below 1/2 rate is what is desired. The way it used to work is it would keep producing the frames at a rate of 1 generated frame for every real frame, not switch on and off. Smart Smoothing would only turn off if you could actually hit your refresh rate. In 1/2 rate scenarios; Lets say you dropped to 40fps for a few seconds; Smart Smoothing would generate 40 fake frames, one for each real frame, giving you 80 frames, and would then give you 45+45 again as soon as it could do so. Disabling and enabling Smart Smoothing altogether if you ever drop below 90hz/45fps sounds really jarring? (I realize that’s not a common scenario, as I expect most of us try to tune our game performance so we never, ever, drop below whatever the appropriate floor is (typically 45 in 90/45 mode. Regardless, it’s certainly possible that momentary spikes could cause a title to drop below 45fps, which, if I’m reading things correctly, will disable smoothing completely for a bit.)