Slashdot Mirror
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."
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.
There's a spot in User Info for World of Warcraft account names? Really?
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.
No sig today...
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.
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
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.