AMD MANTLE DEVELOPER VIDEO 44 mins

[Rroff]

That's actually the opposite of what you would expect to happen... the Mantle driver forces devs to do a lot of fine-tuning that for 10 years or so hasn't been strictly necessary. Focusing on drawcalls is a distraction from what Mantle provides as a whole.

I agree that focusing on drawcalls is distracting from what mantle provides as a whole however I have a great deal of cynicism for what I call "career" programmers who seem to be making up increasing numbers in the industry and rare have the ability or willingness to stray far from what they've been taught and not a fan of giving them tools to enable them.

 

[GoogalyMoogaly]

The worrying thing about it all is this, will Devs become lazy and just push out stuff like we have now knowing Mantle is making their job of hitting fps targets etc a lot easier, and leaving CPUs undertaxed? i hope not, i hope the Devs suddenly realise how much power they now have extra to play with and we start seeing really innovative and new things in our games.

The thing is developers will still have to write DirectX (or OpenGL) render paths for any game they want to sell a large number of so they don't exclude Nvidia owners or older AMD card owners. So how much they can really do will still be limited, in my opinion, to superficial new effects.

 

[melmac]

And how does that effect performance..?
An honest question here... I have never made a game or dabbled in programming.

What FPS gains are to be had from increasing the drawcalls from 15k to 100k?
Or is that just a number they can use because it's a big difference so people who don't know what it means will think it is a massive breakthrough and something they'll benefit from immediately? Because to me, it looks like a big number that is important to devs, but also that people who haven't got a clue will throw around as if it is something huge.

The numbers that I have seen from that demo are that it the Swarm demo ran 3-4 times faster on the mantle system as compared with the directx system. Of course this is a tech demo which probably shows the best case scenario.

I do agree there is a lot of focus on drawcalls because of the big numbers, but mantle isn't just about drawcalls. It's only a part of the whole thing.

the worry is that it becomes a band aid for devs who can't be bothered to do any proper DX optimisation

Its one of the things I dislike about it (Mantle) as drawcall limitations is one of the first major hurdles an inexperienced developer runs into and it quickly seperates the wheat from the chaff - those devs who do sloppy coding and lack the ability to innovate or come up with creative solutions, etc. from those for who its actually a passion and can push tech to the limits.

I don't agree with either of you about this. Developers have been complaining about the drawcall problem for years, until finally in Directx 10 Microsoft improved things a little. Because there shouldn't be a need to waste development time coming up with "creative solutions" that are only work arounds and can only ever be work arounds.

 

[Sighn]

this ^

it is basically just a big number, without the detail behind it it is meaningless

if I've understood this correctly;

that PS4 demo where they showed lots of cubes dropping was "30k draw calls"... the only reason it was 30k was because they deliberately did no optimisation and made each cube 1 draw call

with DX11 you can instance each object and just set the location and positioning (and scaling and colour and...), so effectively you could have all 30k cubes handled by a single draw call (this is how stuff like physx particles work and why you can have thousands or millions of particles on screen swirling about without massive performance hits)

now, if you actually did want to have 30k DIFFERENT cubes, then ps4 would win, however if you want 30k very similar cubes then doing each one as a single draw call is just poor optimisation

and there's things like directx command lists which allow you to batch draw calls together

without direct side by side comparisons of properly optimised DX code against mantle code, we have no idea what improvement it is going to give

the worry is that it becomes a band aid for devs who can't be bothered to do any proper DX optimisation

Curiously enough, AMD doesn't support DX11 command lists for its gfx drivers.

 

[humbug]

@ no_1_dave, this has been said universally many times, often explained to you. AMD aren't going to put numbers and graphs on performance because the variation in that is massive. the performance gain could be anything, pick a number and you could be right. it depends on the game, the map / game level. the developer...

You can't make graphs for for something that could be 'anything'

Why are you so desperate for AMD to put a number on it? so you can pull them up on it later?

 

[Rroff]

I don't agree with either of you about this. Developers have been complaining about the drawcall problem for years, until finally in Directx 10 Microsoft improved things a little. Because there shouldn't be a need to waste development time coming up with "creative solutions" that are only work arounds and can only ever be work arounds.

Work arounds are nasty but a lot of video game development revolves around making things work that aren't actually practical or feasible to do with the straight forward approach and those who can deal with the drawcall limitations tend to be the ones who do better at the real challenges.

 

[BS Dave]

Curiously enough, AMD doesn't support DX11 command lists for its gfx drivers.

It's annoying as well, Nvidia cards did vey well in BF3 because of those lists. I wonder if it's a hardware of software reason they don't support them...

 

[DarrenM343]

I doubt the patched BF4 will be that impressive to be honest. I don't know much about game development but I am thinking making an already developed game work with a specific API will not reap the best rewards. ANd why spend much time/money on it when the game already runs on the hardware using cross hardware platform DirectX? If it really is quick and easy to do then that would suggest that there isn't much to mantle, or as already stated, optmisation by the devs will be minimal.

 

[Gregster]

More on how Mantle helps performance
Mantle's closer-to-the-metal development model, coupled with a more lightweight driver, seems to pay some very real performance dividends. The game developers in attendance at APU13 were reluctant to quote actual performance figures from their games, partly because their work still isn't quite finished. However, some figures were quoted that shed light on Mantle's performance benefits.

For starters, Nixxes' Katsman revealed that "very early figures from Thief" (which is "not fully running on Mantle yet") showed a big reduction in draw call overhead. "Before, we would often see about 40% of the CPU time stuck in the driver, in D3D, or in various threads," he said. "The early measurements we did, right now we have that down to about a fifth of that."

The guys from Oxide offered a more visual representation of Mantle's CPU overhead in their talk. Mantle is the yellow rectangle, the game engine is the blue one, and unused CPU time is shown in green:

DICE's Andersson extrapolated upon that same notion in his keynote, saying that, with Mantle, the CPU "should never really be a bottleneck for the GPU anymore." In a separate demonstration, Oxide showed their Mantle-enabled space game suffering no frame rate hit when the FX-8350 processor on which it ran was underclocked to 2GHz, or half its base speed. (Graphics processing in that demo was handled by a Radeon R9 290X.)

The reduction in draw call overhead also means more draw calls can be issued per frame. Riguer said Mantle raises the draw call limit by an order of magnitude to "at least" 100,000 draw calls per frame "at reasonable frame rates." This isn't just theoretical—Oxide showed their space game demo actually hitting 100,000 draw calls per frame. Andersson, who was in the audience for that presentation, was impressed enough to tweet about the demo.

Mantle will allow game developers to use more CPU cores, too, as these two slides from Andersson's presentation show. According to Andersson, the Mantle model outlined in the second slide is the "the exact model that we're using on all of the consoles"—both current and next-gen ones. In his talk, Katsman explained that, if a system has eight cores, Mantle allows developers to use all of those cores for their game. "So, we can have four to do rendering, a few more to do physics and some other things. We can make games that are far more complicated. We can increase the draw distance to significant distances, have far denser worlds."

According to Katsman, "The density of everything in the world is something that's being held back, and I think Mantle will help alleviate that." That said, "Just because we can draw more things doesn't mean we have the CPU resources to simulate them all." For example, while Mantle might make it possible to draw many more characters in a given scene, developers will have to consider the cost of running AI simulations for all of those characters.

In addition to making more effective and efficient use of the CPU, Mantle will allow GPU resources to be used more efficiently. Katsman brought up the Radeon R9 290X, which has 5.6 tflops of compute power, and said that an "awful lot" of that compute power is "lying there dormant." With current APIs, some of the compute power might be used for some parts of a frame, but other parts "will be bottlenecked by something else," such as "getting things from memory, by fetching textures through the texture fetch units, [and] the rasterization units." He went on:

The APIs we have right now, they just allow us to queue synchronous workloads. We say, "draw some triangles," and then, "do some compute," and the driver can try to be a little smart, and maybe it'll overlap some of that. But for the most part, it's serial, and where we're doing one thing, it's not doing other things.
With Mantle . . . we can schedule compute work in parallel with the normal graphics work. That allows for some really interesting optimizations that will really help your overall frame rate and how . . . with less power, you can achieve higher frame rates.

What we'd see, for example—say we're rendering shadow maps. There's really not much compute going on. . . . Compute units are basically sitting there being idle. If, at the same time, we are able to do post-processing effects—say maybe even the post-processing from a previous frame, or what we could do in Tomb Raider, [where] we have TressFX hair simulations, which can be quite expensive—we can do that in parallel, in compute, with these other graphics tasks, and effectively, they can become close to zero cost.

If we guessed that maybe only 50% of that compute power was utilized, the theoretical number—and we won't reach that, but in theory, we might be able to get up to 50% better GPU performance from overlapping compute work, if you would be able to find enough compute work to really fill it up.

The 50% figure is a theoretical best-case scenario, but Katsman added, "It seems quite realistic that you would get maybe 20% additional GPU performance out of optimizations like that."

Also, because Mantle lets developers use GPU memory more efficiently, the new API could allow for the use of higher-resolution textures in a given game, according to Katsman.

Some caveats
Mantle's advantages are many, but a few downsides that were mentioned in the various presentations at APU13.

One of those is that, unsurprisingly, supporting an additional API incurs added development time and cost. Mantle currently works only on GCN-based Radeon graphics processors, which means that developers who adopt it must also use either Direct3D or OpenGL to support other graphics hardware. Andersson said DICE spent about two months porting Battlefield 4's Frostbite 3 game engine to Mantle. Asked for a ballpark cost figure, Katsman told me that, for a simple PC project like Nixxes' Thief port, adding Mantle support might amount to roughly a 10% increase in development cost. He was quick to add, however, that such an increase is a drop in the bucket compared to the total development cost of the entire game for all platforms, which might add up to something like $50 million.

The lack of multi-vendor and multi-platform support is another one of Mantle's notable downsides. Microsoft and Sony use different APIs for the Xbox One and PlayStation 4, and Mantle doesn't yet support Linux, OS X, or Valve's upcoming SteamOS. There are some mitigating factors here, though. Katsman noted that Mantle optimizations are "conceptually similar" to the ones developers write for next-gen consoles. That tells us developers won't be starting from scratch when adding Mantle support to their games. Also, Katsman believes Mantle's performance improvements make its implementation worthwhile even if only a fraction of users benefit. As he pointed out, developers already spend time writing support for features like Eyefinity and HD3D into their games, and those features have even smaller user bases.

Finally, adding Mantle support to current game engines, as Nixxes did with the version of Unreal Engine 3 used by Thief, can be a challenge. "Native D3D ports will not magically get much higher performance," explained Katsman. "If you emulate the same system on top of Mantle, you will not get much better performance." Fully optimizing an existing engine for Mantle seems to involve breaking and rewriting some chunks of that engine to take advantage of the new development model. But here again, Katsman believes the performance improvements make the effort worthwhile.

http://techreport.com/review/25683/delving-deeper-into-amd-mantle-api/3

 

[=XDC=FluphyBunny]

10% increase in development cost

AMD are going to have to throw money at developers to program for Mantle if that figure is correct!

 

[straxusii]

I can't see mantle being used for many games unless it is available in Nvidia drivers also, just like Physx

 

[TheRealDeal]

AMD are going to have to throw money at developers to program for Mantle if that figure is correct!

"He was quick to add, however, that such an increase is a drop in the bucket compared to the total development cost of the entire game for all platforms, which might add up to something like $50 million."

From this statement it really won't cost much at all to implement mantle and it may allow game developers to push boundaries dx won't so mantle becomes a bonus to developers.

 

[shankly1985]

I can't see mantle being used for many games unless it is available in Nvidia drivers also, just like Physx

The hole EA line up thats on Frostbite engine will be using this. Think its something 15 games just next year. Thats almost all of the physx enabled games in one year's time.
Thats not even including the games from other devs who on board.

 

[straxusii]

That's a decent start, I guess being integrated into a game engine gives it a better chance than something like Physx if it stays AMD only.

 

[Rusty0611]

"He was quick to add, however, that such an increase is a drop in the bucket compared to the total development cost of the entire game for all platforms, which might add up to something like $50 million."

From this statement it really won't cost much at all to implement mantle and it may allow game developers to push boundaries dx won't so mantle becomes a bonus to developers.

He's not exactly going to say otherwise is he.

The point =XDC=FluphyBunny was making, I believe, is that you aren't just going to get studio's taking a 10% increase in cost without some kind of incentive. Especially when the extra sales generated as a result of Mantle is an unknown quantity. Hell Mantle itself is still a relatively unknown quantity (in terms of market reception).

The 10% translates directly to their bottom line so AMD will have to pay people to adopt it unless studios think they can absorb the cost and offset it through extra sales which to me would look to be a gamble at this stage so I can't see it happening for a while.

 

[Yaayuh!]

As my boss would say:
"I don't care about how or why. Where are my damn numbers?"

 

[melmac]

That's a decent start, I guess being integrated into a game engine gives it a better chance than something like Physx if it stays AMD only.

It's not AMD only. It will be at the start but they said at the developers conference that other companies will be able to use mantle.

 

[wolvers]

That goes both ways in regards to PhysX, the amount of hate directed to the actual tech instead of its employment is quite pathetic tbph.

My biggest concern over Mantle is that it will end up like just like fizzX. A really great piece of tech that's totally underutilised and only available to a portion of PC gamers.

 

[Rroff]

Curiously enough, AMD doesn't support DX11 command lists for its gfx drivers.

I did kind of want to slap the dev when he was saying about "most of those cores are not accessable to drive graphics... this is wrong"... that said driver command lists require both support from both the graphic card developer and video game developer to work properly and have several limitations and caveats.

That only nVidia have performance drivers that support the type of useage in BF3/4 and even MS seems to handle CPU/GPU parallel dispatch as an afterthought I'm not suprised to see their use not return in BF4 however I'm beginning to think the lacking support of them from AMD is political a couple of titles that AMD have jumped on for this generation have removed them that used them in their previous version of the game.

 

[rare]

So what happened to the Mantle BF4 patch. Wasn't it supposed to be out by now?