Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
AMD releases Mantle documentation
And yes, that headline does imply that AMD hadn't previously released Mantle documentation. If you wanted to use Mantle before or just wanted to know what it did, you were out of luck. Because secrecy will drive API adoption or something.
Here's the link in case you want to check:
http://www.amd.com/Documents/Mantle-Programming-Guide-and-API-Reference.pdf
Which you probably don't, as most of you probably aren't comfortable with reading through 450 page documents on graphics APIs. I had a quick glance at it, and here are some highlights:
Substantial chunks of the documentation are specific to Windows. There is no mention of Linux in the entire document. For those who were hoping that Mantle would mean easier porting of games to other operating systems: nope. Vulkan might, but that's not Mantle.
I'm not sure about porting Mantle to other programming languages, either. Khronos group APIs are released in C, and if you want to use them in anything else, you have to get some wrapper for them. I don't know if said wrappers are available for Mantle. It wouldn't surprise me if AMD just made the API for C++ directly and skipped C entirely, but I don't know if they did that.
Lots and lots and lots of things in the Mantle API start with "gr". I'm guessing that's short for "graphics". Having distinctive letters for the start of all API commands is hardly unique to Mantle; OpenGL uses "gl", while OpenCL uses "cl" and CUDA uses "cu" for a ton of things.
There are a number of sections on extensions. I find that strange in an API that AMD controls entirely and can add stuff to however they like. In OpenGL and OpenCL, extensions mean things that some architectures support, but others might not. But the only architecture that supports Mantle is AMD's GCN, so I don't see the point of extensions. It's not like Nvidia will decide to support Mantle but skip some of the extensions.
There's also a section on asynchronous CrossFire. Just in case there is anyone who is not an AMD employee but still thinks that asynchronous CrossFire is a good idea.
