Support NeoGAF

[Brad Grenz]

What? Where the hell are you getting those numbers from? 1/8 as fast on SIMD? Citation needed.

15GFlops vs 102GFLOPs. It's actually more like 1/7th. My apologies.

 

[Brad Grenz]

I know how FB operates, thank you very much (for the umpteenth time - check the discussion a few pages ago). The FLOPS workloads that the engine can handle (as in viable throughput), are one thing. The engine's requirements - an entirely different thing. The entire argument started from:

DICE guy: We tried FB2 on the WiiU and it did not perform well.
forumite: It must be the CPU!
me: how come their well-scalable-with-CPUs engine did not perform well? If they say that did not perform well outside of the context of any game, then the engine's requirements alone (read: for doing any meaningful workloads) must be pegged at something akin to 3x PPEs (which was a sarcastic statement on my part, I do not honestly expect that to be the case). And since the only advantage Xenon has over Espresso are (SIMD) FLOPS, that would mean the engine eats a significant amount of FLOPS per breakfast.

It's almost like they built the whole engine explicitly for dynamic objects and a heavy emphasis on destructibility and material simulation require intensive vector calculations! So weird that they'd spend this whole generation creating technology that plays to the strengths of the 2 major platforms. Hell, the engine's requirements could be half what Xenon provides, but it would still be well out of reach for Espresso.

I've been aware what you're claiming since the beginning. Here's a hypothetical for you to perhaps help ypu understand what I've been asking you about single-threaded performance: do you expect FB to perform equally well compared to the 'baseline' 3x PPE if the setup contained 10 cores at ~1GHz each? How about 100 cores at 100MHz? If yes - why? If not, then how are you so sure FB would be fine on a bunch of Jaguars? We are still talking SIMD FP here, not even discussing GP code.

Well, again, if you look back at the powerpoint it shows that something like 2-300 jobs are executed in any given frame. Seems like they chopped everything up into nice bite size morsels, so, yeah, there's a good chance it would work on all those configurations, assuming the infrastructure exists to keep all the processors fed. But here's an idea, since you're the one making extraordinary claims (like Frostbite won't work on an 8 core Jaguar), why don't you tell us why that's the case? Or better yet, why don't you go back to the drawing board and figure out what point you're actually trying to make, because arguing that a system we know is getting Battlefield 4 can't run Battlefield 4 is the act of a crazy person.

 

[Log4Girlz]

There's no reason why Wii U shouldn't be getting these fangled new engines if developers were willing to take the time to butcher them.

 

[prag16]

There's no reason why Wii U shouldn't be getting these fangled new engines if developers were willing to take the time to butcher them.

For someone knowledgeable on such things, is Cryengine 3 (or Unreal 3, or Ubi's AnvilNext for that matter) really so drastically easier on the CPU than FB2/3? That seems to be the claim some are making, but I haven't seen much to back it up.

 

[diffusionx]

I understand that this is a business, but how do you go from announcing an unprecedented partnership mentioning EA Sports and Battlefield series, from not even calling the system next gen, not releasing Wii U versions of your multi million selling franchises, EA wants to give Wii U the Dreamcast treatment.

You go in that direction by releasing a weak system that nobody wants to buy.

Sorry but I haven't seen a single reason why EA should drop millions of dollars to support this thing over the years. Handshakes and polite PR are not reasons.

 

[TalesOfWin]

This thread still is going? So many salty tears from the nintendo fans. Protip, buy a ps4 or durango if frostbite games is such a big deal. Or do you plan to stay wii u only?

 

[prag16]

This thread still is going? So many salty tears from the nintendo fans. Protip, buy a ps4 or durango if frostbite games is such a big deal. Or do you plan to stay wii u only?

I'll ignore the troll/rage bait.

I will go Wii U/PC, just like I went Wii/PC last gen. The only series I sort of (not even strongly) feel like I missed out on is Uncharted. Otherwise, meh.

 

[blu]

It's almost like they built the whole engine explicitly for dynamic objects and a heavy emphasis on destructibility and material simulation require intensive vector calculations! So weird that they'd spend this whole generation creating technology that plays to the strengths of the 2 major platforms.

One'd assume all those things would be subject to scalability, but hey, if you believe they actually pegged their engine at the 3x PPEs ballpark in terms of sheer engine requirements then I have nothing to tell you. We just agree to disagree.

Hell, the engine's requirements could be half what Xenon provides, but it would still be well out of reach for Espresso.

Wait a sec, saying Xenon beats Espresso in FLOPS is one thing which hardly anybody would argue; saying it beats it by a factor or N implies you have actual figures. So feel free to provide sustained FLOPS throuhput data.

Well, again, if you look back at the powerpoint it shows that something like 2-300 jobs are executed in any given frame. Seems like they chopped everything up into nice bite size morsels, so, yeah, there's a good chance it would work on all those configurations, assuming the infrastructure exists to keep all the processors fed.

You misunderstood my question. I'm not interested whether you believe FB could utilized 100 cores - for the sake of argument we can agree they can.

Are you familiar with the concept of throughput versus latency? The smaller the packet, the larger the packet latency overhead per the packet payload. '300 jobs per frame' is ultra-coarse work granularity - games can do thousands of traditional fine-granularity computational routine calls per frame. So, a coarse granularity packet suggest high performance of the individual core. Actually DICE quote re jobs is '15-200k C++ code each. 25k is common'. These are reasonably large routines. Are you starting to see now why I've been asking you about single-thread performance?

But here's an idea, since you're the one making extraordinary claims (like Frostbite won't work on an 8 core Jaguar), why don't you tell us why that's the case? Or better yet, why don't you go back to the drawing board and figure out what point you're actually trying to make, because arguing that a system we know is getting Battlefield 4 can't run Battlefield 4 is the act of a crazy person.

Huh? I'm not saying FB would not work on 8 Jaguars. I'm questioning the (presumed) claim that FB (as in the engine itself) would not work well on Espresso. I've also been the one saying that if Xenon was such a hard base requirement for FB, then the latter could face issues on the Jaguars due to the large single-thread performance discrepancy in FLOPS. Since you've been arguing against that point, I've asked you to provide a hard backing of the statement, nothing more, nothing less. To which you pointed me to the generation-old FB paper where DICE first discussed the benefits of data parallelism. Yes, everybody who's been remotely interested in engine tech this gen is well aware of DICE's early breakthrough in data parallelism, and that their engine can sustain excellent FLOPS throughput. Yes, that allowed them to have good run on the ps3.

 

[Technosteve]

Why the fuck are you two arguing about make believe hardware requirements of the Frostbite engine? I am pretty sure if EA big bosses say we want our franchises on this platform they would figure out how.

I highly doubt it's a technical hurdle, but a financial one

 

[Relaxed Muscle]

Why the fuck are you two arguing about make believe hardware requirements of the Frostbite engine? I am pretty sure if EA big bosses say we want our franchises on this platform they would figure out how.

I highly doubt it's a technical hurdle, but a financial one

Is a technical hurdle that becomes a financial problem. If they could adapt FB on Wii U easily money wouldn't have been a problem.

 

[prag16]

Is a technical hurdle that becomes a financial problem. If they could adapt FB on Wii U easily money wouldn't have been a problem.

That's not this guy's claim though. He seems to be asserting that the engine would need to be massively stripped down (not just optimized) to work on Wii U. That's why this argument is going on.

 

[Maxrunner]

That's not this guy's claim though. He seems to be asserting that the engine would need to be massively stripped down (not just optimized) to work on Wii U. That's why this argument is going on.

What i don't understand is at any point did EA forgot to tell Nintendo about this engine benchmarks since it was going to be used extensively on EA ?that is before the unprecedent partnership went out of the window...

 

[Durante]

Did you somehow entirely miss the context of the discussion? Espresso was being compared to Xenon, supposedly unfavorably, which was used as a justification for FB's absence from the WiiU. What marcan said about Espresso compared to A9 has zilch to do with the discussion. He did say something about Xenon, though, which you somehow entirely discarded. I wonder why.

He said it beats it clock-per-clock on integer workloads. Which is nice and all, but the clock speed on Xenon is 2.6 times higher.

When a CPU is largely more efficient per clock, clock differences of the magnitude of Xenon/Espresso (which apropos is 2.58, not 3), will not help you much. Why do you think Intel dropped their 4GHz P4s in favor of ~3x slower clock designs?

That's a ridiculous statement. If a CPU A is 2 times as efficient per clock as another CPU B, then B will still outperform A if it works at 2.6 times A's the clock rate.

Actually DICE quote re jobs is '15-200k C++ code each. 25k is common'. These are reasonably large routines. Are you starting to see now why I've been asking you about single-thread performance?

The amount of code lines is not a good indicator for anything, least of all the granularity of a parallel task. A 20 line task can take seconds, and a 100k LoC task can be done in a millisecond.

 

[Zoramon089]

He said it beats it clock-per-clock on integer workloads. Which is nice and all, but the clock speed on Xenon is 2.6 times higher.

That's a ridiculous statement. If a CPU A is 2 times as efficient per clock as another CPU B, then B will still outperform A if it works at 2.6 times A's the clock rate.

We don't know the relative efficiencies but I'm assuming if it wasn't at least some somewhat significant amount he wouldn't even mention it

 

[megabytecr]

If it was only on PS4, Durango, the weak CPU would be accepted, but they are developing for PS3 and 360, certainly the userbase was enough to overcome the hurdles there.

 

[Dictator93]

If it was only on PS4, Durango, the weak CPU would be accepted, but they are developing for PS3 and 360, certainly the userbase was enough to overcome the hurdles there.

Or the WiiU could just have an incredibly weak CPU. THere is that too.

BTW, it is obvious now that this is a combination of lack of power, lack of install pabse, and lack of will on EA and Nintendos part.

 

[Durante]

We don't know the relative efficiencies but I'm assuming if it wasn't at least some somewhat significant amount he wouldn't even mention it

Are you saying anything less than a factor of 2.6 is not significant?

Yes, everybody who's been remotely interested in engine tech this gen is well aware of DICE's early breakthrough in data parallelism, and that their engine can sustain excellent FLOPS throughput. Yes, that allowed them to have good run on the ps3.

So why are you so vehemently opposed to the further conclusion of this line of thought: "Yes, that's what makes their engine hard to port to such a CPU FLOPS-deficient architecture as the Wii U"?

 

[blu]

He said it beats it clock-per-clock on integer workloads. Which is nice and all, but the clock speed on Xenon is 2.6 times higher.

That's a ridiculous statement. If a CPU A is 2 times as efficient per clock as another CPU B, then B will still outperform A if it works at 2.6 times A's the clock rate.

Marcan said a universal truth - PPE's IPC is abysmal. I said 'if the IPC of the lower clock unit is largely higher, 2.6x clock will not cut it'. You come and pick an arbitrary value to 'largely' and claim the statement is ridiculous. Pardon my french, but WTH?

The amount of code lines is not a good indicator for anything, least of all the granularity of a parallel task. A 20 line task can take seconds, and a 100k LoC task can be done in a millisecond.

Yes, a 2 line asm function can take eons. And yet, the size of the code is normally indicative of the granularity. Which we already got a quote for - 300 jobs per frame is very low granularity - even if they all occurred sequentially (which would void the whole idea of the engine, but just for the sake of argument), at 30fps that's north of 100us per task - if that's not long I don't know what is.

So why are you so vehemently opposed to the further conclusion of this line of thought: "Yes, that's what makes their engine hard to port to such a CPU FLOPS-deficient architecture as the Wii U"?

Because FB is not a Xenon/Cell-exclusive engine. It also happens to run on dual-core x86 setups from years ago.

 

[Durante]

Marcan said a universal truth - PPE's IPC is abysmal. I said 'if the IPC of the lower clock unit is largely higher, 2.6x clock will not cut it'. You come and pick arbitrary value to 'largely' and claim the statement is ridiculous. Pardon my french, but WTH?

You assigned an arbitrary value first (one higher than 2.6), because it's the only way your statement works. I merely illustrated that if you pick a different value it works out differently.

Yes, a 2 line asm function can take eons. And yet, the size of the code is normally indicative of the granularity. Which we already got a quote for - 300 jobs per frame is very low granularity - even if they all occurred sequentially (which would void the whole idea of the engine, but just for the sake of argument), at 30fps that's north of 100us per task - if that's not long I don't know what is.

I don't understand your whole argument about throughput and latency, or how it relates to the discussion at hand. As far as I can tell, you wanted to make a point that, if FB3 were designed for Xenon-level CPU FP performance, it would be hard to port to PS4/720. And your idea is that per-core performance could be insufficient (because it can't be overall performance, as that is equivalent in theory and clearly superior in practice on the AMD platform). However, if 3 cores are sufficient to process 300 jobs per frame, then -- unless there is a ridiculous load imbalance -- the workload per core, even on the core with the largest-grain tasks, should consist of at least 40 parallel tasks. Distributing those 40 tasks further on the 2 or a bit more cores required to match the single Xenon core would not appear to be an issue.

On the other hand, running tasks that come even close to utilizing Xenon's theoretical FP performance on Wii Us CPU is impossible.

Because FB is not a Xenon/Cell-exclusive engine. It also happens to run on dual-core x86 setups from years ago.

BF3, as an example of one FB game they might be interested in porting to Wii U, does not run well at all on dual core chips -- even if said chips are clocked at 2.7 times the frequency of the Wii U CPU (and offer higher per-clock SIMD performance): http://www.pcgameshardware.de/Battl...ld-3-Multiplayer-Tipps-CPU-Benchmark-1039293/

 

[blu]

You assigned an arbitrary value first (one higher than 2.6), because it's the only way your statement works. I merely illustrated that if you pick a different value it works out differently.

Yes, I did. You, on the other hand, assumed that that arbitrary value was so small that the statement would not hold. Can't you see the disconnection?

I don't understand your whole argument about throughput and latency, or how it relates to the discussion at hand. As far as I can tell, you wanted to make a point that, if FB3 were designed for Xenon-level CPU FP performance, i would be hard to port to PS4/720. And your idea is that per-core performance could be insufficient (because it can't be overall performance, as that is equivalent in theory and clearly superior in practice on the AMD platform). However, if 3 cores are sufficient to process 300 jobs per frame, then -- unless there is a ridiculous load imbalance -- the workload per core, even on the core with the largest-grain tasks, should consist of at least 40 parallel tasks. Distributing those 40 tasks further on the 2 or a bit more cores required to match the single Xenon core would not appear to be an issue.

First of all, those jobs are not all parallel - there's a job depencency graph in there. From there on, you cannot discard the possibility that there could be dependency paths of jobs where the overall path length becomes critical for the single-core performance. The reason I brought in task granularity was that if you tried to further split such hot-path jobs into even smaller parallel ones (assuming you can), you'd hit at one stage the latency/throughput saturation.

On the other hand, running tasks that come even close to utilizing Xenon's theoretical FP performance on Wii Us CPU is impossible.

Of course. I never questioned that.

BF3, as an example of one FB game they might be interested in porting to Wii U, does not run well at all on dual core chips -- even if said chips are clocked at 2.7 times the frequency of the Wii U CPU (and offer higher per-clock SIMD performance): http://www.pcgameshardware.de/Battl...ld-3-Multiplayer-Tipps-CPU-Benchmark-1039293/

Well, if the topic of this discussion was 'DICE guy says they tested Espresso for BF3 prospects and decided platform was not a good fit' I would not have joined the discussion in the first place. The premise of this discussion formed quite differently though - 'FB2 does not perform well on Espresso'.

 

[diffusionx]

If it was only on PS4, Durango, the weak CPU would be accepted, but they are developing for PS3 and 360, certainly the userbase was enough to overcome the hurdles there.

They won't be developing for PS3 and 360 for that much longer.

 

[Waylon Drums]

Side note: people really need to get over the use of the term "dat" around here. I have an irrational level of hate for slangish terms that stay around well past their expiration dates.

 

[Durante]

Well, if the topic of this discussion was 'DICE guy says they tested Espresso for BF3 prospects and decided platform was not a good fit' I would not have joined the discussion in the first place. The premise of this discussion formed quite differently though - 'FB2 does not perform well on Espresso'.

I think that distinction is meaningless. If games using FB2 (for which BF3 is the most recent and relevant example) fail to perform well on Espresso, then for all intents and purposes FB2 fails to perform well on Espresso. Or would you expect them to port the engine but not the games using it?

 

[Argyle]

Erm, the timing snapshot is for a particular game (BC2@ps3). What the engine requires in terms of vector capabilities is not something you could conclude from that snapshot.

I know how FB operates, thank you very much (for the umpteenth time - check the discussion a few pages ago). The FLOPS workloads that the engine can handle (as in viable throughput), are one thing. The engine's requirements - an entirely different thing. The entire argument started from:

DICE guy: We tried FB2 on the WiiU and it did not perform well.
forumite: It must be the CPU!
me: how come their well-scalable-with-CPUs engine did not perform well? If they say that did not perform well outside of the context of any game, then the engine's requirements alone (read: for doing any meaningful workloads) must be pegged at something akin to 3x PPEs (which was a sarcastic statement on my part, I do not honestly expect that to be the case). And since the only advantage Xenon has over Espresso is (SIMD) FLOPS, that would mean the engine eats a significant amount of FLOPS for breakfast. Like how the software occlusion culling should eat FLOPS on the PS3, but that does not have to be the case on other platforms where the trisetup is on the average twice faster than on the RSX.

It's almost as if you didn't read anything I posted.

(You put me on ignore, didn't you

Let me ask you this: so is your argument that EA and DICE should ship Frostbite on WiiU?

No, not a GAME using Frostbite. Just the engine! Maybe put some gray boxes in there so you have SOMETHING to look at. I bet it would even hit 60fps on WiiU

If you were at DICE doing the evaluation on the WiiU don't you think you would put some actual game content in the engine so that you can see how it performs? Wouldn't that be an important part of the evaluation - how it handles current generation game content?

Isn't it interesting that from the outside looking in, it's easy to come to the same conclusion that DICE did if you look at a lot of the shipped AAA multiplatforms on the system?

(Before I get flamed by a bunch of Nintendo fans - this doesn't mean the WiiU will never get games worth playing or anything. Lots of games have PS2-level complexity gameplay code and will run great on the WiiU - that's not a diss on those games at all! No snarkiness here - all you WiiU fans should probably be rooting for stuff to get ported to Vita because if it can make it there intact, it should be able to make it to the WiiU intact. As an example, look at all the fighting games on Vita, IMHO in general these types of games have low simulation complexity so they should be great on WiiU!)

One'd assume all those things would be subject to scalability, but hey, if you believe they actually pegged their engine at the 3x PPEs ballpark in terms of sheer engine requirements then I have nothing to tell you. We just agree to disagree.

Really, a straw man argument? I'm pretty sure no one you are talking to thinks this. Besides, if this were true then the Xbox version of Battlefield 3 would be a plane with a couple of gray boxes in it.

Believe me, if they wanted to implement Boom Blox: Frosty U edition on Frostbite 3 instead of Battlefield 4, they probably would. But as I mentioned earlier, my guess is that there is no business case for it.

Are you familiar with the concept of throughput versus latency? The smaller the packet, the larger the packet latency overhead per the packet payload. '300 jobs per frame' is ultra-coarse work granularity - games can do thousands of traditional fine-granularity computational routine calls per frame. So, a coarse granularity packet suggest high performance of the individual core. Actually DICE quote re jobs is '15-200k C++ code each. 25k is common'. These are reasonably large routines. Are you starting to see now why I've been asking you about single-thread performance?

Honest question. Do you really think that you will see games distributing jobs in ultra fine grained payloads?

You do realize that any job manager has a certain amount of overhead, right? Even on a platform that doesn't have to DMA local store in and out of its coprocessors. The more often you switch jobs, the more often you incur that overhead, so it makes sense to chunk the work out into reasonably sized payloads to try to maximize throughput.

BTW, are you trying to make the argument that finer grained jobs would perform better on Espresso or is this a Chewbacca defense thing like the CPU scalability/GPU features thing you posted on the last page?

 

[TheGreyHulk]

let's be honest people. we all know why EA doesn't want to waste money getting their go to engine for next gen running on Wii U, the return on investment just isn't there.

EA is looking to cut costs and make money right now and wasting money on the Wii U is pointless when the user base is tiny and it's pretty obvious that nintendo didn't catch lightning in a bottle again.

PS360 can still get ports because the ROI is still there. The user base is massive and they already had previous versions of their engines up and running for years. With the Wii U, it's different. They'd have to spend time and money to get their engine running on it. They tried it and didn't like what they saw. I believe they saw that they would need to spend a decent amount of time to fine tune the engine to run on the system and for what? What game will they release on the Wii U that would give them a decent ROI? Madden? Fifa? Battlefield? Are we honestly going to sit here and realistically say that the people buying a Wii U are doing it for these titles? C'mon man.

If the ROI isn't there, your company shouldn't be there. That's the name of the game and EA is making the right decision. I believe they can get the engine running on it, but it's not worth it plain and simple.

 

[Z3M0G]

let's be honest people. we all know why EA doesn't want to waste money getting their go to engine for next gen running on Wii U, the return on investment just isn't there.

EA is looking to cut costs and make money right now and wasting money on the Wii U is pointless when the user base is tiny and it's pretty obvious that nintendo didn't catch lightning in a bottle again.

PS360 can still get ports because the ROI is still there. The user base is massive and they already had previous versions of their engines up and running for years. With the Wii U, it's different. They'd have to spend time and money to get their engine running on it. They tried it and didn't like what they saw. I believe they saw that they would need to spend a decent amount of time to fine tune the engine to run on the system and for what? What game will they release on the Wii U that would give them a decent ROI? Madden? Fifa? Battlefield? Are we honestly going to sit here and realistically say that the people buying a Wii U are doing it for these titles? C'mon man.

If the ROI isn't there, your company shouldn't be there. That's the name of the game and EA is making the right decision. I believe they can get the engine running on it, but it's not worth it plain and simple.

The unfortunate truth...

 

[blu]

It's almost as if you didn't read anything I posted.

(You put me on ignore, didn't you

Not at all. I'm just still waiting for your response on the subject of PPE's non-SIMD prowess ; )

Let me ask you this: so is your argument that EA and DICE should ship Frostbite on WiiU?

No, my argument is that EA can ship whatever they like on whatever platform they fancy. Neither I'm questioning their motives. I'm just questioning the face-value interpretation of the DICE employee statement.

Honest question. Do you really think that you will see games distributing jobs in ultra fine grained payloads?

You do realize that any job manager has a certain amount of overhead, right? Even on a platform that doesn't have to DMA local store in and out of its coprocessors. The more often you switch jobs, the more often you incur that overhead, so it makes sense to chunk the work out into reasonably sized payloads to try to maximize throughput.

Why, thank you for supporting my side of the argument : ) Even though you somehow got the impression I was arguing the opposite ; )

 

[TheGreatMightyPoo]

Why the fuck are you two arguing about make believe hardware requirements of the Frostbite engine? I am pretty sure if EA big bosses say we want our franchises on this platform they would figure out how.

I highly doubt it's a technical hurdle, but a financial one

And Bingo was his post-o.

 

[Argyle]

Not at all. I'm just still waiting for your response on the subject of PPE's non-SIMD prowess ; )

Is this how you "win" arguments on the internet these days? Sheesh.

I'll play along, though. Which part did I not respond to?

Why, thank you for supporting my side of the argument : ) Even though you somehow got the impression I was arguing the opposite ; )

No, I had no idea what the hell you are talking about as it seemed pretty much irrelevant to the discussion, so I was trying to understand why you were bringing it up. So, what was your point again?

 

[Rolf NB]

Both Bobcat and Bulldozer are pseudo dual core chips, but the implementation is indeed different.

Wtf, no! Bobcat is in no way a dual-core, pseudo-dual-core or anything else beyond single-core. It doesn't even have SMT.

 

[scakko84]

I guess it has more to do with the lousy WiiU's install base than to what the hardware is capable of. If the WiiU had a 20M install base they'd probably be more willing to work out something to improve the performances or invest resources to make a better port of the engine.

I'm a WiiU owner and it sucks a lot seeing so much titles jumping the boat, but thinking from a business point of view makes sense not wasting resources on a platform where revenues are not guaranteed.

 

[wsippel]

Wtf, no! Bobcat is in no way a dual-core, pseudo-dual-core or anything else beyond single-core. It doesn't even have SMT.

Yeah, I noticed a few hours ago. Doesn't matter though because it doesn't change the CoreMark results - which is why I didn't edit my post.

 

[blu]

Is this how you "win" arguments on the internet these days? Sheesh.

I'll play along, though. Which part did I not respond to?

The part about Xenon's computational superiority over Espresso, SIMD non-withstanding. Just give me a bone here, anything.

No, I had no idea what the hell you are talking about as it seemed pretty much irrelevant to the discussion, so I was trying to understand why you were bringing it up. So, what was your point again?

My point was that one cannot say, 'Given that a pool of cores yields a certain amount of FLOPS (x * y = z; x: num_cores, y: single_core_flops), another bigger pool of slower cores yielding the same total amount of FLOPS (a * b = z; a > x, b < y) can be deemed performance-equivalent to the original pool'.

Wtf, no! Bobcat is in no way a dual-core, pseudo-dual-core or anything else beyond single-core. It doesn't even have SMT.

I'm not entirely sure what you're saying, but if it's what it seems to be, here's what a bobcat looks like:

$ grep -A 4 processor /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 20
model		: 2
model name	: AMD C-60 APU with Radeon(tm) HD Graphics
--
processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 20
model		: 2
model name	: AMD C-60 APU with Radeon(tm) HD Graphics

 

[wsippel]

I'm not entirely sure what you're saying, but if it's what it seems to be, here's what a bobcat looks like:

$ grep -A 4 processor /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 20
model		: 2
model name	: AMD C-60 APU with Radeon(tm) HD Graphics
--
processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 20
model		: 2
model name	: AMD C-60 APU with Radeon(tm) HD Graphics

I assumed Bobcat was some sort of "CMT lite" design - which it isn't.

 

[blu]

I assumed Bobcat was some sort of "CMT lite" design - which it isn't.

No, it's literally two brazos cores + a gpu on a die.

ed: Ooops, I was wrong - seems there are single-core bobcat APUs out there just as well! Mea culpa.

 

[Argyle]

The part about Xenon's computational superiority over Espresso, SIMD non-withstanding. Just give me a bone here, anything.

Seriously?

Was it not clear enough from my previous post? It's sheer brute force.

Let's say processing power = clock speed * average work done per clock.

You'll notice that I never disagreed that the Xenon is much less efficient (less work done per clock) compared to the Espresso. But at the same time, it's clocked nearly 3x higher. So basically, in the end, it seems that this is the case:

(3.2Ghz * lower Xenon work per clock) > (1.25Ghz * better Espresso work per clock)

Simple as that.

My point was that one cannot say, 'Given that a pool of cores yields a certain amount of FLOPS (x * y = z; x: num_cores, y: single_core_flops), another bigger pool of slower cores yielding the same total amount of FLOPS (a * b = z; a > x, b < y) can be deemed performance-equivalent to the original pool'.

I do not necessarily have a bone to pick with that, but honestly in my experience most of the jobs that are going to emphasize floating point performance tend towards tasks that have few dependencies against each other (so it is relatively simple to throw more cores at the problem). I think most of the jobs in Frostbite are engineered this way - you can see for yourself by the similarly colored blocks on the timing view screenshot.

I'm still confused at the premise, it seemed like you are the one who is suddenly talking about PS4/Durango, so I'm not sure why you are discussing this in a thread about the WiiU. Do you really think they will port Frostbite from the current generation consoles to next gen console instead of starting from DX11 PC with compute shaders?

Are you aware that there are feature set differences between Frostbite on current gen console and PC?

I have an honest question for you. Do you work on games?

 

[Rolf NB]

I'm not entirely sure what you're saying, but if it's what it seems to be, here's what a bobcat looks like:

I wasn't making myself very clear. Yes, there are dual-core configurations. But a Bobcat core has one instruction pointer, and runs one hardware thread. Completely unlike Bulldozer where two hardware threads are built into the core architecture (1 "module" runs two threads, and there is no such thing as a single-core/single-thread Bulldozer), and also unlike SMT/"HyperThreading" architectures where IP and register state are duplicated, but all execution hardware is shared between two (or more threads).

I think the "dual decoder" thing can easily be misinterpreted as meaning two threads can run simultaneously. But it's really just an increase of hardware resources that all go toward the execution of a single thread per core.

 

[blu]

I wasn't making myself very clear. Yes, there are dual-core configurations. But a Bobcat core has one instruction pointer, and runs one hardware thread. Completely unlike Bulldozer where two hardware threads are built into the core architecture (1 "module" runs two threads, and there is no such thing as a single-core/single-thread Bulldozer), and also unlike SMT/"HyperThreading" architectures where IP and register state are duplicated, but all execution hardware is shared between two (or more threads).

I think the "dual decoder" thing can easily be misinterpreted as meaning two threads can run simultaneously. But it's really just an increase of hardware resources that all go toward the execution of a single thread per core.

Ok, I suspected that was a misunderstanding. Yes, bobcat is as vanilla x86_64 core as they come.

 

[blu]

Seriously?

I saw that post. It does not really answer the question though, just explains how it could be faster. I'm expecting a 'Xenon is faster because such and such characteristics of its pipeline, under such and such conditions'.

I do not necessarily have a bone to pick with that, but honestly in my experience most of the jobs that are going to emphasize floating point performance tend towards tasks that have few dependencies against each other (so it is relatively simple to throw more cores at the problem). I think most of the jobs in Frostbite are engineered this way - you can see for yourself by the similarly colored blocks on the timing view screenshot.

I'm still confused at the premise, it seemed like you are the one who is suddenly talking about PS4/Durango, so I'm not sure why you are discussing this in a thread about the WiiU. Do you really think they will port Frostbite from the current generation consoles to next gen console instead of starting from DX11 PC with compute shaders?

I thought I was bringing up an obvious point to Brad Grenz re how 8 Jaguars are not necessarily immune to not being able to perform on par with 3 PPEs in some intense SIMD scenarios. Little did I know it would get out of hand.

Are you aware that there are feature set differences between Frostbite on current gen console and PC?

Yes.

I have an honest question for you. Do you work on games?

Used to do game engine R&D and maintenance for a living. Not anymore.

ps: apologies for the doublepost.

 

[wsippel]

Was it not clear enough from my previous post? It's sheer brute force.

Let's say processing power = clock speed * average work done per clock.

You'll notice that I never disagreed that the Xenon is much less efficient (less work done per clock) compared to the Espresso. But at the same time, it's clocked nearly 3x higher. So basically, in the end, it seems that this is the case:

(3.2Ghz * lower Xenon work per clock) > (1.25Ghz * better Espresso work per clock)

Simple as that.

The problem is that we don't know the multiplier for Espresso, but if we use CoreMark, and compare a PPE to the 1998 entry-level PowerPC 405 (only 32kB L1, no L2, only one integer unit, no dynamic branch prediction), we get this:

(3.2 * 0.97) : (1.25 * 2.22)

Or:

3,104 : 2.775

The PPE benchmark apparently didn't take SMT into account, so the score should be a few percent higher. Probably around 20 - 30%. Still, considering what the 405 is, it already comes surprisingly close at Espresso clockspeeds. Of course, if we look at SIMD performance, there's no contest - Xenon and CELL mop the floor with Espresso.

 

[TalesOfWin]

That's not this guy's claim though. He seems to be asserting that the engine would need to be massively stripped down (not just optimized) to work on Wii U. That's why this argument is going on.

And apparently armchair gaffers know the frostbite engine better than the technical director himself.

 

[shandy706]

The WiiU struggles with heavy action during single player CoD.

That alone with worry me with BF games.

 

[prag16]

(Before I get flamed by a bunch of Nintendo fans - this doesn't mean the WiiU will never get games worth playing or anything. Lots of games have PS2-level complexity gameplay code and will run great on the WiiU - that's not a diss on those games at all! No snarkiness here - all you WiiU fans should probably be rooting for stuff to get ported to Vita because if it can make it there intact, it should be able to make it to the WiiU intact. As an example, look at all the fighting games on Vita, IMHO in general these types of games have low simulation complexity so they should be great on WiiU!)

I hope you're joking. Your paragraph that allegedly will prevent a bunch of Nintendo fans from flaming you is the part of your post that will likely incite the most flaming from Nintendo fans.

Vita ports? PS2 level complexity? I hope you're joking/trolling. Because if you're serious you have no business even taking part in this discussion. I don't think even Brad Genz would claim Wii U needs things dumbed down to PS2 levels to run properly.

And apparently armchair gaffers know the frostbite engine better than the technical director himself.

I don't think anybody claimed that. Nice straw man.

 

[TheDrowningMan]

The WiiU struggles with heavy action during single player CoD.

That alone with worry me with BF games.

Given that it took 7 years to get something approaching CoD parity with PS3, and the launch-port Wii U version sports better image quality (and fixed resolution) while performing worse in some busy situations (and somewhat better elsewhere) while v-synced, I wouldn't recommend losing sleep over it. Shadows are baked in MP, but I'll see how things are across the board 18 months from now.

Unless we are to assume that it is remarkable for being the first console to be maxed out at launch.

 

[dubq]

Why is the Wii U looking out into the rain? It's stuck inside the house?

edit: Wait, I guess the pad would be reversed if that were the case. But then why is the controller semi-transparent/turning invisible?

dem photoshop layer blends

 

[Schnozberry]

The PPE benchmark apparently didn't take SMT into account, so the score should be a few percent higher. Probably around 20 - 30%. Still, considering what the 405 is, it already comes surprisingly close at Espresso clockspeeds. Of course, if we look at SIMD performance, there's no contest - Xenon and CELL mop the floor with Espresso.

Perhaps I'm mistaken, but don't Cell and Xenon PPE cores mop the floor with a Jaguar as well, in terms of peak FLOPS?

 

[Argyle]

I saw that post. It does not really answer the question though, just explains how it could be faster. I'm expecting a 'Xenon is faster because such and such characteristics of its pipeline, under such and such conditions'.

How about this, which I thought was implicit in my response:

"It would seem that on a real-life, well-parallelized workload on a production game, which is comprised of a mix of floating point and integer work,

(3.2Ghz * lower average Xenon work per clock) > (1.25Ghz * better Espresso average work per clock)"

My guess is that when DICE did their testing "production game" was likely "Battlefield 3" (they did say the test was done on FB2). I'm sure they could get the engine to work but they would have to produce an entirely unique game in order to get it to run well (or gimp the version on the current generation consoles so that they can achieve parity) - both decisions have their costs.

Yes.


Used to do game engine R&D and maintenance for a living. Not anymore.

That is more or less my job description as well - although I don't generally work on engines absent an actual game on top of it. Did you never work on an actual game, only support for the engine? I'm just wondering how you came to the conclusion that the gameplay code was going to be scalable?

I hope you're joking. Your paragraph that allegedly will prevent a bunch of Nintendo fans from flaming you is the part of your post that will likely incite the most flaming from Nintendo fans.

Vita ports? PS2 level complexity? I hope you're joking/trolling. Because if you're serious you have no business even taking part in this discussion. I don't think even Brad Genz would claim Wii U needs things dumbed down to PS2 levels to run properly.

Sheesh, so angry. All I was trying to say is this - the amount of CPU power your game uses does not necessarily make your game more awesome as far as gameplay. The WiiU has a lot of potential for cool stuff, but I think the potential is not going to be based on how many doohickeys you can simulate on the CPU at once. Some games have a higher minimum baseline CPU requirement and it looks like the WiiU will not make the cut for those games even if they are already targetted at current generation consoles, which is unfortunate - too bad Nintendo couldn't have clocked the CPU higher or whatever. I mean, honestly Nintendo hasn't even started to bring it as far as games yet? Why did you buy your WiiU if it wasn't for Nintendo games - those games have never been about pushing the tech envelope, right?

I'm heartened by Nintendo opening up to indie developers. I'm hopeful that we will see some really clever ideas coming from those guys.

I haven't bought a WiiU yet as there are no games (IMHO) that are tapping into that potential, but once the games come, I'm sure I'll pick one up.

 

[TalesOfWin]

I don't think anybody claimed that. Nice straw man.

this thread seems to have a lot of baseless claims though.

Repi said test results were not promising and unless someone here has extensive knowledge of the FB engine, he cant be proven wrong.

 

[Durante]

Perhaps I'm mistaken, but don't Cell and Xenon PPE cores mop the floor with a Jaguar as well, in terms of peak FLOPS?

No, an 8 core Jaguar at 1.8 Ghz is pretty much on par with Xenon in that metric.

this thread seems to have a lot of baseless claims though.

Repi said test results were not promising and unless someone here has extensive knowledge of the FB engine, he cant be proven wrong.

Yeah, and why would he be wrong? Everything (their statements, presentations, and the performance of FB games on PS3 and various PC CPUs) points to FB games making great use of parallel CPU SIMD FLOPS. Which the Wii U lacks in. Greatly.

 

[TalesOfWin]

Yeah, and why would he be wrong? Everything (their statements, presentations, and the performance of FB games on PS3 and various PC CPUs) points to FB games making great use of parallel CPU SIMD FLOPS. Which the Wii U lacks in. Greatly.

He isn't wrong but some people seems to refuse to believe the cold truth. Hey I have a Wii U and all but I didn't really bought it for the 3rd party games.