Much has been made over the advent of low-level graphics APIs over the last year, with APIs based on this concept having sprouted up on a number of platforms in a very short period of time. For game developers this has changed the API landscape dramatically in the last couple of years, and it’s no surprise that as a result API news has been centered on the annual Game Developers Conference. With the 2015 conference taking place this week, we’re going to hear a lot more about it in the run-up to the release of DirectX 12 and other APIs.

Kicking things off this week is AMD, who is going first with an update on Mantle, their in-house low-level API. The first announced of the low-level APIs and so far limited to AMD’s GCN’s architecture, there has been quite a bit of pondering over the future of the API in light of the more recent developments of DirectX 12 and glNext. AMD in turn is seeking to answer these questions first, before Microsoft and Khronos take the stage later this week for their own announcements.

In a news post on AMD’s gaming website, AMD has announced that due to the progress on DX12 and glNext, the company is changing direction on the API. The API will be sticking around, but AMD’s earlier plans have partially changed. As originally planned, AMD is transitioning Mantle application development from a closed beta to a (quasi) released product – via the release of a programming guide and API reference this month – however AMD’s broader plans to also release a Mantle SDK to allow full access, particularly allowing iit to be implemented on other hardware, has been shelved. In place of that AMD is refocusing Mantle on being a “graphics innovation platform” to develop new technologies.

As far as “Mantle 1.0” is concerned, AMD is acknowledging at this point that Mantle’s greatest benefits – reduced CPU usage due to low-level command buffer submission – is something that DX12 and glNext can do just as well, negating the need for Mantle in this context.  For AMD this is still something of a win because it has led to Microsoft and Khronos implementing the core ideas of Mantle in the first place, but it also means that Mantle would be relegated to a third wheel. As a result AMD is shifting focus, and advising developers looking to tap Mantle for its draw call benefits (and other features also found in DX12/glNext) to just use those forthcoming APIs instead.

Mantle’s new focus in turn is going to be a testbed for future graphics API development.  Along with releasing the specifications for “Mantle 1.0”, AMD will essentially keep the closed beta program open for the continued development of Mantle, building it in conjunction with a limited number of partners in a fashion similar to how Mantle has been developed so far.

Thie biggest change here is that any plans to make Mantle open have been put on hold for the moment with the cancelation of the Mantle SDK. With Mantle going back into development and made redundant by DX12/glNext, AMD has canned what was from the start the hardest to develop/least likely to occur API feature, keeping it proprietary (at least for now) for future development. Which is not to say that AMD has given up on their “open” ideals entirely though, as the company is promising to deliver more information on their long-term plans for the API on the 5th, including their future plans for openness.

Mantle Pipeline States

As for what happens from here, we will have to see what AMD announces later this week. AMD’s announcement is essentially in two parts: today’s disclosure on the status of Mantle, and a further announcement on the 5th. It’s quite likely that AMD already has their future Mantle features in mind, and will want to discuss those after the DX12 and glNext disclosures.

Finally, from a consumer perspective Mantle won’t be going anywhere. Mantle remains in AMD’s drivers and Mantle applications continue to work, and for that matter there are still more Mantle enabled games to come (pretty much anything Frostbite, for a start). How many more games beyond 2015 though – basically anything post-DX12 – remains to be seen, as developers capable of targeting Mantle will almost certainly want to target DX12 as well as soon as it’s ready.

Update 03/03: To add some further context to AMD's announcement, we have the announcement of Vulkan (aka glNext). In short Mantle is being used as a building block for Vulkan, making Vulkan a derivative of Mantle. So although Mantle proper goes back under wraps at AMD, "Mantle 1.0" continues on in an evolved form as Vulkan.

Source: AMD

Comments Locked


View All Comments

  • piiman - Saturday, March 7, 2015 - link

    Just because you reverse engineer something doesn't mean you own it.
  • CPUGPUGURU - Saturday, March 7, 2015 - link

    In this case yes it does, its Intel's 64 bit version of x86 that Intel does own, so you are wrong Intel owns its version.
  • dooki - Thursday, April 30, 2015 - link

    "Intel reverse engineered it"....

    "quit making this crap up"...

    "do your D&D"... ...what?.... did you mean to write R&D? ..and even then ,Why would he need to do development?

    The only pumping fool tool here is

    Irony in your name And post.
  • CPUGPUGURU - Wednesday, March 4, 2015 - link

    You Fact-less AMD pumpers need to learn how to read so that you can read to learn.

    Intel Did Not license the x86 64 bit from AMD, Intel instead Reverse Engineered x86 64 bit, read, "Microprocessor Reports", the article, "AMD and Intel Harmonize on 64" can be found in the March 29th edition of In-Stat/MDR's Microprocessor Report
    "Intel's reverse-engineering of AMD64 " says Halfhill. "

    AMD owns its 64 bit implementation but AMD's 64 bit instruction set requires 32 bit backward compatibility. Also 64 bit x86 is integer units only, AMD's ISA is not unique, the (FPU) floating point unit or SIMD units are Intel's patents and IP. It's a Fact that x86 is so old that Intel has no patents to x86 ISA they expired long ago, but the addition of new and evolving instruction set are still Intel's IP. Anyone today can an design and mfg a x86 ISA 32 bit processor license royalty free using original ISA but it's useless without the many new extensions like MMX, SSE, SSE2

    Read learn and stop posting nonsense.
  • ppi - Wednesday, March 4, 2015 - link

    x86 is specification. Are you sure it expires?

    You are correct that Intel did reverse-engineer it (in the same manner, I wonder if AMD could "reverse-engineer" 32- and 16-bit x86, when they have the 64-bit one), but they did so only because they had to catch up with AMD64, especially when their best product was Prescott. Otherwise, we would live in "merry world" of VLIW IA-64...

    ... Actually, with the x86 backward compatibility thrown out, it would have been easier to change to ARM :D.
  • CPUGPUGURU - Saturday, March 7, 2015 - link

    I believe it has expired and now public domain but pretty much useless without new extensions.
  • mikeztm - Friday, March 6, 2015 - link

    I hope AMD64 was never happen. We could have been throw away all the x86 into trash bin back to 2003. I purchased Athlon64 at that time and thought it was awesome. But now I think shift instructions like Apple did with Rosetta is a much better solution. IA64 itself is a revised architecture and it is designed to be better than the 30 years old x86(IA32).
  • CPUGPUGURU - Saturday, March 7, 2015 - link

    I'm with you this, Intel wanted to move forward to a RISC architecture world, but you know who dropped a 64bit anchor into the muddy instruction set waters and let ARM set its RISC sail on those waters. Bad for x86 good for ARM but x86 is evolving into a RISC form, ARM's efficiency advantage will be lost as more IPC is needed.
  • joemark - Tuesday, March 3, 2015 - link

    AMD64 helped push Windows XP(64bit); I was a beta tester of the 64 bit operating system and was so because I wanted to play Far Cry's 64bit version (AMD was a partner of a little known German development house called Crytek back in the day); Remember rambus ram? Thanks to AMD, we don't have to. God only knows how much we would be paying for technology these days if only Intel existed. AMD has forced both Intel and Microsoft to improve, innovate and do things they otherwise would have taken longer to do if indeed at all.
  • FITCamaro - Tuesday, March 3, 2015 - link

    Rambus memory was awesome memory. It was just expensive.

Log in

Don't have an account? Sign up now