What is Mantle?
A cross-platform low-level API that exposes all GCN architecture features and improves performance.
More info at the AMD Developer Summit, November 11-14th.
Slides:
More info from AMD:
Developer thoughts:
https://twitter.com/ID_AA_Carmack/status/383051142755663872
Press Reactions:
Digital Foundy
HardOCP
AnandTech.[/QUOTE]
Some notable info related
*mod: I was not sure were to open this thread. I made this open post that I can update when more info is available
A cross-platform low-level API that exposes all GCN architecture features and improves performance.
More info at the AMD Developer Summit, November 11-14th.
Slides:
More info from AMD:
Dave Baumann said:OpenGL is fully out of the domain of Windows and wholly in the hands of the IHV's, Mantle will be no different in this respect. Memory re-write was already implemented many releases ago.
Dave Baumann said:Development has changed. Previously a development house would create a new engine with a new game - maybe some follow ups, but there was a lot of starting from scratch. Now 50%-75% of all games on the PC are covered by a relatively small number of engines; the render engine now is effectively engine middleware. And guess what, the developer of that middleware makes money by supporting multiple different platforms and API's - Frostbite supports PC DX11 (and probably other DX revisions), XBOX 360, PS3, PS4, XBOX One; Unreal supports all of these and iOS, HTML5, etc., etc. Adding another optimized back end can actually be a selling feature of engine developers and the reuse is high - as Johan points out, look at the number of EA titles using Frostbite 3 in the coming year or so.
Dave Baumann said:The AMD Developer Summit (which covers all things AMD from a developer point of view) is in November, we will have Mantle tracks from us and partners.
Nick said:Mantle is the direct result of a number of AAA game developers asking us for something like this because of several constraints they're experiencing with existing PC graphics APIs. Those developers want to get closer to the metal and able to achieve more with the GPU(s) on their PC without the API getting in the way of this effort. "More with more" is the term used by Raja and it couldn't be more spot on.
AMD listened to developer feedback and entered this venture with Johan Andersson leading the charge. Johan has a passion for writing efficient code that can allow him to accomplish his technical vision and Mantle exists to serve this purpose.
Mantle is not for every developer. It is a low-level graphics API designed to drive the GPU in the most efficient manner. This level of access requires a bit more development effort than existing APIs to reap the rewards it provides.
AMD remains committed to support DirectX and OpenGL and to keep optimizing our drivers for those APIs. Mantle is an option that some developers may choose, but it does not affect those that wish to keep using existing APIs.
Some technical concerns are mentioned on this thread. The Mantle API has been in design and development for more than 2 years and rest assured we've had some time to think about the best way to address those (and loads of others).
More technical details about Mantle will be revealed in due course. Johan is a keynote speaker at the AMD Developer Summit (11-14 November, San Jose).
Nick - Gaming Engineering Manager, AMD
With Battlefield 4 running with Mantle, the card will be able to ‘ridicule’ the Titan in terms of performance.”
AMD Product Manager Devon Nekechuck
Developer thoughts:
https://twitter.com/ID_AA_Carmack/status/383051142755663872
John Carmak said:Considering the boost Mantle could give to a steambox, MS and Sony may wind up being downright hostile to it.
repi said:Using OpenGL would have been a downgrade from using DX11 and we wouldn't solve any of the problems that I mentioned on my slide about what challenges we have on PC. Hence Mantle is needed.
Press Reactions:
Digital Foundy
HardOCP
AnandTech.[/QUOTE]
Some notable info related
sebbi said:Draw call overhead on PC is considerably higher compared to consoles. On a console you can just write a few bytes (command header + data) directly to the ring buffer (existing in same unified memory system). That's just a few CPU cycles. You can just ignore all the CPU and GPU synchronization if you know what you are doing (you manage the life time of your data properly, and make sure you are not modifying the data while the GPU is accessing it - for example by manually double buffering the resources).
DirectX/OpenGL doesn't know enough about your data usage pattern to skip unneeded synchronization. And on PC there's always other applications (and the OS) using the GPU as well. So the API calls (draw, map, state change) needs to be always properly synchronized. A simple mutex lock costs over 1000 cycles. There's multiple driver layers (user, kernel) and some parts are shared between all applications (and OS). So you should expect DirectX/driver to have multiple synchronization points (locks) for each draw call. And then of course the data must be transferred over PCI express bus to the GPU's memory, since there's no shared memory that both CPU and GPU can access. So the 10x overhead discussed in this thread is likely a conservative guess. I would expect the CPU cycle overhead to be much higher.
Earlier in this thread, there was some discussion about DX11 multithreaded rendering. It doesn't actually reduce the driver overhead at all. It allows you to use several CPU cores record the draw calls to separate command buffers. This is kind of awkward, since one modern (Sandy/Ivy Bridge) PC CPU core is powerful enough to run all the processing that six x360 thread would do in a single frame. Usually x360 games use just one of those six threads to submit the draw calls. With DX11 you can now use two high performance PC cores in tandem to send as many draw calls as a single x360 thread... Brute force at it's finest. Not something to brag about
*mod: I was not sure were to open this thread. I made this open post that I can update when more info is available
Last edited by a moderator: