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.

AMD’s 2014 GPU Lineup: The Radeon R9 and Radeon R7 Series AMD Display Technologies: 3x DVI/HDMI Out, Tiled Display Support, & More
POST A COMMENT

151 Comments

View All Comments

  • Dribble - Tuesday, October 8, 2013 - link

    Didn't you read the article - it is a 7970GE give or take a little on clocks (depending on what 280 you buy). The only new card is the 290 all the others are the same cards you could already buy. The news is lower prices, although as 7970's were already at lower prices then AMD recommended not sure how much real change there will be.

    The biggest downer for AMD fans will be the end of the 7950, which was always the price/performance king.
    Reply
  • Da W - Tuesday, October 8, 2013 - link

    It's gonna be the R9 280 (no X).
    I might just go and buy two 7950 right now. I'm not sure a single Hawaii priced near a 780 is worth it, crossfire issues notwithstanding.
    Very disappointing. Specs I saw floating here and there pointed to 270X being more like a Tahiti XL.
    Reply
  • zeock9 - Tuesday, October 8, 2013 - link

    Didn't you read my comment - 7970GE can already be had for the same price, so it's the same card for more money because 280X doesn't come with the Never Settle bundle.

    Trying to charge more buck for less bang just because it has a new name is a effing shame of a business practice.
    Reply
  • ninjaquick - Tuesday, October 8, 2013 - link

    What do you expect? AMD is not releasing a new architecture this time around. They have a very efficient design in GCN, they will not go changing it. Mark my words, the 370X is going to be a die shrunk 7970 GHz, and the 460X is going to be the same, or just a 'rebadged' 370X. AMD's GCN is a bottom-up modular design, not a top-down big chip first design. Reply
  • HisDivineOrder - Tuesday, October 8, 2013 - link

    Mantle is going to require they not stray too far from GCN and the way the cards are currently laid out. Otherwise, you'd have games suddenly having cards they're "Mantle compatible" with and cards they aren't.

    You won't see huge shifts in how the GCN is laid out post GCN 1.1 if they want to keep low level access working smoothly for the foreseeable future. Then again, perhaps they'll do the shift and just shift back to supporting their high level (drivers) instead once Mantle craters on impact because nVidia and Intel start throwing their money around...

    Either way, I'm pretty sure Mantle is a cost-cutting tool to help de-emphasize driver development on the consumer side and help keep up with performance gains by aggressive nVidia and intel release cycles that AMD doesn't have the money to fight.
    Reply
  • roastmeat - Tuesday, July 21, 2015 - link

    Ha, well what do you know

    The 370 is a rebadge
    Reply
  • chizow - Tuesday, October 8, 2013 - link

    "AMD has been very explicit in not calling these rebadges, and technically they are correct, but all of these products should be very familiar to our regular readers."

    So how are these not rebadges/rebrands again and how is it technically correct to not call them rebadges? I just find it funny that AMD was so explicit about not calling them as such, I mean it's clear both parties have a history of rebranding, but let's call a spade a spade here.

    Nvidia was pounded by AMD fanboys and the press alike for it's rebranding of G92, but any single iteration from G92 certainly had more changes than the non-existent changes we see with this R7/R9 rebrand stack.
    Reply
  • Ryan Smith - Tuesday, October 8, 2013 - link

    A rebadge would be something like the 5770 to 6770. Same card, same clocks, same TDP. These are new SKUs, based on existing GPUs, under a new name. Reply
  • chizow - Tuesday, October 8, 2013 - link

    lol I guess we have some revisionist history that needs to be written then. Not blaming you of course for public perception, just saying, these were not the standards in G92's day as it easily cleared this very low standard of different clockspeeds/TDP/card design, as every single G92 incarnation surpassed these requirements.

    In any case, I did appreciate the in-depth coverage of Mantle, possible benefits, repercussions, downsides. Excellent coverage and commentary on all angles, as usual. Look forward to more detail about it in the future.
    Reply
  • Gigaplex - Tuesday, October 8, 2013 - link

    If the silicon isn't any different, the only distinction is in the board itself and the firmware setting the speeds etc, then it's a rebadge in my books. Nothing stopping OEMs from changing these around, and this does in fact happen with the OC cards. What is the difference between a rebadged chip with an OC vs one of these? Reply

Log in

Don't have an account? Sign up now