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:

[EdZ]

It depends on where the problem lies: If the game is using the directX (or openGL) libraries correctly but the driver is mucking things up, then the game developer should not need to code around driver bugs. Conversely, if the game developer is using a 'clever hack' to eke out some more performance, this creates a headache for the driver developers to keep this hack working in one instance but stop it working for things written to the word of the API in other instances.

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:

[makomk]

Even more unfortunately, NVidia have realised this and have been paying off video game developers not to test their games on AMD graphics cards prior to release and not to allow AMD access to pre-release versions to do it themselves.

Re:Let me get this straight:

[sandytaru]

nVidia has the mother of all driver bugs and they've refused to fix it for years. If you run a DVI to HDMI cable from an nVidia card with no native HDMI support, the driver recognizes the HDMI cable anyway, assumes it can run sound, and attempts to run sound via the nonexistent sound chip on the video card. In essence, it overrides the onboard sound and sometimes even a discrete sound card in the computer. Since native HDMI support was introduced in newer cards, nVidia has felt no need to address this glitch in their older cards. I ended up recycling an otherwise perfectly good GeForce 9800 GT because the computer it was in was hooked up to the 40" television, but any time I had the video card driver installed I had no sound!

Re:Let me get this straight:

[Shinobi]

Direct3D technically allows for both, the XNA game dev framework specifies number of pixels however, for performance reasons. The number of samples method tends to be more accurate but very slow. It's the same thing on the OpenGL side. CAD, 3D applications such as Maya etc, compositing programs etc tend to use samples over pixels, for more accuracy.

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.

Re:Let me get this straight:

[murdocj]

Really? Bitcoin mining??? You think people are buying ATI cards to mine bitcoins? And not for gaming? Maybe a few people are reusing their old cards for mining, but the bitcoin fad has pretty much passed... I'd be shocked if even .1% of the AMD graphics cards sold are for bitcoin.

The NVIDIA Transition?

[deweyhewson]

As someone who is generally an AMD fan - their processors and video cards generally provide much better performance for much cheaper - their driver support, or lack thereof, is frustrating. NVIDIA consistently has far better driver support, and features, than their AMD counterparts, even if their cards don't provide as much bang for the buck.

If AMD falls even further behind in that game, I may just bite the bullet and switch to NVIDIA just to stop having to worry about driver-related frustrations altogether.

Re:The NVIDIA Transition?

[DWMorse]

To date, my nForce motherboard can't hit sleep mode without the network card going full retard. You NEVER go full retard. For shame, Nvidia. It's been over 2 years and they still haven't released a fix. Nvidia has their share of issues too.

Re:The NVIDIA Transition?

[TheEyes]

Here's irony for you:

-AMD supposedly releases driver updates on a monthly basis, though they haven't quite managed it for the last couple years, sometimes not making the deadline, sometimes just releasing basically the same driver two months in a row, then releasing out-of-band updates when games break their cards.)
-nVIDIA has always released drivers "as needed'.
-AMD switches to releasing drivers "as needed".
-Everyone complains, and threatens to switch to nVIDIA.

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.

Re:Is this nvidia spin?

[epyT-R]

I'd rather have to download patches than have the thing autoupdating when I don't want it to just yet. Same thing with drivers. Those are things that really should be managed by the user. There are plenty of circumstances where latest_version = best choice is a horrible assumption, esp with people who have older hardware. Some drivers just don't like some hardware configs too.

One of the biggest selling points of PCs is that the user controls the software. Take that away and it's just another stupid console like everything else is nowadays. I don't mind having an option for autoupdate, but I would not want it mandatory. I still want to have the installers available for local storage.