Mysterious resolution changes (Solved)

While I keep the same pitool at 2, base SteamVR SS 20%, per App SS 250% (assetto corsa), no advanced supersampling filter, which makes a total SteamSS of 50% and a total SS of 50x400=200%,
this leads to a resolution that is not the same everyday.
One day it was 4828x3216, the other day it’s 4828x3116, and today it gives me 4828 x 2980.
In clear, the first number stays the same, but the second number keep changing and I have no idea why since I don’t change anything in the game.
I made a test with FPSVR to detect the resolution in game, and it gives the same resolutions I just stated.
Any idea?

Edit: mystery solved
it turns out it comes from the different screen vertical offset value I used in pitool that changes the vertical resolution.
with vertical offset at 0 Left / -0.5 Right I get 4828 x 2980
with vertical offset at -5.5 Left / -6 Right I get 4828 x 3344
with vertical offset at +5.5 Left / -6 Right I get 4828 x 3496

putting both vertical offset to the minimum -10 or maximum +10 gives me a vertical resolution of 3608
with both at zero vertical offset it gives me 2980
So, using the vertical offset in pitool only to raise or lower the virtual screen can lead up to a 21% maximum increase of vertical resolution. good to know in term of performances impact !

1 Like

Looks like steam is lowering some settings for you.
I’m not an expert on config files.


SteamVR has a habit of changing config files with each time it runs.

Check out the guide how to get the resolution you want: How To Make Your Pimax Image/Picture/Screen Clear/Crisp (Increase Clarity)

The upcoming Pimax Experience (PiTool replacement as far as I know) should be fixing this forever, so think of this as a temporary solution.


I guess it does, but this is weird.
I know this thread, and often edit the config file by copy/past this :
“GpuSpeed” : {
“gpuSpeed0” : 15000,
“gpuSpeed1” : 15000,
“gpuSpeed2” : 15000,
“gpuSpeed3” : 15000,
“gpuSpeed4” : 15000,
“gpuSpeed5” : 15000,
“gpuSpeed6” : 15000,
“gpuSpeed7” : 15000,
“gpuSpeed8” : 15000,
“gpuSpeed9” : 15000,
“gpuSpeedCount” : 10,
“gpuSpeedDriver” : “”,
“gpuSpeedHorsepower” : 15000,
“gpuSpeedRenderTargetScale” : 1.5,

I also make sure this line is there :
“maxRecommendedResolution” : 16384,

but those changes for no reason are nuts.

1 Like

Well, there sure is some reason for it, the SteamVR gods just didn’t find it worth their time to let us in on those arcane secrets.
Soon it won’t matter anymore.

1 Like

That does sound peculiar… You write that you change nothing in the game; What about in Pitool?
-No changes at all to FOV or Parallel projections mode (both of which would alter the target resolution and aspect ratio)?

It sounds like something could result in different resolutions, which are then capped at 4828, as if your custom maxRecommendedResolution hasn’t “taken hold”, and ends up 4828 instead of 16384, although even then you should, unless something has changed, see the uncapped numbers under the SteamVR settings sliders. (EDIT: I believe I’ve seen that 4828 number before… I wonder whether there could be some place where stuff on top of a 2.0 PiQuality could overflow a signed int16, or something… :P)

In the SteamVR status panel menu, there is a “Developer” section, that among other things has a separate settings window, from which you can do a few things, including checking your settings path.

(I assume any settings in one’s AppData hierarchy will still override that, though, so that you begin with “default.vrsettings”; Substitute any diverging personal setting for the machine, from the same directory as the default; And after that substitute further personal preferences, chosen by the currently logged in user…)

As for the compositor render target scale, which you are forcing to a high value, by spoofing inflated numbers into the gpuSpeed benchmark queue, there is now a four-state: “Overlay Render Quality” setting in the “Video” section, but I have no idea what that does, exactly. :stuck_out_tongue:

the only thing I keep changing a lot in pitool is the IPD offset because I experiment a lot with IPD.
during my experimentations, I also changer the vertical offset.
The 4828 doesn’t sound like a limitation to me, since the same phenomenon is happening if I only take in account the global SteamVR SS and pitool (that I keep at 2) : the second number (vertical pixels) is not the same from a day to another while I keep it at 20% and I didn’t play other games the last few days.
anyway, pitool at 2 is equal to a 400% SS
so 20%x250%x400% = 200% total resolution multiplier
4828x2980 = 14 387 440 pixels
it’s 200% of 7 193 720
if we take the pure panel resolution in large mode, without PP (I don’t use it for AC), 2650 x 1440 it gives 3 816 000 pixels.
I know the headset needs more pixels for wrapping, I don’t know how much, but with 7 193 720 I guess it has more than enough, all the more so as with a 200% total multiplier, I give it twice that amount.
So I 'm not sure there’s a limitation here, cause I would have think a 200% total supersampling leaded to less pixels than 14 387 720 pixels which is between 3 and 4 times the native number of pixels each panel has.
the other reason I don’t think this 4828 is not a limitation, is that I’m pretty sure if I increase the SS, I will get more pixels for the horizontal number.
what I just don’t understand is the second number changing for no reason

There are two possible reasons for the values to be different:

  1. PiTool is reporting different FOV, which will lead to the change in resolution, according to the “pixel density”.
  2. PiTool is reporting different nominal resolution.

You can check the exact configuration (recommended resolution advertised by OpenVR and the FOV) by using hmdq ( to see what was the reason.


I’ve noticed that changing the vertical offset will change the height of the render window in SteamVR (in the past).

I haven’t checked this in the last few months, but there’s a good chance this hasn’t changed. I think that PiTool can’t directly change the vertical offset in SteamVR, so it increases the viewport height and clips what isn’t needed from the data sent to the headset.


I just checked:
with vertical offset at 0 Left / -0.5 Right I get 4828 x 2980
with vertical offset at -5.5 Left / -6 Right I get 4828 x 3344

Mystery solved


SteamVR cannot change the resolution or the FOV without a restart. It can however change the eye/camera geometry on the fly.

So changing the vertical position of the eye/camera is something it actually can do without a problem.

Not really :wink:.

I edited my main original post with more numbers.
the vertical offset set to it’s minimum or maximum for both eyes leads to a 21% increase of the vertical resolution. (after a steamVR restart)
I was looking for an explanation of why the second number was changing, and it looks like I found it :wink:
now the question is : does messing with the vertical offset can lead to a impact on performance ?

1 Like

Risa2000 I have an additional question for you. what exactly does advanced supersampling filtering in steamVR ?
when I started to realize the second number was changing I suspected it was because I turned ASF off, so I thought ASF was adding some pixels to the resolution, but since it’s not that, what does it do and what is its impact on performance?

Well, that settles it, then. :slight_smile:
It was the fact that only the vertical count otherwise changed, that made me suspect a limiter. :7

Unticking it makes SteamVR revert to a different sampling algorithm, that was used in older SteamVR versions. It should have an infinitessimal effect on performance.

I frankly believed changing it should only have any effect when one let SteamVR do the distortion correction, which is only the case with the Vive and Index ranges – with other headsets, the function is deferred to its equivalent in piserver/oculus runtime/whatever; But since people report seeing a difference with such “non-SteamVR-native” headsets, I suppose something more could be going on in the compositor…

Allowing ASF will produce a smoother image at high supersampling levels, for good and for bad; There will be less aliasing, but small detail may consequently become somewhat blurred.

The option was instated as a concession to an outcry from many users, myself included, who appreciate a crisp image, even if that means swallowing some jaggies, and considered the new, “advanced” filter a downgrade.

1 Like