AMD Unveils New Family of GPUs: Radeon R5, R7, R9 With BF 4 Preorder Bundle

MojoKid writes "AMD has just announced a full suite of new GPUs based on its Graphics Core Next (GCN) architecture. The Radeon R5, R7, and R9 families are the new product lines aimed at mainstream, performance, and high-end gaming, respectively. Specs on the new cards are still limited, but we know that the highest-end R9 290X is a six-billion transistor GPU with more than 300GB/s of memory bandwidth and prominent support for 4K gaming. The R5 series will start at $89, with 1GB of RAM. The R7 260X will hit $139 with 2GB of RAM, the R9 270X and 280X appear to replace the current Radeon 7950 and 7970 with price points at $199 and $299, and 2GB/3GB of RAM, and then the R9 290X, at an unannounced price point and 4GB of RAM. AMD is also offering a limited preorder pack, that offers Battlefield 4 license combined with the graphics cards, which should go on sale in the very near future. Finally, AMD is also debuting a new positional and 3D spatial audio engine in conjunction with GenAudio dubbed 'AstoundSound,' but they're only making it available on the R9 290X, R9 280X, and the R9 270X."

Comments

A new indecipherable numbering system, yay!

[Anonymous Coward]

Looks like the numbers were getting too close to the big ten thousand again, gotta reshuffle the whole system.

Fuck it, I'm buying some sort of PlayBoxStation One-Four. I give up.

Re:A new indecipherable numbering system, yay!

[Anonymous Coward]

And stop saying 4K resolution. Say 4000x2017 or whatfckingever resolution.

Re:A new indecipherable numbering system, yay!

[viperidaenz]

But 3840x2160 isn't as cool as "4k"

Re:A new indecipherable numbering system, yay!

[Anonymous Coward]

Wonder how long until HD manufacturers adopt 1k == 960 to "avoid customer confusion"

Re:A new indecipherable numbering system, yay!

[Luckyo]

Considering the whole "HD ready, full HD" crap, probably never. Ignorance sells products.

Re:A new indecipherable numbering system, yay!

[tinkerton]

Especially since if you can pronounce 4K to sound like 'fuck' which is fun.

Re:A new indecipherable numbering system, yay!

[TwentyCharsIsNotEnou]

It's easier to say.

Plus, it's fairly descriptive - it's almost 4000 pixels wide, and it's 4 x the resolution of HD.

I don't see the problem here, and I don't think it's "just marketing". People would come up with their own shorthand anyway if it was marketed at 3840x2160.

Re:A new indecipherable numbering system, yay!

[Anonymous Coward]

Especially since if you can pronounce 4K to sound like 'fuck' which is fun.

Wouldn't it sound like 'fork'?

Re:A new indecipherable numbering system, yay!

[tinkerton]

If it sounds like 'fork' you're clearly not trying hard enough...

Re:A new indecipherable numbering system, yay!

[Anonymous Coward]

Or you're Australian.

Re:A new indecipherable numbering system, yay!

[tinkerton]

You mean speaking australian is like speaking english but not trying hard enough? Well it didn't come from me!

Re:A new indecipherable numbering system, yay!

[Applekid]

It's easier to say.

Plus, it's fairly descriptive - it's almost 4000 pixels wide, and it's 4 x the resolution of HD.

I don't see the problem here, and I don't think it's "just marketing". People would come up with their own shorthand anyway if it was marketed at 3840x2160.

It's also completely backwards to what the established systems are. Resolution for television has always been specified in the number of horizontal lines. This is a consequence of early CRT raster displays only caring how many times HSYNC and VSYNC are flickered. However many distinct analog values you can toss out on the display wires per line is completely open. This is why we talk about 1080p and not "2K" even though a 16:9 display with square pixels will have 1920 pixels per line.

For TV resolution to be rightfully called 4K, it really should have 4000 horizontal lines.

Re:A new indecipherable numbering system, yay!

[toddestan]

Perhaps when people figure out that that 1366x788 is *not* HD resolution.

Now I feel like a fool

[Billly Gates]

For paying $225 a month ago for an ATI 7850 with just 1 gig of ram.

Re:Now I feel like a fool

[alvinrod]

Where did you buy it from that you paid that much? I bought a 2GB 7850 over a year ago for around that price.

Re:Now I feel like a fool

[Anonymous Coward]

I paid like 220 for a 7950 with 3 gigs 6 months ago, but there's always some retard willing to flush their money away on the first handful of beans they see

dumbass

Re:Now I feel like a fool

[pspahn]

Maybe one day we will be allowed to upgrade RAM on these cards so that going from 1Gb to 2Gb didn't cost you another $60.

Re:Now I feel like a fool

[Hamsterdan]

Like we could do with ISA VLB and PCI cards around 20 years ago (even onboard graphics and some soundcards)

Re:Now I feel like a fool

[Anonymous Coward]

at GDDR5 speeds memory has to be soldered to GPU card, you could have removable memory but at DDR3 speeds that are several times slower

on the other hand if your good with soldiering and have few millions dollars in soldiering equipment you can just soldier additional ram to board yourself, so expanding is still possible for some

Re:Now I feel like a fool

[LordLimecat]

That would not be possible, considering noone sells graphics RAM for consumer installation.

Re:Now I feel like a fool

[armanox]

Wow, I was looking at picking up a Radeon HD 7870 for $150 at Microcenter....

Re:Now I feel like a fool

[haruchai]

Keep soldiering on, AC

Re:Now I feel like a fool

[Anonymous Coward]

If they are not BGA, then they are pretty easy to solder with at most a bit of copper braid and maybe a flux pen. BGA requires more equipment, like a toaster oven and some solder paste or flux that might cost you a little more than the generic stuff. The hardest part will be getting the RAM chips in small quantities and if something has to be done besides just putting the chips on the board. The soldering of even tiny surface mount stuff is easily in the reach of most geeks with any reasonable level of hand tool use.

Re:Now I feel like a fool

[Anonymous Coward]

You paid almost $100 too much. I bought one for $139. You can even buy a 7950 for $205...

Re:Now I feel like a fool

[Anonymous Coward]

Yeah, good luck with that. Of course it is BGA, do they even make modern RAM in anything else these days? I think it is even part of the GDDR spec at this point, but there are so many pins, and the industry is all about density, so the chips are going to be *GA of some variety. So yeah, toaster oven, after you have disassembled the card to remove the melty plastic bits, then you get to put it back together and find out it doesn't work because it didn't reflow properly. I suppose with proper investment in your toaster oven controller you could get something proximate to an appropriate flow profile, but that is far from a guarantee of success. You won't have the xray, and while JTAG adapters are cheap and plentiful, good luck getting a JTAG pinout from , so even knowing if its at all correct is a stretch, and at the speeds they use as mentioned above these things are quite sensitive to the quality of the joint. If you don't get it right on your first go, you'll probably pull some pads trying to rework it. I would put my money on the card, the ram, or both being ruined as opposed to success - unless doing this sorta thing is your day job. You are right in that it can be tricky to get your hands on a small quantity of parts, but I have had good success getting samples if you put some effort into it (some things are rather simple to get with web order forms, but you won't find that for Samsung and the like- probably gotta go old school and reach into the sales channels). That being said, they probably have something like 4-8 chips (4Gb I think is towards the high end of available densities) and I've never had anyone offer me more than 5 in samples (not that I've asked).

Worth it? You'll spend more breaking stuff than it would have cost to just buy it with what you want.

FTR, soldering normal SMD packages doesn't scare me, SOIC and the like aren't so much trouble. I'd even be willing to give *GA a shot - if I was starting from a bare board and could afford to chuck a bunch of them.

Re:Now I feel like a fool

[Anonymous Coward]

Never said it was worthwhile, only pointing out that you don't need "few millions dollars in soldiering equipment." Even BGA stuff can be properly done with equipment for under a thousand dollars (although a lot of places with money to spare blow more than that on their equipment, which might be nice, but not necessary). Joint quality is an issue in a production environment, but with prototypes and hobby projects, you can get away with a lot. I've seen enough stuff around the lab I work in put together that is a lot more sensitive than a RAM chip, but half-assed assembled by a grad student that didn't ask for help with the proper tools. And you wouldn't have much issue with melting plastic or messing up other things if you get the right solder components meant for rework.

Re:Now I feel like a fool

[uninformedLuddite]

I suspect I still have a bit of life in my 6950 yet. I don't understand those that need the $1000 new release cards.

Schlameel, Schlamazel

[slick7]

What happened to the Radeon R4, R6, R8?

Re:Schlameel, Schlamazel

[cheater512]

Or the R1 for that matter?

Re:Schlameel, Schlamazel

[SJHillman]

The same thing that happened to the Intel i2, i4 and i6 processors.

Re:Schlameel, Schlamazel

[ralphaostrander]

Suckers I am holding out for the i10.

Re:Schlameel, Schlamazel

[Anonymous Coward]

The same thing that happened to the Intel i2, i4 and i6 processors.

You're going to be even more baffled when they release the i11 next.

Re:Schlameel, Schlamazel

[Anonymous Coward]

Spinal Tap Edition(TM)?

Re:Schlameel, Schlamazel

[Anonymous Coward]

Even numbers are sooo yesterday.

Maybe time for an upgrade?

[Fwipp]

Wow, that $89 R5 actually looks surprisingly attractive. If the benchmarks hold up, I might think about replacing the old power-hungry card I've got in my main desktop machine right now - I'd probably save energy and get better performance to boot.

Re:Maybe time for an upgrade?

[Anonymous Coward]

I did look at it as I'd like to replace my 5 year old Radeon 4850 but judging by the specs of the R5 M200 my 5yo card annihilates it!

Radeon 4850 vs R5 M200:
800 vs 384 shading units
40 vs 24 TMUs
16 vs 8 ROPs
10 vs 5.2 GPixel/s
25 vs 15.6 GTexel/s
1000 vs 499.2 GFlops
63.6 vs 14.4 GBbps BW (256 vs 64 bit) ...
Sure, it's probably very low power but unless your machine is *very* outdated it's gonna be a big downgrade.

The $139 R7 260X seems like something worth upgrading to but then again, it's a matter of price:performance ratio, compared to existing offerings like the existing Radeon 7790 (both being a little short of getting 4000 points on 3dmark fire strike) which you can buy today for $120, or the Radeon 7850 which seems a little faster still (a hair over 4000 points) and which can also be had for $139 today. The $199 R9 270X scores about 5500, whereas the existing 7950 (scores 6000) can be had for $205 today... Meh. Nothing to see here...

Re:Maybe time for an upgrade?

[OhANameWhatName]

Wow, that $89 R5 actually looks surprisingly attractive

I'm guessing that /. is the only website where this comment would find general agreement.

Re:Maybe time for an upgrade?

[Fwipp]

Ah, thanks for the writeup. I'm actually using a 4850 too, and just kinda assumed that the architectural improvements & extra/faster RAM (mine has 512MB) would compensate for the lower shader counts. Thanks for correcting me!

And then, $40!

[LordMyren]

And once one has started playing BF4 ($60 value), one can either pay for DLC individually or spend $40 more for Premium.

I'm pretty displeased BF4 is a $100 game.

Re:And then, $40!

[Anonymous Coward]

Or, you know... not buy the DLC if you don't think it is worth the money.

That's what I do. Not buy things I don't think are worth buying. Always worked out well so far.

Re:And then, $40!

[Xest]

Don't have a problem with it if it's anything like BF3.

At the end of the day BF3 still had way more content than most games, and the premium subscription was slightly less than a new game but also had more content.

I've got no problem paying for DLC if the original game has enough content to be classed as a perfectly reasonable retail buy and the DLC also has enough content relative to it's cost.

That's been completely true of BF3 and BF3's Premium subscription.

It's one thing to complain about 6hr long games that cost $60, and it's one thing to complain about $40 of DLC that gives you peanuts, but that didn't apply to BF3 and hopefully wont apply to BF4.

DLC like that included with Premium are just like the modern version of add-on packs. I didn't see any point moaning that I had to pay £20 for Command and Conquer covert operations after having blown £30 on Command and Conquer itself a year before back in the 90s, so I don't see the point whinging now that companies are still selling pay-for addon packs providing they're reasonably priced.

Re:And then, $40!

[Lithdren]

What?

You people really are daft. Absolutly nothing in the 'premium' package wouldn't have been developed by the community at large if they were allowed to. These 'packs' work out to be little more than extra maps. Sure you got a few extra vehicles and weapons, but it still works out to be very little content for the money.

Lack of mod support, lack of custom map support. About the only thing BF3 had was you could actually still own a server for it if you wanted to, but I suspect that wont be true for long either.

without decent drivers

[epyT-R]

that work reliably for more than the current crop of just released games, I don't care how much faster these chips are. I've had too many glitches with radeon drivers over the years to consider them again. Their opengl is horrible, and CCC is a bloated pos.

Re:without decent drivers

[LesFerg]

Yeah I feel the same way about their driver support, couldn't trust them with too much of my limited gaming hardware budget.
Also, would it be really really difficult for them to hire some decent programmers and produce a new version of Catalyst control center that doesn't have to run on .Net?
Whatever happened to C++ and fast reliable software?

Re:without decent drivers

[Anonymous Coward]

I have been using them for the last 3-4 cards with no issues what so ever, but then again I run an OS that isnt spearheaded by a manchild and a bunch of basement dwellers

Re:without decent drivers

[DigiShaman]

Wish I had mod points for you. This is absolutely true. Going far back as 2003, the CCC was bloated, buggy, and aggravating to install. Particularly annoying was that .NET was required. That means having to install updates and .NET in default VGA mode first before you could load the drivers on a fresh format/reinstall of XP. Not sure if that's still the case though. Yuck!

You can have the best GPU in the world. It doesn't do much good without quality drivers however.

Re:without decent drivers

[Billly Gates]

NVidia drivers tend to be worse nowdays.

I hear them on hear saying how crappy Windows 7 is because aero brings thier GTX 680s to a crawl. Funny my parents Intel GMA 950 integratred 2007 era graphics run aero fine. Again driver issues.

I only had one bug with my ati drivers and if you base your data from 10 years ago then it is obsolete.

Re:without decent drivers

[epyT-R]

I based it starting at 10 years ago.. actually it starts with the ATI rage 128 which came out in 98(?), through to the radeon 5000 series. that 128 used to bsod windows on a regular basis with opengl applications (eg quake2). Years later, a litany of broken scenes, kernel panics due to unhandled exceptions (HANDLE YOUR DAMNED EXCEPTIONS!), tearing in video playback, completely broken support in non-game accelerated applications, etc, have kept me far far away. There's a reason adobe, autodesk et al, (and even the demoscene) stick with nvidia even though they want to move to openCL. It's not due to kickbacks, it's because their drivers work (for the most part).

I've had to service a lot of machines over the years (don't do it anymore thankfully), and when the owner complained of video problems, more often than not, there was a radeon in the machine.

I realize this is anecdotal, but my 770 (which is a 680 with higher clocks and faster ram) works fine with the 326.80 and 327.xx drivers. I do know some were having some issues with post 314.x drivers, but I didn't run into any.

Re:without decent drivers

[epyT-R]

Well, my experience with radeon cards is in windows, for the most part. Really, it doesn't matter because the fglrx drivers for X11 aren't any better. So unless Windows was developed by basement dwellers, your assumption is incorrect.

Re:without decent drivers

[epyT-R]

What happened? Point-and-stick software 'development.' Visual basic on steroids (.NET), and huge interpreted runtimes (python/php/ruby/.NET/ad nauseum) being used to write programs that could be done in a few dozen lines of C or shellcode..

This disease is everywhere. Basic system software should have as few dependencies as possible. GNU land suffers from this too. Honestly if CCC was the only problem, I could live with it.

Re:without decent drivers

[Anonymous Coward]

With any new generation of products from hardware companies, there is enough of a chance to drop the ball and screw things up, or to get lucky and do better (or just not screw up as bad as the competitor). Anecdotes and grudges from 10 years ago are rarely relevant.

Re:without decent drivers

[epyT-R]

You lack reading comprehension. Please reread.

Re:without decent drivers

[Nemyst]

Interfaces in a few dozen lines of C? Hahahaha.

Re:without decent drivers

[happymellon]

I think you are both saying the same thing.

Balmer == Manchild.

Re:without decent drivers

[sharklasers]

Whatever happened to C++ and fast reliable software?

The path of least resistance. Given the amount of computing power available these days, there's little effort in writing clean, efficient, snappy code requiring little in the way of dependencies, if it results in longer development times. Heck, what are people gonna do, not buy an AMD/NVIDIA card just because of its control panel? That doesn't happen - people grit their teeth, install the .NET dependencies and live with it because no-one's gonna boycott cards because of it - and the companies know this. So there's no motivation to code better.

I have no problem with modern toolkits and IDEs making it easier to product something quickly compared to traditional programming tools. But it also makes it much easier to write rubbish, but quickly-developed rubbish that does the essentials with a lot of overhead. Such is the nature of this industry.

Re:without decent drivers

[MojoMagic]

A couple of problems with this statement:
- .Net is not a programming language. Your comparison is just silly.
- In case you meant to refer to C#, no part of this development process is "point-and-click". In this regard, it is no different to C++ (I develop in both).
- It is not interpreted. Nor has it ever been.
- I think you'll find that the simple programs of "a few dozen lines" that you mention would likely be smaller (3 of lines) in C# than C++. But, again, this is a silly comparison and shouldn't be used in any reasonable comparison. If things like this are a problem, you are just using the wrong libraries; in most cases it has little to do with the language directly.

Re:without decent drivers

[Anonymous Coward]

The idea that these platforms and languages (python/php/ruby/.NET/Java) provide "Point-and-stick software development" is fucking retarded, anyone who knows even the slightest bit about them knows immediately that such a statement is objectively false. But that very thing is often said by the sort of people have no understanding of them through choosing to ignore them or genuine inability to comprehend them.

Frankly the runtimes are so lightweight and efficient that if you cant manage to write a GUI control panel in say .Net that performs as well as native then you are just a shit programmer. But of course people who think the programming world begins and ends with C that have no understanding of anything else will immediately blame the language or the tools rather than admit they need to actually learn more.

Re:without decent drivers

[Mashiki]

I do know some were having some issues with post 314.x drivers, but I didn't run into any.

Some? Anything post 290.x have been complete crap on 400-600 series cards. At best, they might be stable, at worst you're going to see amazing hardlocks which require a complete powerdown to fix. The last time I looked on the nvidia forums with that issue, there was a thread on this with nearly 140k views. Funny enough it was the bad drivers that broke me, and I dumped my 560ti for a 7950 I have no complaints of doing so.

Re:without decent drivers

[CadentOrange]

You list Python/PHP/Ruby and then talk about shellcode as an alternative? Huh?

Re:without decent drivers

[CadentOrange]

Frankly the runtimes are so lightweight and efficient that if you cant manage to write a GUI control panel in say .Net that performs as well as native then you are just a shit programmer.

Unless said controls are using WPF which then performs horribly on older machines. They might have improved it since .NET 3.5, but I haven't developed on Windows for quite a few years now so my knowledge could well be out of date. Or just plain wrong. This is the internet after all ;)

Re:without decent drivers

[Xest]

"Whatever happened to C++ and fast reliable software?"

That makes no sense, C# and .NET let you write fast, reliable software. In fact, the very nature of .NET means it's more reliable by default because it has better handling of common programming mistakes and the JIT compiler means you can get equally good performance out of it, .NET even gives you a decent amount of control over the GC so is lesser plagued by the nature of that in say Java and even Java can perform equally well otherwise.

CCC's problems have nothing to do with the development environment, language, and framework used and everything to do with the same incompetence that has left ATI's drivers shit for over a decade - they just seem to have abysmally poor procedures in place for maximising software quality.

Re:without decent drivers

[Xest]

"requiring little in the way of dependencies"

This has always been a myth. Even before .NET in a very C++ world people were using various libraries like MFC that had to be installed.

Installing .NET is no different to installing things like new Winsock versions, through to MFC updates, through to MSXML. Nothing's changed, it's all just in one big package called .NET now.

"But it also makes it much easier to write rubbish"

This hasn't changed either. People said the same about BASIC, and COBOL and assembly programmers have even said the same about C and C++ when they came about.

Re:without decent drivers

[Xest]

But has that ever been different?

New functionality, runs shit on older hardware. It's not really news it's just the way the world works.

The classic Windows style GUI and toolbars and most common controls haven't changed in decades yet computing power has increased tremendously. WPF is the first attempt at doing something about that because given the change in computing power we can definitely do better now with those interfaces.

If that means running shit on old hardware then well yeah, that's the price we pay for advancement. There's always still the option of WinForms et. al. if you want to produce something for old systems or even C and Win32 API if you want to go far back enough.

Re:without decent drivers

[Xest]

This is what happens when non-programmers try and converse about programming whilst having a certain arrogance that prevents them seeing that they're way out of their depth.

He also listed .NET as interpreted which is flat out wrong (unless you're talking about code executing on the DLR but given his level of understanding I doubt he even knows what that is).

The idea you can write more concise code in C or Shellcode than the others is also laughable. The fact you have to explicitly write code for dynamic memory allocations alone in C prevents that. C is a language I love because it was my first language, but there's a time and a place for it and way too many idiots who think it's a magic solution to all software's problems whilst forgetting how much more unstable and how many more severe root escalation vulnerabilities and buffer overflows we suffered when everything was written in C.

PHP practically encourages bad software development practices and the tutorials are even worse in pushing insecure development practices, but at least even given this the most harm that seems to get done is normally nothing more than an SQL injection vulnerability - bad, but at least they're not rooting your server with those mistakes which is a step up from the days where arbitrary executables were getting executed on remote machines left and right and so forth.

Re:without decent drivers

[Anonymous Coward]

C is the be all and end all. If you can't code C, you shouldn't be coding.

That said, C++, OBJC, Java, and all the Microfluff C#/VisualBasic people need to go die in a fire if you're OOB coding for the same of it being OOB and not for some practical feature enabled by programming on that platform. I've never seen anything good written in VisualBasic, and doubt I'll ever see anything good written in C# or JAVA.

No Minecraft is a just a wonderful example of why not to program in Java.

Re:without decent drivers

[fast turtle]

Yet I have decided that my next card is going to be Nvidia because of the POS CCC. Nvidia does include a control panel applet but unlike the POS CCC, it doesn't crash every time I open it plus I can actually disable the Nvidia services since the driver does not depend on it - unlike AMD's latest generation.

Re:without decent drivers

[sharklasers]

OK, you're an exception. There's probably others (many others?) who think like you, and that's perfectly reasonable. Just not enough for these companies to care, unfortunately.

Re:without decent drivers

[sharklasers]

There's always someone who wants to ruin the party. :)

OK. Without any hard evidence and going totally with anecdotal evidence and a certain "feeling", I can say with almost 100% certainty that the trend of coding these days is that it's just not as well built as code designed for systems with fewer resources, and hence requiring better quality coding to make use of said limited resources. Is that better? If not, bugger off - I want my old fogies moment!

Re:without decent drivers

[ProzacPatient]

- I think you'll find that the simple programs of "a few dozen lines" that you mention would likely be smaller (3 of lines) in C# than C++. But, again, this is a silly comparison and shouldn't be used in any reasonable comparison. If things like this are a problem, you are just using the wrong libraries; in most cases it has little to do with the language directly.

I'm also a professional software developer but if you stop to think about it I think that you'll find MSVCRT (Microsoft Visual C++ Runtime) is significantly smaller then the .NET Framework that MSIL applications can't run without. I'm not sure about the size of the Mono runtime in comparison.
Most of the time this won't be important, especially given that .NET framework is pre-installed on Windows, but depending on your project and targeted runtime environment it could be a factor.

Re:without decent drivers

[Applekid]

The idea that these platforms and languages (python/php/ruby/.NET/Java) provide "Point-and-stick software development" is fucking retarded, anyone who knows even the slightest bit about them knows immediately that such a statement is objectively false. But that very thing is often said by the sort of people have no understanding of them through choosing to ignore them or genuine inability to comprehend them.

Frankly the runtimes are so lightweight and efficient that if you cant manage to write a GUI control panel in say .Net that performs as well as native then you are just a shit programmer. But of course people who think the programming world begins and ends with C that have no understanding of anything else will immediately blame the language or the tools rather than admit they need to actually learn more.

There's only one reason for using high level languages at all. More efficient development, easier to support, and better cross compatibility. But all that is on one side of the equation. Execution is always going to be slower, and it gets worse the higher up you go.

You can't really argue managed code isn't several orders of magnitude slower than native code. Boxing/unboxing, automatic garbage collection, all of it's other benefits: none of it comes free.

The defending of managed code because the difference between a user waiting 0.2 seconds versus 2 milliseconds for a window to open for a window that is rarely (if ever) opened is just good economy if it's going to be cheaper to develop. That actually isn't really a testament to a programmer's skill, it's really a testament that computers are so powerful now that we can afford to waste that much computing power in forcing the machine to unravel all these human abstractions, when really it just wants to run machine code.

That said, I assure anyone that the actual business-end (not any human interface) of a video card's drivers is most certainly using C or C++, tops.

Re:without decent drivers

[Anonymous Coward]

You spend a half of your post saying you had problems with cards 4-10 years ago, and then mention that you haven't helped other people with their computers in a while. If I talked about AMD vs. Intel CPUs, who would care about my issues with K6s and K7s years ago?

Re:without decent drivers

[LesFerg]

... CCC's problems have nothing to do with the development environment, language, and framework used ...

Well I seem to remember repeated faults with mismatched .Net library dependencies and somehow ending up with a CCC installation that would not load up its user interface and could not be fixed by uninstall/re-install and wasted many days of effort. But I guess you are right, it takes a special kind of developer to make such a poor hash-up of a user interface.

Re:without decent drivers

[Anonymous Coward]

You can't really argue managed code isn't several orders of magnitude slower than native code.

Actually you can, and quite correctly too unless you dont know the meaning of the term 'orders of magnitude', a quick google search turns up a myriad of results that prove you have absolutely no idea and are just making baseless claims. Here is just first one i happened upon.

The defending of managed code because the difference between a user waiting 0.2 seconds versus 2 milliseconds for a window to open

Yet another unsubstantiated random bullshit number.

Re:without decent drivers

[Anonymous Coward]

and if you arent able write decent programs in C# or Java then you are just a shit programmer. obviously you are another who has significant problems yet continues to blame the tools without any objective proof of specifically what is wrong, just that you cant do it.

Re:without decent drivers

[exomondo]

You can't really argue managed code isn't several orders of magnitude slower than native code.

I'd be interested in seeing what makes you so dismissive of even attempting to argue your assertion that managed code is (even at the lowest end definition of 'several') at least 1000 times slower than native code.

Re:without decent drivers

[Xest]

That's definitely a developer issue. The various .NET framework versions sit alongside each other, and there is plenty of functionality for ensuring .NET assemblies don't clash (DLL hell was one of the key things they wanted to avoid with .NET). There's a thing called the Global Assembly Cache with .NET which is a place you can cache common libraries, because they foresaw the fact that people may want to cache different versions of the same library if you have apps that are dependent on different versions they explicitly made sure it was possible to have multiple versions alongside each other and to ensure applications would always access the correct version. Ironically it's C/C++ that has historically suffered DLL hell and dependency mismatches because native development didn't have the level of functionality .NET has to solve that sort of problem.

If you've got an issue with clashing dependencies in .NET then that's entirely an issue of developers without even the slightest clue what they're doing with .NET. It worries me that ATI is trusting people this unskilled and incompetent with software that interacts with hardware and sits on millions of computers.

Re:without decent drivers

[Applekid]

You can't really argue managed code isn't several orders of magnitude slower than native code.

I'd be interested in seeing what makes you so dismissive of even attempting to argue your assertion that managed code is (even at the lowest end definition of 'several') at least 1000 times slower than native code.

Try taking a compiler design course at your local university and educate yourself.

Re:without decent drivers

[Applekid]

You can't really argue managed code isn't several orders of magnitude slower than native code.

Actually you can, and quite correctly too unless you dont know the meaning of the term 'orders of magnitude', a quick google search turns up a myriad of results that prove you have absolutely no idea and are just making baseless claims. Here is just first one i happened upon.

I suppose you can argue that, if you really are that stupid. Where's the source? I can draw a chart, too, you'd be a moron to draw conclusions about language throughput without seeing what's actually being written. It's very easy to write inefficient code in any language and stuff the ballot box for such a "benchmark." If you weren't a mouthbreather you'd know that.

The defending of managed code because the difference between a user waiting 0.2 seconds versus 2 milliseconds for a window to open

Yet another unsubstantiated random bullshit number.

Correction, a mouthbreather that is incapable of understanding examples and hyperbole. If I was going to use actual numbers, it would be addressed in number of cycles for a given platform. But, hey, believe what you want. You dragging down the average intelligence of all humans has nothing to do with me.

Re:without decent drivers

[Anonymous Coward]

Execution is always going to be slower...You can't really argue managed code isn't several orders of magnitude slower than native code.

Good day to troll? Except for SIMD, if your C# app doesn't run near metal speed, you're doing it wrong, assuming you needed to and spent the time optimizing.

Re:without decent drivers

[exomondo]

Try taking a compiler design course at your local university and educate yourself.

I have, but I want to see where you get the idea that native code is at least 1000 times faster than managed code.

Re:without decent drivers

[Anonymous Coward]

I suppose you can argue that, if you really are that stupid. Where's the source? I can draw a chart, too, you'd be a moron to draw conclusions about language throughput without seeing what's actually being written.

well done, now that you have proven that you have that philosophy you can show me the code that proves you claim about "a user waiting 0.2 seconds versus 2 milliseconds for a window to open", and i will forgive you the fact that 0.2s vs 2ms is not "several orders of magnitude". and also your claim that managed code is several orders of magnitude slower than native code. because only a moron would believe a claim like that without seeing what's actually being written, right?

Bitcoin?

[Anonymous Coward]

The real question is, how many bitcoins a day can these things mine?

Re:Bitcoin?

[Anonymous Coward]

GPU mining is over.

Re:Bitcoin?

[Agent ME]

Mining bitcoins with GPUs is no longer profitable for the most part. Most profitable miners today use hardware designed specifically for bitcoin mining.

Re:Bitcoin?

[Anonymous Coward]

Not sure, but I think they reduced the probabilities in finding bitcoins, so gpus are no longer cost effective.

Re:Bitcoin?

[Anonymous Coward]

The better question is what is what is the hash rate for scrypt mining.

Mantle API

[LordMyren]

Personally I would've gone for a mention of Mantle, the proprietary API they are introducing that sidesteps OpenGL and DirectX. I don't really know what it does yet, haven't found good coverage, but DICE's Battlefield 4 is mentioned as using it, and the description I've read said it enabled a faster rate of calling Draw calls.

http://www.xbitlabs.com/news/graphics/display/20130924210043_AMD_Unveils_Next_Generation_Radeon_R9_290X_Graphics_Card.html

Re:Mantle API

[Anonymous Coward]

That is really what we don't want though - a return to the bad old days of game developers having to write code specifically for each vendor's cards. As much as some people love to hate on them, standards such as OpenGL (and for Windows DirectX) make it so that the game developer doesn't have to keep writing modules to support video cards and other video APIs.

Re:Mantle API

[tibman]

Windows only (for now), blah. Still really exciting though! I remember glide being pretty awesome back in the day. It's funny that NVIDIA bought 3dfx and got glide but it is AMD that built a new low-level api. NVIDIA's NVAPI doesn't seem like an openGL or directX replacement but a helper of sorts for managing all kinds of stuff on the card.

Re:Mantle API

[blahplusplus]

"That is really what we don't want though - a return to the bad old days of game developers having to write code specifically for each vendor's cards"

It doesn't really matter since there are only two videocard vendors now, and the pace of graphics card innovation has slowed to a crawl. Not only that a vendor API would not prevent anyone from doing a direct X and OGL executable. The same way many games have DX9 and Dx10 exe's.

More importantly EA is big enough to afford to do native API + OGL + Direct X if they wanted to. I don't see the problem.

Re:Mantle API

[dotancohen]

It doesn't really matter since there are only two videocard vendors now,...

There are only two operating systems in widespread use now, so I should go write my new software in .Net and Objective C/Cocoa? There is only one Office Producitivity software suite in widespread use now, so I should release documents in .docx format? There is only one web browser, so I should only test sites in IE and ignore the standards?

The more we entrench the already-entrenched mono/duopolies, the harder it will be to get out of that mess.

Re:Mantle API

[Anonymous Coward]

In the old days it was hard, because there were so many companies around. With only two major companies left, it'll be a better option than writing D3D9 for XP support, D3D11 for Windows 7, D3D-WhateverXBoneIsLockedAt, Mantle for PS4, OpenGL4.4 for linux, and OpenGL3 for MacOS.

Re:Mantle API

[Anonymous Coward]

You are forgetting the OpenGLES variants found in mobile phones. That is a space not yet dominated by NVidia or ATI. I do agree with you though. 2 native GPU implementations, + GLES implementation, is a better situation than the current one.

Re:Mantle API

[Anonymous Coward]

Glide, anyone?

Re:Mantle API

[tlhIngan]

It doesn't really matter since there are only two videocard vendors now

There are THREE major videocard vendors. You missed the biggest of them all by far (bigger than the other two combined).

Yes, Intel counts - they are by far the largest graphics provider. Of course, Intel graphics is so-so compared to the latest and greatest, but it is surprisingly "good enough" and unless you want to target the enthusiast market exclusively, you'll have to deal with Intel.

Then there's the various little video providers like Via (they bought S3, remember and own a lot of patents), which really don't matter for games, but may matter in other areas.

Quick situation check

[Anonymous Coward]

At last check (not that long ago)

- Catalyst control centre still crashed periodically
- Linux drivers were slow (I don't give a phuck about open source or not, I want my driver to work, like nvidia's do).

I'd like to consider ATI for a next card, but I've been constantly rebutted from doing so by crappy drivers. Nvidia's "just work".

What is the situation like now?

Re:Quick situation check

[armanox]

I can play DOTA2 and L4D2 on Linux with a Radeon HD 7750 with about the same FPS the card would give me in Windows, if that would help. Only other ATI card I've had recently is a Radeon HD 5770, and that does about the same as the 7750 (slightly better or worse depending on the application - OpenCL performance seems better on the 7750, and the 7750 also supports DP FP).

Re:Quick situation check

[Anonymous Coward]

gallium drivers are getting better, but still have issues.. fglrx drivers are still shit.. CCC is still garbage.

Re:Quick situation check

[dltaylor]

My 6850 also "just works", CCC and all, in Debian 7 (amd64).

Haven't checked the supported cards list, lately, to see what newer card works.

How does it perform hash-wise?

[terbeaux]

I can't find any information on the scrypt hash rate of these cards. Does anybody have any info? Thanks

Bigger question is what's going on with Nvidia

[Anonymous Coward]

Nvidia has let slip 2 product generations. Their latest cards are re-badges of the previous gen, with prices shifted down one SKU. Their top-end became the 2nd fastest card, and a stripped down version of the Titian became the top-end. (The titan isn't a mainstream product. It's a remarked version of their workstation/server product sold in the consumer space, much like the Intel's relationship between the Xeon and the "Extreme Edition" cpus.) ... And that was last gen. This current gen, the one that AMD is releasing now, has slipped. They aren't releasing anything outside maybe a few SKU tweaks/re-badges. Probably some price cuts too.

Re:Bigger question is what's going on with Nvidia

[epyT-R]

They haven't needed to. The 800 series is out next year iirc. Internet rumor mills say it is a real architecture change.

'MANTLE' was the game-changing announcement

[Anonymous Coward]

AMD has totally ruined the future of Nvidia and Intel in the AAA/console-port gaming space. Working with partners at EA/DICE, AMD has created a 'to-the-metal' API for GPU programming on the PS4, Xbox One, and any PC (Linux or Windows) with AMD's GCN technology. GCN is the AMD architecture in 7000 series cards, 8000 series, and the coming new discrete GPU cards later this year and onwards into the foreseeable future. It is also the GPU design in all future AMD CPUs with integrated graphics.

GCN is *not* the architecture of any Intel or Nvidia products, neither now or in the future. Nvidia and Intel will be stuck with only openGL or directX versions of games, and these versions will be much slower/feature incomplete compared to 'Mantle' versions ported form the consoles.

OpenGL and DirectX are OBSOLETE methods of controlling rendering for future AAA games. Both of these APIs/drivers have massive state overheads, and can never be made efficient for the mixed rendering/GPGPU methods required for the new games engines of late 2013 and later.

While some nerds with a better memory than brainpower will dribble about 'Glide' (the proprietary API from now defunct 3DFX), the correct comparison is x86 vs 68000 (the Motorola CPU design). GCN is actually an ISA (instruction set architecture) like the x86 ISA. Intel and Nvidia are like TI and Motorola at the time of emerging competing 16-bit CPU designs that finally led to the dominance of x64. Nvidia is Motorola. Intel is TI. TI's 16-bit CPU designs were no-hopers. Motorola was widely seen as superior to Intel at the time. When Intel was chosen for the first PC, it was game-over for Motorola.

Using OpenGL or DirectX to 'program' a modern GPU is like using Fortran to program the CPU. Using 'Mantle' on the other hand is like using 'C'. However, because 'Mantle' closely connects to the GCN 'metal', it is almost impossible to envisage a version of Mantle for competing GPU architectures.

Of course, ATI customers with 6000 series cards or earlier (or Zacate, Llano, or Richland APUs) are as out-of-luck as Intel and Nvidia GPU users. AMD is only supporting GCN, because older GPU designs from AMD use a different GPU ISA.

With the rise of Mantle, many console games developers are going to desire that the PC market rapidly changes to AMD only, so the ported games need have only one version- the good one. Other developers, whose games do NOT need strong GPU performance, will wish to use only OpenGL on the PC, for maximum compatibility with games in the ARM space (where OpenGL ES rules).

Any PC gamer interested in high-performance would be INSANE to buy any Nvidia product from now on. 99%+ of all AAA games will originate on the new consoles released later this year- which are 100% AMD. Most casual gamers might as well choose AMD for maximum future compatibility. Intel was never really in the game. Nvidia, on the other hand, will be cursing themselves for ever starting this war (Nvidia previously paid AAA games developers to cripple AMD performance, and attempted to leverage the proprietary PhysX physics engine).

Re:'MANTLE' was the game-changing announcement

[Lawrence_Bird]

Using OpenGL or DirectX to 'program' a modern GPU is like using Fortran to program the CPU

Are you saying that OpenGL and DirectX are the fastest? Because Fortran code sure is.

Re:'MANTLE' was the game-changing announcement

[Guspaz]

So, you're convinced that the slight improvement in performance brought about by a reduction of software overhead is going to completely cripple nVidia? Yeah, sure.

Even if Mantle does produce faster performance (and there's no reason to doubt that it will), the advantages will be relatively small, and about all they might cause nVidia to do is adjust their pricing slightly. The won't be anything that you'll be able to accomplish with Mantle that wasn't possible without it, such is the nature of fully programmable graphics processors.

Game publishers, for their part, will hesitate to ignore the 53% of nVidia owners in favour of the 34% AMD owners. It's highly unlikely that this will cause a repeat of the situation caused by the Radeon 9700, which scooped a big win by essentially having DirectX 9 standardized around it. In that case, ATI managed to capture significant marketshare, but more because nVidia had no competitive products on the market for a year or two after. This time around, both companies have very comparable performance, and minor differences in performance usually just result in price adjustments.

Re:'MANTLE' was the game-changing announcement

[Narcocide]

I have a completely different prediction: you don't know what the fuck you're talking about. Nothing can kill OpenGL, if DirectX couldn't do it, certainly not this proprietary shit.

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

You've just described the death of PC gaming, I think. Extrapolate into the future where all PC gaming is done with AMD cards because there is no other option. What is the motivation for AMD to innovate? Sure, they might do so on the console, because they'll be selling huge volume to the console makers. So you'll have consoles being pretty much the same as PC and PC cards not being really worked on... Why not just buy a console and be done with it?

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

Hey Charlie, still hold a grudge against Nvidia and Intel?

Re:'MANTLE' was the game-changing announcement

[TejWC]

Isn't nVidia's Cg very close to metal as well? Also, you seem to be implying that making an GPL driver for Mantle should be easy since it will just send the compiled code directly to the card. Could Linux finally be able to get "release day" open source drivers for AMD cards?

Re:'MANTLE' was the game-changing announcement

[DarkTempes]

Mantle does sound like good news but they also said it is an open API and so I wouldn't be too worried about Nvidia...they'll just implement it themselves if it's so good.

And Nvidia has been crushing AMD/ATI in the PC market for a while (the Steam hardware survey shows 52.38% Nvidia to 33.08% AMD/ATI with 14% Intel).
Hopefully this will even things out some but I don't see it making OpenGL or DirectX obsolete.
OpenGL and DirectX have so much momentum and market share that game devs are going to have to target and support them for a while yet.

Also, until we get more solid details about Mantle we won't know how good it really is. I am cautiously optimistic but at most this will cause me to delay my next video card purchase until things shake out.

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

actually he is probably right, both 3D APIs DirectX and OpenGL are bulky, have big overhead and dont bring much to table except limiting developer, most future application/game UIs will be made by programing directly in OpenCL, or CUDA or MANTLE with DirectX/OpenGL "compatibility" layer loaded for slow old games, and if i was choosing API out of i would choose MANTLE because of level of control and performance compared to other 2

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

Isn't nVidia's Cg very close to metal as well?

it is, but this is even closer, CG is made to be compatible with many generations, this one is made without any compatibility whatsoever, compatibility is expensive

Also, you seem to be implying that making an GPL driver for Mantle should be easy since it will just send the compiled code directly to the card. Could Linux finally be able to get "release day" open source drivers for AMD cards?

release date probably not, but would make time difference much lower since most code would be cross platform

Re:'MANTLE' was the game-changing announcement

[epyT-R]

So, how much is amd paying you? I'd like to supplement my income.. OpenGL and D3D aren't going anywhere for the immediate future. We went down this vendor-api route with glide, and while it did run well, it created support issues for the consumer that fragmented the market and made it difficult to make money selling gpus. It would be nice, however, to see better support parity between the vendors' shader compilers.

Re:'MANTLE' was the game-changing announcement

[epyT-R]

Not if you care about your game running on the majority of hardware out there. You'd support a mantle path, but not exclusively.

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

The difference in performance will be MASSIVE when the rendering features made viable by Mantle are enabled. If these features are disabled, and the game is played in '2009' mode, Mantle will only give a small boost at best. So, if you want your game to look like crap, but play at some insane resolution with an ancient form of AA forced, you are right- the Nvidia solution will be fine.

Game publishers have a 95%+ AAA market that is AMD GCN exclusive- it is called the next-gen console market (and yes, these figures won't be true until a few years time, but this is the new unstoppable trend that all serious publishers must account for). Against the Xbox One and PS4, the PC market is a sad joke. It becomes a far less sad joke if AMD GCN gets properly established on EVERY gaming PC.

And what does Mantle solve? It solves the biggest problems with AAA graphics on the PC- namely memory management, multi-CPU-core processing of GPU intensive tasks, and massive numbers of GPU state changes per frame. DirectX and OpenGL are horrid jokes, designed for single thread CPU work driving simple workloads on a GPU. As these ancient driver models/APIs are forced to work with large numbers of CPU cores and GPUs that need to be in intimate control of their own memory resources, and instruction flows, inefficiencies build faster that improvements in CPU/GPU resources.

Mantle allows CPU and GPU operations that are just NOT worth attempting under DirectX/OpenGL. Here we are talking about performance factors that may be 10-100 times faster. A Mantle method could thus easily have a game running at unplayable frame rates if emulated under DirectX.

With existing engines like Unreal or those from Crytek or Dice, Mantle would, as I said, allow for features that could be enabled for the Mantle version, and disabled for the 'Nvidia' version (much as Nvidia does with PhsysX today). BUT the next gen engines ported from the consoles to the PC would suffer vastly greater degradation when run in 'Nvidia' mode on the PC. This problem will be solved for the next 3 years by having the 'Nvidia' version (or DirectX version if you will) being some form of the LAST generation console game- in other words the Nvidia version of the PC game would be running in 'Xbox 360' mode. The GCN version will be running in PS4 mode.

PC owners are in terrible denial about the massive architectural improvements in the PS4- they focus entirely on comparing the GPU of the console with current PC graphics cards, and completely ignore the advanced architectural overhaul the PS4 has over the ancient desktop PC. AMD wants to bring the same modern HSA/Huma design to the PC, liberating the full power of the PC hardware for the first time. Mantle is an essential part of this strategy. Without Mantle, PC owners can play games with the same crappy visuals, just at greater resolutions and framerates in the future. This is Nvidia's strategy. With Mantle (and the improvement of the PC architecture), the PC will have games that actually render ever more impressive scenes.

And here's a warning. If, for some pathetic reason, Mantle fails in the PC space, fewer and fewer AAA games will be ported to the PC, because as engines improve on the new consoles, their rendering codebases will be less and less compatible with the capabilities of the desktop PC. It will literally not be worth the effort of the publishers of games on the PS4 and Xbox One to move their most complex games to the PC. Nvidia will have killed AAA gaming on the PC dead.

The Mantle project is ESSENTIAL to ensure the best games have the best possible home on our PCs. The GCN ISA is about to become the coding language of AAA gaming algorithms, just as the x86 rose to prominence. Nvidia fanboys will whine and whine and whine and whine, but nothing they scream and dribble about will change the fact that 95%+ of future AAA games will use GCN close-to-the-metal, and therefore the tiny AAA PC gaming market must follow the same path. Nvidia fans can rest assured that casual games will be near 100%

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

The main benefit they touted was lowering the cpu load, which is interesting because the cpu is rarely the bottleneck. Also notice AMD's cpu's are far behind Intel's, and they actually have to benchmark the flagship gpus with intel cpus because otherwise the AMD cpu would be the bottleneck.

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

if you want compatibility there is always OpenCL, runs on AMD, NVIDIA and Intel, but its slower than CUDA/MANTLE

Re:'MANTLE' was the game-changing announcement

[willy_me]

Game publishers have a 95%+ AAA market that is AMD GCN exclusive- it is called the next-gen console market (and yes, these figures won't be true until a few years time, but this is the new unstoppable trend that all serious publishers must account for). Against the Xbox One and PS4, the PC market is a sad joke. It becomes a far less sad joke if AMD GCN gets properly established on EVERY gaming PC.

The new AMD flat memory model for GPU / CPU is very interesting. I assume this is what will be used in the upcoming consoles. But you have to realize that the console and PC markets are currently being crushed by the newly created portable market (Android / iOS). The larger market of iOS users combined with the App Store model that limits piracy has game developers making more money with their stupid little Apps then they do with their much more impressive console games. The Android market is also growing and, despite being limited by piracy, will eventually catch up with regards to developer profits.

AMD looks like it's making some impressive products when it comes to GPU / CPU integration. If they could catch up to Intel fabs (now at 14nm) they would be doing great in the market. They might also bring their flat memory model to mobile ARM CPU/GPU chips which would be quite interesting. But the reality is that AMD is not going to dominate the market anytime soon. Those who think otherwise have been drinking too much AMD Koolaid. These changes take time and we don't even know how Intel / Nvidia plan on responding - and they will respond.

Re:'MANTLE' was the game-changing announcement

[Khyber]

" limiting developer"

Not OpenGL. Extension not there? Just add it in. Can't do that with Direct3D.

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

Silence dirty console peasant! /r/pcmasterrace

Re:'MANTLE' was the game-changing announcement

[blahplusplus]

"The difference in performance will be MASSIVE when the rendering features made viable by Mantle are enabled."

I'm sorry but you are full of shit. Memory bandwidth has been the KEY factor in framerates. Not drawcalls. That drawcall bs is propaganda. Transistors > software (provides software developer isn't braindead). Always. The same way CISC was 'slower' then RISC, and the itanium was supposed to be the death of x86 but we still have X86. They found ways around it and to make it faster. Same deal.

Re:'MANTLE' was the game-changing announcement

[OhANameWhatName]

Hello Mr AC,

Of course, ATI customers with 6000 series cards or earlier (or Zacate, Llano, or Richland APUs) are as out-of-luck as Intel and Nvidia GPU users

So existing ATI customers are being given the shaft

With the rise of Mantle, many console games developers are going to desire that the PC market rapidly changes to AMD only

because games producers are going to ditch 66% of the pc gaming marketplace

Any PC gamer interested in high-performance would be INSANE to buy any Nvidia product from now on

in favor of the minority of sane gamers

Nvidia, on the other hand, will be cursing themselves for ever starting this war

because the market leader in graphics cards is going to start crying into their huge wads of cash.

Next time you write a new API, try creating world peace. We need that more than faster fly by wire shooters.

Sincerely.

Re:'MANTLE' was the game-changing announcement

[bill_mcgonigle]

AMD isn't a certain enough company for game developers to drop nVidia and Intel, and they're not all going to do do yet another port. Does AMD really think MANTLE will kill nVidia? They certainly won't kill Intel (yeah, the macho gamers all buy discrete hardware, but publishers won't give up all the buyers who run the games on integrated hardware).

If AMD is serious about OpenGL being a problem, then they need to take whatever they figured out in the lab about MANTLE and work to get it into OpenGL 5 (or whatever version). Or if Khronos won't listen, fork it, but that seems unlikely.

If AMD tries to take the industry with a proprietary API (ultimately meaning by using "IP" as a weapon) they'll just wind up hurting or killing PC gaming and sell less hardware.

Re:'MANTLE' was the game-changing announcement

[xiando]

Nothing can kill OpenGL, if DirectX couldn't do it, certainly not this proprietary shit.

Android based phones, tablets, consoles and even laptops and dekstops (yes, they are coming and they are getting better very very fast) all use a simple version of OpenGL. You'd have to kill that fast-moving train to kill OpenGL and that is not going to happen. Yes, AMD got a big win with it being the base of the new XBox and Playstation toys. That would have major implications a few years back. I'm not convinced it will make such a huge difference today. As I said, there are Android consoles for sale right now and more are coming. These android consoles won't have the horse-power of the new XBox / Playstation things, but it really won't matter. Also note that there will be one XBox and one Playstation but there are already dozens of Android consoles to pick from.

Re:'MANTLE' was the game-changing announcement

[Terrasque]

because games producers are going to ditch 66% of the pc gaming marketplace

I'd like to mention that many of them are currently ditching 100% of the pc gaming marketplace, and are doing fine.

Re:'MANTLE' was the game-changing announcement

[phorm]

Not if the API is tied to proprietary hardware, methods, or other such things.

Re:'MANTLE' was the game-changing announcement

[non0score]

I'm sorry, but you're the one who's clearly full of shit. GP clearly has some experience doing console/PC game programming. You clearly don't. Have you tried making 10k draw calls per frame on DX/OGL? Do the same in LibGSM, and you'll know the day-and-night difference (read: you can make hundreds of thousands of draw calls on the PS3, which is 6+ years old, without breaking a sweat). The point you don't understand is, the overhead isn't on the GPU -- it's on the CPU. Think Amdhal's law; the single threaded bottleneck is on CPU, and the speedup in PC graphics you see is from the parallel speedup in the GPU. The point of Mantle is to get rid of the CPU overhead, not somehow magically make the GPU faster.

Re:'MANTLE' was the game-changing announcement

[Guspaz]

Here we are talking about performance factors that may be 10-100 times faster. A Mantle method could thus easily have a game running at unplayable frame rates if emulated under DirectX.

This statement is so mindbogglingly idiotic that it pretty much makes anything else you say meaningless by proving that you really have no idea what you're talking about. AMD claimed that MANTLE might enable up to nine times as many draw calls to be made per second under ideal circumstances, but draw calls are not that big a bottleneck. Thinking that somehow reduced overhead on draw calls could enable a one hundred fold performance increase on the same silicon that is today rather well utilized is akin to thinking that if you reduced the distance between cars on the highway, you could somehow increase the traffic capacity by one hundred times without increasing the speed of the cars.

Re:'MANTLE' was the game-changing announcement

[blahplusplus]

"I'm sorry, but you're the one who's clearly full of shit. GP clearly has some experience doing console/PC game programming."

I'm sorry but the OPPOSITE is true, perhaps you don't know the theory behind ITANIUM. Do a bit of research you dumb cunt. Right now in the hardware world ALL SOFTWARE both GPU and CPU is suffering performance penalty from the memory bottleneck.

https://epic.hpi.uni-potsdam.de/pub/Home/TrendsAndConceptsII2010/HW_Trends_The_Processor-Memory_bottleneck___Problems_and_Solutions..pdf

"The rate of improvement in microprocessor speed exceeds the rate of improvement in DRAM (Dynamic
Random Access Memory) speed. So although the disparity between processor and memory speed is
already an issue, downstream someplace it will be a much bigger one. Hence computer designers are
faced with an increasing Processor - Memory Performance Gap [1] , which now is the primary
obstacle to improved computer system performance."

Re:'MANTLE' was the game-changing announcement

[Guspaz]

And this is why there are tons of ways to reduce draw calls using various batching techniques. Instancing, for example, or vertex buffers. If modern software drew every single piece of geometry or sprite or primitive using individual draw calls, then yeah, you'd see some massive speedups. But that's not what graphics engines are doing.

Re:'MANTLE' was the game-changing announcement

[non0score]

You are correct, and this is where a big chunk of work in graphics engines go into. But a lot of times, the batching just doesn't work well. For example, you can't batch well when you have custom materials written by artists (it used to work when there were only about 20 different materials -- you just set the textures and a few uniforms, and off you go). So having the flexibility of draw calls is definitely valuable here. Also, draw calls aren't the only performance bottlenecks imposed by DX/OGL.

Re:'MANTLE' was the game-changing announcement

[non0score]

Oh wow, you're vitriolic when you're proven wrong, aren't you?

1) Draw call overhead is a problem of CPU utilization and synchronization. On the CPU end, the drivers have to check a bunch of states before moving forward with the draw call (yes, like you said, this hits DRAM, but...!). During this check, the CPU may stall and stop handing instructions to the GPU until the GPU finishes with its current tasks (read: a sync), which stalls both the CPU and GPU. When you have 10000+ threads in flight, a pipeline flush is terrible for performance.

However, if you didn't have to check the states in the first place, there isn't such a problem, which is what Mantle allows. The problem with OpenGL (in the eyes of advanced developers) is exactly the safety net OGL provides for beginner developers. It's akin to an API function stubbornly checking its input parameters, even if you, the user of the API, already know that the inputs you provided to the API are valid.

2) Have you ever developed for Cell SPUs? The pros at doing so aren't complaining that the DRAM is too slow -- they're complaining that they don't have enough SPUs to do the wonderful things they can do with it. And since you're all up there quoting Itanium, you probably don't know the SPU only has 256KB (that's kilo, not mega or giga) of local store (i.e. local DRAM-thing). That and if you used Itanium as the counterexample, you just defined yourself out of the game development world.

3) If you understand the points in 1), then you'll realize that the reason for having the 10000+ threads in flight: to hide memory latency. When you flush all that (like what OGL and DX potentially do), you incur all of the memory latency again. The point of Mantle is to not have to flush nearly as often.

4) Yes, the CPU-memory gap is a valid problem. But in the game development world where most of the compute-intensive stuff already know ahead of time what portions of data the computations need to access, most of these problems are mitigated (e.g. latency hiding, prefetching, etc...). In other words, you're raising a problem that isn't even close to the biggest set of problems in the game development world. It's not like game developers are writing a huge database program that has no idea which part of main memory they're going to touch on the next request.

Re:'MANTLE' was the game-changing announcement

[blahplusplus]

I know all about this you stupid fuck, the problem is -- 99% of games don't need the marginal increase performance and that's EXACTLY what it would be. When looking at performance of games you have to look at total system performance of the entire system and the ecosystem of games. Say you increase draw calls by 900% it doesn't mean those draw calls are spent doing anything necessary to the game, in that there is no added value.

You're narrow minded thinking regarding performance is the issue, out of all the current cross platform games from consoles, you wouldn't even be able to name ONE where draw calls were a significant barrier to performance (i.e. the performance boost would be irrelevant).

Drawcall performance is only relevant on consoles because consoles are always slower and have less memory than PC's. PC's have had massive game and graphics headroom for years. Head and shoulders above the PS3 and Xbox 360. Graphics cards have been lightyears ahead in terms of memory and texture size on PC. But textures and gamecode/levels have to be dumbed down for the LIMITED MEMORY of consoles.

So draw calls are only one small marginal thing that goes into game quality. You can have the best hardware on the planet drawing tree's, but they only add marginal value to the game, especially if you console company cheaps out on memory. Epic's #1 concern with consoles was main memory and video memory, not drawcalls. Why would that be? because they take a systemic view of what adds value to games.

There is this thing called 'good enough' and we've been there for the last 6-8 years. Most games target the lowest common denominator because they don't have massive AAA budgets. 99% of games are made for cheap out-dated hardware.

You couldn't find me any current console port that would benefit in any major way from increased drawcalls... why? because the PC is light-years ahead of the console space in terms of performance.

You're splitting hairs like dumbass, you're not 'correct' in anyway because what a gamer cares about is whether a game is any good, they could care less about the technical details of drawcalls.

Drawcalls and minor performance boost it would add are the LEAST important thing when it comes to making a fun game, this is LOST on you.

Re:'MANTLE' was the game-changing announcement

[Sollord]

Mantel is directly related to AMDs total ownership of the nextgen console market and it should let developers use mantel to optimize across both consoles and AMD based pc using generally one main code base with only minor tweaks for each platform but of course it screws over anyone with a nVidia gfx card who will get stuck with the lower optimized paths. This is basicaly just AMD releasing it's custom GCN based console development api for PC usage allowing develops the option to max out the games on PCs with GCN based gfx cards

Re:'MANTLE' was the game-changing announcement

[Guspaz]

Sure, but a 10x performance increase beyond what you'd get by batching seems ridiculous to me. I'm not denying you're going to get extra performance and flexibility out of a lower-level API, but the AC who started this whole argument's claims that you'll see orders of magnitude greater performance don't fly.

Re:'MANTLE' was the game-changing announcement

[non0score]

LOL, you're not fooling anyone with your arguments. You first talk about "Memory bandwidth has been the KEY factor in framerates." Then you move on to saying Epic cares about memory [size]. Then you jump to talking how none of that matters because all people care about are fun games. I love how you jump from point to point because you don't even know what you're talking about. Since you offer so little detail and like to quote Epic, I think it's pretty obvious to everyone here that you're a raving fanboy of the PC Master Race, and definitely not someone technical at all -- exactly the type of person that entertain us devs.

I think one thing you utterly failed to understand is that we engine devs only care about performance. We make our engine run fast so that our pals in the gameplay department can make the game fun and interesting. If our engines run slow, then their gameplay suffers because they can't have as many AI simultaneously, can't have as many enemies on screen (drawing, AI, physics, you name it), etc.... There are only a fixed number of cycles in a CPU every time delta; if we take one cycle, that's one less cycle for gameplay. If you can't understand that distinction, then I don't know what position you're in to argue. It's clear that "you know about this" in the sense you read some comments out of context on some random forum.

Here are a few other points:

* If you think that performance isn't an issue, why did you even bring up bandwidth numbers?

* If "There is this thing called 'good enough' and we've been there for the last 6-8 years." is true, then why do you complain about PS3/XBox360 holding PC gaming back? Afterall, they're from 6-8 years ago (and they were close to top-of-the-line back then).

* Yeah, I definitely can't find any current day console ports that are limited on draw calls, but that's because (if you read any of the articles on the tech sites about Mantle) video cards have brute forced their way out of the problem. But I'm sure if there was any console ports back in 2007 (or after LibGCM got released), they would benefit from it. Furthermore, you're asking for selective bias -- if a console game was draw call limited, the chances of it making to the PC world would decrease. So what you're asking for is just plain absurd. But now that the new generation is ahead of us? Yeah, the draw call issue will come to the forefront again.

Re:'MANTLE' was the game-changing announcement

[blahplusplus]

"Yeah, I definitely can't find any current day console ports that are limited on draw calls,"

Thank you. This is all we needed. All AAA game console ports worth playing are not limited on draw calls... and even then the AAA ports are still underutilizing PC CPU and GPU power by a huge grotesque margin (i.e. lower resolution texture models, etc, etc). You were telling us how it was going to miraculously change performance for ever, yet even the most advanced AAA games are not limited on draw calls, and games don't even use high enough quality textures/models to even make use of the massive underutilized power we already have.

You said " video cards have brute forced their way out of the problem. "

Duh... you ignored this part of my post I said "They found ways around it and to make it faster. Same deal."

Nothing you said in any way disproved what I said, I said the key factor was memory bandwidth and you didn't prove that with you draw call thesis and you just said 'they brute forced their way out of it' (aka transistors/memory advancements).

Thanks buddy for PROVING WHAT I JUST SAID ALL ALONG.

The worst part is you have no AAA game examples, where mantle would add anything to the most popular AAA ports, why is that? Because we already have more then enough performance on the PC already. The real bottleneck for PC games has always been fucking consoles. We'd be so much more advanced if PC had been the main platform to begin with and we didn't have to tolerate sloppy low quality textures and severely cut down content (smaller levels, etc) of AAA console games to fit them in the limits of the console's memory.

The reality is all your talk of mantle centers around being a console centric game programmer (and it's obvious you are) there are alternative models that would have emerged if PC had remained the main platform. Optimization and software models would have just taken a different (and more accelerated) path.

The fact that you harp on Draw calls, means your a console fanboy who's never done any serious PC development. This is really about your hard-on for game consoles and nothing else.

Re:'MANTLE' was the game-changing announcement

[non0score]

Awesome, you just went ahead and showed off how ignorant you are and how much you're frothing at the mouth for your supposed PC Master Race "superiority". There are so many factual errors in your reply that it's going to take a while to respond to.

If you want to say that consoles are holding PC development back TODAY, sure, I can work with that. But if you weren't blind, you'd see that I said I can't find current day console ports that are limited on draw calls. After all, PCs have brute forced their way past consoles. On the other hand, when the current gen console games were first released (that is, 6+ years ago), there were definitely draw call limitations on their PC ports. For that matter, I'm not sure why you're railing so hard on modern day ports. Obviously the progression of time would've solved some issues. So you only need to look further than any of the PS3-only dev houses a few years back to realize none of those games could ever run on a PC at the time (pick any game out of Naughty Dog, Insomniac, Sucker Punch, Gorilla, etc... I'm sure there are X360 houses that work just as well). Your frivolous arguments against draw calls being an issue when next gen comes out (in two months) hold as much water as saying that that 640KB is enough for everyone.

Besides, let's face it, are the engineers at AMD clueless? Are PC/console game devs clueless? Are the guys who wrote LibGCM clueless? If you think they're smart, then AMD either wouldn't have released this or AMD would've been criticized for doing so (by devs and/or tech sites). Neither of this has happened. So there is only one conclusion we can draw: you think you're so smart that all other developers are idiots. In that case, please keep talking, because I think this is comedy goldmine for all the devs reading (PCs AND consoles).

The point you keep missing is hardware keeps moving forward, including consoles (albeit at a 7+ year interval now). When consoles catch up in hardware, the games are going to blast draw calls because of the availability of low level graphics libraries. When those games get ported to PCs (or co-developed), the PCs will be bottlenecked by draw calls if they keep using DX or whatever the high level gfx libs are for PS4. I think if hardware/software devs are as shortsighted as you, then PC ports will be unplayable. Just because PC games don't make a lot of draw calls now doesn't mean they won't in two months. Then again, maybe the point is that PCs are holding back consoles because they can't perform those draw calls.

And again, since you're of the PC Master Race, I'm sure all you think about is how to jack off to your dual Titan graphics cards + i7-4770...all the while forgetting that all but Crysis will target much lower hardware platforms. I.e. they will be much slower and will handle draw calls at much, much worse rates. Have you tried gaming on anything but enthusiast PCs? That's, they don't have any of the "massive underutilized power" that you so passionately claim.

As for you claiming that I didn't disproved what you said...well, I was never trying to disprove that the memory vs. CPU speed gap isn't a problem (and if you knew how to read, you would've seen this in point 4) two posts ago). The problem with all of your arguments is that you're missing the forest for the tree. The biggest problem that hinders even PC performance is draw calls; somewhere further down the list is your memory bandwidth/CPU disparity issues. It's clear you don't even know what Amdahl's law is -- you keep barking up the parallel tree when the biggest gains are going to come from optimizing the serial portions.

Re:'MANTLE' was the game-changing announcement

[blahplusplus]

"After all, PCs have brute forced their way past consoles."

And here you LOSE all credibility. PC's have ALWAYS BEEN AHEAD of consoles since the 3dfx era. By GPU power alone, PC's have NEVER been behind consoles. It's a myth propagated by moronic developers who never were part of the PC game era. You are just too obviously historically illiterate.

The xbox and gamecube used chips from PC graphics card vendors because.. GASP the PC was way ahead of console land. Xbox 360 and PS3 were never ahead, and Xbox 1 and GC were NEVER AHEAD of the PC EVER.

This myth is propagated only because developers jumped ship from PC around the 2000's, it's not because the PC was behind it's simply because console gaming was where the money was.

Re:'MANTLE' was the game-changing announcement

[non0score]

Yeah, it's hard to believe. But we've done experiments and seen the result. It definitely depends on your engine setup. If everything is just one uber shader in a forward rendering engine, this isn't going to be as much of an issue since you can easily batch (although you're going to hit fragment shader limits in terms of registers/compute very fast, not to mention keeping all of the combinations manageable). On the other hand, if you have artist-made materials, multiple alpha transparency settings, etc..., you're going to see that increasing draw call performance is going to dramatically speed up your game. Batching only gets you more of the same, and game artists hate more of the same.

Also do note that modern games do multiple passes on the scene. Shadow maps, gloss generation, normal generation, etc...and each of them multiplies against the number of draw calls per single layer. These all get factored in, and none of them can be batched across passes.

And to respond to your question about the AC's post, if you carefully read what he/she says, you can see that those are valid concerns the gaming industry has as a whole. So it's pretty clear that the person has at least some fundamental knowledge of what he/she is talking about with respect to the state of the industry. And if you visit some of my previous posts (not that you'd necessarily have the time, I'm just offering other opinions), you'd see other game devs agreeing on the issue that OGL/DX are dramatic overheads to PC graphics.

Re:'MANTLE' was the game-changing announcement

[non0score]

Calm down, son. If you can't see from context of the thread or my paragraph that everyone in this thread is talking about Mantle and not hardware specs (i.e. brute forcing past the draw call issue), then there really is no hope or point in further educating you. The fact that you don't even understand that draw call limitations are CPU-bound and not (presently) GPU-bound shows how little you know of this subject. Now that you understand this is a CPU issue, where could you find a CPU that matched the computational throughput of a Cell processor or the SPU's guaranteed 5 cycle latency? Intel processors couldn't even come close at the time (the Core 2 was released in mid 2006, a few months before the PS3). Sure, the Core 2 could've done better than Cell in heavily branching code, but by many other measures (throughput, latency, etc...), the Cell is much better than the Core 2.

Anyway, it's clear that you don't understand even the basics of what's going on, I'll just leave this link for you to read over at Anandtech...if you know what's good for you.

Re:'MANTLE' was the game-changing announcement

[Anonymous Coward]

Yes, nothing says "standard" like extensions. OpenGL, a great way to detect a myriad of features, then have separate code paths for every combination.

3dmark firestrike performance?

[Anonymous Coward]

this firestrike?

New Family, My Ass

[Khyber]

If these links are to be believed, this is just another rebadge:

http://news.softpedia.com/news/First-Sighting-of-Radeon-R9-280X-Really-a-Rebranded-HD-7970-GHz-Edition-386239.shtml

http://videocardz.com/45877/amd-radeon-r9-280x-rebranded-hd-7970-ghz-edition

http://www.techpowerup.com/191440/radeon-r9-280x-is-rebranded-hd-7970-ghz-edition.html

http://www.guru3d.com/news_story/radeon_r9_280x_could_be_a_rebadged_hd_7970_ghz_edition.html

Re:New Family, My Ass

[Pinhedd]

Low end models in each familar are almost always a rebadge of the high end models from the previous family. This has been the case for a very long time. It allows the manufacturer to better move inventory that would otherwise be unsold.

Re:New Family, My Ass

[AbRASiON]

When you say "a very long time" I assume you only mean a generation or two? because this tacky shit wasn't done by any of them a while back. Each model number in a 3xxx series was all based on the 3xxx tech or the 2xx or whatever. Now as you state the top end part in a series is new, the middle end parts in the new series are old.

It's deceptive.

Re:New Family, My Ass

[armanox]

nVidia is famous for rebadging. I'll give an example: the Geforce 8800GTX became the 9800 GTX, and then the GTS 250.

ATI on the other hand, has followed a different pattern. All cards of a series (HD 2xxx, 3xxx, 4xxx, etc) are based on the same tech. The 6xxx series cards were tuned versions of the 5xxx cards, and I think what's happening is the new R-series cards are tuned versions of the 7xxx series. nVidia does this with their cards now too - the Fermi family (4xx and 5xx) and Kepler family (6xx and 7xx) introduce a chip in the first gen, and refine that chip in the second.

Re:New Family, My Ass

[TubeSteak]

They also seem to be saying that the flagship R9 290X is going to be based on the new technology.

Re:New Family, My Ass

[Anonymous Coward]

Low end models in each familar are almost always a rebadge of the high end models from the previous family

Try the same card in some cases. And I mean literally the same card. e.g. the 5770 and 6770. The only thing that changed was the first numeral.

Re:New Family, My Ass

[Anonymous Coward]

Ever looked at their Mobile GPU range?

AMD is full of rebadges.

Re:New Family, My Ass

[Anonymous Coward]

It also happened 10 years ago, not just " a generation or two" ago. In 2003 the Radeon 8500LE was rebadged as the Radeon 9100.

Re:New Family, My Ass

[Blaskowicz]

"Radeon X1250" was also a chipset based around Radeon 9600/9700 tech, and its users were shafted with dropped driver support.
Current "Radeon 8660D" is kind of a cut-down Radeon 6970. So you have Radeon 7000 series (barring some OEM and laptop models) with a more recent and advanced architecture than Radeon 8000 series :D

As AMD now wants to boast about their GCN and HSA, they thus needed to introduce R5, R7, R9 as a naming clean up.

Re:New Family, My Ass

[edxwelch]

in the case of mobile gpu's this will be the secound time around. The 8000 series was a rebadge of 7000 series

Re:New Family, My Ass

[armanox]

My experience with mobile GPU is greatly lacking, I'm afraid.

Re:New Family, My Ass

[Pinhedd]

Both companies have done this for quite some time. They often introduce new products into emerging markets to sell off old silicon.

The Radeon 9100 (2003) was a rebadged Radeon 8500 (2001)

The HD 3410 (2009) was a rebadged HD 2400 (2007), and the HD 3610 (2009) is a rebadge and slightly retuned HD 2600 (2007). In fact, most of the HD 3000 series was a patch for the short lived HD 2000 series.

The HD 4580 (2011) is a rebadged HD 3750 (2008).

With the exception of the HD 6900 series GPUs, the entire HD 6000 family is just a fine tuning of the HD 5000 family. Only the HD 6930, HD 6950, and HD 6970 are based on an actual architectural revision.

It got really bad with the HD 7000 series though, with all of the 73xx through 76xx models being based on low end HD 6000 GPUs which were themselves refinements of the HD 5000 family.

a change is gonna come

[enzo1]

I am starting to distrust the Radeon brand. Look at their decrepit website—clearly AMD is under poor management. They are a near–penny stock and haven't even thought to improve their marketing image. I've always bought Radeon cards, but an idiot could see that the GPU market is ready for a landscape change.

Re:a change is gonna come

[PixetaledPikachu]

are you by chance opened radeon.com? Go to amd.com instead

Ignore numbers

[rsilvergun]

just look at the bit rate on the memory bus. Video card manufactures use the mem bus bitrate to limit card performance so that their low end doesn't cannibalize their mid range and high end (ala 3DFX).

128-bit is low end.

192-bit is your mid range card.

256-bit is your high end.

You don't need to pay attention to anything else until 256 bit. After that just sort by price on newegg and check the release date. Newer is better :)

Re:Ignore numbers

[Anonymous Coward]

You forgot 64-bit for 'spreadsheet end and grandmas'

Re:Ignore numbers

[Anonymous Coward]

False. Perhaps this was true in the past, but currently memory bandwidth is tailored to the GPU's processing power - that is, it's the bandwidth the core needs, usually defined by the most bandwidth-hungry scenario.

Bandwidth is not constrained by bitrate alone, but by bitrate and clockspeed - a 128-bit interface at 2 ghz is just as good as a 256-bit interface at 1 ghz. Usually the wider bus is less power-hungry at the same bandwidth, and is therefore preferred.

Also, bitrates of 384 and 512 exist.

Re:Ignore numbers

[Anonymous Coward]

you forgot 384 bit, 512bit (this new radeon card with 4GB GDDR5 seems to be 512bit) and "dual" cards
with 2 GPU and twice ram (2*384bit and 2*512bit probably)

At the risk of being labeled troll

[rsilvergun]

I'll ask what /.ers think of the stability of low end ATI hardware. I've heard once you get into the $250 range it's fine, but everything I've tried below $130 has crashed hard on everything except the biggest titles :(. I miss my super stable 1650...

Re:At the risk of being labeled troll

[Khyber]

I never had a problem with my crap of the line HD4200. Sure, it's not going to run the latest and greatest at any respectable frame rate, but hey, it worked and didn't die.

Re:At the risk of being labeled troll

[bemymonkey]

I'm currently running a 7750 (my critera were basically SC2 and CS:GO at a solid fps-capped 128FPS, so anything more would have been overkill) and haven't had any issues whatsoever. Rock solid cheap card...

Re:At the risk of being labeled troll

[PixetaledPikachu]

The most recent AMD card that I have is the Radeon 5650, embedded on my Vaio E-Series. It certainly won't win any speed contest, but it can comfortably runs MOH, BF3, Skyrim, Deus Ex Human Revolution, Dragon Age 2 on windows, TF2, Dota 2, and Strike Suit Zero from Steam's Linux library, and finally Street Fighter x Tekken on wine on Ubuntu. No crash whatsoever, at least nothing GPU related. I started with ATI Rage Pro, and went Nvidia for several generations (Riva TNT2, Ti 4200, and 6xxx). I returned to ATI with the X300, just in time when ATI released their first linux binary driver. I'm not really an avid gamer and any graphic chip will suit my daily usage scenario, so I decided to support them, and my next two cards are AMD's 3470 (on Toshiba M300), and the aforementioned 5650. I have ran GTA III, Need For Speed (Most wanteds, carbons), Fallout 3, Super Street Fighter IV, and many other things, and the AMD cards are the least of my problem

Re:At the risk of being labeled troll

[Radical Moderate]

I've been running a 5670 for a couple years. Other than some minor glitches in Skyrim, no issues.

Re:At the risk of being labeled troll

[tibman]

Same here. I do have a small problem with the driver though. I have to use a special version or the box might lockup. But it is a great card and has been rendering perfectly for years. Just ordered a 6970.. very excited for the upgrade!

Curious about stability

[PhrostyMcByte]

The idea is that operating systems introduce a huge amount of overhead in the name of security. Being general purpose, they view their primary role as protecting all the other apps from your unstable app. And, lets face it, even AAA games these days are plagued with issues -- I'm really not sure I want games to have low-level access to my system. Going back to the days of Windows 98's frequent bluescreens isn't on my must-have list of features.

John Carmack has been complaining about this for years, saying this puts PCs at such a tremendous disadvantage that consoles were able to run circles around PCs when it came to raw draw calls until eventually they simply brute-forced their way past the problem.

Graphics APIs have largely gone a route that encourages keeping data and processing out of the OS. That's definitely the right call, but there are always things you'll need to touch the CPU for. I'm curious exactly how much of a benefit we'll see in modern games.

Re:Curious about stability

[epyT-R]

1. today's consoles also run protected mode (or architecture specific equivalent) operating systems too. The userland kernel hardware latencies are present.

2. You're complaining about games? Today's operating systems are hardly any better off. There is no way the vendors can vouch for the security of 10gb worth of libraries and executables in windows 7 or osx. The same is true for OSS. Best practice is to just assume every application and system you're using is compromised or compromisable and mitigate accordingly.

3. IIRC that particular carmack commentary was done to hype up the new gen systems. It's largely bogus. I'm sure the latencies between the intel on-die hd5000 gpu and cpu are lower, but that doesn't mean it's going to perform better overall. Same thing goes with the amd fusion chips used in the new consoles. They're powerful for their size and power draw, but they will not outperform current gaming pc rigs..

Re:Curious about stability

[MTEK]

Bring back DOS. Or something like it. If people are willing to spend crazy money on gaming hardware and tweaking the MHz out of it, let people reboot their computer into a dedicated game mode, one where the OS layer is incredibly thin, even single-user, if it means performance would be that much better.

Re:Curious about stability

[Terrasque]

Did anyone say SteamOS?

Re:Curious about stability

[Parker Lewis]

"The Windows NT 3.x series of releases had placed the GDI component in the user-mode Client/Server Runtime Subsystem, but this was moved into kernel mode with Windows NT 4.0 to improve graphics performance." > http://en.wikipedia.org/wiki/Architecture_of_Windows_NT

Re:Curious about stability

[non0score]

3. Sorry, you're completely wrong. Try making 10k calls per frame (30fps) on a modern high-end PC (use the latest Haswell i7 + 7970/780 if you want), and your game will still slow down quite a bit due to single-threaded CPU overhead. On the PS3 (which is over 6 years old now?), you can make hundreds of thousands of draw calls per frame on libGSM and get away with it just fine. Why? Simple: every time you make a draw call on OpenGL/DX, you have to validate/potentially flush/sync all sorts of states. On libGSM (and to some extent, the special DX on the X360), it's a simple "write 4-byte value to command buffer, which is in CPU land". Yeah, semi-immediate/deferred mode 4TL.

Re:Curious about stability

[Anonymous Coward]

Simple: every time you make a draw call on OpenGL/DX, you have to validate/potentially flush/sync all sorts of states. On libGSM (and to some extent, the special DX on the X360), it's a simple "write 4-byte value to command buffer, which is in CPU land". Yeah, semi-immediate/deferred mode 4TL.

Consoles have the benefit of running games in kernel mode, making 0 overhead for system calls.

Today I learned

[Anonymous Coward]

that AMD still exists.

Re:Today I learned

[Khyber]

You mean today you just crawled out of your hole, considering AMD has all three consoles, and they're about to drop a brand new graphic architecture to the table.

Re: Today I learned

[Anonymous Coward]

Troll harder

AMD = case study in good engineering, bad biz dev

[hyperfl0w]

Recall when AMD first had 64bit support and intel was still doing *EMULATED* 32bit. AMD was hands down the best option. Either AMD biz dev was bad, or Intel biz dev was good (illegal?), or both. I suspect it was both. Having one CPU maker is bad for everyone. Long live AMD, I guess.

Will it fit?

[dutchwhizzman]

Maybe you should instead buy a new PC to replace the power hungry CPU and small storage you have in it and gain faster GFX with the built in on the CPU? Without giving specs of what you are replacing, your comment sounds awfully like a fake review.

Re:AMD = case study in good engineering, bad biz d

[Blaskowicz]

Dunno what you mean by "emulated 32bit", Intel had 64bit itanium with emulated or hardware assisted emulation of x86 32bit. It was crap and sold on computers that cost the same as a house or a car. Then they had 64bit Pentium 4 (and Xeon Pentium 4), not very great but a full 64bit x86 CPU.

Re:AMD = case study in good engineering, bad biz d

[Anonymous Coward]

Thinking about bulldozer, pilledriver and heat generation, I'd say: not really.

Lucky Luke

[aliquis]

They should had called it Lucky Luke.

No-one draws faster!

Re:AMD = case study in good engineering, bad biz d

[turgid]

Then they had 64bit Pentium 4

No, the Pentium 4 was most definitely 32-bit. AMD got the first 64-bit x86 CPUs out in 2003 and intel didn't have any for sale until at least 2005 IIRC.

The 1.4GHz 64-bit Opterons spanked the 2.8GHz Pentium 4s...

In those days, intel was a joke.

whats the hashrate?

[KingBenny]

do they compare to an asic mining box ?