That’s a great start. Thank you.
2 Likes
I noticed a drop in fps when using the .260 pitool
So I did a little comparative test on a 15-minute session on Assetto Corsa Competizione
I used this same settings for each test :
FW 264
FOV : NORMAL
90 Hz
QUALITY : 1.25
FFR : BALANCED
HAM : ON
SS : OFF
PP OFF
PITOOL 260 > 68 FPS (Average FpsVR)
STEAMVR 132% (Recommended value) > 3676x3024
PITOOL 253 > 81 FPS (Average FpsVR)
STEAMVR 86% (Recommended value) > 3708x3052
I have not done the comparison on other games but for ACC pitool .253 is much more effective.
EDIT :
Pimax 5K+ (203)
Hardware > i9-9900KF / RTX2080Ti
8 Likes
So still 253 for performance on simulators like iRacing and AC.
Why does the new versions need to have this performance hit ?
2 Likes
The crash in Alyx occurred to me with a save game after a steam and Alyx update a while ago… Went to another save game and it worked, so not sure if that is a pitool thing, as I did not update pitool at that time.
But I haven’t tried the 260 yet. (only installed and a quick overview of the change log that is also displayed in pitool)
1 Like
I can recommend 260 for DR2, HLA and Boneworks, the three games I’ve tested. Especially the 144hz mode, I can get the same performance that I used to have with 120hz and 130fov, but in 144hz and 140fov, dirt rally2 looks great with SmartSmoothing on. With HLA and Boneworks I get 139hz with this fov, not bad
1 Like
I developed a crash in Alyx after the latest SVR update yesterday. It occurs in exactly the same spot every time. I switched from Vulkan back to DX11 and the crash went away. Using PT 249 though so not totally relevant but worth a mention.
2 Likes
It was the same for me, my latest save game did not work anymore. I was in the “area” but height seemed off, i could walk a bit back and furth, but the area where I wanted to continue (a jump down) always broke the game. I had to go back a bit further (save game wise) and replay, and everything worked fine - I also think it must have been a SteamVR Update - what ever it did. It was the PiTool 2 Iterations before 260 I believe.
2 Likes
My issue with PiTool is that for some reason if the headset falls over - it is a PITA to restart it and get it functioning again without a computer / headset power down.
It seems PiTool or moreso PiService is very finicky in the order of getting ones headset running. For me it is switch on computer, turn on headset after Windows 10 boot. Then after turning on the headset - start PiTool and play. If it falls over - shut all down and restart. I have tried when the HMD falls over to use the Reboot Headset button in PiTool and also the Restart Service button but to no avail - just screwed images through the headset or blanks.
Would be nice to have this more bullet proof. AKA functional so one doesn’t have to follow a power down and power up again procedure.
That aside - Pitool working fine. 
1 Like
I appeal to the developers:
The question is WHY .253 is faster.
Is this due to a simplified implementation of the algorithms?
More successful allocation of resources?
What did they sacrifice in .253 to achieve such a speed?
Why is all subsequent versions slower? And why can’t developers repeat success?
my hardware is: RTX2080ti + 8700k 5.2ghz 253 still have best fps, any GPU Catalist >0 is not working for me.
9 Likes
Each user has a different GPU and CPU.
Accordingly, different internal delays and processing speeds. Is it really impossible to do an internal mini-test to fine-tune Pimax algorithms in the best way? In my opinion, this is the only way to achieve optimization on all devices.
PS: i mean mini-test inside Pimax drivers for auto-tune delay and speed settings exactly for given GPU/CPU
Interesting . I have also switched from 253 to 260 and receiving almost the same fps In ACC but with different settings than yours. 144hz mode, normal fov , ffr balanced with smart smoothing and average in both PT is 70 fps. Max is 72 fps becouse of SM. (i7 8700k + rtx 2080ti )
5 Likes
Imo, adding the Catalyst option is the most likely culprit.
3 Likes
I heard that this option (catalyst) works on some configurations. That’s why I suggested embedding a test in the Pitool to adjust it to different GPU and CPU.
3 Likes
It is faster because it enables something that pushes past a limit that breaks a decent percentage of configurations. So it’s better for a lucky few, but renders the headset unusable for others.
2 Likes
There isn’t a drop in render quality, it’s the scale in SteamVR. @anon57422158
Are there some specific references to check? Because that would be a massive change, surely. I run PT 2 and SVR 0.25 by default, and this mean retesting using PT 2 and SVR 0.5 etc.
I don’t have PT 259 or 260 yet, but I checked the latest SVR 1.12.5 changelog. If there’s a reference to a scale change, maybe I didn’t understand it:
SteamVR:
- Fixed Vive Pro audio control buttons.
- Fixed render model loading on paths with non-ASCII UTF-8 characters in the path.
- Fixed Windows Mixed Reality controllers missing textures or models.
- Fixed intermittent bug with Vulkan games on AMD where images fail to render in the HMD.
- Fixed status bar icons being stretch on two-line dashboard overlay titles.
- Fixed a rare vrwebhelper crash.
- Fixed a rare bug where production Index HMDs could incorrectly show a “prototype hardware” warning.
SteamVR Dashboard:
- Selecting the Play Area settings used to force chaperone bounds to be visible. Now it does again.
Lighthouse:
- Fix a case where turning on an additional tracked object while playing could lead to the world becoming tilted.
Oculus:
- Fix for application performance activating ASW.
- Improved reporting in the SteamVR mini-perf graph (orange = reprojected frame, yellow = ASW active, red = frame took three or more display intervals).
- Rendering throttled to 10Hz when headset is not worn (before going idle completely).
2 Likes
This is interesting. It says that the recommended rendered resolution advertised by the headset driver changed between versions 253 and 260. SteamVR is recommending basically the same resolution for both versions, which means that your GPU was benched for the same fill rate in both PiTools (as this is the only parameter, which affects the recommended res).
But in order to get to the same res at the end for each version of PiTool SteamVR has to use different supersampling setting. It can oversample in v260, which means the original res, recommended by PiTool is lower than the final one, while in v253 it has to undersample the PiTool res (which means the original PiTool res was higher).
The possible reasons are:
-
Pimax changed the recommended rendered resolution the headset driver reports to SteamVR for particular Render Quality setting. Verifying it should be easy by setting SteamVR supersampling manually to 100% and checking the reported final res.
-
PiTool Render Quality setting does not work correctly in the v260 PiTool.
-
Change in SteamVR is less likely, because SteamVR alone is consistent in calculating the same final res, regardless the PiTool version.
8 Likes
Yes, it is interesting. I don’t want to install any tool more often than necessary, so I’m not going to try this, but I hope someone else will. I look forward to their observations.
1 Like
It is not the render resolution change that makes the new versions perform worse than 253. It changes in every pitool version and that messes with the UI screen in iRacing. So I have to manually match the resolution in Steam VR each time I install a new pitool. 254 is still the fastest for simulation but that can only be run for less then an hour because of the crash.
3 Likes
Agree with last comments. 253 is much faster than 260 and, in addition, has 64hz option. For me, 144hz is unusable for now due to its annoying ghosting (203 series here). Catalyst doesn´t seems to work well for me, since the graphics in game seems to be much unstable when it´s set higher than 0. I´m rolling back to 253 right now after 1 week of tests in many games with 260.
In my opinion, Pimax have to fix the crash bug of 254 version, since it´s the smoothest and most performance friendly Pitools version ever made.
4 Likes
that’s why I suggest developers to embed a small test to determine the limits in the driver or pitool, so everything will be adjusted to the current hardware in the best way.
it can be, for example, the “optimize” button in the pitool when the user himself stops third-party programs for the correct test. Or maybe an automatic procedure. (but then other programs occupying the GPU / CPU may interfere with the correct definition)
5 Likes