I agree with the double blinding idea. Techreport had some videos on the skyrim stuttering and I showed it my bro with the card names covered and he actually preferred the AMD card. Personally I though both of them were playable since the 240fps video exaggerated any stuttering issues. If you can't tell the difference in a 60hz or 120hz video/monitor there is no difference.
It would be nice if someone would develop an tool to measure the frames as they are being displayed, like as they are actually being viewed.
The benefit of blindtest is twofold: It removes all the complexity involved in testing, and get to the point where it matters. Secondly we get an oppinion as to what the benefits of the game have, going to higher quality settings. Anand for much good, have the same staff, and we will get to know Ryan preferences in just a few rounds of testing. Then he can have a nice assistant changing the cards for him :)
While not blind, HardOCP's maximum playable settings testing is done to capture this. They report min/avg/max/graphed FPS; but at whatever combination of settings gave the most eye candy while still being fast and smooth enough to be enjoyable. At times this has resulted in observations that "while the raw FPS numbers imply that turning on X should be doable the gameplay results indicated otherwise" (generally due to stuttering problems).
Its a real interesting read, and i hope they will start doing testing real soon, as hard numbers are hard to come by, as there is still no perfect way of testing frame times.
"Playable" and "optimal" are different things; for the most part no one is suggesting the games and cards that have more problems with stuttering are "unplayable".
And, some people don't notice what bugs the fire out of others. Stuttering is one of those things. I think this has a lot to do with the fact that these problems have existed for quite awhile and people just got used to them, so kind of automatically ignore them.
So, I agree, if you don't notice it then it's not important. But if you do, then it is. :) I noticed this phenomenon years ago, and am very excited to see numbers that people can show quantifying the situation so that it can be discussed on more than a seat-of-the-pants level.
The problem with double blinding is that some people notice more than others. If you're used to high end equipment on a 120hz monitor, you'll notice a hell of a lot more problems than dude off the street that normally plays on his laptop.
That's the correct guestimate. I think AMD will be the end of the year/start of 2014 and Nvidia probably end of 3rd quarter/start of 4th quarter since they don't have to make console hardware apart from their own handheld.
In recapping the history, I believe it was around 04' or 05' that ATI and Nvidia were getting busted for optimizing their drivers for the benchmarks. Can't forget that boondoggle!
Really great article. I like seeing stuff like this it's interesting.
Can you answer this though: has the work that AMD have done with single GPU stuttering atleast improved multi-GPU stuttering a little? Or has this work had no affect at all on multiple GPU's, and we will have to wait for the July drivers?
Multi-GPU stuttering is basically a superset of single-GPU stuttering. So while it doesn't fix any frame pacing issues, it will fix any single-GPU stuttering issues that made themselves present in multi-GPU mode.
I find this whole exercise very sporting of AMD. Nvidia might be thinking that this undermines their technical competitiveness. But i find it very mature of AMD to even admit that they have a problem, and are working on it.
It sadly is. But thats how big tech corporations work. You ever heard Nvidia, Intel and Apple admitting they have a problem, even in the face of clear evidence?
Nope, never, I remember Nvidia back in the days of the 6800 GT that caused INFINITE stuttering(worse I've ever seen) with Nforce 3 or was it nforce 4 motherboard that I had. Only thing I could do to fix it was to underclock the video card, go back to older drivers. That made me lose 30-40% performance.
They never ever fixed the problem or admitted it, EVER. I had to change video card after 6 months of trying everything. Nvidia forums were full of it not even an answer from them that they were fixing that issue. Some were able to fix this by disabling AGP fastwrites or other tricks but others had no choice doing what I did and lose the performance...
It's great that AMD admitted to a problem, but wow what a big problem to have totally missed. I guess they were so busy laying off engineers and R&D they didn't keep ahead of the game.
If Windows is a major problem with stuttering, then why can't they develop a user-switchable "gaming mode" to make the OS prioritize the resources of the OS in favor of the games and their rendering processes?
Microsoft is the company that might work something like that out. Unfortunately, Microsoft is also one of the companies that wants you to go buy a console. So I don't think they're going to facilitate what you suggest.
I also suspect it's not as simple as what you suggest since it'd require game support, low level changes, etc. But ultimately, it doesn't matter how easy or hard it is because MS won't do it. They have no reason to.
If they cared about PC gaming in the slightest, I think they'd have ported Halo 3, ODST, Halo Reach, Halo 4, Gears of War 2, Gears of War 3, or Fable 2 to PC. Face it. MS gave up on PC gaming. Steam is what kept it going and Steam is what will carry it forward.
And the Steam Box may do exactly what you're suggesting.
methinks you place too much confidence in their acumen. As an exercise, find one thing microsoft has done lately which can be spun as plausibly in service of windows gamers.
Fundamentally AMD failed because instead of making a driver to play games well, they make one that's there to give the highest fps at the expense of everything else. They were the first for example they customize the driver for every game - which makes the driver an order of magnitude more complex and introduced a lot more bugs to everything for a few % more performance.
They did this because they care about the bottom line numbers shown in reviews more then actually playing the game well. Only now a reviewer has focused on stuttering are they focusing on it. It's not the only problem either - runt frames was also exposed by another tool which if anything is a cheat to exploit fraps - but AMD haven't got as far as discussing that yet.
This is a problem - AMD should be making drivers to play games well, not to look good in reviews. Journalists shouldn't be the ones having to do AMD's driver QA. I can't believe AMD didn't know about the stuttering - it's obvious even with a slow cam, they just didn't think it was important because it didn't effect their sales because journalists weren't reporting on it.
Read the article again, your assumptions are wrong.
Fixing the stuttering provided an increase in averaged framerates (in cases up to 13%), so it would've made them look a lot better even in traditional reviews not reporting on stuttering. And that's a huge delta for a small software change.
If anything, you could blame them for ineptitude, but there's no ill-will here.
The increase in fps was a surprise to them. The article suggests that if they had known it would increase fps they would have done it ages ago. Fact is there was stuttering, they knew about it but ignored it - the "well we assumed everyone else stuttered too" excuse isn't great. Clearly it was fixable, and a side effect was it even increased fps, but they were so fixated on fps charts in reviews that it was never deemed important enough to look at until the reviews started castigating them for it.
If they had actually been trying to make the card as good as possible for gamers to play with they would have fixed it years ago as stuttering really matters to people trying to play the games.
Their stance wasn't "Everyone else stutters so why should we bother with it." It was closer to "Everyone else stutters and we have no more control over it that they do ... Wait, you're saying they don't stutter as bad as we do ... and fixing our stutter would've actually helped our performance. Aw, nuts." I agree with Spoelie, it was ineptitude, not ill-will.
Lots of people seem to think AMD does so much mistakes that everytime it happens the world speaks about it more intensely because they actually admit it instead of trying to HIDE things, they even let the sites like anandtech make reviews on their problem. Right now, at home, I have two very comparable systems based on overclocked SNB. One with a 7950, and the other with a gtx 660 ti. Both play games extremely well but I have more trouble with my 660 ti. I get lots of ''Display adapter has stopped responding'' while surfing the internet, when waking up from long idle states and when playing League of Legends. I switched drivers, did clean install and I can't get rid of it totally. No my card is not overclocked and I can make it furmark all day long without a problem.
I decided to play on my girlfriend's computer(which has the 7950) when I play league of legends because you just can't be interrupted in this kind of game. It even froze in LoL a couple times, at first I thought it was my SSD but after reading the dump files, found out it was the 660 ti. But hey, Nvidia is perfect(we just don't see them speaking of their problems that's it)... 4 months of it now, thanks alot... I wrote on nvidia forums did my research did everything they told me. Good thing it's only with LoL, internet and long idles, everything else runs flawlessly.
Actually, I think you should reread the article. It's true that fixing these stuttering issues has given them some frame rate improvements, but the article seemed relatively clear on the point that they were focused on frame rates and not frame latency or frame interval or whatever they're choosing to call it today.
They had all their focus on one aspect of driver development and that actually cost them in that area because they weren't considering a more well-rounded approach.
I'll grant you AMD was pretty inept though. This has been problem they've had for years and it's taken them this long to suss it out...
Looks to me as being the best way to measure it, as it uses a DVI capture card to actually capture what the user sees, forgoing any overhead software may have..
The ideal method would be something that gives us timestamps at both ends of the pipeline, but that's a tall order. The PCPer method is very interesting indeed... ;)
First very informative article. The issue at hand is that this so called concern is based on an individuals perception. Remember we are not talking about a stuttering that was so bad as to be noticeable to all gamers. Scott basically had to make a video specifically designed to point out the issue for others to see it originally.
Because there is no real way to quantify the personal experience we have an issue in the fact that we now have a measurement craze that is being treated as fact when it is based in the end on subjection for the final result.
Having access to various levels of AMD and NVidia based machines I can tell you that my gaming experience across them has been pretty uniform in most cases. The cases when I had a bad experience, probably a wash as they are on both platforms.
I think the biggest issue is we sometimes get to caught up in the technology. We let benchmarks and measurement programs dictate to us what we will get the most enjoyment from with our gaming experience. A game is not the frame rates but the play that matters. While frame rates might play a roll it is not the measurement of them that makes that part of the fun.
At the end of the day the single best test of a video card is not a benchmark suite or tool to measure frame rendering time. The best tool is to play the games you want and see if you get the game experience you desire. Turn off the benchmark and turn on the game, that is the ONLY true test of what is best.
Speak for yourself. I've noticed this problem between nVidia vs AMD for years. For many years, gamers have said that nVidia cards are "smoother." People didn't listen because they didn't want to hear the truth or because they were likely stuck with one high end from AMD and a low end or medium end from nVidia.
But comparing equivalent cards, I can tell you my experience has always led inescapably to the "feeling" that the nVidia card is smoother at the same or even slightly lower frame rate.
This just proves what I "felt" was the case was in fact really the case. If you didn't see it, then that's a fail on the part of your visual acuity or perhaps you had a bias you wanted to see, so you saw less than everything present.
But the stutter was always there. Now even AMD admits it.
This is great victory for all of the tech press. When people started complaining about stuttering years ago we were only dreaming of getting so much attention from gpu brands. I still remember someone constantly saying "micro-stuttering doesn't exist", I wonder how they feel now that they enjoy the fps and smoothness benefits. In any case I praise constructive journalism that triggered a significant leap in the technology.
One important fact I feel is missing in your treatment of what it is fraps is measuring and why its more representative of problems than you and AMD think it is. For some reason everyone who makes this argument that fraps is isn't very useful seems to skip this one, but its really really important.
Fraps measures at the present call and that isn't a random choice. Because the present call has a few different modes of operation, but all games use blocking mode. What that means is that if the context queue is full (which it normally is) then game thread is held up waiting for that present call to complete. Subsequent present calls are regulated by the GPU's driver in this case as the thread is held and when it chooses to accept the completion of that frame only then can the games thread continue. Since Fraps is measuring this it can see when the driver is accepting frames in an uneven fashion, so while you might see even frames presented to the monitor due to the buffering there is still a knock on effect.
Game simulations produce particular frames of their simulation, sometimes in the same thread as the present call and sometimes in a different thread. Regardless they use the release of the present call as the end of their rendering step and that allows another frame to be started or delivered. So if the present calls are coming back unevenly the game simulation itself will stutter as it tries to produce as many simulation steps as the rendering is producing. If the present calls are stuttering there is a feedback loop into the game simulation that is too causing it to stutter.
Its this feedback loop on the rendering and game simulation which causes much of the problem, and it starts in the GPU driver. It might very well be caused by Windows but the big difference we see in the manufacturers solutions tells us that its almost entirely the manufacturers fault when it happens and impacts on gameplay.
So quite rightly fraps does not measure stuttering out to the screen, it measures the GPUs regulation of the frame rate of the game rendering and its simulation and that does cause real stuttering, both of the subsequent present calls and the game simulation.
Of course pcperspective have now shown that AMD's SLI stuttering out the DVI port is considerably worse than Fraps, so much so they considered what they are doing is a cheat as the frames aren't real. But you need bothperspectives, the output and the input to the pipeline to see the impact on the game. Its not just the frames themselves that have to be regulated to be smooth its also the game simulation that must run smoothly, and it is regulated by the handling of the context queue.
There are two things you need to keep in mind: 1) Nvidia also agrees with the limitation of FRAPS. In fact, IIRC they were the first to voice the issue that FRAPS recordings are in the wrong place and can only infer what actually needs to be recorded. The author is correct, when Ati and Nvidia agree, we should at least pay attention.
2) Though your your points are AFAIK correct and well articulated, they still point to the issue of FRAPS inferring, rather than recording the the targeted information. The difference is, rather than consistency of output frames, you are looking for consistency of simulation steps. I agree that this is a metric that really needs to be covered. In fact, I would even go as far as matching simulation steps to their corresponding frame times to expose issues when short steps are accompanied by long frames or vice versa.
Unfortunately, FRAPS can't measure any of this directly and even for your points proves to be limited to inference. That said, until a reviewer gets tools that can reveal this information, inference via FRAPS is better than no information at all. Pcperspective's comments on AMD's stuttering issues are related (as they state) to crossfire setups. I could see the differences between CF and SLI in blind tests (though SLI also has some microstutter) and this only confirms it. The runt frames only add fuel to the fire. I'm open to using AMD in single GPU builds, but only use Nvidia for multiGPU builds. Perhaps this will change in July, but I'm guessing there will still be plenty of work to do.
I should probably expand a little on what I consider a limitation of FRAPS for stutter caused by simulation steps. FRAPS inserts itself at the output of the render and is therefore subject to a variable delay between the simulator time step through the render. Important information can still be inferred, like simulation stutter in AMD's heartbeat waveform. However, I'd still rather get a timestamp directly at the output of the simulator rather than at the output of the renderer, if it ever becomes an option. Unfortunately, that would probably require cooperation with the game developer, so I'm not sure that will ever happen.
sadly the issue they find isn't exsactly caused by the gpu!it is at the os end!data fragmentation at various level is often the cause.and this happen everywhere,at the processor cache level to the server cache level!ms say it doesn't mather !they re wrong!it affect everything related to image quality.bufferbloat also is the main problem.mtu,udp fragmentation ,multithreading and rss fragmentation etc etc etc!oh they say they can reconstruct the data in the proper maner that wont impact performance or quality!again ms is either wrong or unknowing of the problem these various issue cause .I haven't event started on the gpu side yet!all that data manipulation etc is the main issue !how to fix it?mm!probably use official standard limit like the 1460 for mtu and add udp to that also so that it is also at 1460.(just a random exemple cause these will need to be tweaked ,why?so that packet don't get fragmented anywhere in the computer or the server.or they tell people how to make it happen ,because right now not many have 1080p quality even most have a 1080p monitor.so imagine if amd is using window idea to tweak their gpu?like .net4 etc !(yep it become a nightmare)hopefully they ll fix this but all side have been on a race for performance .(wouldn't want to sell a = performing w8 instead of w7 .it wouldn't sell!i am all for getting better performance but not at the expense of subpixel quality of graphic.nvidia is probably better because they noticed ms error and have worked to avoid the os mistake by using standard and proper ways .I aint saying ms is wrong maybe they can really fragment packet and have everything being fine and dandy looking in 1080p.but I will tell you this.in most area of computing it feels like this:os is saying 255.0.0 and at the other end for some reason its like our old phone game,at the other end what is being done isn't at all what the os said the beginning (and viceversa)hopefully these idea of new data mining and testing tool will go deeper and test what is actually going on in our computer,network and server datapath so they all can work together.cause right now?our game look 1080i even tho we are all set at 1080p
I love you guys, but this article comes off a bit like sour grapes. The Tech Report dove into this issue head first and admitted from the beginning the testing methods may not be perfect. They have continued to be clear on this and you made no mention of the high speed video tests that they performed. The bottom line is The Tech Report is primarily responsible for getting AMD to get on the ball with this issue. Regardless of AMD's bag of excuses and their sudden clarity on the best methods for testing we would not be where we are without the sold work of The Tech Report. I feel that if the FRAPS method of testing was sufficient for bringing these issues to light then a job well done. The situation will only improve from there and Scott Wasson and company deserve more praise than this sour attempt of an article to discredit the good work they have done. If that we not your intention then I apologize, but it comes off as such.
I did not see it this way at all. Instead, I read it as TechReport started a trend in evaluating stuttering that most were not looking for, and that while there is some merit to their methods, there are other better ways of evaluating the issue. I did not see any effort to hide, obscure, or otherwise show "sour grapes" to them for their testing.
As to the merit of the article, if AMD, Nvidia, and Anandtech folks all agree that the methods used by TechReport are okay but could be improved upon with better tools, then the end result will be better for everyone. Much as standard bench-marking software has evolved a lot over the the last decade, the bench-marking for this type of testing will change dramatically as people find interesting and new ways to really get in depth with the issue and generate data that is easy to aggregate and report. I think that is a net benefit for all of us!
All of us will benefit from the light shed on the subject with better testing and companies paying closer attention to issues and work arounds related to the subject. Still we would not even be talking about better testing methods right now without the attention it got from The Tech Report. I look forward to more sites implementing some type of real world testing methods that results in a true user experience evaluation. I reread the article and still standby my original conclusion. The Tech Report gets credit, but rather then stopping there this article seems to attack their methodology when they themselves had already admitted that it was less then perfect. To date there are still not better tools being used for reviews and The Tech Report still got the point across with what was available. I am a huge fan for what they did over there as I could not pinpoint why my AMD experience was less than optimal. It forced me to early retire my 6950 grab a very affordable 660 OC and enjoy a much smoother game experience. This is my first nVidia card since my trusty 4200ti and I am not looking back until AMD is on par with nVidia in the stuttering department...it was literally making me motion sick )-:
"holding back one frame but not another can sometimes make the frame display evenly, but from a simulation step only a few milliseconds after the previous step"
wouldn't this also happen with the single GPU "heartbeat stuttering"?
Yes it would, which is exactly the problem with the heartbeat pattern that AMD's problem causes. You can deliver the frames evenly out to the monitor but their contents has a noticeable stutter due to the graphics driver accepting the frames unevenly. The heartbeat is a sign of a real problem without a doubt, all non smooth frame time captures are. What they are not is a sign that the DVI monitor is seeing frames at those periods, but then no one ever said that was what was being measured anyway.
The best way to think about it is that this is the problem going into the pipeline, measuring the output also needs to be done to get the smoothness on the output. Only with both can you understand the impact. We have half the picture, and that half is accurately measured by fraps.
Design and launch a product. Ignore user feedback.
Did we forget about those people with $2000 laptops sporting AMD mobile card drivers that didn't work correctly for over a year due to some bug with the graphics switching MUX? This seems to be a pattern that revolves around AMD software people being wholly out of their depth, overworked, or just not caring. They don’t even seem to be able to figure out when they have a fix. The laptop GPU story here on AT was presented as AMD sending over beta drives and asking “Did we fix it this time?”
One minor correction to the description of the submission of commands through the stack - the DirectX runtime under Windows Vista and later does NOT accumulate a frames' worth of draw calls before sending them to the UMD. I believe it sends state and draw calls to the UMD immediately.
The UMD accumulates commands in the command buffer and flushes them to the KMD either when a present call occurs, when the command buffer is full, or when the application requests to read back the results of enqueued rendering (Map/Lock/read Query result).
It used to be true under Windows XP that the dx runtime accumulated calls and dispatched them to the driver - but that is because in XP, the driver ran in kernel mode and it was too expensive to make the user mode->kernel mode transition on every "SetState", etc call.
As a long time ATI/AMD fan this report doesn't fill me with confidence. It appears AMD is using anandtech for their public relations spin on the stuttering issue. I don't blame anandtech for running the story, AMD's comments are newsworthy and anandtech deserves credit for being honest about AMD's intentions. On the negative side, the explanation about fraps not being an effective tool only need to be said once, it seems (by the number of times it was mentioned) that AMD's message is to make sure everyone knows Fraps its not accurate, but doesn't explain why Nvidia performs better.
On the issue, it sounds like AMD is conceding and preparing us for much of the same. No where in the explanation do they mention why Nvidia performs better in the latency tests, other than to say its not what the end user is seeing. Well I disagree, users have been complaining about stuttering for years. I just don't believe that AMD have never looked into this issue before. Also with the multi-gpu stuttering. It has been an issue since crossfire/SLI first appeared and nothing has really happened there.
Im a fan of AMD cards but I use both brands and personally I have noticed Nvidia do a better job with latency and general responsiveness in game, whereas ATI/AMD has the edge with image quality. Its subtle, and probably not something the average user notices but a lot of people do notice.. If AMD can solve this issue they would sell many more cards but by the sounds of this article, its too big and complex for them to solve completely without major work. Hence the excuses. Nvidia has to play by the same rules, the same OS etc and they do a better job at latency/stuttering, hopefully AMD can fix it enough to at least perform as good as a NVidia card.
"NVIDIA made a big deal about moving away from timedemos and average frame rates during the early GeForce FX (NV30) days, when its cards might have delivered a decent gaming experience but were slaughtered in most benchmarks."
Well, that's not really what happened at all...;) The chip "slaughtering" everything nVidia made in those days was the ATi R300. Seems rather strange to tell just half of that story. And the problem nVidia had with benchmarks wasn't technical--it was that nVidia was found to be actively cheating in 3dMark (camera on rails), among other cheats/shortcuts/optimizations in their drivers. The benchmarks told a story nVidia couldn't abide, and that was how much better the R300 was than anything nVidia had at the time. R300 was in every sense a revolution in the 3d gpu markets, blowing everything else away. All gpus on the market today are descended from R300 (just as all Intel and AMD x86 cpus are descended from AMD's original 64-bit Opterons.) nVidia did eventually own up to all of it, right before cancelling the nV30 after a month or two in production, however. People kept publishing proof after proof of what nVidia was doing until finally the company said "uncle." nVidia has been a better company since, imo. At least, its products are certainly better.
I'm using a single ATi gpu and over the last few years I have to say that I haven't seen any stuttering worth mentioning. Whenever I have seen stuttering it is usually due to some software condition or other, and rectified by the appropriate patch. I do appreciate your pointing out that Fraps isn't perfect and I think TR should stop pretending that it is. Fraps as you point out was never intended to measure this kind of latency and so using it to produce data other than frame-rate data is an "off-label" use of the program, imo. And also as you point out, I use vsync more often than not.
Really, though, I would loathe seeing AMD optimizing its drivers just to look better in TR's off-label Fraps usage...!...;) Let's hope that doesn't happen as I got quite a belly full of that sort of thing back in the nV30 days--enough to last me a lifetime.
How can FRAPS detect any vendor-specific stuttering if it injects itself before the gpu-driver is called? The second thing is that v-sync is just crap. I'm not a professional gamer, not even close but in certain games turning it off made me a much better player and the difference is huge. even more annoyingly it was not directly noticeable. I did not "feel" anything changed. Except that my stats were better. Tearing and stuttering: no issue for me so far.
I had meant the above as a reply to the guy talking about network fragmentation; I'm not sure why the reply in the new format doesn't auto-nest the response.
Thanks a lot for this interesting article. Is astonishing to see how minimal software issues can severely degrade performance and efforts done in other areas, turning a company less competitive with the money losses this takes with it. Also is a reminder of how important is to implement deep quality and performance evaluations in software development. Is a shame that in today software industry the delivery dates are more important than quality many times and programmers end up delivering half baked applications from also half baked requirements. Thanks again.
Good to know I'm not going crazy. Almost every game I play has a decent frame rate, but still doesn't seem smooth. (Gigabyte Windforce 6850 OC) Tried underclocking, overclocking, Different PC's... I thought I had a dud card.
Reading through the whole article, I became increasingly convinced that it's not that FRAPS is necessarily a bad tool for measuring this, but that people need guidance in how to interpret the graphs correctly.
The first time I saw a frame latency (or whatever you're calling them now) graph, my first impression wasn't, "Wow, look at all these little latency spikes." It was, "Holy sh*t! Look at those huge freaking spikes!" It was a simple matter of severity. I think anyone can take a look at the "heartbeat", see that it is a recurring pattern with a relatively consistent frequency, and- while they may not be able to say for certain if it is indicative of a problem- they can say that it is "normal" for that particular card. It's the huge spikes, the ones that aren't occurring at consistent intervals, that are so much more severe than the "heartbeat", that are the issue.
How hard would it be for a reviewer to draw a pair of horizontal lines across the graph to indicate the limits of "normal" stuttering, where anything beyond the lines in either direction would be considered "abnormal"? A method of separating the signal from the noise.
Furthermore, I thought it was reviewers noticing a difference- that framerate alone couldn't explain- in the way games played between ATI and NVIDIA that prompted the whole investigation into latency. Several sections in the article mention how FRAPS results may not be indicative of user experience. But it was user experience that prompted using FRAPS to try and explain what was being observed.
Thre are two things you need to keep in mind: 1) Nvidia also agrees with the limitation of FRAPS. In fact, IIRC they were the first to voice the issue that FRAPS recordings are in the wrong place and can only infer what actually needs to be recorded. The author is correct, when Ati and Nvidia agree, we should at least pay attention.
2) Though your your points are AFAIK correct and well articulated, they still point to the issue of FRAPS inferring, rather than recording the the targeted information. The difference is, rather than consistency of output frames, you are looking for consistency of simulation steps. I agree that this is a metric that really needs to be covered. In fact, I would even go as far as matching simulation steps to their corresponding frame times to expose issues when short steps are accompanied by long frames or vice versa.
Unfortunately, FRAPS can't measure any of this directly and even for your points proves to be limited to inference. That said, until a reviewer gets tools that can reveal this information, inference via FRAPS is better than no information at all. Pcperspective's comments on AMD's stuttering issues are related (as they state) to crossfire setups. I could see the differences between CF and SLI in blind tests (though SLI also has some microstutter) and this only confirms it. The runt frames only add fuel to the fire. I'm open to using AMD in single GPU builds, but only use Nvidia for multiGPU builds. Perhaps this will change in July, but I'm guessing there will still be plenty of work to do.
Thre are two things you need to keep in mind: 1) Nvidia also agrees with the limitation of FRAPS. In fact, IIRC they were the first to voice the issue that FRAPS recordings are in the wrong place and can only infer what actually needs to be recorded. The author is correct, when Ati and Nvidia agree, we should at least pay attention.
2) Though your your points are AFAIK correct and well articulated, they still point to the issue of FRAPS inferring, rather than recording the the targeted information. The difference is, rather than consistency of output frames, you are looking for consistency of simulation steps. I agree that this is a metric that really needs to be covered. In fact, I would even go as far as matching simulation steps to their corresponding frame times to expose issues when short steps are accompanied by long frames or vice versa.
Unfortunately, FRAPS can't measure any of this directly and even for your points proves to be limited to inference. That said, until a reviewer gets tools that can reveal this information, inference via FRAPS is better than no information at all. Pcperspective's comments on AMD's stuttering issues are related (as they state) to crossfire setups. I could see the differences between CF and SLI in blind tests (though SLI also has some microstutter) and this only confirms it. The runt frames only add fuel to the fire. I'm open to using AMD in single GPU builds, but only use Nvidia for multiGPU builds. Perhaps this will change in July, but I'm guessing there will still be plenty of work to do.
Long time reader first timer commentor. I really liked this article, and have liked most of the articles here. What I want to say is, I hope that AMD fixes their drivers and address both single and dual gpu issues. I personally didn't have any stuttering when I had 2x7970s but they sometimes lost the link to each other and my system would only see one. I switched to the Titan since I got it for a reasonable price. Now this articles makes me wonder whether I should go back and grab the 2x7970s and save some cash in hopping that AMD has the mutliple GPUs issue solved by early summer. It's good to see them working to address the issue and hope we never have to encounter this again once it's done with. Next step should be how their mutli gpu solutions scale. Thanks Ryan and keep up the good work.
"AMD, quite bluntly, has a problem with how FRAPS is being used in some cases. To be clear here FRAPS is a wonderful tool, and withOUT it we would be unable to include a number of different games in our hardware reviews."
Very interesting article, still digesting it all, thank you for taking the time & effort to share it.
I told you... AMD Peasants, that's what we are. Stuttering, Microstuttering, Flashing/Flickering black artifacts on DX9 games, many times we're forced to disable GPU acceleration on very few programs outside gaming that use the card, like Firefox, Flash and even Windows...
I'd seriously prefer sporadic issues on games, but at least all the programs and Windows to be working flawlessly. Even on video occasionally we get problems...
I guess I learnt the hard way that all "rumors" about bad AMD drivers experience are god damn true... And no, Nvidia isn't like that nor in the slightest. In my many years experience with Nvidia cards, I can only name you one serious problem I faced, but the solution came relatively fast, 275.33 drivers started Browser TDR, it ended with 290.26 drivers.
What are you talking about? I have had ATI / AMD cards for years almost 10 years. Never ever an issue like the one you are describing. Disable GPU acceleration? Serioulsy? that's incredibly ridiculous.
Guys, i know you think you're Gods one true miracle to tech news, but would it be so much to ask to stop writing your articles as if there were no question as to the veracity of that claim? You sound so pious, so arrogant, so self-righteous in this article. Please tone it down.
Fantastic article! The presentation is very clear and clarifies the situation, especially the question of whether FRAPS is an appropriate tool. The whole latency has been way overblown by techreport and the nvidia fanboys. Anyway, the AMD engineers have done a great job on improving things.
Very nice "damage control" article for both AMD and Anandtech! Well done with excuses like "FRAPS sux anyways so we will wait for "better tools", giving AMD more time to fix the issues, which aren't really issues anyways because most people won't notice any stuttering" ;-) P.S: Yes, I know that FRAPS has issues (Scott himself said that), but you could've said it in more neutral way and much earlier.
Totally NOT about the article.... You had a comment regarding Dr. Pabst, that (being blue) I thought might be a link to something bearing some information regarding the venerable Dr. Tom... But no... It just linked back to Tom's hardware, which I am sure Dr. Pabst would have considered an insult. Tsk Tsk...
Great write up. Can someone explain why it is not possible to hook into the interrupt that the GPU generates after rendering a frame to provide the measure that's FRAPS is missing?
Overall a good article, but it has one huge problem. Ryan, you are repeating about 10 times that there is no good tool to replace the Fraps measuring, which is inaccurate.
I just bought an AMD/ATI card and not only do I have stuttering I have that horrid POWERPLAY kicking in all the time with screen tearing. I'm pulling my hair out and wondered why I didn't buy Geforce. My old 8800GTS was doing great but it finally gave up the ghost one day, I should have stuck with at least something consistent in performance.
This is the main problem on Anand's end, they need to sit down with a manufacturer firstly, in order to give us at least some valid graphs. It's understandable to a point, you don't bite the hand that feeds you, but... to a point. On the other hand, I trust TechReport's graphs... Actually TR is one of the very few websites I trust.
There's actually been a lot of research on frame jitter's effects on people. You measure how well people do a specific task with different amounts of it, and compare their performance on the task to the jitter.
Re problem of GPUView "Furthermore it still doesn’t show us when a GPU buffer swap actually takes place and the user sees a new frame, and that remains the basis of any kind of fine-grained look into stuttering." :
It can actually show you a "flip queue" in yellow color where you can see when the frame was started to get flipped with the front buffer, the end of the flip process, and the wait time until it reaches VSync signal and that's the time user sees the frame. Not sure why you mentioned this. Better to revise it. I have been using GPUView for about two years and it's really unique, no other tool can yet compete with it.
First of all: Great read! Very technical, but very interesting and still easy to understand. :)
Concerning V-Sync: I always enable it when I start playing a game for the first time. But 3 times out of 5, the gameplay gets too sluggish (that would probably be the added latency). So I have to turn it off and live with screen tearing and too much frames being rendered. It's a shame.
And reading all this and the issues involved, it makes me wonder how Oculus and the involved parties are getting around this problem. They are working on minimizing latency left and right. I would like to see their input on this and if they are only optimizing for a few hardware setups. :)
It is great to finally see someone deconstructing the issue of stutter in games, it drives me nuts! I also wrote an article that actually offers a solution to this problem. I developed a simple system that allows games to smooth out their delta by predicting the time when a frame will be rendered rather then using the measured delta from the update.
The main cause of stutter is due to a drop frame (by moving simply the 3d camera face to the polygons, shaders etc...) this can happen on any GPU/CPU, did Nvidia buy you ?
It can happen on video game console too...
Also caused by a non optimized engine that doesn't execute the instructions a render cache to prevent any stutter problem.
I can easily show you that on every GPU/CPU the problem exist but the fact is that problem doesn't come necessarily from the GPU/CPU but more about render path/engine works -> like i said you can prevent this by using a render cache to final render, it's a software problem not a hardware problem...
What about explaining that Nvidia stole works from a certain person ? no you can't talk about that, it would make problem to your website and your Nvidia contract
I bloody knew it. There were two reasons I moved away from AMD in spite of the on-the-surface better performance per $, and they were 1) Too many of my games wouldn't work properly with some random graphics feature switched on (many hours lost to this) and 2) Nvidia cards just seemed to be more smooth than AMD cards. Vindicated at last! My AMD gaming experience always looked choppy to me even if I was getting 100+fps, whereas Nvidia played more like a console in terms of chocolatey smoothness. Glad I stumped up the extra cash and went Nvidia instead of listening to people talking crap about there being no difference.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
103 Comments
Back to Article
eezip - Tuesday, March 26, 2013 - link
First one! Wow, I'm lame. Thanks Ryan - keep 'em coming!B3an - Tuesday, March 26, 2013 - link
Yes very lame. You should sit down and think what you're doing with your life and what kind of sad person you are.xaml - Tuesday, March 26, 2013 - link
It reads as if you didn't, so why do you point a finger.stickmansam - Tuesday, March 26, 2013 - link
I agree with the double blinding idea. Techreport had some videos on the skyrim stuttering and I showed it my bro with the card names covered and he actually preferred the AMD card. Personally I though both of them were playable since the 240fps video exaggerated any stuttering issues. If you can't tell the difference in a 60hz or 120hz video/monitor there is no difference.It would be nice if someone would develop an tool to measure the frames as they are being displayed, like as they are actually being viewed.
krumme - Tuesday, March 26, 2013 - link
The benefit of blindtest is twofold:It removes all the complexity involved in testing, and get to the point where it matters.
Secondly we get an oppinion as to what the benefits of the game have, going to higher quality settings.
Anand for much good, have the same staff, and we will get to know Ryan preferences in just a few rounds of testing.
Then he can have a nice assistant changing the cards for him :)
DanNeely - Tuesday, March 26, 2013 - link
While not blind, HardOCP's maximum playable settings testing is done to capture this. They report min/avg/max/graphed FPS; but at whatever combination of settings gave the most eye candy while still being fast and smooth enough to be enjoyable. At times this has resulted in observations that "while the raw FPS numbers imply that turning on X should be doable the gameplay results indicated otherwise" (generally due to stuttering problems).Havor - Tuesday, March 26, 2013 - link
I always liked HardOCP's maximum playable settings approach.But now i think that Ryan Shrout from PC Perspective is doing the best testing there is, by actually capturing all the frames with a capture card.
So no testing @ the start as FRAPS dose or some ware in the middle, no realworld frame output, better then that you cant do.
http://www.pcper.com/reviews/Graphics-Cards/Frame-...
http://www.pcper.com/reviews/Graphics-Cards/Frame-...
http://www.pcper.com/reviews/Graphics-Cards/Frame-...
Its a real interesting read, and i hope they will start doing testing real soon, as hard numbers are hard to come by, as there is still no perfect way of testing frame times.
Sabresiberian - Tuesday, March 26, 2013 - link
"Playable" and "optimal" are different things; for the most part no one is suggesting the games and cards that have more problems with stuttering are "unplayable".And, some people don't notice what bugs the fire out of others. Stuttering is one of those things. I think this has a lot to do with the fact that these problems have existed for quite awhile and people just got used to them, so kind of automatically ignore them.
So, I agree, if you don't notice it then it's not important. But if you do, then it is. :) I noticed this phenomenon years ago, and am very excited to see numbers that people can show quantifying the situation so that it can be discussed on more than a seat-of-the-pants level.
Soulwager - Tuesday, March 26, 2013 - link
The problem with double blinding is that some people notice more than others. If you're used to high end equipment on a 120hz monitor, you'll notice a hell of a lot more problems than dude off the street that normally plays on his laptop.medi01 - Wednesday, March 27, 2013 - link
Last time I've checked on toms, AMD's GPUs were better in this regard.Looks like yet another article to "compensate" for 7790.
maxcellerate - Saturday, March 30, 2013 - link
they have it's called an 'eyeball', but I doubt it'll catch on.Sandcat - Tuesday, March 26, 2013 - link
I've read rumors that the Kepler refresh is 'supposed' to be out in Q3 2013. Anyone know how accurate this is?stickmansam - Tuesday, March 26, 2013 - link
Maybe near the end of the year/holidays is what I am hearing for AMD and Nvidia refreshhero1 - Tuesday, March 26, 2013 - link
That's the correct guestimate. I think AMD will be the end of the year/start of 2014 and Nvidia probably end of 3rd quarter/start of 4th quarter since they don't have to make console hardware apart from their own handheld.EzioAs - Tuesday, March 26, 2013 - link
Wasn't it Q4? Anyway, as stickmansam said, it'll probably at the end of the year.stickmansam - Tuesday, March 26, 2013 - link
^ I think I've seen your name around somewhere -.-EzioAs - Tuesday, March 26, 2013 - link
THG?stickmansam - Tuesday, March 26, 2013 - link
Yeah that's where :)Integr8d - Tuesday, March 26, 2013 - link
In recapping the history, I believe it was around 04' or 05' that ATI and Nvidia were getting busted for optimizing their drivers for the benchmarks. Can't forget that boondoggle!faizo - Tuesday, March 26, 2013 - link
Great and very informative article.Kudos to AMD for admitting to their issues and working on a fix.
epoon2 - Tuesday, March 26, 2013 - link
Great Great article. I need 2 cups of coffee to finish it. Analytical, informative.The Keeper - Tuesday, March 26, 2013 - link
Only Direct3D was ever mentioned, what about OpenGL?Ryan Smith - Tuesday, March 26, 2013 - link
OpenGL will for all intents and purposes be the same.B3an - Tuesday, March 26, 2013 - link
Really great article. I like seeing stuff like this it's interesting.Can you answer this though: has the work that AMD have done with single GPU stuttering atleast improved multi-GPU stuttering a little? Or has this work had no affect at all on multiple GPU's, and we will have to wait for the July drivers?
Ryan Smith - Tuesday, March 26, 2013 - link
Multi-GPU stuttering is basically a superset of single-GPU stuttering. So while it doesn't fix any frame pacing issues, it will fix any single-GPU stuttering issues that made themselves present in multi-GPU mode.TerdFerguson - Tuesday, March 26, 2013 - link
A very long essay that really says very little about its supposed topic. Either it needed severe editing, or it's horribly mistitled.argosreality - Tuesday, March 26, 2013 - link
This article had some interesting information but it is in severe need of a work over by an editor.mayankleoboy1 - Tuesday, March 26, 2013 - link
I find this whole exercise very sporting of AMD. Nvidia might be thinking that this undermines their technical competitiveness. But i find it very mature of AMD to even admit that they have a problem, and are working on it.JeffFlanagan - Tuesday, March 26, 2013 - link
> But i find it very mature of AMD to even admit that they have a problem, and are working on it.Isn't that lowering the bar a bit too much? Is not lying in the face of convincing evidence really something they should be credited for?
mayankleoboy1 - Tuesday, March 26, 2013 - link
It sadly is. But thats how big tech corporations work. You ever heard Nvidia, Intel and Apple admitting they have a problem, even in the face of clear evidence?Galidou - Saturday, March 30, 2013 - link
Nope, never, I remember Nvidia back in the days of the 6800 GT that caused INFINITE stuttering(worse I've ever seen) with Nforce 3 or was it nforce 4 motherboard that I had. Only thing I could do to fix it was to underclock the video card, go back to older drivers. That made me lose 30-40% performance.They never ever fixed the problem or admitted it, EVER. I had to change video card after 6 months of trying everything. Nvidia forums were full of it not even an answer from them that they were fixing that issue. Some were able to fix this by disabling AGP fastwrites or other tricks but others had no choice doing what I did and lose the performance...
HisDivineOrder - Tuesday, March 26, 2013 - link
It's great that AMD admitted to a problem, but wow what a big problem to have totally missed. I guess they were so busy laying off engineers and R&D they didn't keep ahead of the game.haplo602 - Tuesday, March 26, 2013 - link
all nice and fine, but now please get your arse moving and do something for OpenGL performance AMD !!!kzinti1 - Tuesday, March 26, 2013 - link
If Windows is a major problem with stuttering, then why can't they develop a user-switchable "gaming mode" to make the OS prioritize the resources of the OS in favor of the games and their rendering processes?HisDivineOrder - Tuesday, March 26, 2013 - link
Microsoft is the company that might work something like that out. Unfortunately, Microsoft is also one of the companies that wants you to go buy a console. So I don't think they're going to facilitate what you suggest.I also suspect it's not as simple as what you suggest since it'd require game support, low level changes, etc. But ultimately, it doesn't matter how easy or hard it is because MS won't do it. They have no reason to.
If they cared about PC gaming in the slightest, I think they'd have ported Halo 3, ODST, Halo Reach, Halo 4, Gears of War 2, Gears of War 3, or Fable 2 to PC. Face it. MS gave up on PC gaming. Steam is what kept it going and Steam is what will carry it forward.
And the Steam Box may do exactly what you're suggesting.
mikato - Wednesday, March 27, 2013 - link
I'm pretty sure they care a bit because gaming is the only reason many people still use Windows.mgambrell - Wednesday, March 27, 2013 - link
methinks you place too much confidence in their acumen. As an exercise, find one thing microsoft has done lately which can be spun as plausibly in service of windows gamers.Dribble - Tuesday, March 26, 2013 - link
Fundamentally AMD failed because instead of making a driver to play games well, they make one that's there to give the highest fps at the expense of everything else. They were the first for example they customize the driver for every game - which makes the driver an order of magnitude more complex and introduced a lot more bugs to everything for a few % more performance.They did this because they care about the bottom line numbers shown in reviews more then actually playing the game well. Only now a reviewer has focused on stuttering are they focusing on it. It's not the only problem either - runt frames was also exposed by another tool which if anything is a cheat to exploit fraps - but AMD haven't got as far as discussing that yet.
This is a problem - AMD should be making drivers to play games well, not to look good in reviews. Journalists shouldn't be the ones having to do AMD's driver QA. I can't believe AMD didn't know about the stuttering - it's obvious even with a slow cam, they just didn't think it was important because it didn't effect their sales because journalists weren't reporting on it.
Spoelie - Tuesday, March 26, 2013 - link
Read the article again, your assumptions are wrong.Fixing the stuttering provided an increase in averaged framerates (in cases up to 13%), so it would've made them look a lot better even in traditional reviews not reporting on stuttering. And that's a huge delta for a small software change.
If anything, you could blame them for ineptitude, but there's no ill-will here.
Dribble - Tuesday, March 26, 2013 - link
The increase in fps was a surprise to them. The article suggests that if they had known it would increase fps they would have done it ages ago. Fact is there was stuttering, they knew about it but ignored it - the "well we assumed everyone else stuttered too" excuse isn't great. Clearly it was fixable, and a side effect was it even increased fps, but they were so fixated on fps charts in reviews that it was never deemed important enough to look at until the reviews started castigating them for it.If they had actually been trying to make the card as good as possible for gamers to play with they would have fixed it years ago as stuttering really matters to people trying to play the games.
JPForums - Tuesday, March 26, 2013 - link
Their stance wasn't "Everyone else stutters so why should we bother with it." It was closer to "Everyone else stutters and we have no more control over it that they do ... Wait, you're saying they don't stutter as bad as we do ... and fixing our stutter would've actually helped our performance. Aw, nuts." I agree with Spoelie, it was ineptitude, not ill-will.extide - Wednesday, March 27, 2013 - link
You make absolutely no sense.Galidou - Saturday, March 30, 2013 - link
Lots of people seem to think AMD does so much mistakes that everytime it happens the world speaks about it more intensely because they actually admit it instead of trying to HIDE things, they even let the sites like anandtech make reviews on their problem. Right now, at home, I have two very comparable systems based on overclocked SNB. One with a 7950, and the other with a gtx 660 ti. Both play games extremely well but I have more trouble with my 660 ti. I get lots of ''Display adapter has stopped responding'' while surfing the internet, when waking up from long idle states and when playing League of Legends. I switched drivers, did clean install and I can't get rid of it totally. No my card is not overclocked and I can make it furmark all day long without a problem.I decided to play on my girlfriend's computer(which has the 7950) when I play league of legends because you just can't be interrupted in this kind of game. It even froze in LoL a couple times, at first I thought it was my SSD but after reading the dump files, found out it was the 660 ti. But hey, Nvidia is perfect(we just don't see them speaking of their problems that's it)... 4 months of it now, thanks alot... I wrote on nvidia forums did my research did everything they told me. Good thing it's only with LoL, internet and long idles, everything else runs flawlessly.
HisDivineOrder - Tuesday, March 26, 2013 - link
Actually, I think you should reread the article. It's true that fixing these stuttering issues has given them some frame rate improvements, but the article seemed relatively clear on the point that they were focused on frame rates and not frame latency or frame interval or whatever they're choosing to call it today.They had all their focus on one aspect of driver development and that actually cost them in that area because they weren't considering a more well-rounded approach.
I'll grant you AMD was pretty inept though. This has been problem they've had for years and it's taken them this long to suss it out...
piroroadkill - Tuesday, March 26, 2013 - link
Hey, what about PC Perspective: http://www.pcper.com/reviews/Graphics-Cards/Frame-...Looks to me as being the best way to measure it, as it uses a DVI capture card to actually capture what the user sees, forgoing any overhead software may have..
Rick83 - Tuesday, March 26, 2013 - link
Yes, that is the correct way to measure frame time.KikassAssassin - Tuesday, March 26, 2013 - link
Yeah, their method looks like the best of both worlds. It gets around the limitations of FRAPS without the complexity and difficulty of using GPUView.Anand Lal Shimpi - Tuesday, March 26, 2013 - link
The ideal method would be something that gives us timestamps at both ends of the pipeline, but that's a tall order. The PCPer method is very interesting indeed... ;)Mopar63 - Tuesday, March 26, 2013 - link
First very informative article. The issue at hand is that this so called concern is based on an individuals perception. Remember we are not talking about a stuttering that was so bad as to be noticeable to all gamers. Scott basically had to make a video specifically designed to point out the issue for others to see it originally.Because there is no real way to quantify the personal experience we have an issue in the fact that we now have a measurement craze that is being treated as fact when it is based in the end on subjection for the final result.
Having access to various levels of AMD and NVidia based machines I can tell you that my gaming experience across them has been pretty uniform in most cases. The cases when I had a bad experience, probably a wash as they are on both platforms.
I think the biggest issue is we sometimes get to caught up in the technology. We let benchmarks and measurement programs dictate to us what we will get the most enjoyment from with our gaming experience. A game is not the frame rates but the play that matters. While frame rates might play a roll it is not the measurement of them that makes that part of the fun.
At the end of the day the single best test of a video card is not a benchmark suite or tool to measure frame rendering time. The best tool is to play the games you want and see if you get the game experience you desire. Turn off the benchmark and turn on the game, that is the ONLY true test of what is best.
HisDivineOrder - Tuesday, March 26, 2013 - link
Speak for yourself. I've noticed this problem between nVidia vs AMD for years. For many years, gamers have said that nVidia cards are "smoother." People didn't listen because they didn't want to hear the truth or because they were likely stuck with one high end from AMD and a low end or medium end from nVidia.But comparing equivalent cards, I can tell you my experience has always led inescapably to the "feeling" that the nVidia card is smoother at the same or even slightly lower frame rate.
This just proves what I "felt" was the case was in fact really the case. If you didn't see it, then that's a fail on the part of your visual acuity or perhaps you had a bias you wanted to see, so you saw less than everything present.
But the stutter was always there. Now even AMD admits it.
Tuvok86 - Tuesday, March 26, 2013 - link
This is great victory for all of the tech press.When people started complaining about stuttering years ago we were only dreaming of getting so much attention from gpu brands.
I still remember someone constantly saying "micro-stuttering doesn't exist", I wonder how they feel now that they enjoy the fps and smoothness benefits.
In any case I praise constructive journalism that triggered a significant leap in the technology.
BrightCandle - Tuesday, March 26, 2013 - link
One important fact I feel is missing in your treatment of what it is fraps is measuring and why its more representative of problems than you and AMD think it is. For some reason everyone who makes this argument that fraps is isn't very useful seems to skip this one, but its really really important.Fraps measures at the present call and that isn't a random choice. Because the present call has a few different modes of operation, but all games use blocking mode. What that means is that if the context queue is full (which it normally is) then game thread is held up waiting for that present call to complete. Subsequent present calls are regulated by the GPU's driver in this case as the thread is held and when it chooses to accept the completion of that frame only then can the games thread continue. Since Fraps is measuring this it can see when the driver is accepting frames in an uneven fashion, so while you might see even frames presented to the monitor due to the buffering there is still a knock on effect.
Game simulations produce particular frames of their simulation, sometimes in the same thread as the present call and sometimes in a different thread. Regardless they use the release of the present call as the end of their rendering step and that allows another frame to be started or delivered. So if the present calls are coming back unevenly the game simulation itself will stutter as it tries to produce as many simulation steps as the rendering is producing. If the present calls are stuttering there is a feedback loop into the game simulation that is too causing it to stutter.
Its this feedback loop on the rendering and game simulation which causes much of the problem, and it starts in the GPU driver. It might very well be caused by Windows but the big difference we see in the manufacturers solutions tells us that its almost entirely the manufacturers fault when it happens and impacts on gameplay.
So quite rightly fraps does not measure stuttering out to the screen, it measures the GPUs regulation of the frame rate of the game rendering and its simulation and that does cause real stuttering, both of the subsequent present calls and the game simulation.
Of course pcperspective have now shown that AMD's SLI stuttering out the DVI port is considerably worse than Fraps, so much so they considered what they are doing is a cheat as the frames aren't real. But you need bothperspectives, the output and the input to the pipeline to see the impact on the game. Its not just the frames themselves that have to be regulated to be smooth its also the game simulation that must run smoothly, and it is regulated by the handling of the context queue.
JPForums - Tuesday, March 26, 2013 - link
There are two things you need to keep in mind:1) Nvidia also agrees with the limitation of FRAPS. In fact, IIRC they were the first to voice the issue that FRAPS recordings are in the wrong place and can only infer what actually needs to be recorded. The author is correct, when Ati and Nvidia agree, we should at least pay attention.
2) Though your your points are AFAIK correct and well articulated, they still point to the issue of FRAPS inferring, rather than recording the the targeted information. The difference is, rather than consistency of output frames, you are looking for consistency of simulation steps. I agree that this is a metric that really needs to be covered. In fact, I would even go as far as matching simulation steps to their corresponding frame times to expose issues when short steps are accompanied by long frames or vice versa.
Unfortunately, FRAPS can't measure any of this directly and even for your points proves to be limited to inference. That said, until a reviewer gets tools that can reveal this information, inference via FRAPS is better than no information at all. Pcperspective's comments on AMD's stuttering issues are related (as they state) to crossfire setups. I could see the differences between CF and SLI in blind tests (though SLI also has some microstutter) and this only confirms it. The runt frames only add fuel to the fire. I'm open to using AMD in single GPU builds, but only use Nvidia for multiGPU builds. Perhaps this will change in July, but I'm guessing there will still be plenty of work to do.
JPForums - Tuesday, March 26, 2013 - link
I should probably expand a little on what I consider a limitation of FRAPS for stutter caused by simulation steps. FRAPS inserts itself at the output of the render and is therefore subject to a variable delay between the simulator time step through the render. Important information can still be inferred, like simulation stutter in AMD's heartbeat waveform. However, I'd still rather get a timestamp directly at the output of the simulator rather than at the output of the renderer, if it ever becomes an option. Unfortunately, that would probably require cooperation with the game developer, so I'm not sure that will ever happen.tipoo - Tuesday, March 26, 2013 - link
The third page makes me wonder, just how much would a real time operating system improve performance? QNX on BB10 is real time, the PS4 OS may be too.juampavalverde - Tuesday, March 26, 2013 - link
Time to update the GPU review template guys... At least copy&paste PCPer and TechReport methods.cjb110 - Tuesday, March 26, 2013 - link
Sounds like there's a market for a tool then, something that does what GPUView does but in simpler manner (like Fraps presents).drbaltazar - Tuesday, March 26, 2013 - link
sadly the issue they find isn't exsactly caused by the gpu!it is at the os end!data fragmentation at various level is often the cause.and this happen everywhere,at the processor cache level to the server cache level!ms say it doesn't mather !they re wrong!it affect everything related to image quality.bufferbloat also is the main problem.mtu,udp fragmentation ,multithreading and rss fragmentation etc etc etc!oh they say they can reconstruct the data in the proper maner that wont impact performance or quality!again ms is either wrong or unknowing of the problem these various issue cause .I haven't event started on the gpu side yet!all that data manipulation etc is the main issue !how to fix it?mm!probably use official standard limit like the 1460 for mtu and add udp to that also so that it is also at 1460.(just a random exemple cause these will need to be tweaked ,why?so that packet don't get fragmented anywhere in the computer or the server.or they tell people how to make it happen ,because right now not many have 1080p quality even most have a 1080p monitor.so imagine if amd is using window idea to tweak their gpu?like .net4 etc !(yep it become a nightmare)hopefully they ll fix this but all side have been on a race for performance .(wouldn't want to sell a = performing w8 instead of w7 .it wouldn't sell!i am all for getting better performance but not at the expense of subpixel quality of graphic.nvidia is probably better because they noticed ms error and have worked to avoid the os mistake by using standard and proper ways .I aint saying ms is wrong maybe they can really fragment packet and have everything being fine and dandy looking in 1080p.but I will tell you this.in most area of computing it feels like this:os is saying 255.0.0 and at the other end for some reason its like our old phone game,at the other end what is being done isn't at all what the os said the beginning (and viceversa)hopefully these idea of new data mining and testing tool will go deeper and test what is actually going on in our computer,network and server datapath so they all can work together.cause right now?our game look 1080i even tho we are all set at 1080pmi1stormilst - Tuesday, March 26, 2013 - link
I love you guys, but this article comes off a bit like sour grapes. The Tech Report dove into this issue head first and admitted from the beginning the testing methods may not be perfect. They have continued to be clear on this and you made no mention of the high speed video tests that they performed. The bottom line is The Tech Report is primarily responsible for getting AMD to get on the ball with this issue. Regardless of AMD's bag of excuses and their sudden clarity on the best methods for testing we would not be where we are without the sold work of The Tech Report. I feel that if the FRAPS method of testing was sufficient for bringing these issues to light then a job well done. The situation will only improve from there and Scott Wasson and company deserve more praise than this sour attempt of an article to discredit the good work they have done. If that we not your intention then I apologize, but it comes off as such.brybir - Tuesday, March 26, 2013 - link
I did not see it this way at all. Instead, I read it as TechReport started a trend in evaluating stuttering that most were not looking for, and that while there is some merit to their methods, there are other better ways of evaluating the issue. I did not see any effort to hide, obscure, or otherwise show "sour grapes" to them for their testing.As to the merit of the article, if AMD, Nvidia, and Anandtech folks all agree that the methods used by TechReport are okay but could be improved upon with better tools, then the end result will be better for everyone. Much as standard bench-marking software has evolved a lot over the the last decade, the bench-marking for this type of testing will change dramatically as people find interesting and new ways to really get in depth with the issue and generate data that is easy to aggregate and report. I think that is a net benefit for all of us!
mi1stormilst - Tuesday, March 26, 2013 - link
All of us will benefit from the light shed on the subject with better testing and companies paying closer attention to issues and work arounds related to the subject. Still we would not even be talking about better testing methods right now without the attention it got from The Tech Report. I look forward to more sites implementing some type of real world testing methods that results in a true user experience evaluation. I reread the article and still standby my original conclusion. The Tech Report gets credit, but rather then stopping there this article seems to attack their methodology when they themselves had already admitted that it was less then perfect. To date there are still not better tools being used for reviews and The Tech Report still got the point across with what was available. I am a huge fan for what they did over there as I could not pinpoint why my AMD experience was less than optimal. It forced me to early retire my 6950 grab a very affordable 660 OC and enjoy a much smoother game experience. This is my first nVidia card since my trusty 4200ti and I am not looking back until AMD is on par with nVidia in the stuttering department...it was literally making me motion sick )-:SPBHM - Tuesday, March 26, 2013 - link
"holding back one frame but not another can sometimes make the frame display evenly, but from a simulation step only a few milliseconds after the previous step"wouldn't this also happen with the single GPU "heartbeat stuttering"?
BrightCandle - Tuesday, March 26, 2013 - link
Yes it would, which is exactly the problem with the heartbeat pattern that AMD's problem causes. You can deliver the frames evenly out to the monitor but their contents has a noticeable stutter due to the graphics driver accepting the frames unevenly. The heartbeat is a sign of a real problem without a doubt, all non smooth frame time captures are. What they are not is a sign that the DVI monitor is seeing frames at those periods, but then no one ever said that was what was being measured anyway.The best way to think about it is that this is the problem going into the pipeline, measuring the output also needs to be done to get the smoothness on the output. Only with both can you understand the impact. We have half the picture, and that half is accurately measured by fraps.
Gunbuster - Tuesday, March 26, 2013 - link
Design and launch a product. Ignore user feedback.Did we forget about those people with $2000 laptops sporting AMD mobile card drivers that didn't work correctly for over a year due to some bug with the graphics switching MUX? This seems to be a pattern that revolves around AMD software people being wholly out of their depth, overworked, or just not caring. They don’t even seem to be able to figure out when they have a fix. The laptop GPU story here on AT was presented as AMD sending over beta drives and asking “Did we fix it this time?”
rootheday - Tuesday, March 26, 2013 - link
One minor correction to the description of the submission of commands through the stack - the DirectX runtime under Windows Vista and later does NOT accumulate a frames' worth of draw calls before sending them to the UMD. I believe it sends state and draw calls to the UMD immediately.The UMD accumulates commands in the command buffer and flushes them to the KMD either when a present call occurs, when the command buffer is full, or when the application requests to read back the results of enqueued rendering (Map/Lock/read Query result).
It used to be true under Windows XP that the dx runtime accumulated calls and dispatched them to the driver - but that is because in XP, the driver ran in kernel mode and it was too expensive to make the user mode->kernel mode transition on every "SetState", etc call.
tynopik - Tuesday, March 26, 2013 - link
"frame latter than it would have" -> later (pg 3)cactusdog - Tuesday, March 26, 2013 - link
As a long time ATI/AMD fan this report doesn't fill me with confidence. It appears AMD is using anandtech for their public relations spin on the stuttering issue. I don't blame anandtech for running the story, AMD's comments are newsworthy and anandtech deserves credit for being honest about AMD's intentions. On the negative side, the explanation about fraps not being an effective tool only need to be said once, it seems (by the number of times it was mentioned) that AMD's message is to make sure everyone knows Fraps its not accurate, but doesn't explain why Nvidia performs better.On the issue, it sounds like AMD is conceding and preparing us for much of the same. No where in the explanation do they mention why Nvidia performs better in the latency tests, other than to say its not what the end user is seeing. Well I disagree, users have been complaining about stuttering for years. I just don't believe that AMD have never looked into this issue before. Also with the multi-gpu stuttering. It has been an issue since crossfire/SLI first appeared and nothing has really happened there.
Im a fan of AMD cards but I use both brands and personally I have noticed Nvidia do a better job with latency and general responsiveness in game, whereas ATI/AMD has the edge with image quality. Its subtle, and probably not something the average user notices but a lot of people do notice.. If AMD can solve this issue they would sell many more cards but by the sounds of this article, its too big and complex for them to solve completely without major work. Hence the excuses. Nvidia has to play by the same rules, the same OS etc and they do a better job at latency/stuttering, hopefully AMD can fix it enough to at least perform as good as a NVidia card.
WaltC - Tuesday, March 26, 2013 - link
"NVIDIA made a big deal about moving away from timedemos and average frame rates during the early GeForce FX (NV30) days, when its cards might have delivered a decent gaming experience but were slaughtered in most benchmarks."Well, that's not really what happened at all...;) The chip "slaughtering" everything nVidia made in those days was the ATi R300. Seems rather strange to tell just half of that story. And the problem nVidia had with benchmarks wasn't technical--it was that nVidia was found to be actively cheating in 3dMark (camera on rails), among other cheats/shortcuts/optimizations in their drivers. The benchmarks told a story nVidia couldn't abide, and that was how much better the R300 was than anything nVidia had at the time. R300 was in every sense a revolution in the 3d gpu markets, blowing everything else away. All gpus on the market today are descended from R300 (just as all Intel and AMD x86 cpus are descended from AMD's original 64-bit Opterons.) nVidia did eventually own up to all of it, right before cancelling the nV30 after a month or two in production, however. People kept publishing proof after proof of what nVidia was doing until finally the company said "uncle." nVidia has been a better company since, imo. At least, its products are certainly better.
I'm using a single ATi gpu and over the last few years I have to say that I haven't seen any stuttering worth mentioning. Whenever I have seen stuttering it is usually due to some software condition or other, and rectified by the appropriate patch. I do appreciate your pointing out that Fraps isn't perfect and I think TR should stop pretending that it is. Fraps as you point out was never intended to measure this kind of latency and so using it to produce data other than frame-rate data is an "off-label" use of the program, imo. And also as you point out, I use vsync more often than not.
Really, though, I would loathe seeing AMD optimizing its drivers just to look better in TR's off-label Fraps usage...!...;) Let's hope that doesn't happen as I got quite a belly full of that sort of thing back in the nV30 days--enough to last me a lifetime.
beginner99 - Tuesday, March 26, 2013 - link
How can FRAPS detect any vendor-specific stuttering if it injects itself before the gpu-driver is called?The second thing is that v-sync is just crap. I'm not a professional gamer, not even close but in certain games turning it off made me a much better player and the difference is huge. even more annoyingly it was not directly noticeable. I did not "feel" anything changed. Except that my stats were better. Tearing and stuttering: no issue for me so far.
DanNeely - Tuesday, March 26, 2013 - link
The timing at the point it's measuring is normally blocked until the queue the GPUs feeding from has an open slot?Juddog - Tuesday, March 26, 2013 - link
What the hell you talking about? Network latency is an entirely different subject.Juddog - Tuesday, March 26, 2013 - link
I had meant the above as a reply to the guy talking about network fragmentation; I'm not sure why the reply in the new format doesn't auto-nest the response.danielkza - Tuesday, March 26, 2013 - link
Because then the measurement wouldn't be representative of the performance users will actually see?polaco - Tuesday, March 26, 2013 - link
Thanks a lot for this interesting article. Is astonishing to see how minimal software issues can severely degrade performance and efforts done in other areas, turning a company less competitive with the money losses this takes with it.Also is a reminder of how important is to implement deep quality and performance evaluations in software development. Is a shame that in today software industry the delivery dates are more important than quality many times and programmers end up delivering half baked applications from also half baked requirements.
Thanks again.
sudz - Tuesday, March 26, 2013 - link
Good to know I'm not going crazy. Almost every game I play has a decent frame rate, but still doesn't seem smooth. (Gigabyte Windforce 6850 OC) Tried underclocking, overclocking, Different PC's... I thought I had a dud card.DemBones79 - Tuesday, March 26, 2013 - link
Reading through the whole article, I became increasingly convinced that it's not that FRAPS is necessarily a bad tool for measuring this, but that people need guidance in how to interpret the graphs correctly.The first time I saw a frame latency (or whatever you're calling them now) graph, my first impression wasn't, "Wow, look at all these little latency spikes." It was, "Holy sh*t! Look at those huge freaking spikes!" It was a simple matter of severity. I think anyone can take a look at the "heartbeat", see that it is a recurring pattern with a relatively consistent frequency, and- while they may not be able to say for certain if it is indicative of a problem- they can say that it is "normal" for that particular card. It's the huge spikes, the ones that aren't occurring at consistent intervals, that are so much more severe than the "heartbeat", that are the issue.
How hard would it be for a reviewer to draw a pair of horizontal lines across the graph to indicate the limits of "normal" stuttering, where anything beyond the lines in either direction would be considered "abnormal"? A method of separating the signal from the noise.
Furthermore, I thought it was reviewers noticing a difference- that framerate alone couldn't explain- in the way games played between ATI and NVIDIA that prompted the whole investigation into latency. Several sections in the article mention how FRAPS results may not be indicative of user experience. But it was user experience that prompted using FRAPS to try and explain what was being observed.
JPForums - Tuesday, March 26, 2013 - link
Thre are two things you need to keep in mind:1) Nvidia also agrees with the limitation of FRAPS. In fact, IIRC they were the first to voice the issue that FRAPS recordings are in the wrong place and can only infer what actually needs to be recorded. The author is correct, when Ati and Nvidia agree, we should at least pay attention.
2) Though your your points are AFAIK correct and well articulated, they still point to the issue of FRAPS inferring, rather than recording the the targeted information. The difference is, rather than consistency of output frames, you are looking for consistency of simulation steps. I agree that this is a metric that really needs to be covered. In fact, I would even go as far as matching simulation steps to their corresponding frame times to expose issues when short steps are accompanied by long frames or vice versa.
Unfortunately, FRAPS can't measure any of this directly and even for your points proves to be limited to inference. That said, until a reviewer gets tools that can reveal this information, inference via FRAPS is better than no information at all. Pcperspective's comments on AMD's stuttering issues are related (as they state) to crossfire setups. I could see the differences between CF and SLI in blind tests (though SLI also has some microstutter) and this only confirms it. The runt frames only add fuel to the fire. I'm open to using AMD in single GPU builds, but only use Nvidia for multiGPU builds. Perhaps this will change in July, but I'm guessing there will still be plenty of work to do.
JPForums - Tuesday, March 26, 2013 - link
Thre are two things you need to keep in mind:1) Nvidia also agrees with the limitation of FRAPS. In fact, IIRC they were the first to voice the issue that FRAPS recordings are in the wrong place and can only infer what actually needs to be recorded. The author is correct, when Ati and Nvidia agree, we should at least pay attention.
2) Though your your points are AFAIK correct and well articulated, they still point to the issue of FRAPS inferring, rather than recording the the targeted information. The difference is, rather than consistency of output frames, you are looking for consistency of simulation steps. I agree that this is a metric that really needs to be covered. In fact, I would even go as far as matching simulation steps to their corresponding frame times to expose issues when short steps are accompanied by long frames or vice versa.
Unfortunately, FRAPS can't measure any of this directly and even for your points proves to be limited to inference. That said, until a reviewer gets tools that can reveal this information, inference via FRAPS is better than no information at all. Pcperspective's comments on AMD's stuttering issues are related (as they state) to crossfire setups. I could see the differences between CF and SLI in blind tests (though SLI also has some microstutter) and this only confirms it. The runt frames only add fuel to the fire. I'm open to using AMD in single GPU builds, but only use Nvidia for multiGPU builds. Perhaps this will change in July, but I'm guessing there will still be plenty of work to do.
hero1 - Tuesday, March 26, 2013 - link
Long time reader first timer commentor. I really liked this article, and have liked most of the articles here. What I want to say is, I hope that AMD fixes their drivers and address both single and dual gpu issues. I personally didn't have any stuttering when I had 2x7970s but they sometimes lost the link to each other and my system would only see one. I switched to the Titan since I got it for a reasonable price. Now this articles makes me wonder whether I should go back and grab the 2x7970s and save some cash in hopping that AMD has the mutliple GPUs issue solved by early summer. It's good to see them working to address the issue and hope we never have to encounter this again once it's done with. Next step should be how their mutli gpu solutions scale. Thanks Ryan and keep up the good work.Hrel - Tuesday, March 26, 2013 - link
That was a good breakdown of Direct3D. I'd like to see another one for OpenGL if we could. A side by side comparison would be nice.jb14 - Tuesday, March 26, 2013 - link
Perhaps a small typo: 'without'? Pg 4 para 2."AMD, quite bluntly, has a problem with how FRAPS is being used in some cases. To be clear here FRAPS is a wonderful tool, and withOUT it we would be unable to include a number of different games in our hardware reviews."
Very interesting article, still digesting it all, thank you for taking the time & effort to share it.
Deo Domuique - Tuesday, March 26, 2013 - link
I told you... AMD Peasants, that's what we are. Stuttering, Microstuttering, Flashing/Flickering black artifacts on DX9 games, many times we're forced to disable GPU acceleration on very few programs outside gaming that use the card, like Firefox, Flash and even Windows...I'd seriously prefer sporadic issues on games, but at least all the programs and Windows to be working flawlessly. Even on video occasionally we get problems...
I guess I learnt the hard way that all "rumors" about bad AMD drivers experience are god damn true... And no, Nvidia isn't like that nor in the slightest. In my many years experience with Nvidia cards, I can only name you one serious problem I faced, but the solution came relatively fast, 275.33 drivers started Browser TDR, it ended with 290.26 drivers.
polaco - Wednesday, March 27, 2013 - link
What are you talking about? I have had ATI / AMD cards for years almost 10 years. Never ever an issue like the one you are describing. Disable GPU acceleration? Serioulsy? that's incredibly ridiculous.alacard - Tuesday, March 26, 2013 - link
Sanctimonious.Guys, i know you think you're Gods one true miracle to tech news, but would it be so much to ask to stop writing your articles as if there were no question as to the veracity of that claim? You sound so pious, so arrogant, so self-righteous in this article. Please tone it down.
FriendlyUser - Tuesday, March 26, 2013 - link
Fantastic article! The presentation is very clear and clarifies the situation, especially the question of whether FRAPS is an appropriate tool. The whole latency has been way overblown by techreport and the nvidia fanboys. Anyway, the AMD engineers have done a great job on improving things.GordonM256 - Tuesday, March 26, 2013 - link
Very nice "damage control" article for both AMD and Anandtech! Well done with excuses like "FRAPS sux anyways so we will wait for "better tools", giving AMD more time to fix the issues, which aren't really issues anyways because most people won't notice any stuttering" ;-)P.S: Yes, I know that FRAPS has issues (Scott himself said that), but you could've said it in more neutral way and much earlier.
JonnyDough - Tuesday, March 26, 2013 - link
Does this mean that they will be updating OLD drivers as well? Specifically for a VERY LARGE base of HD4800 series users?croc123 - Tuesday, March 26, 2013 - link
Totally NOT about the article.... You had a comment regarding Dr. Pabst, that (being blue) I thought might be a link to something bearing some information regarding the venerable Dr. Tom... But no... It just linked back to Tom's hardware, which I am sure Dr. Pabst would have considered an insult. Tsk Tsk...StevePeters - Tuesday, March 26, 2013 - link
Great write up.Can someone explain why it is not possible to hook into the interrupt that the GPU generates after rendering a frame to provide the measure that's FRAPS is missing?
pandemonium - Wednesday, March 27, 2013 - link
Superb article! The detail of explanation and the reference citing - absolutely excellent. Thanks, Ryan!Shark321 - Wednesday, March 27, 2013 - link
Overall a good article, but it has one huge problem. Ryan, you are repeating about 10 times that there is no good tool to replace the Fraps measuring, which is inaccurate.But there is. PcPerformance has intruduced a new microstutter measuring method weeks ago: http://www.pcper.com/reviews/Graphics-Cards/Frame-...
rickcain2320 - Wednesday, March 27, 2013 - link
I just bought an AMD/ATI card and not only do I have stuttering I have that horrid POWERPLAY kicking in all the time with screen tearing. I'm pulling my hair out and wondered why I didn't buy Geforce. My old 8800GTS was doing great but it finally gave up the ghost one day, I should have stuck with at least something consistent in performance.Deo Domuique - Wednesday, March 27, 2013 - link
This is the main problem on Anand's end, they need to sit down with a manufacturer firstly, in order to give us at least some valid graphs. It's understandable to a point, you don't bite the hand that feeds you, but... to a point. On the other hand, I trust TechReport's graphs... Actually TR is one of the very few websites I trust.lally - Wednesday, March 27, 2013 - link
There's actually been a lot of research on frame jitter's effects on people. You measure how well people do a specific task with different amounts of it, and compare their performance on the task to the jitter.http://lmgtfy.com/?q=virtual+reality+frame+rate+ji...
NerdT - Wednesday, March 27, 2013 - link
First of all, it's a very good read. Thanks.Re problem of GPUView "Furthermore it still doesn’t show us when a GPU buffer swap actually takes place and the user sees a new frame, and that remains the basis of any kind of fine-grained look into stuttering." :
It can actually show you a "flip queue" in yellow color where you can see when the frame was started to get flipped with the front buffer, the end of the flip process, and the wait time until it reaches VSync signal and that's the time user sees the frame. Not sure why you mentioned this. Better to revise it. I have been using GPUView for about two years and it's really unique, no other tool can yet compete with it.
mikato - Wednesday, March 27, 2013 - link
Nvidia: ok we knew our ride here would end sometime. No more competitive advantage "secret bonus" in performance.AMD fanboy: argh, as usual my AMD parts will perform better with time, and not get the respect deserved since all the benchmarks were done already.
JeBarr - Thursday, March 28, 2013 - link
What a long drawn out way of helping AMD in the PR department.Unlike most commenters, what I took away from this article is the fact that Ryan Smith is no longer qualified to conduct GPU benchmarks.
GPUView too complicated? Seriously?
lol.
Death666Angel - Thursday, March 28, 2013 - link
First of all: Great read! Very technical, but very interesting and still easy to understand. :)Concerning V-Sync: I always enable it when I start playing a game for the first time. But 3 times out of 5, the gameplay gets too sluggish (that would probably be the added latency). So I have to turn it off and live with screen tearing and too much frames being rendered. It's a shame.
And reading all this and the issues involved, it makes me wonder how Oculus and the involved parties are getting around this problem. They are working on minimizing latency left and right. I would like to see their input on this and if they are only optimizing for a few hardware setups. :)
LoccOtHaN - Wednesday, April 3, 2013 - link
Mirillis Action! that Program is an Alternative to Fraps (no stutering ! and its werry light ) RECOMENDED by Ne01KilledByAPixel - Thursday, April 4, 2013 - link
It is great to finally see someone deconstructing the issue of stutter in games, it drives me nuts! I also wrote an article that actually offers a solution to this problem. I developed a simple system that allows games to smooth out their delta by predicting the time when a frame will be rendered rather then using the measured delta from the update.http://frankforce.com/?p=2636
Bilna - Saturday, April 6, 2013 - link
False defintion of Stutter.The main cause of stutter is due to a drop frame (by moving simply the 3d camera face to the polygons, shaders etc...) this can happen on any GPU/CPU, did Nvidia buy you ?
It can happen on video game console too...
Also caused by a non optimized engine that doesn't execute the instructions a render cache to prevent any stutter problem.
I can easily show you that on every GPU/CPU the problem exist but the fact is that problem doesn't come necessarily from the GPU/CPU but more about render path/engine works -> like i said you can prevent this by using a render cache to final render, it's a software problem not a hardware problem...
What about explaining that Nvidia stole works from a certain person ? no you can't talk about that, it would make problem to your website and your Nvidia contract
AvonX - Friday, April 12, 2013 - link
You really are an idiot by supporting and defending a failing company.Dangerous_Dave - Friday, May 10, 2013 - link
I bloody knew it. There were two reasons I moved away from AMD in spite of the on-the-surface better performance per $, and they were 1) Too many of my games wouldn't work properly with some random graphics feature switched on (many hours lost to this) and 2) Nvidia cards just seemed to be more smooth than AMD cards. Vindicated at last! My AMD gaming experience always looked choppy to me even if I was getting 100+fps, whereas Nvidia played more like a console in terms of chocolatey smoothness. Glad I stumped up the extra cash and went Nvidia instead of listening to people talking crap about there being no difference.