What Mantle signifies about GPU architectures
Guennadi is the chief architect for Mantle. We discuss how Mantle reflects the future of the rendering pipeline and much more.
Mantle is a very interesting concept. From the various keynote speeches, it sounds like the API is being designed to address the current state (and trajectory) of graphics processors. GPUs are generalized and highly parallel computation devices which are assisted by a little bit of specialized silicon, when appropriate. The vendors have even settled on standards, such as IEEE-754 floating point decimal numbers, which means that the driver has much less reason to shield developers from the underlying architectures.
Still, Mantle is currently a private technology for an unknown number of developers. Without a public SDK, or anything beyond the half-dozen keynotes, we can only speculate on its specific attributes. I, for one, have technical questions and hunches which linger unanswered or unconfirmed, probably until the API is suitable for public development.
Or, until we just… ask AMD.
Our response came from Guennadi Riguer, the chief architect for Mantle. In it, he discusses the API's usage as a computation language, the future of the rendering pipeline, and whether there will be a day where Crossfire-like benefits can occur by leaving an older Mantle-capable GPU in your system when purchasing a new, also Mantle-supporting one.
Q: Mantle's shading language is said to be compatible with HLSL. How will optimizations made for DirectX, such as tweaks during shader compilation, carry over to Mantle? How much tuning will (and will not) be shared between the two APIs?
[Guennadi] The current Mantle solution relies on the same shader generation path games the DirectX uses and includes an open-source component for translating DirectX shaders to Mantle accepted intermediate language (IL). This enables developers to quickly develop Mantle code path without any changes to the shaders. This was one of the strongest requests we got from our ISV partners when we were developing Mantle.
Follow-Up: What does this mean, specifically, in terms of driver optimizations? Would AMD, or anyone else who supports Mantle, be able to re-use the effort they spent on tuning their shader compilers (and so forth) for DirectX?
[Guennadi] With the current shader compilation strategy in Mantle, the developers can directly leverage DirectX shader optimization efforts in Mantle. They would use the same front-end HLSL compiler for DX and Mantle, and inside of the DX and Mantle drivers we share the shader compiler that generates the shader code our hardware understands.
Q: Johan Andersson, during his AMD Developer Summit 2013 keynote, seems to describe Mantle as a low-overhead API for graphics as well as for compute, memory transfers, video encode and decode, and so forth.
How do you expect Mantle will be used for non-graphics workloads? How does OpenCL and C++ AMP compare to it, especially in terms of driver overhead and efficient queuing?
[Guennadi] Our focus for Mantle has been on solving practical graphics problems that game developers are facing today. It is possible that there are other applications that could benefit from Mantle, even if we didn't purposely target those. We haven't compared overhead of Mantle to OpenCL, and frankly these should not be directly compared since these solutions try to solve slightly different problems in different ways and are optimized for different scenarios. C++ AMP is even less comparable since it tries to address a different set of problems.
Q: Johan also described Mantle as being able to address any and all compatible GPUs. Will this support and encourage users to leave past generation GPUs in their systems, during upgrades, for applications which can effectively load balance?
[Guennadi] Mantle definitely offers more options for handling multiple GPUs beyond how they could be used in AMD CrossFire(tm) configurations. It's up to game developers to decide how to leverage those configurations, and in the future we hope to see more use of the asymmetric configurations.
Q: How will Mantle tie in with HSA features? For instance, can both halves of an APU collaborate while discrete GPUs are busy drawing? For example, during AI update code which blends serial (logic) and parallel (pathfinding and visibility) tasks?
[Guennadi] This is something we'll need to evaluate in the future. Right now HSA and Mantle try to solve different sets of problems, but there is certainly room for overlap at some point.
Q: When I see Mantle, it feels like AMD is making a play for compute-based game engines. Specifically, I see the minimizing of strict shaders (one which runs per vertex, one which runs per pixel, etc.) and the emphasis of keeping shader units constantly loaded with relevant math. What future do you see for the graphics pipeline as a whole? How about fixed-function features?
[Guennadi] Pipeline concept in Mantle provides a nice abstraction that is forward looking and allows to move graphics further into the compute shader territory. It has to be said: except for a few slight differences in terms of how compute and graphics shaders are fed data and how they tie into the flow of data in the pipeline, they are very similar and are running on the same shader core. Right now the graphics pipeline is fairly rigid in terms of the data flow, but hopefully in the future it will become more flexible. The fixed-function parts won't completely go away since they provide very high power and performance efficiency, but they could evolve to support more flexible pipeline configurations. This is a pipe dream at this point, pun intended J, but in the future it can definitely be a reality. Definitely, more research is needed in this direction.
Q: Is there anything to be said about Mantle on mobile?
[Guennadi] Arguably, mobiles are in the most need for solution like Mantle because of the high efficiency of the API and its lower CPU requirements.