Many of you probably may have noticed that we recently have included the so called frame times in a few benchmarks. It turns out that just an average fps-value does not represent the entire picture any longer; some games run better on video cards from a specific brand, despite that they calculate less frames per second. That is because of the fact that it takes (a lot) longer for some frames to be calculated, something that can’t be concluded just out of fps-averages.
AMD realizes for quite some time that games like Far Cry 3 stutter on their video cards, and fixed many of those issues with driver updates. The manufacturer has taken the time to respond to the stuttering problems, and a road map has been released at the same time that shows when AMD wants to achieve certain milestones. Earlier today, on Anandtech, a long article has been published that explains in detail what the cause of the problem is, and what can be done about it.
By the way, the problems don’t necessarily always lie with the video card itself, because the drivers and especially Windows are also still in between it. In order to calculate a frame, the program gives an instruction to Windows first that subsequently redirects it to the GPU. Therefore the stuttering can be caused by the video chip itself, it simply cannot calculate a frame on time, but can also be that the driver takes too long to sent a frame to the GPU. Of course the processor can stall the entire process if it needs to save computing power for other programs or drivers on these crucial moments.
At which rendering times someone notices stuttering, or finds it annoying, depends on the user. AMD indicates somewhat justly that we can measure times, but that we actually can never predict what the consequences are for the overall user experience.
The program that’s usually utilized to measure the times in between the frames is called FRAPS, what’s not ideal according to AMD. Before a frame is shown on the screen the program may request a short pause in order to calculate the screen overlay. Moreover, only the Present calls are measured as frames. Therefore FRAPS works with pretty much all programs, but there are also some objections according to AMD. Because FRAPS works on the Windows,- driver- and hardware layer, it can only specify what is being sent as an instruction and not what (if any delayed) the final result is.
This would exaggerated some of the stuttering problems, while it’s overlooked in other situations. According to Anandtech, Nvidia shares the same opinion, for the same reasons as mentioned above. An alternative that was mentioned by AMD is Microsoft’s GPUView, a program that monitors the rendering pipeline of the video card.
The biggest reason for the stuttering is simply that AMD claims to have always tried to compete with Nvidia in terms of marketing; the frames per second. The faltering has never been studied, so nothing has ever been done about it. Previously, the video card manufacturer even assumed that the problem was caused by the operating system or other programs; of course knew its own drivers exceptionally well. On top of that AMD wrongly assumed that Nvidia and Intel were dealing with the same problems, due to the lack of proper analytical studies. Ultimately, the solution to the problem was in their own backyard. Most problems were even very easy to solve, so was the outcome of several recently conducted studies of the company itself.
AMD has worked hard to solve the stuttering problem, and in the mean time has released new beta versions of its Catalyst drivers online that have slight improvements. By the way, in DirectX9 the bottleneck should’ve been solved, and at the moment they’re working hard to make DX10 run fluently. From this review of Techreport it turns out that the Catalyst 13.2 beta performs significantly better when it comes to frame times that version number 12.11 b8, what becomes clear in the chart below.