• What
    is this?
    You've landed on the AMD Portal on AnandTech. This section is sponsored by AMD. It features a collection of all of our independent AMD content, as well as Tweets & News from AMD directly. AMD will also be running a couple of huge giveaways here so check back for those.
    PRESENTED BY

As part of a larger Mantle promotion, AMD has posted a number of blogs on their site detailing their low level API. The blog posts themselves are unabashedly closer to advertising than technical writing, but as something of a diamond in the rough AMD has also published a whitepaper on Mantle.

At 11 pages long the Mantle whitepaper offers a solid high level overview of the technology. In it AMD delves into further detail about several aspects of the API, without getting buried in the minutia of an API in a way that only seasoned programmers can appreciate. Among the subjects covered are Mantle's memory model, execution model, pipeline model, and the basic tenet of where low-level APIs can reduce overhead and improve performance over high level APIs.

The bulk of this information is a repeat from AMD’s earlier developer presentations, so we won’t spend any time going over the materials in-depth here, but for a more approachable look at the API from AMD’s perspective this is a great start.

Source: AMD

POST A COMMENT

25 Comments

View All Comments

  • nathanddrews - Thursday, May 29, 2014 - link

    I'm guessing that this was all part of a more elaborate plan.
    1. "Look at how evil NVIDIA are with their GameWorks!"
    2. "Look at how open we are about Mantle!"
    Reply
  • nathanddrews - Thursday, May 29, 2014 - link

    In hindsight... not that elaborate. Reply
  • Wreckage - Thursday, May 29, 2014 - link

    The title should be "AMD posts more marketing material, Mantle still completely proprietary" Reply
  • CiccioB - Thursday, May 29, 2014 - link

    I wonder how one can doubt that a low level API can have better performances than a high level API. The main problem of developing something is not about performances. It is about how much of the market you can cover with the smaller effort.
    That's why high level API in all fields are used. Tha's why programs are written in C or bigger one in C++ instead of ASM.
    You can go as long as you want to demontrate that low level programming in ASM gives you more performances than using an high level language.
    The fact is that low level programming, in all fields (now even in embedded marked) is not profitable. You need a lot of efforts to maintain your product and to follow market evolution.

    About this very API, the problem is that is is linked tightly to GCN architecture. What will happen when a new architecture will be developed?
    On the other hand, how much can AMD change its architecture if they have an API that works only if some features/limitations of that one are respected?
    If you have a large program written in ASm you cannot use another microprocessor with a different ASM language, nor you can't even exploit a eventual upgrade of the same micro.
    Look at Motorola 68000 and Amiga development story to know what it leams being tied to a particular architecture.
    Reply
  • CiccioB - Thursday, May 29, 2014 - link

    leams = means

    Still waiting for that edit button someday :D
    Reply
  • aruisdante - Thursday, May 29, 2014 - link

    So... Mantle is definitely not Assembly-level low-level. It's still primarily a C/C++ construct. It just exposes a Mantle specific API instead of using the DirectX/OpenGL one, and it uses Mantle specific data structures in some cases. Reply
  • CiccioB - Friday, May 30, 2014 - link

    Well, not. It is a low level language that can be used only on one architecture. Set you the low level threshold, but it is like as you are using a custom LISP-like language for yopur customized MIPS and shows that you get better performance than using C++ that runs on anything in the world.
    You may have all the performance advantages you want, but you have long time to convience all the world to use both your MIPS implementation and your custom language which cannot evolve in future not to disrupt what that SW+HW tight integration brings today.

    This kind of APIs are a lock-in issue. 3Dfx's Glide were the same, and infact as soon ad DX started to be used widely they died miserably because they could not sustain their advantages using new architectures (32-bit depth color and T&L just to name some).
    Market compatibility, maintanability and easy porting to other/new/future architectures are factors that for complex projects are much more important that squeezing 10 more frame per second just for 25% of the market today.

    You may thing that doble implementation (Mantle+DX) can be the solution, but that is only if AMD pays for the extra work, otherwise none is ever thinking of using a limiting (market wise) API to create something that is just barely faster than using another that guarantess 100% market cover.
    Reply
  • przemo_li - Friday, May 30, 2014 - link

    Funny You bring, DX.

    DX12 will bring many same architectural decisions.

    That mean at least MS see AMD architecture as mature enough for serving as base for next gen of GPU advancement.
    (DX12 is based on DX from console which evolved around AMD APUs capabilities)
    Reply
  • pTmdfx - Saturday, May 31, 2014 - link

    Nah. Shader programs are still HLSL. Mantle just makes the application closer to the metal while still having a thin abstraction. It isn't even a "low-level language" but a paradigm of controlling the GPU. You sounds going too far. Yep. Reply
  • pTmdfx - Saturday, May 31, 2014 - link

    By the way, glad to tell you that cross-platform game engines do not use graphics API directly. They will wrap it into their own internal abstractions so that the engines can target numerous platforms with different APIs. So eventually there is nothing different from traditional APIs - just that the game developers have now more power to utilize the hardware to the edge, and the work of supporting it can be mostly hidden internally by the game engines. Reply

Log in

Don't have an account? Sign up now