Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
AMD Bug Graphics Hardware

AMD Tweaking Radeon Drivers To Reduce Frame Latency Spikes 105

crookedvulture writes "Slashdot has previously covered The Tech Report's exposure of frame latency issues with recent AMD graphics processors. Both desktop and notebook Radeons exhibit frame latency spikes that interrupt the smoothness of in-game animation but don't show up in the FPS averages typically used to benchmark performance. AMD has been looking into the problem and may have discovered the culprit. The Graphics Core Next architecture underpinning recent Radeons is quite different from previous designs, and AMD has been rewriting the memory management portion of its driver to properly take advantage. This new code improves frame latencies, according to AMD's David Baumann, and the firm has accelerated the process of rolling it into the official Catalyst drivers available to end users. Radeon owners can take some comfort in the fact that a driver update may soon alleviate the frame latency problems associated with AMD's latest GPUs. However, they might also be disappointed that it's taken AMD this long to optimize its drivers for the now year-old GCN architecture."
This discussion has been archived. No new comments can be posted.

AMD Tweaking Radeon Drivers To Reduce Frame Latency Spikes

Comments Filter:
  • Give them credit (Score:5, Insightful)

    by Anonymous Coward on Wednesday January 02, 2013 @07:14PM (#42455729)

    taken AMD this long to optimize its drivers for the now year-old GCN architecture.

    Give them some credit... they've acknowledged the problem and this isn't a simple tweaking/bugfix, this is a complete redesign and rewrite of the entire driver architecture.

  • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday January 02, 2013 @07:33PM (#42455915) Homepage

    This only went on so long because tech sites use such poor, useless benchmarking methods. Minimum/Average/Maximum FPS, or often just Average/Maximum FPS, are worthless!

    A game, or a video card, can average 100fps, but still have that one frame every second that performs some extra I/O and takes 3x longer than usual causing an annoying stutter effect.

    A good first step would be to use frame latency percentiles.. i.e. 90% of frames are at least 60 FPS, 95% of frames are at least 50 FPS, 99% of frames are at least 40 FPS.

    The next step is to measure spikes themselves -- low framerate sucks, but not nearly as much as a stuttering framerate. A sudden spike from constant 10ms/frame to 50ms/frame and back should be counted as far more detrimental than a smooth transition from constant 10ms to constant 25ms.

  • by hattig ( 47930 ) on Wednesday January 02, 2013 @07:38PM (#42455977) Journal

    Well, it's in the memory manager portion of the driver. Memory management isn't easy at the best of times, and when you're dealing with a GPU that has thousands of cores, and each of those cores has its own local memory, and shared memory with a local cluster group, and then there are software controllable caches further up the hierarchy, I can see how writing this code could be fraught with difficulty.

    And as many of us here have worked in professional software environments, I'm sure we can all see how something that was pretty hard to pin down like these latency spikes might not have been a top priority for development, even if they were aware of it at all - after all the FPS figures were great. You'd end up with a driver kernel that had some magic that nobody would want to touch, and most of the work would be game specific optimisations and higher level optimisations. A year sounds about right really.

  • by citizenr ( 871508 ) on Wednesday January 02, 2013 @07:57PM (#42456183) Homepage

    Because this should have been done 9 months ago. Leave it to AMD to once again just drop the ball. At least they're consistent at failing.

    Better 9 months for software patch than 5 years for process change and MASSIVE GPU die off Nvidia gave us starting with 8xxx models.

  • by citizenr ( 871508 ) on Wednesday January 02, 2013 @09:51PM (#42456969) Homepage

    Clearly you are unaware of Nvidia fiasco and following litigation. It wasnt "share of the units". It was Majority of them. Basically finding a working laptop with nv8xxx/9xxx GPU is considered lucky (they ALL die sooner or later, ticking bombs), and there are companies doing nothing else but fixing them.

  • by nanoflower ( 1077145 ) on Wednesday January 02, 2013 @10:00PM (#42457009)
    Only one problem with what you suggest is that it is based on bad information. TR made the effort to look at different versions of the drivers and they've tested it on Win7 and Win8. Also only a couple of other sites have done the same level of testing frame rates that TR has been doing and they've found the same issues. Then you add in that AMD has looked into the issue and acknowledged there is a real issue that they need to address. So you are doing a disservice to Tech Report by misstating the situation and ignoring the other sites that have agreed with their findings.
  • by Anonymous Coward on Thursday January 03, 2013 @12:25AM (#42457823)

    I don't doubt their findings, merely that the latency spikes are a universal problem, and that they weren't recently introduced in a _beta_ driver (or at the least, a newer one - we know the problem didn't exist back in earlier versions).

    I wouldn't be surprised to find out that this is a result of the chipset/disk controller driver (which they updated in the interval between their older stutter-free results and their new stutter-heavy ones) interacting poorly with the newer graphics drivers, and possibly the older ones as well - disk reads can be a major culprit in stutter, particularly in all these console ports which use texture streaming heavily. It's unlikely, but since disk reads are one of the biggest sources of notable stutter, it merits investigation.

    Or it could be a hyper-threading problem, as hyper-threading is known to cause stutter in some cases, and some, if not all, of the testers who haven't noticed stutter issues despite casting an eye towards smoothness of frame delivery are using processors without hyper-threading. This would be particularly easy to investigate, and they didn't even try.

    Win7/Win8 was a reasonable thing to investigate, but that only serves to highlight their utter irresponsibility in not even commenting on the possibility in the original article, or actually investigating it before publication like any responsible reviewer should when faced with such remarkable results.

    The problem here is _not_ the data, it's the lack of questions they've asked about the wildly different data, and the lack of any sort of scientific rigor applied to a very surprising result.

Evolution is a million line computer program falling into place by accident.