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."

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:The NVIDIA Transition?

[Anonymous Coward]

no nforce had a built-in ethernet controller.

Yes they did. See the forcedeth [wordpress.com] driver (nVidia also provided a binary driver, called "nvnet" in Linux).

Re:Let me get this straight:

[Sir_Sri]

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?

Having been on both sides of this.

There are some functions, usually directx functions that just do not behave properly with certain drivers. There is, in many cases, nothing you can do except ask the company to fix it. This is a double problem because a lot of times they won't look at your game until it's finished, so if you finish on friday and release on tuesday guess how much it's been looked at by nVIDIA or AMD.

  While you are writing your game nVIDIA and AMD are writing new drivers and changing how their drivers behave. usually to accommodate someone eleses release, but not necessarily. That's incredibly frustrating, because you may not know whether the bug is your end, or theirs, especially if it behaves differently between driver releases.

For anyone who got the original version of the witcher 2 you could see the problem with 'test their damn game'. There was a problem with how ubersampling the ability to interact with objects. So the game came out with this problem, which is actually rare because almost no one had a card capable of doing ubersampling (even a new gtx680 today has slowdown with it). So AMD and the Witcher devs get onto fixing this problem. I think the problem was actually in how AMD was handling the sampling, but I'm not 100% sure. CD projekt did a hack workaround patch that changed how they did the sampling slightly, and at the same time AMD issued a fix, that wasn't compatible with the workaround. So you ended up in this problem where you're not even sure which solution you should be using as an end user.

Sure, a lot of the releases basically exists to clarify which codepath a particular game should be rendered with, or which SLI/crossfire profile it should use, which is relatively minor on the scale of things. But it really is a problem on the driver end that games are all treated inconsistently, or maybe that's a feature. Depends on your perspective. Treating games differently is a massive pain in the ass for development, but makes the experience much better for players, so take your pick.

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:

[Anonymous Coward]

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

Occlusion queries are supposed to return number of pixels in both Direct3D and OpenGL.

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

In both API's or just one? If just one, then the problem is actually within Direct3D and isn't the card at all.

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.

Then you're doing something else wrong and have misidentified the source of your trouble. I won't get into here, but this might prove helpful to you:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html
http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html

Comment removed

[account_deleted]

Comment removed based on user account deletion