Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by samzenpus on from the latest-and-greatest dept.

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

5 of 188 comments (clear)

  1. Mantle API by LordMyren · · Score: 5, Interesting

    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

  2. Re:Schlameel, Schlamazel by SJHillman · · Score: 5, Funny

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

  3. Curious about stability by PhrostyMcByte · · Score: 5, Interesting

    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.

    1. Re:Curious about stability by epyT-R · · Score: 5, Interesting

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

  4. Re:without decent drivers by MojoMagic · · Score: 5, Insightful

    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.