-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
MSI Afterburner Beta 10-FPS limiter in
- Thread starter RavenXXX2
- Start date
That would be my guess... I would be interested to hear if anyone has tried it, as a 120Hz monitor is something I would like to get in the future.
I see no difference with Vsync on and TB in games like l4d so i cant see why people are getting results such as the above Fifa 12 and the BF3 comments.Especially the ones using 59fps limited and pre rednered frames 1.Surely all this does it lower mouse lag but introduce frame skipping you are just not aware of?I can see it with my eyes in L4d2.And why even use pre rendered frames at all with a 59fps cap? do you even have a buffer if using a 59fps limit with vsync? really confusing topic tbh.
Im not using D3D TB tool just using l4d's built in TB and vsync and i tried locking fps to 58,57,59,60,63 and theres really zero difference other than by putting it to 59 i see frames skipping as its preventing it from queuing frames?.Btw This is a game that plagues me with a very minor circle strafe object tear/vibration even with every fix known to man apart from a new pc with extra Vram which ill have very soon to finalise my viewpoints.
I tried pre rendered frames as well and although i do feel maybe a certain combo of these two made my mouse feel a little better i saw frame skipping quite easily with 0 and 1 and any fps locks below 60.I think that no fps cap and pre rendered frames 3 for me is probably a tiny bit smoother or if not the same but without frame skipping.
So i duno what you guys see? I dont have Bf3 yet but any stutter i had in l4d was removed by raw mouse input and nothing to do with fps limiter or pre rendered frames.the little bits i do see and i have a thread and super human eyes for stutter and circle strafe etc.I may need to perhaps get more games perhaps?
ps i know this is a little off topic but on the subject of pre rendered frames 3 is the correct setting for triple buffering right? Triple > 3 frames > prerendered frames = 3.
Im not using D3D TB tool just using l4d's built in TB and vsync and i tried locking fps to 58,57,59,60,63 and theres really zero difference other than by putting it to 59 i see frames skipping as its preventing it from queuing frames?.Btw This is a game that plagues me with a very minor circle strafe object tear/vibration even with every fix known to man apart from a new pc with extra Vram which ill have very soon to finalise my viewpoints.
I tried pre rendered frames as well and although i do feel maybe a certain combo of these two made my mouse feel a little better i saw frame skipping quite easily with 0 and 1 and any fps locks below 60.I think that no fps cap and pre rendered frames 3 for me is probably a tiny bit smoother or if not the same but without frame skipping.
So i duno what you guys see? I dont have Bf3 yet but any stutter i had in l4d was removed by raw mouse input and nothing to do with fps limiter or pre rendered frames.the little bits i do see and i have a thread and super human eyes for stutter and circle strafe etc.I may need to perhaps get more games perhaps?
ps i know this is a little off topic but on the subject of pre rendered frames 3 is the correct setting for triple buffering right? Triple > 3 frames > prerendered frames = 3.
Last edited:
I don't know what you mean by "frame skipping", but it is true that at 59 limit there will be one monitor refresh per second that draws the same frame twice. There are no frames skipped, but there must be one frame that will get drawn twice in a row before a new frame is generated.
I occasionally feel a little "hiccup", but for me this is far more preferable to either (a) tearing caused by no VSync, or (b) input lag caused by poor Triple Buffering.
This "frame skipping" also causes cutscenes (for example in Lost Planet 2 and F.E.A.R.) to have a once per second hiccup, so I know they are occurring. What is strange is that these are far less pronounced in games than in cutscenes (and are too large to be a simple duplicate frame). The Afterburner FPS limiter must be doing something, but no idea what. I tried the nVidia FPS limiter but it was the same.
You say L4D2 has a TB option, so perhaps they have coded a proper implementation, in which case you shouldn't feel any real input lag caused by VSync + TB, just a tiny bit because you have to wait for the monitor refresh. Certainly this would explain why you see zero difference between FPS limit of 57 and 63. In poor TB implementations you would absolutely feel this difference with VSync + TB both on. I can only assume that L4D2 has proper TB support, in which case there would be no additional input lag with an FPS limit of 63 over 57.
To see the effect of poorly coded TB, try a game like HL2 or F.E.A.R. which have no native TB support that I know of. Enable VSync + TB using something like D3DOverrider and feel the nasty input lag caused by this. Then cap the FPS to 59 and try it again. If you feel/see frame skipping then believe me, you would feel input sluggishness in this scenario (assuming the system is capable of over 60 FPS constantly).
The "pre-rendered frames" option limits how many frames the CPU is allowed to calculate before passing to the GPU. If this is too high, you will get an input lag caused by the difference between CPU rendered frames and those currently being processed by the GPU. Pre-rendered frames is not the same as the frame buffers used in the GPU and hence not the same as Triple Buffering. The only way to get three buffers is either with game support or with a tool such as D3DOverrider. Oh, or for OpenGL games the nVidia Control Panel can force TB, but not for D3D (as it isn't true TB).
Right, my next post is very long, but gives an explanation of buffers and input lag for anyone interested. Feel free to skip it
Martin
I occasionally feel a little "hiccup", but for me this is far more preferable to either (a) tearing caused by no VSync, or (b) input lag caused by poor Triple Buffering.
This "frame skipping" also causes cutscenes (for example in Lost Planet 2 and F.E.A.R.) to have a once per second hiccup, so I know they are occurring. What is strange is that these are far less pronounced in games than in cutscenes (and are too large to be a simple duplicate frame). The Afterburner FPS limiter must be doing something, but no idea what. I tried the nVidia FPS limiter but it was the same.
You say L4D2 has a TB option, so perhaps they have coded a proper implementation, in which case you shouldn't feel any real input lag caused by VSync + TB, just a tiny bit because you have to wait for the monitor refresh. Certainly this would explain why you see zero difference between FPS limit of 57 and 63. In poor TB implementations you would absolutely feel this difference with VSync + TB both on. I can only assume that L4D2 has proper TB support, in which case there would be no additional input lag with an FPS limit of 63 over 57.
To see the effect of poorly coded TB, try a game like HL2 or F.E.A.R. which have no native TB support that I know of. Enable VSync + TB using something like D3DOverrider and feel the nasty input lag caused by this. Then cap the FPS to 59 and try it again. If you feel/see frame skipping then believe me, you would feel input sluggishness in this scenario (assuming the system is capable of over 60 FPS constantly).
The "pre-rendered frames" option limits how many frames the CPU is allowed to calculate before passing to the GPU. If this is too high, you will get an input lag caused by the difference between CPU rendered frames and those currently being processed by the GPU. Pre-rendered frames is not the same as the frame buffers used in the GPU and hence not the same as Triple Buffering. The only way to get three buffers is either with game support or with a tool such as D3DOverrider. Oh, or for OpenGL games the nVidia Control Panel can force TB, but not for D3D (as it isn't true TB).
Right, my next post is very long, but gives an explanation of buffers and input lag for anyone interested. Feel free to skip it
Martin
Frame Buffers
The word "buffer" here refers to the memory used by the GPU to store the frame being rendered. There must be one, else no frame can be generated. The monitor (well, RAMDAC or digital interface) has to read from this buffer to show the frame on the screen. It is possible to run with a single buffer, but this is not done anymore. Imagine slowing the GPU down tremendously... you would see every graphics operation being drawn in real-time on the screen. You don't want this. So, at the very least, Double Buffering is used. Here, the GPU can prepare a frame in one buffer (A), whist the monitor is allowed to read from the other, completed frame (held in the other buffer, B). Only when the GPU has finished a frame completely is the monitor allowed to switch (known as a "flip") to the first buffer (A) and start to show the new frame. The GPU also does a buffer flip and starts rendering the next frame in the second buffer (B). Once another frame is completed they both flip back and start again.
Double buffering with VSync causes a problem: If the FPS falls below the monitor refresh rate, even by 1 FPS (e.g. 59 FPS and 60Hz monitor), the framerate falls to half the refresh rate (e.g. 30 FPS). This is because the GPU only has one "working" buffer with double buffering, the monitor must be given exclusive access to the other for its reads, to prevent partially rendered frames being drawn to screen. The GPU will stall as it has to wait for the monitor to finish drawing the same frame for a second time, all because it was a fraction of a refresh slow to draw the next frame... result: framerate halves, or worse as the FPS drops (e.g. 29 goes to 20, etc.).
Now, TB overcomes this limitation, as the GPU now has two "working" buffers and one more for the monitor. If the FPS falls to 59 there is no problem, it is allowed to flip to its second "working" buffer and prepare a third frame.
The problem with input lag comes down to this...
Lets say that the GPU is so fast, it can prepare more than 60 FPS and we are using VSync + TB. At some point, it WILL finish work on its second "working" buffer whilst waiting for a refresh to finish. It has to. So, we have two frames yet to be shown to the player. Which should we show next? It makes no sense to show the oldest of the two... it is already out of date. So, we show the newest one. But, if we are going to do that, the GPU could have already started to overwrite the oldest one (even before the monitor is ready to flip). This is what it does with proper TB, AFAIK.
Unfortunately, as I read somewhere else, the D3D TB is not, IMHO, correct. It does have (at least) two working buffers, but the frames are shown to the player IN SEQUENCE and none are ever thrown away. True, the game might like to know that a frame has been thrown away, in case it wanted to ensure that the player saw something, but unless it is a subliminal message, one frame long, I see no need for this. Anyway, because they assume that we should not throw frames away, this is what they do. The result: input lag... constant and without remorse. Every frame from then on will be delayed, unless the framerate drops below the refresh rate. Of course, if it climbs again, the lag will return.
Now, impose a FPS limit below the refresh rate (ideally EXACTLY on it, but this is impossible I would think). Now, we ensure that the GPU cannot race ahead and there is no input lag. We still need the three buffers, to prevent the halving of FPS caused by only two buffers, but we prevent lag caused by too many completed frames that insist on being drawn in sequence. However, at least we save power/heat because we let the card idle when framerate goes above refresh rate.
However, we do get frames drawn multiple times, but this is the same as you would get with a game that could only generate, say, 58 FPS and we decided to use VSync. There will always be some "skipped frames". Do you feel this: I think you do, but is the price you pay for VSync and no tearing.
The ideal solution? Monitors that allow dynamic refresh rate, up to some limit (e.g. 60 or 120), that allow the time between frames to vary... meaning that an FPS under the refresh rate does not suffer any frame skipping, and each frame has identical output lag through the interface to the monitor. Given LCD's don't need "refreshing" in the same way as CRTs, I'm amazed this hasn't been done already. There will be some additional input lag caused by longer GPU rendering times, but the result would be much smoother than "frame skipping" / duplicate refreshes.
Martin
The word "buffer" here refers to the memory used by the GPU to store the frame being rendered. There must be one, else no frame can be generated. The monitor (well, RAMDAC or digital interface) has to read from this buffer to show the frame on the screen. It is possible to run with a single buffer, but this is not done anymore. Imagine slowing the GPU down tremendously... you would see every graphics operation being drawn in real-time on the screen. You don't want this. So, at the very least, Double Buffering is used. Here, the GPU can prepare a frame in one buffer (A), whist the monitor is allowed to read from the other, completed frame (held in the other buffer, B). Only when the GPU has finished a frame completely is the monitor allowed to switch (known as a "flip") to the first buffer (A) and start to show the new frame. The GPU also does a buffer flip and starts rendering the next frame in the second buffer (B). Once another frame is completed they both flip back and start again.
Double buffering with VSync causes a problem: If the FPS falls below the monitor refresh rate, even by 1 FPS (e.g. 59 FPS and 60Hz monitor), the framerate falls to half the refresh rate (e.g. 30 FPS). This is because the GPU only has one "working" buffer with double buffering, the monitor must be given exclusive access to the other for its reads, to prevent partially rendered frames being drawn to screen. The GPU will stall as it has to wait for the monitor to finish drawing the same frame for a second time, all because it was a fraction of a refresh slow to draw the next frame... result: framerate halves, or worse as the FPS drops (e.g. 29 goes to 20, etc.).
Now, TB overcomes this limitation, as the GPU now has two "working" buffers and one more for the monitor. If the FPS falls to 59 there is no problem, it is allowed to flip to its second "working" buffer and prepare a third frame.
The problem with input lag comes down to this...
Lets say that the GPU is so fast, it can prepare more than 60 FPS and we are using VSync + TB. At some point, it WILL finish work on its second "working" buffer whilst waiting for a refresh to finish. It has to. So, we have two frames yet to be shown to the player. Which should we show next? It makes no sense to show the oldest of the two... it is already out of date. So, we show the newest one. But, if we are going to do that, the GPU could have already started to overwrite the oldest one (even before the monitor is ready to flip). This is what it does with proper TB, AFAIK.
Unfortunately, as I read somewhere else, the D3D TB is not, IMHO, correct. It does have (at least) two working buffers, but the frames are shown to the player IN SEQUENCE and none are ever thrown away. True, the game might like to know that a frame has been thrown away, in case it wanted to ensure that the player saw something, but unless it is a subliminal message, one frame long, I see no need for this. Anyway, because they assume that we should not throw frames away, this is what they do. The result: input lag... constant and without remorse. Every frame from then on will be delayed, unless the framerate drops below the refresh rate. Of course, if it climbs again, the lag will return.
Now, impose a FPS limit below the refresh rate (ideally EXACTLY on it, but this is impossible I would think). Now, we ensure that the GPU cannot race ahead and there is no input lag. We still need the three buffers, to prevent the halving of FPS caused by only two buffers, but we prevent lag caused by too many completed frames that insist on being drawn in sequence. However, at least we save power/heat because we let the card idle when framerate goes above refresh rate.
However, we do get frames drawn multiple times, but this is the same as you would get with a game that could only generate, say, 58 FPS and we decided to use VSync. There will always be some "skipped frames". Do you feel this: I think you do, but is the price you pay for VSync and no tearing.
The ideal solution? Monitors that allow dynamic refresh rate, up to some limit (e.g. 60 or 120), that allow the time between frames to vary... meaning that an FPS under the refresh rate does not suffer any frame skipping, and each frame has identical output lag through the interface to the monitor. Given LCD's don't need "refreshing" in the same way as CRTs, I'm amazed this hasn't been done already. There will be some additional input lag caused by longer GPU rendering times, but the result would be much smoother than "frame skipping" / duplicate refreshes.
Martin
