[stormy]

Hi all,

I did some research into this and looked at options in fbconfig, but I can't seem to find a way. My graphics card is an XVR-600. In case some people don't know what I mean, on apple macs it's called 'beam sync', in other places it's called 'vertical synchronization' When enabled it sync's every frame with the monitor refresh to reduce/stop screen tearing, but this has a detrimental effect on performance. 'Back in the day' it was always common-place to disable vsync to make game performance better on windows machines.

Thanks,

[weblacky]

The correct "old-school" answer to your question is: "triple buffering", these days that's been modified into "adaptive refresh" to meet v-sync on monitors OVER 60 Hz, with only v-sync disabled for UNDER 60 FPS performance on 60 Hz monitors.

I don't know if you've used NVIDIA cards under Solaris (that's the only info I can openly find). But look up triple buffering as your answer to locking 60 FPS without tearing WHILE having lower input lag in a game due to "missing deadlines" on the next frame.

For the card you have, the install guide only openly talks about double buffering...nothing else..perhaps there is a hack or ENV variable for this stuff?

All triple buffering does is allow the graphics card to work 2 frames ahead of you, if it MEETS the next deadline (2 frames out) that's what gets displayed, if it misses the deadline for the third frame, it just shows the next frame only.

Cheers.

[stormy]

Just to clarify triple buffering does allow the FPS to be 'unlocked' while keeping vsync enabled (you cannot disable vsync with triple buffering enabled) so it does have it's advantages. But it does add extra lag and requires more framebuffer memory. If I had a choice between enabling triple buffer or running double buffer with vsync disabled, it'd be double buffer with vsync disabled.

But yes another option to consider if I cannot find out how to disable vsync, cheers.

[weblacky]

Here’s a good modern explanation from double to triple to adaptive to free/g sync: https://www.hardwaretimes.com/what-is-v-...on-or-off/

Nvidia drivers call it v-blank, but it’s what’s being talked about.

This article suggest less and not more lag, so I’m unsure where you get more lag from?

Unless what you mean is more lag due to a “busy” computer because you actually do not have the resources to “uncork the GPU” without also maxing/stressing CPU which falls behind on its workload. In that case the sync was helping you keep a performant system and the idea of increasing performance in this manner wasn’t the appropriate choice.

The info I came across seems to imply that you only do this if you’re GPU bound and clearly not CPU bound so you are doing something that has demonstrated you can ceiling smash the GPU without your CPU resources going bananas and running wild.

For a known OpenGL app this could be done, but a game might have too much environmental update or other management entangled in the drawing code areas that it brings other items along for the ride when frame rate is increased alone.

[stormy]

I just know from years of being a pc game enthusiast, and from the early years of Nvidia Vs 3dfx etc. It's well known that triple buffering adds significant output latency. Exactly because there is a larger buffer & the added affect of vsync, you have frame buffers you're waiting to be drawn and also waiting for the monitor refresh, it all adds up.

Fyi this is nothing to do with gsync which is a completely different technology, years between them. Gsync has a chip inside the monitor that communicates back to the GPU to make sure everything can stay in sync without lag, where as previously it was only a one way communication in that regard.

[weblacky]

The effect you’re trying to achieve is exactly the same, as suggested by the article I referenced. You want a higher game event processing rate that is still linked to monitor refresh rate to prevent tearing. Unless I misunderstood your underlying question on your original post.


Whatever sync to blank/refresh you’re using you either get a few frames ahead of the (literal) next frame in time (as game play has progressed past that old frame) and has made the display deadline to prevent tearing, or the program/system cannot meet a further deadline to still get more than a single frame of progress between monitor refresh states.

And I’m still not understanding where you get the claim of more lag from. Assuming you’re system isn’t missing deadlines in event/Environment updates, the input and reaction of events is tied to the result on screen (less multiplayer where it’s another player’s reaction).

So the more frames you “get ahead” in the simulation the better “timed” or updated you are to matching the game events to the screen.

I’d imagine any lag is the missed deadline of using an old frame with recent input. By having the latest frame you have a better chance of getting more accurate input response and game reaction. I thought that most game designs linked the event processing interval to a form of environment refresh. So the environment is re-drawn just in the display buffer every time event processing has updated the game view. By not artificially constraining the event processing to monitor refresh interval you could essentially use the graphics card (if game is designed as such) to process faster which doesn’t translate into a higher frame rate due to the monitor refresh lock but instead translates into a smaller event processing and scene rendering interval.

In other words, I assume on a performant system that any lag would be the game‘s simulation is ahead of its display. If the display does not yet contain the reactions of your input I would consider that to be lag. Even if you’re bound by the screen refresh rate if the environment’s event processing can keep up with input than the assumption is what’s drawn on your screen is accurate for the simulations current inputs.

In this way it’s not that you have a higher frames per second it’s that there’s a higher update interval or more update intervals per interval of screen refresh. Which I assume increases the chances of the game processing an input and displaying its reaction at the next screen refresh.

[stormy]

I mean, you're trying to work all this out theoretically and conceptually, I'm just talking from experience. Triple buffering causes lag between a users input and what they see on screen. I know it's not exactly a 'credential' and may be a bit cringe but I used to be a 'pro gamer' and not just in any old game, Quake, the highest 'twitch/reaction' type game ever in esports. So I know my lag, I have thousands of hours invested in testing.

Zero lag: double buffered & no vsync
Low lag: double buffered & vsync (lag only occurs when the FPS cannot keep up with the monitor refresh)
high lag: triple buffered & vsync (consistant in it's response time due to the extra buffer involved)

Anyway this is all besides the point. All I wanted was to work out how to disable vsync in Solaris 10 ;D