Lack of G-Sync on Oculus Rift

[Chief Blur Buster]

Why does DK2 have to be multisync for us to be able the use the "trick" you described? Can't we do that at specifically 75Hz? Or did you mean setting the max fps and Hz at slightly below the FPS I'm expected to get from a certain game so that the VSYNC buffer doesn't pile up?

Oh, you are right: I was thinking of the trick for GSYNC. Many CS:GO players who hate tearing have said that latency is lower when you use in-game frame rate caps at a rate slightly lower than VSYNC maximum frame rates.

And if that is so, wouldn't that be the holy grail for eliminating all the screen tearing and input lag problems on all games without the need for G-SYNC? I'm sure I'm missing something.

Capped-out VSYNC long has been the holy grail if it weren't for input lag issues. Old 8bit games like Super Mario Brothers and Street Fighter used to synchronize to the blanking interval, and everything was super silky smooth with low lag. But then came 3D rendering architectures, with its frame buffering necessities.

VSYNC ON combined with frame rate capping lowers latency but not quite to the levels of GSYNC or VSYNC OFF. It is good for non-GSYNC owners that really hate tearing but do not want the large input lag addition it can create.

And that is disregarding the fact that there are huge fps variation in most games.

That is very correct. VSYNC ON is only stutterfree if you do framerate=refreshrate! and that is precisely the situation where buffers begins to pile up and add input lag, as the game finishes rendering but cannot present the frame right away. Capping 1 or 2fps below refresh rate adds back some microstutters.

[Blue_Ninja0]

Thanks for all those enlightening answers!

Oh yes, I remember the times of butter-smooth scrolling in 2D games (even though I'm european and we had to suffer severely from the PAL 50Hz stuttering problem). We have regressed so much in regards to motion smoothness since then.

So, in the end variable refresh rates won't be a reality in Oculus Rift in the foreseeable future. My question now is: how effective are higher than 60Hz refresh rates to at least reduce screen tearing? I know it's not possible to fully eliminate it, but say, if Oculus reaches 90Hz on the consumer version, will that be acceptable?

Also, am I correct to say that a 120Hz display VS a 60Hz does effectively half the input lag incurred by Vsync? If so, maybe using Oculus with Vsync can be feasible without input lag nausea.

[RealNC]

My question now is: how effective are higher than 60Hz refresh rates to at least reduce screen tearing?

A higher refresh affects the count and positions of the tearing lines and the rate at which they move upwards/downwards on the screen. So it doesn't help much, really. Going from 60Hz to 120Hz will result in halving the average tearing lines of each frame, but I don't think it looks like "less tearing". It's just as annoying (not better and not worse.)

Also, am I correct to say that a 120Hz display VS a 60Hz does effectively half the input lag incurred by Vsync?

Yes, that is correct, since it halves the frame latency (time the GPU must wait before sending the next frame) from 16.7ms to 8.3ms. Of course, the total input latency is much higher than that and there's no guarantee that a 120Hz monitor will have less input lag than a 60Hz one since VSync is only one of the causes of input lag.

[Blue_Ninja0]

Damn it! I guess I'll have to continue suffering with Vsync input lag then. I hope that 16.7ms to 8.3ms is a big difference to make it almost imperceptible. And yes, I know it's just a portion of the whole input lag chain.

[Chief Blur Buster]

A higher refresh affects the count and positions of the tearing lines and the rate at which they move upwards/downwards on the screen. So it doesn't help much, really. Going from 60Hz to 120Hz will result in halving the average tearing lines of each frame, but I don't think it looks like "less tearing". It's just as annoying (not better and not worse.)

It actually is a matter of perception. It's less visible to some people. For example, 60fps at 120Hz has about half the tearing visibility time of 60fps at 60Hz. But at 120fps @ 120Hz, you get twice as many tearlines at half the visibility time. It appears that some people are sensitive to this, and some people see a lot less tearing visibility.

[Chief Blur Buster]

Damn it! I guess I'll have to continue suffering with Vsync input lag then. I hope that 16.7ms to 8.3ms is a big difference to make it almost imperceptible. And yes, I know it's just a portion of the whole input lag chain.

Doing the below will make VSYNC ON input lag much more tolerable, if you need to use VSYNC ON:
-- Using 120Hz+ instead of 60Hz
-- Set maximum pre-rendered frames to 1
-- Set a frame rate cap very slightly below refresh rate.

Setting frame rate cap below refresh rate, prevents pre-rendered frames pileup from creating input lag. For a source engine game, fps_max 119 at 120fps often works well to have input-lag-reduced VSYNC ON, but can have one microstutter per second. If this is still too much for you, you could theoretically create a custom refresh rate (via NVIDIA "Create Custom Resolution...", or via ToastyX CRU) of 120.1Hz or 120.2Hz and use a fps_max 120, so you only get one microstutter every few seconds.

Some CS:GO players who use VSYNC ON report that the input lag gets reduced.

[Blue_Ninja0]

Thanks for the tips!

I have thought about using those solutions. I never heard about the 120.1Hz though, that's a good idea.
Maximum pre-rendered frames is not an available option on SLI systems though.

On this inevitability of Oculus not being able to use variable refresh rates another question arose on my mind:
Is the implementation of the variable refresh rate strobing algorithm on G-Sync just a matter of driver/firmware update? Or is there any technical limitation that would require a new module/monitor?

Also, assuming the remote possibility of the final consumer version of Oculus somehow having implemented Display Port 1.3 (which will be ratified by then hopefully), what are the chances they'll allow variable refresh strobing? The math and technical limitations to implement it aren't that overly complex. Providing graphics cards vendors adopt DP1.3's variable framerate of course, which AMD certainly will with FreeSync.

[RealNC]

Setting frame rate cap below refresh rate, prevents pre-rendered frames pileup from creating input lag. For a source engine game, fps_max 119 at 120fps often works well to have input-lag-reduced VSYNC ON, but can have one microstutter per second. If this is still too much for you, you could theoretically create a custom refresh rate (via NVIDIA "Create Custom Resolution...", or via ToastyX CRU) of 120.1Hz or 120.2Hz and use a fps_max 120, so you only get one microstutter every few seconds.

You don't need to do that since, luckily, the Source engine supports floating point numbers as a framecap. You can just use "fpx_max 119.7" (or 119.9999 even) though if it's too close to the actual refresh rate, the input lag reducing effect disappears.

[Chief Blur Buster]

Setting frame rate cap below refresh rate, prevents pre-rendered frames pileup from creating input lag. For a source engine game, fps_max 119 at 120fps often works well to have input-lag-reduced VSYNC ON, but can have one microstutter per second. If this is still too much for you, you could theoretically create a custom refresh rate (via NVIDIA "Create Custom Resolution...", or via ToastyX CRU) of 120.1Hz or 120.2Hz and use a fps_max 120, so you only get one microstutter every few seconds.

You don't need to do that since, luckily, the Source engine supports floating point numbers as a framecap. You can just use "fpx_max 119.7" (or 119.9999 even) though if it's too close to the actual refresh rate, the input lag reducing effect disappears.

Even Chief Blur Buster learns something new! Tanks for the tip!