It should still remain sync'd. You would have doubled frames. ie; the same image on two refreshes.
That assumes that your in-game framerate is PERFECTLY matched with your monitor's refresh rate though, right? I.e., enabling Vsync on a 60Hz monitor means that there are 'zero' tears when you have a perfect 60fps...but the reality is that the framerate is not a perfect 60fps unless your rig is powerful enough to guarantee 60fps as the absolute minimum rate in all possible scenarios. Thus in reality, the framerate will sometimes be lower, and when it is, say, in the range of 55-59fps, you get the first type of tearing listed in BrightCandle's post.
That assumes that your in-game framerate is PERFECTLY matched with your monitor's refresh rate though, right? I.e., enabling Vsync on a 60Hz monitor means that there are 'zero' tears when you have a perfect 60fps...but the reality is that the framerate is not a perfect 60fps unless your rig is powerful enough to guarantee 60fps as the absolute minimum rate in all possible scenarios. Thus in reality, the framerate will sometimes be lower, and when it is, say, in the range of 55-59fps, you get the first type of tearing listed in BrightCandle's post.
Triple buffering is supposed to help a wee bit with mouse lag as well.
That assumes that your in-game framerate is PERFECTLY matched with your monitor's refresh rate though, right? I.e., enabling Vsync on a 60Hz monitor means that there are 'zero' tears when you have a perfect 60fps...but the reality is that the framerate is not a perfect 60fps unless your rig is powerful enough to guarantee 60fps as the absolute minimum rate in all possible scenarios. Thus in reality, the framerate will sometimes be lower, and when it is, say, in the range of 55-59fps, you get the first type of tearing listed in BrightCandle's post.
Or framerate with different sync time = tear, even when fps=refresh.frame rate/refresh rate = average tears per refresh.
....... That will help but it also universally is going to add another 16ms of latency on top of the 16ms from the vsync and for marginal gains in smoothing out the output.
My entire frametime is 16ms at 60fps (& 60Hz), obviously it gets higher if the framerate drops.
Interesting that DirectX doesn't support it natively, it used to work fine when I had my SLI setup. Why wouldn't D3DOverrider be able to select which frame to put on the screen? Surely this defeats the object of having a third buffer in the memory?
Tearing happens at all frame rates, this is just a FACT.
For a CRT you can actually calculate the likely average tear lines you'll see, the screen spends approx 95% of the time scanning and 5% of the time moving the electron gun back to the top of the screen, but for easy maths lets say that 100% of the time is spent refreshing, it just makes the concept of tear-scaling easier to grasp.
If you have a frame rate of 60fps and a refresh of 60hz, but it's not in perfect sync (vsync off) then the border between frames will always be somewhere inside your current refresh, so basically at 60fps@60hz you get 1 tear line per refresh or 60 tears per second.
If you have a frame rate higher than your refresh rate, say 120fps@60hz then you've got 120/60=2 frames for every refresh, which means you're likely to see 2 tear lines per refresh.
If you have a frame rate lower than your refresh rate say 30fps@60 then you've got 30/60=0.5 tears per refresh. What does this mean, well you don't have half a tear per frame you have 1 full tear per 2 frames.
Expressed in it's basic form, the number of tears per second you can expect to see is the frame rate you're running at divided by your refresh rate, frame rate is the numerator which means as it goes up the tearing goes up, refresh rate is the denominator which means as the refresh rate goes up the tearing (per refresh) goes down.
Now I said this is effectively for CRTs because they have a known scan time of about 95% of the total refresh period, however I'm not sure how fast LCDs are...do they take most of the refresh period to scan down the pixels, or is that time much smaller? I'm not actually sure it's hard to find numbers on and may differ from model to model.
The smaller that refresh window is the less impact tearing has, if you're at 60hz for example that's 16.6ms per refresh, but it could be that it only takes the LCD 8ms to scan from top to bottom in which case you'd expect on average to see about half the tearing compared to CRT.
But no matter what that window is (because it's constant) it still means that tearing scales linearly with frame rate, the higher the frame rate the more frequently you tear.
Microsoft never added support for it. Mostly because the increased latency is highly noticeable to the grand majority of people and thus is problematic. But its definitely not real triple buffering in DX and DXOverrider can not fix it because it doesn't get to choose which buffer is switched to the screen, it can only set up 3 buffers and their order not the policy on which they are swapped. Just a limitation of the API itself.
Microsoft never added support for it. Mostly because the increased latency is highly noticeable to the grand majority of people and thus is problematic. But its definitely not real triple buffering in DX and DXOverrider can not fix it because it doesn't get to choose which buffer is switched to the screen, it can only set up 3 buffers and their order not the policy on which they are swapped. Just a limitation of the API itself.
DirectX does have official supported triple buffering, but it has an additional rule, which is why some people like to pretend it is not real.
DirectX's version of triple buffering does not allow a new frame to be rendered if both back buffers have complete images. It'll wait until one is displayed and removed before it allows you to start rendering a new frame.
This method makes things just as smooth as the OpenGL version, but in cases where your FPS are much higher than your refresh rate, it can add latency, if there was enough time to render multiple frames before a refresh takes place, but the down side is your GPU must work harder and get hotter.
but the down side is your GPU must work harder and get hotter.
Just tested with Metro: Last light benchmark, Vsync and Triple buffering off, then both on with D3DOverrider. Framerate and temperatures were the same. 62c max.
Ahh I see, I thought you meant in DirectX when comparing hardware triple buffering and D3DOverrider's version.
It does leave me wondering though how Vsync would work with higher FPS than it's synced to.... I seem to remember having to remove Vsync to get more than 85fps with my old CRT in OpenGL.
Wikipedia http://en.wikipedia.org/wiki/Multiple_buffering says this:I would call the DirectX version three buffers not triple buffering. Its just an additional back buffer in front of the vsync one. As far as I know it can overwrite the first back buffer as often as it wants to (which is how it gets greater than 60fps) but it can only ever write to that back buffer, and the other one in between must always be used. Thus the latency is increased and the full benefits of using three back buffers is not realised. Triple buffering the real technique is vastly superior in every way, it has less latency and allows for better performance above vsync refresh rates.
BTW the note [1] refers to AnandTech's article on triple buffering.Another method of triple buffering involves synchronizing with the monitor frame rate. Drawing is not done if both back buffers contain finished images that have not been displayed yet. This avoids wasting CPU drawing undisplayed images and also results in a more constant frame rate (smoother movement of moving objects), but with increased latency.[1] This is the case when using triple buffering in DirectX, where a chain of 3 buffers are rendered and always displayed.