• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Dynamic Vsync

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.

But with triple buffer vsync, which Fito got wrong on page 1 of this thread, you get rid of that input lag feel, because you can write a second back buffer even if the first one hasn't been sent to the monitor in its entirety.

Heck if Fito would have read the article he linked he would have seen that the extra 16-33ms input lag they talk about refers to displays who try to do "smart" postprocessing (another great reason to use digital inputs and turn all monitor//tv based postprocessing off!), and that they say that the best combo is triple buffering with a 120hz monitor (which indeed, for twitch shooters is sweet!)

And edit to add:
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)

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

This is what you seek:
http://forums.guru3d.com/showthread.php?t=315577

Q: Does anybody know if the triple buffering method implemented by by D3Doverrider uses a larger flip queue size (Increasing input lag.) or does it display the newest back buffer and discards any buffered frames that are not needed. (Reducing input lag.) I've always assumed that it was the first due to various articles and benchmarks on the web but a debate sparked on these very forums in the ATI driver section could do with this being answered.

A (from Unwinder who programs D3Doverrider): Of course the first one. That article about TB gave wrong concepts and understanding of TB triple nature and principles. Direct3D gives applications no way to manipulate swap chain that way, any D3D application using TB is always using the first implementation.
 
My understanding is very basic indeed, but what would the point be at all of triple buffering if the old frame wasn't discarded if a new one was in the other buffer? I suppose the advantage would be if your framerate drops below your refresh your card will continue to render in the other buffer?
 
There is a lot of misinformation in this thread.

Firstly, your monitor will only display new information as often as its refresh rate allows. If you have a 60 Hz monitor, then you will only see 60 fps. The extra frames your gpu renders will be discarded partly or completely. You get tearing when they are partially discarded.

Best case scenario for input lag will be that it is between your refresh rate and the time it takes your gpu to draw a frame, even with v-sync and triple buffering off.

I never use v-sync without triple buffering so I can't say how bad it is from experience, but I believe it would add additional delay based on your refresh rate. At 60 Hz this will be about 17 ms.

My understanding of triple buffering is limited, but if properly implemented it should allow input lag to be reduced back to what it would be without v-sync. I believe it allows the newest complete frame the be displayed every time the monitor is refreshed. Frames would only be lost if you are rendering faster than the refresh rate, and you wouldn't have seen those in their entirety anyway.
 
All i do to reduce input lag is use a program called "dxtory" and limit my fps to 59. I never get any tearing and I notice no lag or very little lag in my games compared to when vsync is on. Input lag is very important for street fighter 4, and I can get all my links down with vsync on capped at 59 fps.
 
All i do to reduce input lag is use a program called "dxtory" and limit my fps to 59. I never get any tearing and I notice no lag or very little lag in my games compared to when vsync is on. Input lag is very important for street fighter 4, and I can get all my links down with vsync on capped at 59 fps.
if you are claiming that you get no tearing with vsync off just because you are capped at 59 fps then you are crazy. games can tear at ANY framerate. in fact the games with low framerates are usually the ones that I notice more tearing in. something like CSS though, I see very little tearing while getting insanely high framerates.
 
I've seen a lot of people mention dxtory now, I know it can help with microstutter to limit the framerate like that. Myself, personally, I just cannot stand screen tearing, I just absolutely loath it. I always force triple buffering, I'm sure there is more input lag than w/o any vsync, and I suspect it's similar to regular vsync. At least there aren't jarring framerate drops, and a nice image.

I guess I am lucky in that I don't have the reflexes/eyesight so amazing that 10 ms of extra lag is noticeable. I know I can tell the difference when I play a game on my tv, there is definitely input lag going on, but with triple buffering on my monitor I just have never seen it.
 
Playing bad company 2 is a game that seems to have input lag when I enable vsync, I used to keep vsync on until I turned it off to see how high above 60 my 6970 would get etc., and noticed an improvement in my reflex ability (I would use an m14 and with vsync on, aiming ahead of the target in close combat after every shot didnt seem to contact, with vsync off the shots would hit more often after readjustment)

Sound like this matches the topic?

Also I was researching what to replace Fraps with and found this good video yes. that is the wadsworth constant
 
Last edited:
You can't avoid tearing without vsync.

Not entirely true, Tearing occurs when your fps are higher than your screen refresh rate. You can avoid tearing by buying a monitor with a higher refresh rate. My 120hz setup has no tearing due to fps issues because I'm in eyefinity and am not exceeding 120fps. I think it'll be a long time before I have to cap my fps to 120 to limit my tearing due to excess fps being dropped etc...

This is a huge issue because too many people aren't seeing the light and enjoying true 120hz poling rate smoothness. Granted the fact that most panels are TN keep people away but good things are in the works.
 
Not entirely true, Tearing occurs when your fps are higher than your screen refresh rate.

I don't know a lot about the technical issues, but I can say this is not true. I notice tearing the most on games that run significantly below the 60fps that would match my 60Hz monitor. Crysis had absolutely terrible tearing and it would never get anywhere near 60fps, it was always floating around 30fps.
 
I don't know a lot about the technical issues, but I can say this is not true. I notice tearing the most on games that run significantly below the 60fps that would match my 60Hz monitor. Crysis had absolutely terrible tearing and it would never get anywhere near 60fps, it was always floating around 30fps.

Never had or heard of that problem. What setup were you playing with? Eyefinity? How were monitor/s connected?
 
Not entirely true, Tearing occurs when your fps are higher than your screen refresh rate. You can avoid tearing by buying a monitor with a higher refresh rate. My 120hz setup has no tearing due to fps issues because I'm in eyefinity and am not exceeding 120fps. I think it'll be a long time before I have to cap my fps to 120 to limit my tearing due to excess fps being dropped etc...

This is a huge issue because too many people aren't seeing the light and enjoying true 120hz poling rate smoothness. Granted the fact that most panels are TN keep people away but good things are in the works.
why do people continue to say such nonsense after all this time? AGAIN with vsync off, you can get tearing at ANY framerate and that is a fact. and also AGAIN, it seems that many games with lower framerates seem to tear even more than games with high framerates. thats because framerates can be out of sync well below refresh rate.

Never had or heard of that problem. What setup were you playing with? Eyefinity? How were monitor/s connected?
what Tudz said is exactly right. how you can be a pc gamer and never notice that is beyond me.
 
Last edited:
Never had or heard of that problem. What setup were you playing with? Eyefinity? How were monitor/s connected?

Standard set up, one monitor, through DVI. Run Crysis off an 8800GTS 320mb, 4870 and a GTX460... all well below 60fps and all had tearing. Its one of those games you play every time you install a new card, so I'm pretty positive about it ;) Always end up using vsync.

This is just my non-professional view, so if its wrong feel free to correct me. But to me it would seem like tearing is about frame synchronisation, not framerate. So if you have one frame rendered, the monitor wants the next one in 16.7ms (for 60Hz), if the next frame comes in 10ms (equivalent to 100 frames per second), it came too soon, if it came in 25ms (40frames per second) it came too late. Through in the fact that its not like each frame is rendered in exactly the same time as the last and it creates more problems (one frame might take 20ms, the next frame 30ms, the average is 25, resulting in a framerate of 40fps, but the actual frame timing is different). Vsync forces the frames to be synchronised, so if the refresh rate of your monitor is 60Hz (refreshes every 16.7ms), it forces the game to synchronise its frames 16.7ms apart, or multiples of 16.7ms, so 16.7ms, 33.3ms, 50ms, 66.7ms (60 frames per second, 30fps, 20fps, 15fps), so that the monitor is ready to recieve a frame when the game sends the frame.

Whether you're over or under 60fps for a 60Hz monitor only changes whether the frame comes too late or too early, not whether tearing occurs. Though I can imagine on a 120Hz monitor maybe the effect is less noticable since each frame is displayed for less time.

Again I haven't spent a lot of time researching the matter, so that may be off, but that's what seems most logical to me ;)
 
Last edited:
I never experienced tearing in a scenario where my fps was below my refresh rate and that includes all Crysis Games. I never played them in eyefinity (except for 2) and I only get tearing because of the issue Cayman GPU's have with mismatched connections.

If my fps are above my refresh rate, I can/have gotten tearing that goes away if I enable vsync or use a utility to cap my fps to or below my refresh rate.

Since getting my 120hz displays I have yet to get tearing aside from the mismatched connection on the monitors issue I just mentioned.

If you look up tearing and vsync the very definition that describes why the tearing occurs is in line with what I'm posting. There could be an application or driver issue here or there that defy this logic though. :)
 
Lord_Exodia, that is 100% nonsense. you have to be blind to make such a ridiculous claim. tearing happens when frames are out of sync and that can happen at ANY framerate.

anybody with halfway normal vision can see the tearing here in Metro 2033 at just 25-30 fps. its hard to capture in the video and looks much worse in the actual game but its still clearly noticeable. http://www.youtube.com/watch?v=RkO8U8r2Tf8
 
Last edited:
Lord_Exodia, that is 100% nonsense. you have to be blind to make such a ridiculous claim. tearing happens when frames are out of sync and that can happen at ANY framerate.

anybody with halfway normal vision can see the tearing here in Metro 2033 at just 25-30 fps. its hard to capture in the video and looks much worse in the actual game but its still clearly noticeable. http://www.youtube.com/watch?v=RkO8U8r2Tf8


Guess my frames have been in sync then /shrug

Edit to add, I do see the tearing in that video, I just haven't expereienced that when I played through metro but I was getting over 60 fps constantly.
 
Guess my frames have been in sync then /shrug
I added a vid. there is no chance that you some how get fully synced frames while the rest of us don't though. I too even turned on vsync in Crysis because even at 30-35 fps on my 8600gt the tearing was too bad. you just must not be sensitive at all to tearing is all I can think of.
 
Last edited:
120hz 2233RZ + 120-ish frame limiter works great for weeding out most of the tearing and being very pleasing to the eye. Although I do sort of miss the ludicrously low input lag on my samsung 226BW. Image quality kinda sucks but doesn't bother me.

I own the same monitor as well, 125fps/120hz is a perfect combo, tearring is almost unnoticeable, fuck vsync :D
 
This sucks, I don't like tearing so I always ran vsync. I never knew/noticed extra input lag until now, now that I have looked into it. Now I can definitely see it. I have a 120hz screen, and if I am getting high framerates with vsync off I can live with the small amount of tearing I am able to see. I did start using dxtory to limit my fps at 117, that seems to work pretty well, although dxtory doesn't want to work with MSI afterburner's overlay.

I can pretty much guarantee Lord_Exodia, if you are not running vsync you have screen tearing. You just are not noticing it, which is great, I'm sure different people are more sensitive than others. If your refresh is the same as your fps, everyone can notice the tearing as each sequential frame tears in almost the same exact spot. If your fps does not match your refresh, each frame probably has a tear, but since that tear is in a different spot each frame it is much harder to see.
 
Some engines do react differently to V-Sync though. What games are you noticing lag at 120Hz?

I was just comparing RE5 and Borderlands with vsync on and off. Honestly, the lag is a tiny amount, so small it almost feels like I am imagining a difference, but it's there. I would have no problem getting used to it, but now that I know it's there it bugs me.

Sometimes a guy just needs to stop fiddling with stuff and enjoy the game I guess.
 
Just wanted to mention that controlling fps in BF3 can be excellently accomplished with the console command: Gametime.VariableFps = 60 (or 120). This has got to be the best possible solution as it's internal to the game itself. i.e. BF3.exe does the math for only 60 fps and no more so less cpu congestion and no need to worry about vsync etc. It has been essential for smooth gameplay at the 6046x1080 eyefinity resolution I play at. Without it my fps is still 60 or over but it is not smooth at all, as soon as I enable it everything is fine....

Also, about triple buffering, besides it's other faults I read once that it wont work with crossfire/sli but now I can't remember where??
 
only 2 options to overcome tearing are,

enabling vsync

or having more then 120fps



I personally cannot stand vsync, i'll take tearing anyday over input lag.
 
What, you mean the GTX 680's "adaptive V-Sync"? I'm trying to figure out what the point of it is, so far it seems to be the most useless and gimmicky 'feature' ever conceived.

V-Sync is automatically disabled whenever the framerate drops below the display refresh rate, so for most people (even those with low 60Hz refresh rates) playing modern games, that will be 75%+ of the time looking at torn up shit. Might as well just disable V-Sync altogether.

Secondly, constant V-Sync input lag is bad enough, but having it changing in and out during gameplay is just fucking stupid. It's like having your mouse sensitivity flicking up and down while you're trying to aim.

Then there is the fact that the issue they're trying to fix has already been solved. Haven't they heard of TRIPLE BUFFERING? Maybe instead of inventing this half-baked adaptive v-sync, they should have just added Triple Buffering for D3D in their driver CP and given their cards more than a miserable 2GB of VRAM, because the only downside of triple buffering is that you currently have to use a 3rd party app to force it in the majority of games, and it uses a little bit of extra video memory.

Someone's mad and doesn't understand how V-Sync works. V-Sync is NOT disabled when your framerate drops below the refresh rate of the display. Rather, it chops the framerate in half to give the game time to catch up. So if you drop below 60fps at any point, your framerate snaps to 30fps instantly. It's very jarring.

This technology will disable VSync instantly when your framerate drops below the refresh rate, so you don't get the jarring FPS drop, but you still have the smooth no tearing above the refresh rate. Obviously there isn't going to be any tearing when your framerate is less than the refresh rate of the display, because there aren't extra frames coming out of the GPU before the display can complete one cycle (why you experience tearing).

So in essence, this is exactly how V-Sync should work in a perfect world, and AFAIK it will function almost identically to triple buffering in terms of gameplay experience.
 
I can tell I'm not going to get anywhere productive with this conversation so I'm just going to stop right here...

EDIT: You should really read this: http://hardforum.com/showthread.php?t=928593

There isn't any tearing if your framerate is below the refresh rate of the display. Triple buffering is a solution, but it costs some extra VRAM and it isn't implemented in the vast majority of games. Adaptive V-Sync is something that will work with all games that already support V-Sync and has 0 performance cost... I fail to see how this creates a difference in input lag. When your true framerate is above the refresh rate, your framerate is capped at the refresh rate and you are seeing an additional consecutive frame for each refresh cycle of the display (no input lag). When your framerate falls below, you are getting the frames as they come to the display so again there is no input lag.
 
Last edited:
Actually you didn't ask me to correct you if you're wrong, you called me a fool.

I still believe you're not understanding how V-Sync works at the frame buffer level. I guess we'll just have to wait for [H]'s article on the feature to see how it holds up.
 
In fact, I'll quote directly from the GTX 680 [H] review (emphasis mine):

With Adaptive VSYNC turned on your games will maximize the framerates to your monitors refresh rate, therefore you won't experience tearing. However, if your framerate drops below the refresh rate VSYNC will kick into real-time FPS mode and deliver the real-time FPS being delivered rather than instantly drop to 30 FPS. You won't experience tearing below your refresh rate, and you also won't get large drops in framerate.

I could be wrong, but then [H] is wrong too. Either way I'm very interested to see [H] take a detailed look at this feature now.
 
That first post is wrong on several points (not the least of which is a fundamental misunderstanding of how frames are handled and how tearing happens in the first place).

I still believe you're not understanding how V-Sync works at the frame buffer level.
If you're posting the above link as an accurate description, then you're the one who's mistaken.

There isn't any tearing if your framerate is below the refresh rate of the display.
If there is no explicit synchronisation, there is no guarantee of avoiding tearing.

Triple buffering is a solution, but it costs some extra VRAM and it isn't implemented in the vast majority of games.
The VRAM cost is negligible. And you can force it in just about any game with D3DOverrider.

I fail to see how this creates a difference in input lag.
In order to synchronise, double-buffered VSync has to delay rendering. Delaying rendering means introducing latency. If VSync is constantly switching on and off, then latency is constantly jumping up and down.

I could be wrong, but then [H] is wrong too.
If there is no synchronisation at all below the refresh rate, then [H] is wrong too.
 
That first post is wrong on several points (not the least of which is a fundamental misunderstanding of how frames are handled and how tearing happens in the first place).

Care to explain the true method by which frames are handled and the true source of tearing, then? I'm quoting information which has been deemed reliable by others, the least of which is the official [H] review of the product, so if you have conflicting information please post sources so I can learn where I'm misunderstanding this.

In order to synchronise, double-buffered VSync has to delay rendering.

Can you explain exactly how this causes input latency though? As far as I understand it, when your true framerate is above the refresh rate, there ARE times that the GPU is "delaying" rendering or simply not doing anything (i.e. while waiting for the screen to get to the next refresh cycle so that it can start drawing into the back buffer again).

However I fail to see how this causes input lag. You are still seeing a consecutive stream of frames at 60fps, the maximum possible with a 60Hz display. You see frame 1, you react to it, then you see frame 2 16.67 ms later (1/60Hz), you react to that, then you see frame 3, react to that, etc. It's a stream of consecutive frames drawn at a consistent interval. Frames aren't being skipped or anything. While I could see how you could argue that there is more latency between frames and thus more "input lag" in comparison to a 120Hz display, for example, that's really irrelevant as you are already getting the maximum possible "frame throughput" with a display of that refresh rate.

If this isn't correct then please explain how v-sync causes input lag when the framerate of the GPU is above the refresh rate.

I do understand now how one could see tearing below the refresh rate of the display, though. So then is [H] simply wrong on that point or is there something special about the adaptive-v-sync feature that we don't know about that maintains synchronicity at framerates below the refresh rate?
 
Last edited:
Why not just wait until someone does some testing/in-depth article on it, and then decide whether it is going to be a gimmick or something useful. Right now almost no one has actually seen it in action, so you all are just guessing about what it is going to be like.
 
I'll say it again, if you think the information I have on v-sync is wrong, please explain it yourself (preferrably with sources) so the rest of us can understand. Simply saying, "you are wrong, I am right" really doesn't help anything. :)

EDIT: In any case I am getting one of these cards tomorrow, if I can find something demanding enough to push it into that flip-flop range, I'll try the adaptive v-sync feature and report back on what I experience. :)
 
Care to explain the true method by which frames are handled and the true source of tearing, then?
This is what is stated, implicitly or explicitly, in the first half of that post:
  • Unsynchronised rendering uses a single frame buffer
  • Renderers output the finalised pixels for the displayed frame one by one, left to right, top to bottom
  • Frame transmission to the monitor is instantaneous
  • Tearing happens when frame transmission occurs part-way through the rendering of the current frame
  • Double buffering exists to reduce tearing
  • Double buffering involves the physical copy of frames between front and back buffers
  • Tearing in double-buffered rendering happens when frame transmission occurs part-way through the copy process
Every one of those points is outright nonsense.
  • All 3D rendering is double-buffered.
  • A half-complete frame does not look like half of a complete frame. Renderers build the final image over multiple passes. The intermediate stages may look nothing like the final result. That is why we have double-buffering - so the monitor always has a completed frame to display while the other contains a half-drawn mess.
  • Swapping buffers does not involve a physical copy. It's as simple as flipping a switch; it's instantaneous. The front buffer becomes the back buffer, and the back buffer becomes the front buffer. It's essentially just a renaming.
  • Frame transmission takes a finite amount of time, potentially as much as the entire refresh interval (for a CRT, it's exactly the refresh interval minus the vblank time; on an LCD, it could be anywhere between the refresh interval and the maximum allowed by the DVI/HDMI/DP bandwidth).
  • Tearing occurs when this frame transmission is interrupted by a buffer swap. In between sending pixel n and pixel n+1, it's suddenly retrieving these pixels from the other buffer, and the rest of the frame is drawn from a different image.

Can you explain exactly how this causes input latency though? As far as I understand it, when your true framerate is above the refresh rate, there ARE times that the GPU is "delaying" rendering or simply not doing anything (i.e. while waiting for the screen to get to the next refresh cycle so that it can start drawing into the back buffer again).
It's not just the rendering that's delayed. Generally, your entire game will run in a loop which reads input, updates the game state, and generates output. When you delay the output, you delay the next input as well.

But don't take my word for it. Go play Quake Live for a couple of hours. Then try it with VSync on. If you can't tell the difference, then I guess there's no hope for you :p
 
Last edited:
I don't have in depth theoretical background on it. But you don't need to, to see what happens in practical use. Compare V-sync on and off, using a 60Hz monitor. There is significant lag with it on, regardless of whether your framerate is above/at or below your refresh.

My guess is that the Nvidia engineers do have an in-depth theoretical background on it, and may have actually considered the issues you are raising - and that the actual implementation of Dynamic Vsync might not be happening the way you think it is.

As far as I know, there isn't additional lag added when using a frame rate limiter instead of actual Vsync, so maybe they have figured out a way to implement that and are just calling it Vsync for the sake of convenience, since everyone knows what that means.
 
It'll be interesting to see, but things like AFR Microstutter shake my confidence in the 'Nvidia engineers'.

True enough, but that's not limited to just Nvidia. AMD has microstutter problems also.

I look forward to trying it out when I get my card in a few days.
 
I deal with tearing by making sure the framerate doesn't match the refresh rate because I can't stand the lag (of course in single player games I may not give a damn about the lag and use v-sync). 125fps on 60hz is great, 120fps on 60hz not so much (but better than 60fps/60hz). On my 76,5hz monitor I aim for 60 or below fps (OR 115+ fps). Of course this doesn't get rid of tearing entirely, but it makes it bearable for me: I don't mind a very small amount of tearing if it means no input lag.

I've always had the worst tearing when my framerate and refresh rate are almost equal (like 59, 60, 62fps at 60hz or 75, 76fps at 77hz etc) and I absolutely don't understand people who say they got rid of tearing with a 59fps cap on a 60hz monitor - I can't believe that at all, they must have vsync enabled and think they don't. Vsync is much more than just a framerate cap -in fact it's not a framerate cap per se as it shoots to match the refresh rate which is a slightly fluctuating value- so it can't work. A 60hz refresh rate will always fluctuate slightly for example from 60,0350 to 60,0352hz so it's obvious that a precise 60,00000000fps cap won't do the trick. .

I don't think there can be any better solution than super high refresh rates and framerates. 120hz/120fps is not bad, but 240hz/240fps would be of course even better.
 
Back
Top