"AMD Hawaii (R9 290 series) GPU diagram leaks out" - Videocardz.com


The second image, showing the synthetic performance increases is what I found really interesting. That of course showcases the differences between the HD 7970 Ghz and the R9 290X. Since the HD 7970 Ghz is essentially the same as the R9 280X, this means we're pretty much also seeing the differences between the R9 280X and R9 290X.

(The part below is my own attempt to analyze the comparison chart. Sadly, I'm not experienced in analyzing this... did I get this all right?)

The increase in geometry means better, finer meshes. This means more rounded faces, more realistic folds in clothing, etc. The increase in compute means that if there's an OpenCL Game Physics Engine middleware software included, we'll see an increase in physics realism as well as a decrease of CPU usage.

The texture increase should allow higher quality and resolution (larger textures... why hello there 4K Skyrim texture mods? where have you been all my life? XD ). Pixel fill rate should also mean higher resolution gaming should be better.

The increased compute should only matter when using OpenCL or Mantle, mostly. Speaking of which, if Mantle gets rid of the DirectX bottleneck, might we see 4K gaming at Maximum/Ultra settings at 60fps to 120fps using a single GPU? A gamer can always dream and hope... *sigh*

Question about mantle. Since direct x is a software layer between the game and the hardware, removing that potentially removes a bottleneck but standardizes the process. Do you think removing that standard layer lead to more "buggy" experience? Or, at the very least, a variety of experiences for one game. 

Personally, I'm skeptical. I'm gonna sit and wait till I hear from reviews of all kinds of games to then see what's up. 

Well, it does standardize a lot of things. It allows hardware companies like Qualcomm, AMD, nVidia, Samsung and others to create a single API to access their hardware. This makes game development and coding MUCH easier and standardized. Although there might be some HUGE bugs at first, that's where Quality Assurance, bug testing, closed betas, open betas and other testing happens. This is to ensure the product delivered is as good as the customers demand.

But that doesn't always work. Look at how many patches Skyrim has had since day 1 of the launch, and then check the Unofficial Skyrim Patches which include a metric butt-ton of other fixes that Bethesda never bothered to release or fix in the first place!

So while it may have a learning curve, that's alright; it's something every API and every programming language goes through when it first comes out. But remember something about standardization; think about how much development has been going on with CSS and HTML. Think of how many forums, solutions, code examples and more are out there for HTML and CSS. That was only possible because they became a standard.

If AMD Mantle has the same thing, it'll mean there will be a lot of standardization going on. And if we see Mantle being adopted by ARM hardware companies for mobile phones, we'd now have a way of removing a great deal of the bottleneck from performance.

Think about it this way. DirectX is high-level, and very integrated with the Operating System. If you bypass all that stuff and go directly into the hardware, you can get MUCH better performance. One example I found way that I was using an API in Visual Basic 5 (back in 2005) to draw a 120x120 four-way color fade, custom palette to show my classmates how color fading could be made using multiple dimensions (not just a single dimension), and how one could do so using a single formula.

I wasn't familiar with a single draw call, I only knew how to use the single draw pixel command. Because of this, and the fact that I was using Visual Basic rather than C++, I could only get the darn thing to render after 20 seconds! (Of course it was a bad system, even by 2005 standards, but still. CorelDRAW could do it in the blink of an eye!)

If I had a better API, I could have made this work much better. If I was working at low-level, I might have been able to do all the coding in a very short amount of time, and then render it once it was done. But due to the API I was using, I couldn't.

I know my experience isn't exactly modern, but it shows what happens when you have the OS and a high-level API get in the way.

I hear that some developers claim that Anti-Aliasing would run 100x faster if the DirectX bottleneck was removed. And if that's so, we might see colossal framerate improvements and eye-candy not currently possible given the DirectX bottleneck.

Also, standardization will decrease development time for games, because consoles, PCs and mobile devices might have the same API. Than just use RISC (ARM) or x86-64 for your coding where single-threaded performance is needed, and you're golden. And maybe use OpenCL if you want some highly-parallelized compute power, if you feel you need it.

It makes development a lot easier. Imagine if the internet didn't have HTML and CSS, but instead 40 different languages. AMD, by making Mantle an open API, have created a platform on which other hardware manufacturers can improve their performance. It's a win-win solution for everybody (except Microsoft and DirectX).

Those are slides from the original presentation at the GPU14 event.

What we need is benchmarks. Official ones. :)

whats the diffrence between the 290 and the 290X?

I hope Battlefield 4, in December, will provide us with exactly that. If Mantle is as good as promised, we might see an en-masse migration towards SteamOS, if there are enough games there.

If GOG.com, Steam, and game publishers start getting their code ready for x64 and Mantle, it will be amazing! (And assuming Avegant's VR glasses and the Oculus Rift are as good as we would hope, we might see some really nifty stuff as well.)


The R9 290 Non-X has 2560 Stream Processors, a slightly lower clock, and few other differences from what I can tell. The Base Clock drops a lot, but the boost clock is similar.

Also worth noting is that the amount of TMUs (Texture Mapping Unites) is slightly smaller, 160 in the 290 Non-X versus 176 in the 290X.

Most importantly, the price of the 290 Non-X should hover around 499$ to 549$ (US Dollars), and the 290X should be around 650$. This means it's going head-to-head against the GTX Titan at a much lower price point.

This strategy has been seen before. Remember how closely the GTX 670 and GTX 680 were, and how closely matched the HD 7950 and HD 7970 were at launch? That's how the R9 290 Non-X and R9 290X are going to be. The 290 Non-X is going to be high-performance, better value, while the 290X is going to be for gamers who are interested in benchmarking, overclocking, bragging rights and looking down upon those who don't have swiss banks for wallets.

However, given that the R9 280X is already at 299$, and it's going to be about 60~80% of the gaming horsepower of an R9 290X, the two-fold increase in price isn't going to make the R9 290X a bang-for-your-buck option.

Also worth noting is that nVidia is going to drop prices to compensate for AMD's new card lineup. If so, we'll definitely see a pricing war on our hands - which is good for gamers and good for PC sales, which is exactly what the market needs right now.

(Was that helpful?)

hey thank you ☺ yes i was helpfull diffrences are indeed basicly the amount of stream processors.

There is a general movement of AMD towards the enterprise side of things, their consumer cards are pretty sweet deals for people that need raw computing power. All AMD CPUs are unlocked, but also all AMD CPUs and chipsets have full hardware virtualization. This was traditionally something for the enterprise server market, but as RedHat have shown with nVidia cards running on Intel VT-d enabled platforms, there is also the opportunity of considerable graphics acceleration, at least in linux, which scales well.

Scaling was never a feature of MS-Windows, so people had to buy ever more absurdly overpowered hardware to run pretty basic stuff with acceptable performance. Not only DirectX was the problem. DirectX was always a lie. Microsoft had to come up with a "direct API" after the Core APIs that Steve Jobs introduced when he stole BSD to make BeOS, which became MacOS/OSX. That is a much more "direct" API than DirectX ever was, and everyone that has done multitrack audio production on a PC and on a Mac, will tell you that DirectX never was "direct", in fact, everyone used the Steinberg ASIO API for low latency sound card access instead of DirectX. The same goes for video, DirectX is the most "indirect" graphics API in existence on any platform, it's simply a disgrace, but it was pushed further because Microsoft dodn't allow any alternative on Windows.

Lately, AMD has been very busy bringing enterprise server technology to all of their products, and leveraging performance of various subsystems along the way. An example is OpenCL. AMD GPUs have a lot of compute cores, and AMD graphics cards have a wide data bus. This was used by AMD to allow users of a scalable system, like linux, to try and integrate the existing load balancing technology that has always been a focus point of linux, into those AMD products, and that has worked. In linux, using existing open source tools, you can use AMD GPUs as compute coprocessors. Problem is, this is a feature of linux, that requires some knowledge of the user to configure the load balancing. So AMD took that technology, and made an API that basically recognizes running applications, and activates a profile-based load balancing for them based on the standard existing open source linux tools. That technology is also free to be used by nVidia or Intel, but those manufacturers don't have as many compute cores on their graphics products, and often have a narrower data bus. Also, Intel doesn't believe in enabling hardware virtualization on consumer platforms, and nVidia doesn't help with development of open source drivers that would enable this, and tries to stick to CUDA for it's own proprietary binary blobs. The logical next step for AMD would then be to provide an API that would basically be a simple tool to manipulate the load balancing and direct hardware access functionality, and would allow application developers to create their own performance profiles system-wide (of course not in Windows, that is technically not possible, but in linux, it is normal). The benefit of Mantle in Windows is thus limited to circumventing the buggy and crappy DirectX, but the benefit of Mantle API and profile-based load balancing software optimized for AMD GPUs in a linux operating system, would be exponentially higher. That would allow AMD to not only improve graphics performance enormously, but also to improve compute performance in general, and, on a linux system, provide a cost effective way for users to scale up their system using GPUs. I'm running an array of 5 AMD GPUs right now on one of my AMD Opteron-based servers in a HPC test project, and I'm very likely going to add at least 5 extra cards to that machine. It scales very well for compute performance, and that's without AMD-optimized software, just using the traditional linux tools. I did do trials with nVidia first, I did trials with Intel, Intel beats the AMD solution in raw power, but not in flexibility and overall HPC performance, nVidia didn't perform that well because it's not flexible at all and the compute performance was not what I had expected.

As to ARM-platforms, very little groundbreaking things can be expected from nVidia and Qualcomm for instance, but take a look at some other ARM-licensees, that are using Mali 624 and siminal GPUs on their SoC's: these are DirectX11 compatible! Yes, you've heard right, DirectX 11 compatibility in a 17 USD SoC with up to 8 application processor cores and up to 8 GPU cores. See it as wine built into the hardware. And all the leading development for these is open source. That means that soon, these SoC's will be able to run whatever a user may want to throw at them, and that would allow users a seamless transition from the legacy platform and applications to the new ones on very cheap devices. These SoC's come to the market in Q1 2014, so that's very near.

So of course AMD - that is not an ARM-licensee - wants a piece of that, and they might just have the piece of the puzzle that makes it all possible, because if they deliver the tools needed to profile load balancing on multiple platforms and circumvent DirectX, they have a similar answer for the x86 platform ready to go. Full hardware virtualization on all of their x86 products means that people can virtualize ARM with great performance on their AMD machines and use ARM-focused applications, but at the same time, run legacy DirectX stuff, and run new windows-based x86 stuff with almost legacy linux grade performance, and run modern linux stuff with incredible performance, much faster than ARM, because ARM runs fast, even though it's basically much less potent hardware, because it isn't held back by closed source proprietary and legacy crap like x86.

nVidia doesn't follow the same path, because they are ARM-licensees, and they think they can persuade consumers to buy both their x86 products, and their ARM-products, and set up honey traps like rebranded open source streaming technology to justify that.

We'll see what approach has the most success in the future...

Thanks for the great info, Zoltan. +1 for your awesome post!

Thanks. Make sure you also check the difference in base clock, because that might be of more concern.

(I hope some cards with OC included will remove the boost clock, and just run the base clock at 1000Mhz or higher.)

That was helpful, but on launch day, you can get a 290x for 595.20$ or 591.62$. (But, do note the Canadian Dollar site does show the 290x for 650 us$ normally.)

I have high hopes for the 290. Hopefully it will come in at a good price and I can finally finish this build off.