Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
I don't understand, why would there be any extra latency with v-synch on when frame rates drop below the refresh rate? Not really an issue I've dealt with however since going to 120 Hz monitors.
Because then you have to wait until the next vsync.
I think you enable triple buffering to overcome those drawbacks of vsync IIRC.
Hmm, interesting I didn't realize v-sync/triple buffering added to input lag?? Is that true?
what are you using to enable triple buffering?I've always heard that there is less input lag with triple buffering over regular vsync. The lag I notice the easiest is cursor lag in menu's in certain titles with regular vsync. Definitely lag seems to vary quite a bit between titles, but I hate screen tearing (that also seems to vary between titles). I always run triple buffering and never notice the input lag but have noticed it with regular vsync before.
Not true. With double buffering and vsync, the lag is up to 16.6 ms, but that's only if the frametime is 0 ms, which is unrealistic. If the frametime is 10 ms, the lag is 6.6 ms.yeah V-sync = 16.6 ms added input lag
triple buffering = 33.2 ms added input lag
what are you using to enable triple buffering?
Suppose I don't mind the framerate being capped at 60 fps but I do mind the extra latency if it dips below. Is it possible to use vsync only if a new frame was displayed at or after the last vsync?
How about just capping the framerate at 60FPS? There's been a lot of talk about how doing that improves things with or without Vsync on, and something about Nvidia adding an FPS limiter to their drivers soon.
that would not actually stop a lot of the tearing. it would be nice to help smooth out the framerate though.This would be even better.
If that's the goal, just enable normal vsync.that would not actually stop a lot of the tearing. it would be nice to help smooth out the framerate though.
lol, what? have you completely missed all of the other comments about vsync having its own set of issues? you have to take it on a game by game basis as using vsync can result in very crappy performance and framerate fluctuations.If that's the goal, just enable normal vsync.
You can't avoid tearing without vsync.lol, what? have you completely missed all of the other comments about vsync having its own set of issues? you have to take it on a game by game basis as using vsync can result in very crappy performance and framerate fluctuations.
yeah V-sync = 16.6 ms added input lag
triple buffering = 33.2 ms added input lag
if its an online FPS game i would not run either due to the cost in input lag. if your playing single player then by all means run it whatever way makes the game look the best to you
I am aware of that but sometimes tearing is better than the issues vsync can bring with it. again I just take it on a game by game basis.You can't avoid tearing without vsync.
It's actually worse than that. Not only does it add up to another frame time worth of input lag, the frame which would prompt an input is already up to a full frame behind. So with Vsync, you get up to 33ms of additional lag, Triple buffering gives you up to 66ms
Triple Buffering doesn't mean what you think it means.
http://www.anandtech.com/show/2794/2
^^
Take a look at how the buffers work in triple buffering. There is a reason why it actually decreases input lag.
Editting to add the TLDR version:
"In other words, with triple buffering we get the same high actual performance and similar decreased input lag of a vsync disabled setup while achieving the visual quality and smoothness of leaving vsync enabled."
Triple Buffering doesn't mean what you think it means.
http://www.anandtech.com/show/2794/2
^^
Take a look at how the buffers work in triple buffering. There is a reason why it actually decreases input lag.
Editting to add the TLDR version:
"In other words, with triple buffering we get the same high actual performance and similar decreased input lag of a vsync disabled setup while achieving the visual quality and smoothness of leaving vsync enabled."
Unfortunately there is no such animal as "no input lag". Not even with a CRT display is this achievable. Vertical sync is only one of many contributors to the lag time between you making some sort of input and the result of that input being reflected on your display.Perhaps this is true with some game I've never heard of, or for people who can't tell the difference between no input lag & input lag.
Not true. With double buffering and vsync, the lag is up to 16.6 ms, but that's only if the frametime is 0 ms, which is unrealistic. If the frametime is 10 ms, the lag is 6.6 ms.
For input lag reduction in the general case, we recommend disabling vsync. For NVIDIA card owners running OpenGL games, forcing triple buffering in the driver will provide a better visual experience with no tearing and will always start rendering the same frame that would start rendering with vsync disabled. Only input latency after the time we would see a tear in the frame would be longer, and this by less than a full frame of latency.
Unfortunately, all other implementations that call themselves triple buffering are actually one frame flip queues at this point. One frame render ahead is fine at framerates lower than the monitor refresh, but if the framerate ever goes past refresh you will experience much more input lag than with vsync alone. For everyone without multiGPU soluitons, we recommend setting flip queue or max pre-rendered frames to either 1 or 0. Set it to 1 if framerate is always less than monitor refresh and set it to 0 if framerate is always greater than or equal to monitor refresh. If it goes back and forth, only NVIDIA's OpenGL triple buffering will provide the best of both worlds without tearing and will further reduce input lag in high framerate situations.
Improperly handling vsync (enabling or disabling a 1 frame flip queue at the wrong time) can degrade performance by at least one additional whole frame. But with multiGPU options, we really don't have a choice. With more than one GPU in the system, you will want to leave maximum pre-rendered frames set to the default of 3 and allow the driver to handle everything. Input lag with multiGPU systems is something we will want to explore at a later time.
That's not right at all. Vsync is not a fixed 16.7 ms latency.
That's not right at all. Vsync is not a fixed 16.7 ms latency.
I'm not sure how a game is able to mess up tripple buffering, but I guess some do.
It's mostly just a matter of getting used to it. Assuming you're not one of the 0.1% still rocking a CRT, you've probably done it once already...As for someone like me, V-Sync can go die in a corner. I can't use it in any game period due to the input lag it creates
The developers of D3Doverride warned against that input lag article on Anandtech stating that the writter didn't really have much of an idea about how d3dprogramming works. (And that is the motive why D3DOverride's forced triple buffering does work)
BFG10K said:Vsync causes input lag because the rendering system has to stall if both buffers are full but no refresh cycle is currently available. In theory triple buffering solves this problem because it allows the rendering to continue at the expense of dropped frames, but in practice I?ve found it can make the lag worse.
Sora said:This is because OpenGL's form of triplebuffering can drop the third frame if its not required, where as D3D always displays it.
This does nothing for the double buffering lag under opengl, the only fix for it is still to cap below the refresh rate.
Could you post the link to where they said that? I haven't found it yet.
I did find this thread, though, which contains more discussion on triple buffering:
http://forums.nvidia.com/index.php?showtopic=169911
Wrong again. You render a frame to buffer A, this takes (for example) 10 ms. Then you have to wait 6.7 ms on vsync. Buffer A is sent to the monitor, and you render a frame to buffer B.Ohh that is double buffer vsync, in which you have your frame buffer, and the "back buffer" which cannot be written until it has been sent, and thus yeah a 16.67ms constant lag will be present.
That's easy for the videocard to do, isn't it?The key problem I see is in how you precisely test the framerate to know whether or not you can run a v-sync'ed frame or carry on without.