Despite Game-Related Glitches, AMD Discontinues Monthly Driver Updates

MojoKid writes "Recently AMD announced that it would cease offering monthly graphics driver updates, and instead issue Catalyst versions only 'when it makes sense.' That statement would be a good deal more comforting if it didn't 'make sense' to upgrade AMD's drivers nearly every single month. From 2010 through 2011, AMD released a new Catalyst driver every month like clockwork. Starting last summer, however, AMD began having trouble with high-profile game releases that performed badly or had visual artifacts. Rage was one high-profile example, but there have been launch-day issues with a number of other titles, including Skyrim, Assassin's Creed, Bat Man: Arkham City, and Battlefield 3. The company responded to these problems by quickly releasing out-of-band driver updates. In addition, AMD's recent Catalyst 12.6 beta driver also fixes random BSODs on the desktop, poor Crossfire scaling in Skyrim and random hangs in Crysis 2 in DX9. In other words, AMD is still working to resolve important problems in games that launched more than six months ago. It's hard to put a positive spin on slower driver releases given just how often those releases are necessary."

Comments

They didn't say slower

[macemoneta]

They didn't say slower, they said as needed. Since they are already releasing 'out of band' they are just normalizing that process. They will release when they have fixes / function instead of on an arbitrary timeline. It seems to make perfect sense.

Let me get this straight:

[Anonymous Coward]

You fix third-party software... by modifying drivers?

How about forcing the game makers to TEST THEIR DAMN GAME before releasing? Is it really so hard to throw together four test-beds with GPUs from different vendors?

Re:Let me get this straight:

[91degrees]

I'm in two minds over this. Assuming this is an actual glitch in the drivers causing the problems.

On one hand, AMD should fix it. On the other hand, AMD graphics cards are pretty popular. Their game should be designed to work on what they can reasonably expect their users to have.

Re:Let me get this straight:

[Anonymous Coward]

It's easier to just release the game and let gamers and video card manufacturers fight over who is in the wrong. By the time someone figures it out the developers have made their money and run off.

Re:Let me get this straight:

[drinkypoo]

How about forcing the game makers to TEST THEIR DAMN GAME

Games often expose driver bugs. Major game developers are in communication with GPU vendors and when they discover bugs, the ones which turn out to be in the driver or the microcode sometimes get fixed, depending on how new the product is and whether the GPU is from Intel, AMD, or nVidia. nVidia has by far the best record in terms of working drivers, and also in terms of improving support for old hardware in new driver revisions. AMD is by far the worst. They have abandoned whole platforms while they were still shipping, for example R690M. I'm using a subnotebook based on it right now. Only thing it will run without shitting itself is Vista. And fglrx didn't support it when it was brand new, and still doesn't support it, and never will.

Don't be so quick (or anonymous, or cowardly) to assume that it's the game developer's fault when a problem "with the game" is fixed with a driver update.

Re:Let me get this straight:

[Joce640k]

nVidia is so much better at drivers than AMD that your comment looks like the insane rantings of a madman.

Oh, yeah? I program 3D graphics for a living so I have to deal with this stuff on a daily basis. I'm working around a bug right now.

Question: Are occlusion queries supposed to return number of samples or number of pixels in Direct3D?

A certain company's "pro" graphics cards seem to differ from their "consumer" graphics cards over this.

The only way I've found to get my program working is to do a dummy occlusion query when I create the framebuffer and see what happens.

Re:Let me get this straight:

[Svartalf]

It's not always driver bugs. Many of the fixes are things that tapdance around bad, buggy code within the game itself. Oftentimes the studio's devs play fast and loose with shader parameters or API compliance- and NVidia does it differently than AMD, etc.

Any time you see a "MAY" within a standards document, it really ought to be treated as a "SHALL" unless you know you're working on ONLY a target environment that the "MAY" doesn't affect you. Prime example would be something along the lines of VBO mapping to host addressing space. The spec says that it MAY stall the pipeline if you do this while you're in the middle of a rendering pass. Well...NVidia's implementation knows what VBOs are in-flight with a rendering pass and will stall only if it's known to be about to be used by the current pass in progress. AMD's drivers took the other, in fact, sensible approach because it's easier to implement and gains you performance overall if you don't have devs doing stupid things- they stalled ANY time you mapped any VBOs involved with the rendering pass in progress.

A major studio (Who shall not be named, nor shall the game...who knows, maybe you can guess the title...) did this in their GL code- they recycled VBOs, but did it intra -frame instead of inter -frame. The first is realtively safe, producing pretty good performance, the other's very much not so, based on the lead-in I gave just now. I should know, I've used it with some of the games I've done porting work on (Because the studio did the same thing in DirectX...which has the same restrictions here...). When you do it intra-frame, on NVidia, it slows the render pass down, but not unacceptably because it only stalls as long as needed to assure you're not corrupting the render pass. AMD, until they re-worked their VBO implementation would plummet to seconds per frame slide-show renderings on an X1950XTX card when it was THE hottest, fastest card out there- because it would stall the pipeline, taking milliseconds to recover, each and every time they re-mapped the VBO they were re-using to conserve on card memory on the frame's rendering pass.

Was it the driver's fault? Not even remotely close to the truth there. But...people will blame the driver, calling it "buggy". In fact, that's what happend, even.

Bias much?

[neokushan]

AMD says that they're moving from a monthly release cycle to a release-when-needed cycle and someone decides to write this piece of trash about it?
It's not a bad thing, it makes sense to do it like this. As the summary points out, AMD currently releases out-of-band updates for when a high-profile title has an issue or launch day performance increases, so it doesn't make sense to make another release that month that doesn't change much. It's just confusing and frankly unnecessary. Doing it "as needed" just means that when a driver release comes out, it's worth updating to. If that means I only have to update my drivers once every few months, I'm fine with that - even if it occasionally means there's 2 or 3 updates in the space of a month because a lot of games happened to come out then. Overall, it's better for everyone.

Article is a big load of FUD and should be ignored.

Disclaimer: I've currently got a Geforce 560 Ti in my desktop and my laptop uses a Geforce 555M chipset - frankly, I'm an nvidia fanboy and this article still disgusts me.

Re:Which is worse, AMD or nVidia?

[Cute Fuzzy Bunny]

If as a programmer I can do something that crashes your driver or blows up your machine, then the problem was with the driver, not the application programmer.

I was a systems programmer for 30 years. I wrote a ton of OS and driver code, especially drivers. If you could break the machine or cause stupid things to happen by having your app do something improper with the driver, then that was my fault.