AMD Mantle API [updating]

I was impressed by the demo, because it means devs will be able to do completely new game designs with all the extra power. It won't just be a case of "faster" or "more stuff", there will be games designed around having all this extra horsepower to do new and interesting stuff.

 

Heres a question seeing as the new consoles are like a half decent pc and they have a mantle like to the metal api, why are we seeing things like games have to run at 900p and games limited to 30fps ect
shouldn't they be running those games with 2-3x the performance of a similarly specced pc ?

 

I doubt anyones suggesting that you're average game is going to get a straight 2-3x speedup simply from using a low level API over DX. Some areas might see that kind of speed up and some (draw calls for example) may see even more but on the whole the speedup is likely to be much more modest and then only then the game is coded specifically for that API.

BF4 will back that up soon enough.

 

I didn't think most of the early games for the consoles did use 'to the metal' coding, but used a lot of higher level Direct X/ Open GL type code in order to hit the release deadlines together with the learning curve for new hardware.

 

Mantle isn't "too the metal" either though. It's just a much lower level of abstraction than DirectX on the PC. Even without to the metal programming I'm sure the consoles are using a much thinner API than the PC version of DX.

 

Yes I doubt BF4 with Mantle support will bring large improvements. When you read all the advantages Mantle can offer, it seems pretty likely that you'd need to code from the top for Mantle or at least seriously rewrite your engine to take full advantage if it. As opposed to tacking on support to an existing engine to take advantage of the faster draw calls. Maybe they are the 'low hanging fruit'?

 

The Oxide demo more than anything just demonstrated a 3x increase on the drawcall ceiling bottleneck we saw on cpus thanks to directx.

I don't get how several of you are equating this with 3x performance. So far they only achieve 3x performance if batch count was increased to +40k, wheras in the normal case directx would be bottlenecking the cpu at that batchcount.

 

It might help a lot if you have a slower CPU.

 

I got it from Arwins quote

 

Very impressive demo! Pretty amazing what they are able to do when making better use of a modern CPU (and GPU)!

Definitely excited to see that released.

 

It's worth watching the video if you can find the time but Hardware.fr has the slides from the video up.

http://www.hardware.fr/news/13450/apu13-oxide-fait-exploser-limite-cpu-avec-mantle.html

The 3x and 10x numbers come from this slide.

 

The 3x claim occurs under certain conditions.
Statements elsewhere and the tenor of the presentation make me think that 3x performance improvement does not generally happen with no rewrites.

Oxide's isn't even version 1.0, meaning anything written for it is by definition not a rewrite.
Another difference is that the context of their goals in engine design are for maximizing flexibility and avoiding the undesired but common optimization methods used to help reduce the impact of batches and state changes on the PC.

The engine is a fresh code base whose design goals take it to a different place that older engines tried to avoid.
Without rearchitecting an engine built with the design goals and constraints of prior generations, those scenarios wouldn't come up.

 

I get the sense that the decoupled shading in the Nitrous engine is something that already works on D3D (and/or OpenGL/console).

They imply that "pandora's box is opened by working with Mantle", but isn't that really an experience developers could already have on console?

For example, most of the useful R&D on game-engine multi-core programming seems to have taken place on consoles since PS3/XB360 appeared.

I don't see anything on the topic of why this is better than console programming - other than "it's an abstraction of the hardware and that in itself is useful".

---

The bottom line seems to be: artistic freedom and expansive in-game scale are the direct results of greater system efficiency. We get that efficiency by support for more batches.

With a subtext: freedom in memory usage and task organisation. A direct implication of that is "new types of batches", which sounds obvious, but it's arguably the most important thing. Developers get the freedom to create their own API in concert with a low level abstraction, enabling new types of rendering/games/experiences.

All the stuff that Larrabee promised

---

I noticed the slide implying that things such as bindless textures are just a band-aid.

 

Yeah that also strikes me as weird. I'd always assumed that bindless-style resource usage was a major component of Mantle's claimed efficiency gains. Obviously proper multithreaded command buffer building is a great thing (especially for people who already do that for consoles), but there's tons of work involved in converting a D3D-style slot-based API into something a GCN-based GPU can work with. Sure it requires shader changes and it may have some minor GPU perf implications, but it seems really odd to refer to it as as "band-aid" in the same presentation that complains about API's not matching the underlying hardware.

 

He says in the video that each of those points on the slide gives a few percent. And they're a lot of work to get working.

The comment "and textures are already typically grouped by artists" seems to imply that for the kind of content they're used to dealing with, there is literally no advantage.

I would have thought that "freeing artists from thinking about textures and grouping them" would be a relevant bullet point somewhere in the deck. On another slide (13 in hardware.fr's sequence) it says "Artists pack things into same textures, even when not really appropriate". Aren't these contradictory?

That leads me to think they don't have the breadth of experience to make a valid point about bindless. "Strategy games" seems to be their focus. Would that make them blinkered?

 

Q&A: Just use Bindless?

http://youtu.be/sSY2KXBoro0?t=20m4s

 

Already discussed earlier in the thread... suffice it to say I think they kind of missed the point, hence why I spawned the other thread to discuss in more depth.

But I do agree that there's no reason we can't pursue both. Ultimately they are fairly related, it's just a question of who chases the relevant pointer... just that should be an application decision, not an API design.

 

So I suppose what we really need to see is a demonstration of a "pure" bindless game engine (not just a renderer demo) along the lines of Oxide's demo, to quantify its value when used as part of existing APIs.

It occurred to me that their dismissiveness with respect to bindless might be a direct result of these developers' experience with previous and current gen consoles. If they've used APIs that offered a pseudo-bindless abstraction (in which they had full control over what's in memory, but not how that memory is bound and the kinds of shaders that can bind to them, or how much can be bound to specific shaders), they might have a jaundiced view of bindless. Maybe it didn't give them the freedom we now take for granted in the term "bindless".

Maybe NVidia is hard at work on converting a game engine to a pure bindless model...

On the other hand, Mantle seems to be much more than just getting more performance. It strikes me as a thin compute-centric API that happens to respect the foibles and desires of fixed-function hardware in current GPUs, for graphics rendering.

 

Divinity dragon commander

 

And allows for proper multithreading on CPU while sending commands to the GPU?