• We should now be fully online following an overnight outage. Apologies for any inconvenience, we do not expect there to be any further issues.

The AMD Mantle Thread

Page 78 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Status
Not open for further replies.

moonbogg

Lifer
Jan 8, 2011
10,731
3,440
136
I think the new C&C will be a frostbite game. Would be sick if it was a Mantle title with loads of units and good performance.
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
IMG0043515_1.jpg


According to Oxide, it's just faster. "Huge performance gains even without using Mantle specific features" = it's just faster simply due to coding near the metal.

I can't see the picture, but that has less to do with Mantle itself and more to do with them being able to code more efficiently; which, as I've explained, is completely developer and game specific.

Yes, but the 2 man month was for incorporating Mantle into the engine. Wouldn't that be more work than just a single game?

Even with Mantle in the engine, they still have to learn the Mantle specific paths and code to those. That is a learning curve. And, they still have to make a DX build.
 

f1sherman

Platinum Member
Apr 5, 2011
2,243
1
0
1) Mantle is in such an early stage, that even AMD is not sure what to make of it.
PCGH asked Raja Koduri about Mantle and its "openess". He replied that AMD doesn't see Mantle as an open standard like OpenCL or OpenGL.
And of course, how could they know it's exact shape, when it all depends on key-players reaction.

2) At this point Mantle is more a set of programming principles and ideas, and much less hardware or even implementation specific programming language.
For all we know Intel/Nvidia could gain boost from BF4 Mantle patch, unless AMD/DICE is purposly locking them out.
Mantle is an union of the programming principles and the driver. Driver being the only potentially hw specific component.
In that sense Mantle lays somewhere between CUDA and NVAPI. It's less hw specific than CUDA, less developed than NVAPI, but huuugely ambitious.
I cant get rid of the feeling that someone has gathered room full of industry geeks, and said to them; "I want to you to write me something which can conquer the world".

3) MS & Co. wouldn't touch it with a 10-foot pole. Even if it was 100% open; and it won't be. Who's to say AMD won't do this or change that, once Mantle gains traction.
AMD wants full control, so of course that MS, Intel and NV won't hear none of it.
And either one of them can help make super-optimized AAA PC game, if they really want to or if they feel threatened by the whole Mantle thing.
Posibly even without having to use DX11.3/12.0, NVAPI.

4) Mantle was born out of desire to change the status quo and to make AMD CPUs and APUs more competitive.
AMD can repeat all they want - we didn't approach developers, developers came to us - such scenario won't be any more believable than it already is.
And this is why I'm not overly-enthusiastic about industry wide Mantle addoption.
For the simple reason that AMD has the least amount of resources within the industry, has the least impressive software track-record among big players and yet is super ambitious and wants total control of its project.
The way I see Mantle is piecemeal adoption ala BF4. Ie. few projects backed by AMD with particular Mantle principles incorporated.

Which TBH is not bad. AT ALL!
FREE FPS, who's going to say NO?!

5) Johan Andersson - the man wants better Frostbite. Pure and simple. If AMD is going to finance that - he'd be fool not to go with it. The idea that the overall development is shorter is possibly true - but only when and if the SuperFrostbite is ready. And this is perhaps the best thing AMD can make out of the whole Mantle - help write super efficient next-gen engine.
Realistically, development cost and time is guaranteed to go up with Mantle.
2 man months for implementing exactly WHAT in BF4??
IMHO the whole idea With Mantle No Pain - But So Much Gain, is ludicrous and can only be sold to uninformed investors.
(And apparently AMD needs catalyst NOW, else they would have landed BF4 patch come Xmass on top of Intel/NV head, and at the sane time announced Mantle/List of games supported.
Bad news is BF4 is down 69% in sales compared to BF3)

6) BF4 Mantle deployment is a proof-of-concept. But the reality is it won't prove anything. Other than the more resources you invest - the better results you can achieve.
AMD could have written Efficient Programming Cookbook, then force the developer xyz into following its principles, and results would have been similar;
or even the same if DX/OGL were to be used with additional revision/extensions.
Industry doesn't REALLY need another API in order to code profoundly more efficiently. But IF AMD has something revolutionary new to say, more power to them, they should patent it IMHO.
If it's good, we'll end up using it no-doubt.
But stop flirting with the "openess", because that would defeat the whole purpose of Mantle. Which is, lets repeat it. HOW TO MAKE OUR HW MORE COMPETITIVE.


In the end you have to give it to AMD, they are selling and borrowing left and right, but continuing to fight as hard as they can.
 
Last edited:

3DVagabond

Lifer
Aug 10, 2009
11,951
204
106
If u can read my post again what i said is u cannot get full advantage of Mantle by using intel CPU.U can go twiter there explanation amd of APU how they remove bottleneck by using Mantle.AMD will never allow intel to take advantage from Mantle and why they will.What AMD clearly said that it remove CPU bottleneck.

So i am guessing is that AMD will pay hell of money so that Intel cpu run better on Mantle.

I think you are taking the GCN GPU access from the AMD APU in to acct. As far as CPU vs, CPU all of the advantages of Mantle still apply to Intel as well..
 

krumme

Diamond Member
Oct 9, 2009
5,956
1,596
136
And, I don't think people understand what a man-month is (or the real impact on software development). If Mantle takes someone 2 man-months (the average amount of work a person can do in 2 months), that increases the development process by 2 months. In situations where you get a 24 month release schedule, giving you maybe 20 months to actually code, an additional 2 months of down time for every employee is huge.

No you dont understand it and are just flat out wrong.

A man-hour-month is:

"One person's working time for a month, or the equivalent, used as a measure of how much work or labor is required or consumed to perform some task"

In Oxide case they said mantle cost 2 man hour months. If it took 2 months for them thats what they would say - "it took us 2 months". Its not that complicated. But they didnt.

You are confused. What about a project that cost 200 man years? Will it take 200 years? Lets asume Oxide have more than one coder that can handle this specific task shall we?

Your definition and example is the same as a month. And you didnt even notice.

What about you stop lecturing and attacking?
 

krumme

Diamond Member
Oct 9, 2009
5,956
1,596
136
Even with Mantle in the engine, they still have to learn the Mantle specific paths and code to those. That is a learning curve.

Yes. But learning cost they have already payed for, if they wanted to sell their games to the consoles. Most of them want that market. But most is prioritizing consoles, so Mantle is done and the learning is already paid here. In contrast to complicated dx specific paths for one gfx vendor where its difficult to know what happens in the driver.

And, they still have to make a DX build.

Yes but can save a lot here. Because they will have far better ROI because they dont have to pay to get the last 20% performance on DX because the future market is so small compared to the consoles, gcn and gcn apus together.
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
Yes. But learning cost they have already payed for, if they wanted to sell their games to the consoles. Most of them want that market. But most is prioritizing consoles, so Mantle is done and the learning is already paid here. In contrast to complicated dx specific paths for one gfx vendor where its difficult to know what happens in the driver.

Again, wrong. Only AMD has said it is "similar" and some code can be "reused". You no idea how similar the APIs actually. They've also provided zero examples I've seen that show any similarities. They could easily do this. Provide some sample code or even psuedo code. Anyone with any development experience understands APIs can be similar and require an incredible amount of work for each. Also, the Mantle path isn't going to be simple, especially when it comes to the DX path. Have you used the DX API?

No you dont understand it and are just flat out wrong.

A man-hour-month is:

"One person's working time for a month, or the equivalent, used as a measure of how much work or labor is required or consumed to perform some task"

In Oxide case they said mantle cost 2 man hour months. If it took 2 months for them thats what they would say - "it took us 2 months". Its not that complicated. But they didnt.

You are confused. What about a project that cost 200 man years? Will it take 200 years? Lets asume Oxide have more than one coder that can handle this specific task shall we?

Your definition and example is the same as a month. And you didnt even notice.

What about you stop lecturing and attacking?

They didn't say 2 man-hour-months, they said 2 man-months. Which is the the measurement of the average amount of work a person does in a month. That is an estimate used, and is about 320 hours. It took them, their team, 2 months of work to put Mantle into their engine.

So, unless there is some magical Oxide only definition you know about, in every working (as a software developer) situation I've been in, a man-month is as such.
 

tonyfreak215

Senior member
Nov 21, 2008
274
0
76
Even with Mantle in the engine, they still have to learn the Mantle specific paths and code to those. That is a learning curve. And, they still have to make a DX build.

I agree, but that learning curve is the same curve they'd have when coding for the PS4.
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
I agree, but that learning curve is the same curve they'd have when coding for the PS4.

Not quite. The concepts will be similar, but the implementation is going to be different. They are not just going to have to swap out their ps4API.render() with mantleAPI.render() and be good. Their optimizations for specific things could likely stay in place, depending on how modular they've written them.

And every minute they spend on porting Mantle, is likely one less minute spent on the DX version. Which is what a lot of people are saying could be a problem. They also have to understand how to trace errors and fix bugs in the new Mantle code paths, which might be harder than actually coding for Mantle.
 

krumme

Diamond Member
Oct 9, 2009
5,956
1,596
136
They didn't say 2 man-hour-months, they said 2 man-months. Which is the the measurement of the average amount of work a person does in a month. That is an estimate used, and is about 320 hours. It took them, their team, 2 months of work to put Mantle into their engine.

So, unless there is some magical Oxide only definition you know about, in every working (as a software developer) situation I've been in, a man-month is as such.

You talk nonsense.

It does not matter if they say "man month" or "man hour month". Its different from a month. Its as you say about 320 hours, and unless only one man was working on it on Oxide, it didnt take 2 month. Right? - and mantle dont add 2 month to the development cycle as in your example. Unless you are a one-man show.

And no, the definition is not different as a software developer from the rest of the world. You just didnt understand the definition prior. Now you do, because i have told you how it is.

You were corrected.
 

SiliconWars

Platinum Member
Dec 29, 2012
2,346
0
0
Erm, no smackababy, that's not it. Why on earth would they talk about "man months" when they could just have said "It took us 2 months", or "it took our team 2 months"?

1 man month = the amount of time it takes 1 man to finish a project in 1 month. 2 men can do it in roughly half the time (realistically looking at ~40% faster).
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
You talk nonsense.

It does not matter if they say "man month" or "man hour month". Its different from a month. Its as you say about 320 hours, and unless only one man was working on it on Oxide, it didnt take 2 month. Right? - and mantle dont add 2 month to the development cycle as in your example. Unless you are a one-man show.

And no, the definition is not different as a software developer from the rest of the world. You just didnt understand the definition prior. Now you do, because i have told you how it is.

You were corrected.

No, you don't understand the term. If it took Oxide 2 man-months, that means either it took their team 2 months (which is the correct usage of it take "them 2 man-months") OR it took a team of however many people about 320 man-hours in total, which would be an incredibly stupid way of explaining the time it takes. "Just because a woman can make a baby in nine months, it does not follow that nine women can make a baby in one month." If it took 320 total man-hours, you list it as such, but don't expect adding more people will make it go faster linearly.

Now, any time it takes them to learn to use a new technology is time added to development. And, the entire team pretty much has to have some working knowledge of it.
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
Erm, no smackababy, that's not it. Why on earth would they talk about "man months" when they could just have said "It took us 2 months", or "it took our team 2 months"?

1 man month = the amount of time it takes 1 man to finish a project in 1 month. 2 men can do it in roughly half the time (realistically looking at ~40% faster).

No, that is not how software development works, especially with concerns to new technology. I am curious as to what your professional experience is, because in software development, simply adding people doesn't "realistically reduce the time by such a great amount". There are books written about this.
 

tonyfreak215

Senior member
Nov 21, 2008
274
0
76
http://techreport.com/news/25651/ma...ite-games-dice-calls-for-multi-vendor-support

techreport.com said:
Andersson said creating a Mantle version of the Frostbite 3 engine took about two months of work. The Mantle release's core renderer is closer to the PlayStation 4 version than to the existing DirectX 11 one

techreport.com said:
Jorjen Katsman of Nixxes, the firm porting Thief to the PC, mentioned a reduction in API overhead from 40% with DirectX 11 to around 8% with Mantle. He added that it's "not unrealistic that you'd get 20% additional GPU performance" with Mantle.

techreport.com said:
Mantle provides enough abstraction to support other hardware—i.e. future AMD GPUs and competing offerings. In fact, Andersson said that most Mantle functionality can work on most modern GPUs out today. I presume he meant Nvidia ones, though Nvidia's name wasn't explicitly mentioned. In any event, he repeated multiple times that he'd like to see Mantle become a cross-vendor API supported on "all modern GPUs."
 

Atreidin

Senior member
Mar 31, 2011
464
27
86
I have always heard man-month defined as the amount of work one man does in one month. Kind of like man-hours, just extrapolated to months.

So one man working 2 months is 2 man-months, as is 2 men working one month, or 4 men working 2 weeks, etc. That's pretty much how everyone, everywhere sees it, a cursory Google search will prove that over and over again.

Of course that is just a measurement of work over time, how efficiently adding people works to decrease development time is a separate issue.
 

SiliconWars

Platinum Member
Dec 29, 2012
2,346
0
0
No, that is not how software development works, especially with concerns to new technology. I am curious as to what your professional experience is, because in software development, simply adding people doesn't "realistically reduce the time by such a great amount". There are books written about this.

I'm pretty sure that's why I said 40% instead of 50%. I know that you don't simply divide the time by the amount of people and get the end time, however more people cuts the time unless the project is already running late.

As for my experience in software development, I had a game published in 1989. Working in a team of 3 people, which cut time by around half compared to what I could do by myself funnily enough. What's yours?
 

Atreidin

Senior member
Mar 31, 2011
464
27
86
I think the new C&C will be a frostbite game. Would be sick if it was a Mantle title with loads of units and good performance.

I used to benchmark computers with C&C based on how many guys could be on the screen, just standing around doing their default animations, without slowing the computer down.:D
I wonder how many would fit nowadays, with Mantle and all (assuming a big enough screen/resolution.)
 

Phynaz

Lifer
Mar 13, 2006
10,140
819
126
Did you have the same trouble reconciling the 3x faster statement from the Oxide guys?

I didn't see it, could you link me to it?

Edit: I see a tweet, saying "in some cases".
What engine are they using? Unreal? CryEngine? Frostbyte? Could it be their own engine, and whay are they comparing? Maybe the state of of and old unoptimized DX path compared to the Mantle path they are working on with AMD?

Anybody saying 3x faster is either unqualified, paid off, or flat out lying.
 
Last edited:

smackababy

Lifer
Oct 30, 2008
27,024
79
86
I didn't see it, could you link me to it?

Edit: I see a tweet, saying "in some cases".
What engine are they using? Unreal? CryEngine? Frostbyte? Could it be their own engine, and whay are they comparing? Maybe the state of of and old unoptimized DX path compared to the Mantle path they are working on with AMD?

Anybody saying 3x faster is either unqualified, paid off, or flat out lying.

They (AMD) could easily come up with a scenario where Mantle does provide 3x faster performance. Does that mean that number is usable in any way? Nope.
 
Status
Not open for further replies.