AMD Mantle API [updating]

[firstminion]

Tonga is an example where we need a common ground and IHV should step in, coordinating an update.

My hunch is that it's being downplayed because Mantle is on beta and there are now three other low-level APIs in-development, but some fix is a given for future HW.

 

[Andrew Lauritzen]

NVIDIA and AMD hardware development has stabilized. Both current designs resemble each other quite closely, being similar in-order scalar SIMD designs with similar latency hiding techniques, similar general purpose caches and similar total width (thread count and occupancy charasteristics) and operating clocks.

If you look just at the execution units/shaders, yes. And indeed Intel is similar to them too in practice. (Although there still are non-trivial differences in stuff like shared memory and atomics of course.) Texture units are quite similar as well other than the odd format, totally agreed.

But there's still a large amount of tweakable special sauce in running the overall graphics *pipeline* efficiently. Keeping units fed, Hi-Z/stencil, compression/decompression, MSAA, buffering, state vectors, etc. Even stuff like alpha test can still have unintuitive and architecture-specific implications. This stuff still needs a lot of tweaking for various architectures and workloads and I imagine it will continue to.

Now I realize you guys are trying to get the majority of the "expensive" parts of your code into more general purpose compute/full screen passes and that does dodge some of the issues (although depending on what you're doing, you'll get into fun scheduling and memory layout ones instead! ). But laying down a G-buffer and shadow maps is still a non-trivial part of most game frames and it hasn't really decreased in proportion a huge amount over the past few years. Maybe it will more soon, but my expectation was really that by now it would be a fairly irrelevant part.

 

[Dave Baumann]

Exactly, as the Tonga situation shows, BF4 and Thief ran worse with Mantle than DX, even though Tonga was a subset of GCN with not much radical changes.
http://www.anandtech.com/show/8460/amd-radeon-r9-285-review/6

Some of this is just explained by memory. As mentioned, DX drivers are a black box to the developers and the IHV has some leeway in how buffers are allocated under DX and the drivers can make some (relatively) dynamic priority calls based on target resolution and GPU memory size. Under API's that expose more capabilities to the developers these buffers can be explicitly handled by the developer and in some cases the buffer allocations are not optimal for certain GPU memory sizes. If this type of explicit control is maintained on other low level API's then the devs will likely start to implement their own code that makes these decisions based on differing memory sizes - Mantle is just the first exposure to these new types of considerations that were previously "automatically" handled.

 

[Jawed]

Now I realize you guys are trying to get the majority of the "expensive" parts of your code into more general purpose compute/full screen passes and that does dodge some of the issues (although depending on what you're doing, you'll get into fun scheduling and memory layout ones instead! ).

Well, actually, I'd say that stuff is fun. OpenCL provides plenty of low-level access. For Deathray I implemented sets of circular buffers and event driven scheduling of data moves and kernel executions:

https://github.com/JawedAshraf/Deathray/blob/master/MultiFrame.h
https://github.com/JawedAshraf/Deathray/blob/master/deathray.h

That code happily runs for days without any problems

I can't imagine the misery of not being able to do all this low-level stuff yourself. Maybe graphics devs are numbed to the pain of the D3D straightjacket because of the beautiful pixels they end up making.

 

[DavidGraham]

In the shots below, we've re-run some of our benchmark tests, comparing AMD and Nvidia performance on the high-end quad-core i7 with the middle-of-the-road dual-core i3 processor. The results are stark. Both 260X and 270X lose a good chunk of their performance, while Nvidia's GTX 750 Ti is barely affected. The situation is even more of an issue on the mainstream enthusiast 1080p section on the next page. There's no reason why a Core i3 shouldn't be able to power an R9 280, for example, as the Nvidia cards work fine with this CPU. However, the performance hit is even more substantial there.

http://www.eurogamer.net/articles/digitalfoundry-2015-graphics-card-upgrade-guide?page=2

Digital Foundry tested Ryse, Far Cry 4, The Crew, and COD Advanced Warfare, all showed the same issue.

 

[Dave Glue]

http://www.eurogamer.net/articles/digitalfoundry-2015-graphics-card-upgrade-guide?page=2

Digital Foundry tested Ryse, Far Cry 4, The Crew, and COD Advanced Warfare, all showed the same issue.

Indeed, this is particularly damning for AMD considering the relative power of your APU/CPU's. It's a good article, really tired of seeing value card reviews paired with overclocked i7's and calling it a day.

My system, an A8-5600k with an R270 is of course bottlenecked by the CPU, but ironically part of that CPU bottleneck is because I'm running with an AMD GPU which further impacts the already weak CPU. Mantle is a complete bust so far, despite having somewhat of a 'sweet spot' system in terms of CPU/GPU that Mantle should really benefit, I get crippling stuttering on every Mantle title I try where DX is smoother, even with AMD's CPU-heavy DX11 driver path.

A Haswell i3 is no doubt a better CPU in most tasks - driver overhead or not - but it is amusing to think my AMD CPU is being further hobbled by pairing it with...an AMD GPU. The very small niche category that would support actually building an AMD system these days is pretty much gone, the ultra-value gaming segment - as that AMD GPU will just exacerbate the weakness of the AMD APU even further. You would be far better suited to pair that AMD APU with a 750ti instead of a 260x, and in some cases a 270 as you'll hit the CPU wall more frequently with the AMD GPU.

Don't have much hope AMD can really improve this, but they need to.

 

[3dilettante]

AMD's becoming limited by things other than the GPU has been a pretty consistent theme for what feels like forever.
I haven't been able to really characterize as an outside observer what is going on, at least not without making claims I feel would be too uncharitable without the knowledge to really back things up.

I do not think this can be blamed on Mantle, because if it were one would expect AMD would have done better when DX11 was all it had going.
Examples like this show that Mantle, for all its benefits, is not the only way to provide decent performance at this point in time.
The multitude of other setbacks and Mantle's own missed deadlines just makes me question how much of this is backing out of a fight that can no longer be fought to a fallback that is insufficiently resourced.

 

[Jawed]

http://forums.overclockers.co.uk/showpost.php?p=27572833&postcount=52

Solid shout S2KIP as you're at 4K and you play Battlefield 4 using Mantle. 4GB is not enough for Mantle at 4K maximum details, that will explain your stuttering. I use around 5gb on my 4x290X 8GB setup at 4K in Mantle Ultra Preset.

 

[liquidboy]

I once had an interesting discussion with some Intel engineers at a past Microsoft \\Build\ conference, and these Intel engineers were very experienced software engineers, they wrote driver level system code and been doing it for decades ..

The conversation was around HW companies trying to become top SW companies, more so than ever before.. Not only having to write drivers for their hardware BUT also writing for the entire stack all the way up to application frameworks, and applications on these frameworks etc...

They pretty much weren't too happy with how things were turning out, being stretched thin etc.. And they in passing joked about AMD and Nvidia going the same route, being more full stack SW focused , and how the hell they're coping with it if Intel themselves arnt ...

Anyway ... was an interesting discussion, especially the stories they shared (all be it limited due to NDA) regarding their driver development process ..

 

[Deleted member 2197]

Both mantle and dx12 can combine video memory ....
Robert Hallock (Head of Global Technical Marketing at AMD)

There is a catch though, this is not done automatically, the new APIs allow memory stacking but game developers will need to specifically optimize games as such. An interesting statement.

Keep in mind though, this is a marketing rep talking ...

http://www.guru3d.com/news-story/both-mantle-and-dx12-can-combine-video-memory.html

 

[gkar1]

Low Latency and Stutter-Free Rendering in VR and Graphics Applications (Presented by AMD)
http://schedule.gdconf.com/session/...vr-and-graphics-applications-presented-by-amd

This talk will provide a detailed explanation of several mechanisms by which graphics engine developers can dramatically reduce both actual and perceived latency and "stuttering" in graphics and virtual reality applications running on modern GPUs such as those powered by the AMD Graphics Core Next (GCN) architecture. Real world examples of optimized AAA content will be discussed and explained, complete with before and after performance metrics.

This talk will give developers the tools and understanding required to exploit modern GPU architectures to take their graphics engines to the next level: extremely low latency, stutter-free, liquid smooth graphics at high framerates (90-120Hz and beyond).

Crossfired GPUs running Mantle with one GPU per eye would be my guess.


http://www.reddit.com/r/oculus/comments/2stxxt/amd_to_share_lowlatency_vr_gpu_rendering_tricks/

This is very exciting stuff, all I can say.

Can you say anything about NVIDIA's stuff?

It's somewhere on the scale between "Non-existent" and "Not-so-Exciting."

 

[eastmen]

I thought NVidia implemented stuff in the newest generation ?

 

[gkar1]

I thought NVidia implemented stuff in the newest generation ?

That stuff would fall into the "not-so-exciting" category. Oculus' own efforts in reducing latency already provide better results than what Nvidia came up with.

 

[eastmen]

thanks for the info , any conversations about that anywhere ?

 

[Deleted member 13524]

Low Latency and Stutter-Free Rendering in VR and Graphics Applications (Presented by AMD)
http://schedule.gdconf.com/session/...vr-and-graphics-applications-presented-by-amd

Crossfired GPUs running Mantle with one GPU per eye would be my guess.

I'm counting on that!
I paid a bit more for a X79 setup, a bit on the perspective that dual-GPU setup for VR would be big within the next couple of years.
And the 290X are getting really cheap to boot

 

[3dilettante]

I'm probably a bit slow on thinking about this, but now that Mantle's public SDK may not be released until the 57th week of 2014 or later and news about glNext being shown off at GDC, I was wondering about what case is to be made for AMD's API, should the company's silence on the matter not already speak enough.

The universe around Mantle has shifted.
DX12's low-level API is incoming, and Microsoft is changing Windows licensing to make Windows 10, and the matched change in WDDM, as a natural point that devices will move towards as part of an ongoing device lifetime license. There will not be a clear Vista+DX10 discontinuity that a third-party API capable of straddling Windows versions could exploit.
AMD has insisted that while DX12 appears to capture almost all the major benefits of low-level resource management, Mantle could still do some things better since it can be more readily tailored to GCN and can have certain extensions built into it.
While Mantle theoretically could be multiplatform, and some incredibly non-committal statements were made to that effect, all appearances are that the shores of Mantle's pond are Windows 7 PCs. Thanks to the Xbox One, even DX is more multiplatform.
Whatever gap Mantle could have exploited there is bounded by AMD's lack of adventurism, and is being ground down by the multi-billion-dollar behemoth platform holder that is foregoing (modest--for it) revenues and orienting its whole software universe on changing the situation that allows Mantle any traction right now.

glNext appears to be going for something closely aligned to the current trend. It is multiplatform, and it will also exist in Windows.
Some people were wondering if Mantle could show up in Steam Machines, but the choice of presenter for glNext seems to weight against it.
The GDC presentation has two of the major Mantle proponents/marketing points, as well as several engines Mantle could not entice, either due to philosophical or business reasons.
So glNext could be a low-level DX12-ish model, and vendors can add extensions, and it will be an open standard that should be multi-platform, multi-IHV, and multi-form factor.

Is there some subtlety to the situation that I am missing where an open standard API with low-level access and vendor-specific extensions leaves a business case for Mantle?
I suppose Mantle as we know it could be useful as a model to get glNext-like functionality down onto Windows 7 machines, if the mainline API winds up having the same WDDM update requirement that DX12 will.

 

[liquidboy]

I'm probably a bit slow on thinking about this, but now that Mantle's public SDK may not be released until the 57th week of 2014 or later and news about glNext being shown off at GDC, I was wondering about what case is to be made for AMD's API, should the company's silence on the matter not already speak enough..

Not sure if you and others have seen this article, months ago ...

"AMD hopes to put a little Mantle in OpenGL Next"

 

[silent_guy]

Not sure if you and others have seen this article, months ago ...

"AMD hopes to put a little Mantle in OpenGL Next"

That same guy said as late as last November that Mantle and FreeSync would be available 'this year', meaning 2014.

 

[gkar1]

I suppose you people with an axe to grind are going to say that the 70 developers actively working with Mantle is a lie huh?
I mean who are you trying to convince? Developers are using Mantle, pretty much all games coming from EA that use Frostbyte will support Mantle, Cryengine will also have native support for it. All the Stardock games based on the Starswarm engine will natively support it, etc. etc.

So pardon being blunt but yeah you are a little more than slow lol

 

[silent_guy]

I suppose you people with an axe to grind are going to say that the 70 developers actively working with Mantle is a lie huh?
I mean who are you trying to convince? Developers are using Mantle, pretty much all games coming from EA that use Frostbyte will support Mantle, Cryengine will also have native support for it. All the Stardock games based on the Starswarm engine will natively support it, etc. etc.

So pardon being blunt but yeah you are a little more than slow lol

The 'lol' really did it.

But to answer your question: Mantle was introduced a year and half ago with the promise of being open and all that goodness. And we're now close to the point where Dx12 will be revealed to developers at GDC. And Mantle is still MIA as a public API. And there's only a handful of games that support it. Promises about its appearance never materialize. And I have a really, really hard time seeing a convincing argument about why it has a reason to exist.

AMD has a piss poor record of being able to force their own API. (Can you think of any?) By now they must realize that this is a loosing proposition. So why waste more resources on it?

Nobody said Mantle is a lie. But I do notice that somebody (who admittedly has a history of saying dumb stuff) with a C title said that it'd be available very soon, that it's not there, and so things just have changed. Is it so evil to discuss this?

If you were a game developer, would target an API that reaches 30% of the total audience or one that, according to others here is almost identical, but supports 100%?