The Radeon R9 280X Review: Feat. Asus & XFX - Meet The Radeon 200 Seriesby Ryan Smith on October 8, 2013 12:01 AM EST
Mantle: A Low-Level Graphics API For GCN
Before we dive into the hardware itself we want to spend a bit of time talking about AMD’s new software and technology initiatives for the upcoming year. Most of what we’ll discuss in the next few pages isn’t 200 series in particular, but these are items that will be of importance to AMD’s ecosystem over the next year and beyond.
We’ll start of course with Mantle, AMD’s low level graphics API for GCN. Mantle was first announced at AMD’s public GPU 2014 technology showcase, as part of AMD’s greater plan to leverage their next generation console relationship. Mantle is fundamentally a low level API designed to interact extremely closely with AMD’s GCN architecture GPUs, and in doing so will let them achieve greater performance than either Direct3D or OpenGL in some situations by bypassing the abstractions and overhead that can slow down the rendering process.
Unlike some of AMD’s other technology announcements the company presented everything regarding Mantle in their public session, so there isn’t any new previously-NDA’d material to discuss here. AMD won’t be discussing Mantle in any more detail until their Developers Summit next month. So everything we know about Mantle we’ve previously covered in our Understanding Mantle article, and as such this is going to be a summary of that article.
What is Mantle? Mantle is a new low-level graphics API specifically geared for AMD’s Graphics Core Next architecture. Whereas standard APIs such as OpenGL and Direct3D operate at a high level to provide the necessary abstraction that makes these APIs operate across a wide variety of devices, Mantle is the very opposite. Mantle goes as low as is reasonably possible, with minimal levels of abstraction between the code and the hardware. Mantle is for all practical purposes an API for doing bare metal programming to GCN. The concept itself is simple, and although low-level APIs have been done before, it has been some time since we’ve seen anything like this in the PC space.
Mantle exists because high level API have drawbacks in exchange for their ability to support a wide variety of GPUs. Abstractions in these APIs hide what the hardware is capable of, and are what allows widely disparate hardware to support the same standards. This is how for example both AMD’s VLIW5 and GCN architectures can both be Direct3D 11 compliant, despite the vast differences in their architectures, data structures, and data flows.
At the same time however the code that holds these abstractions together comes with its own performance penalty; there is always a tradeoff. The principle tradeoffs here include memory management – it’s potentially faster if you know exactly where everything is and can load exactly the data you want ahead of time – and CPU overhead from issuing commands to the GPU, due to all of the work that must be done via abstraction to prepare those calls for the target GPU and JIT compiling code as necessary. More commonly known as draw calls, these are the individual calls sent to the GPU to get objects rendered. A single frame can be composed of many draw calls, upwards of a thousand or more, and every one of those draw calls takes time to set up and submit.
Although the issue is receiving renewed focus with the announcement of Mantle, we have known for some time now that groups of developers on both the hardware and software side of game development have been dissatisfied with draw call performance. Microsoft and the rest of the Direct3D partners addressed this issue once with Direct3D 10, which significantly cut down on some forms of overhead.
But the issue was never entirely mitigated, and to this day the number of draw calls high-end GPUs can process is far greater than the number of draw calls high-end CPUs can submit in most instances. The interim solution has been to attempt to use as few draw calls as possible – GPU utilization takes a hit if the draw calls are too small – but there comes a point where a few large draw calls aren’t enough, and where the CPU penalty from generating more draw calls becomes notably expensive.
As a result we have Mantle. A low-level API that cuts the abstraction and in the process makes draw calls cheap (among other features).
However while the performance case for Mantle is significant on its own, it’s far from the only purpose Mantle serves in AMD’s plans. Low-level APIs are not easy to work with, and given the effort needed to develop engines against such APIs it’s unlikely one would ever take off on its own in this manner. So for all of the performance benefits of using Mantle, we must also talk about how AMD is going to leverage their console connection with Mantle both to help make porting easier for multiplatform developers, and at the same time use those games and developers to get the API off of the ground.
In the world of game console software both high level and low level APIs are commonly used. High level APIs are still easier to use due to abstraction hiding the ugly bits of the hardware from programmers, but when you’re working with a fixed platform with a long shelf life, low level APIs not only become practical, they become essential to extracting the maximum performance out of a piece of hardware. As good as a memory manager or a state manager is, if you know your code inside and out then there are numerous shortcuts and optimizations that are opened up by going low level, and these are matters that hardcore console developers chase in full. However because these optimizations are tied to the hardware underlying the console itself, when it comes time to port a game to the PC these optimizations are lost, as the game needs to be able to operate entirely within high-level APIs such as Direct3D and OpenGL. Or at least they used to, until Mantle.
Mantle in this context is a way to allow multiplatform developers to take their already optimized GCN rendering code and bring it over to the PC. They’ll still have to write Direct3D/OpenGL code for NVIDIA/Intel/ImgTech GPUs, but for AMD GPUs they can go lower and faster, and best of all they already have most of the code necessary to do this. Coming from the consoles to the PC over Mantle should be very portable.
How portable? The answer surprised even us. Based on our conversations with AMD and what they’re willing to say (and not say) we are of the belief that Mantle isn’t just a low level API, but rather Mantle is the low level API. As in it’s heavily derived (if not copied directly) from the Xbox One’s low level graphics API. All of the pieces are there; AMD will tell you from the start that Mantle is designed to leverage the optimization work done for games on the next generation consoles, and furthermore Mantle can even use the Direct3D High Level Shader Language (HLSL), the high level shader language Xbox One shaders will be coded against in the first place.
Now let’s be very clear here: AMD will not discuss the matter let alone confirm it, so this is speculation on our part. But it’s speculation that we believe is well grounded. Based on what we know thus far, we believe Mantle is the fundamentals of the Xbox One’s low level API brought to the PC.
By being based on the Xbox One’s low level API, Mantle isn’t just a new low level API for AMD GCN cards, whose success is defined by whether AMD can get developers to create games specifically for it, but Mantle becomes the bridge for porting over Xbox One games to the PC. Nothing like this has ever been done before, so quite how it will play out as a porting API is still up in the air, but it’s the kind of unexpected development that could have significant ramifications for multiplatform games in the future.
Of course an API is only as useful as the software that uses it, and consequently AMD has been working on this matter before they even announced Mantle. As AMD tells it, Mantle doesn’t just exist because AMD wants to leverage their console connection, but it exists because developers want to leverage it too, and indeed developers have been coming to AMD for years asking for such a low level API for this very reason. To that end a big part of Mantle’s creation is rooted in satisfying these requests, rather than just being something AMD created on its own and is trying to drum up interest for after the fact.
With at least one developer already knocking on their door, AMD’s immediate strategy is to get Mantle off the ground with a showcase game, all the while focusing less on individual game developers and more on middleware developers to implement Mantle support. In a roundabout way AMD is expecting middleware to become the new level of abstraction for most game developers in this upcoming generation, due to the prevalence of middleware engines. As game developers make ever increasing use of middleware over limited-reuse in-house game engines, downstream developers in particular will be spending their time programming against the middleware and not the APIs it sits on top of, making it easy to work in Mantle support.
Consequently, AMD for their part believes that if they can get Mantle support into common middleware like DICE’s Frostbite engine, then the downstream games using those products will be in a good position to offer Mantle support with little to no effort on the part of the individual game developer. Put in the humongous effort once at the middleware level, and AMD won’t have to repeat it with individual developers.
As the first part of that plan, the aforementioned showcase game and engine for Mantle will be DICE’s Battlefield 4, which will receive Mantle support in an update in December. Electronic Arts is planning on making extensive use of the Frostbite engine within their company for this generation, and with DICE’s developers being among the premiere technical development houses of this generation, BF4 and Frostbite are exactly what AMD needs to showcase Mantle and get their foot in the door. DICE for their part has proven to be quite enthusiastic about the concept, which helps to validate AMD’s earlier claim about developers having been asking for this in the first place, and also sets up a model for future developers to work from. DICE is just one developer, but with any luck for AMD they are the first of many developers.
Moving on, there is a downside to all of this that we need to point out however, and that is the risk of fragmentation and incompatibility. Unlike consoles, PCs are not fixed platforms, and this is especially the case in the world of PC graphics. If we include both discrete and integrated graphics then we are looking at three very different players: AMD, Intel, and NVIDIA. All three have their own graphics architectures, and while they are bound together at the high level by Direct3D feature requirements and some common sense design choices, at the low level they’re all using very different architectures. The abstraction provided by APIs like Direct3D and OpenGL is what allows these hardware vendors to work together in the PC space, but if those abstractions are removed in the name of performance then that compatibility and broad support is lost in the process.
Low-level APIs, while very performance effective, are the antithesis to the broad compatibility offered by high level APIs. On their own low-level APIs are not a problem, but there is always the risk that development of the low-level code for a game takes precedent over the high-level code, which in turn would impact the users of non-GCN GPUs. We’ve seen this once before in the days of 3dfx’s Glide, so it’s not an entirely unfounded fear.
At the risk of walking a very fine line here, like so many aspects of Mantle these are not questions we have the answer to today. And despite the reservations this creates over Mantle this doesn’t mean we believe Mantle should not exist. But these are real concerns, and they are concerns that developers will need to be careful to address if they intend to use Mantle. Mantle’s potential and benefits are clear, but every stakeholder in PC game production needs to be sure that if Mantle takes off that it doesn’t lead to a repeat of the harmful aspects of Glide.
Wrapping things up, when AMD first told us about their plans for Mantle, it was something we took in equal parts of shock, confusion, and awe. The fact that AMD would seek to exploit their console connection was widely expected, however the fact that they would do so with such an aggressive move was not. If our suspicions are right and AMD is bringing over the Xbox One low level API, then this means AMD isn’t just merely exploiting the similarities to Microsoft’s forthcoming console, but they are exploiting the very heart of their console connection. To bring over a console’s low level graphics API in this manner is quite simply unprecedented.
However at this point we’ve just scratched the surface of Mantle, and AMD’s brief introduction means that questions are plenty and answers are few. The potential for improved performance is clear, as are the potential benefits to multiplatform developers. What’s not clear however is everything else: is Mantle really derived from the Xbox One as it appears? If developers choose to embrace Mantle how will they do so, and what will the real performance implications be? How will Mantle be handled as the PC and the console slowly diverge, and PC GPUs gain new features?
The answers to those questions and more will almost certainly come in November, at the 2013 AMD Developer Summit. In the interim however, AMD has given us plenty to think about.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Drumsticks - Tuesday, October 8, 2013 - linkI'm glad you managed to screw up and then point out every single one of your perceived faults with Anandtech and blame it all on them. That was impressive.
By the way, you could have read even the title.
rtsurfer - Tuesday, October 8, 2013 - link+1
jasonelmore - Wednesday, October 9, 2013 - linkthe title doesnt scream rebadge, and typically flagships are launched first, then the sister cards a few weeks later.
Etern205 - Monday, October 14, 2013 - linkR8-280x is a rebadged HD7970GE, if they're based on the new architecture like the R9-290x then we won't be reading reviews on it until AMD lifts the NDA.
rezztd - Tuesday, October 8, 2013 - linkWhy can't they just use simple naming schemes? I've found AMD's names confusing and generally harder to remember than those from NVIDIA.
piroroadkill - Tuesday, October 8, 2013 - linkHuh, for a long time I thought AMD's names were logical and ultra-simple, and it was NVIDIA who had the silly names with all their extra letters on the end.
However, now the tables are clearly turning, and AMD's naming is terrible.
HisDivineOrder - Wednesday, October 9, 2013 - linkI find the RX 2xx/2xxX naming scheme to be really horrible imo. I have a feeling they did the shift as much to confuse and misdirect away from the fact they did a refresh as to begin a new naming policy because it doesn't really help the consumer.
alwayssts - Tuesday, October 8, 2013 - linkI'm just waiting for the XFX info/overclocking page to load...
I think if they made their 280x similar to their 37th (only slight hyperbole) revision of the original 7970, that could be a rad product. The current version is 9.3 inches (for tiny cases/htpcs) but purposely very limited in overclocking capabilities...it also sells for around $300 +- $20. If they took that design and were allowed an upped/unlocked voltage/clock spec (with perhaps voltage tuning), that could be a sweet (and tiny) 1080p gaming part compared to anything else that size/price.
Slomo4shO - Tuesday, October 8, 2013 - linkAnd I was looking forward to determining the overclock potential of this card...
zeock9 - Tuesday, October 8, 2013 - linkSo there hardly isn't a performance gain over the 7970GE, perhaps less than 5% if that,
and they didn't even bother to include the new TrueAudio or Never Settle bundle.
What's the effing point of this 'new' card when 7970GE can already be had for the same price?
Shame on you AMD.