Wii U CPU |Espresso| Die Photo - Courtesy of Chipworks

I'm still having trouble understanding where the limits of the CPU are.
The limits of the CPU are usually found in the brochure. It's usually finding how it performs in practice that is the interesting question.
 
I'm still having trouble understanding where the limits of the CPU are. If they could port Call of Duty, Skylanders and NFS carbon to the Wii, then why are they having problems on CPU that's all around better?

There are too many things not adding up about this CPU rhetoric.


I'm not going to judge developers on better looking games coming to the u when they said theirs could not; different game engines are different. And we, of all people, know how different CPU characteristics can be. So one game runs great on the U, another cannot, does that mean it's a shitty porting job? No, perhaps game A just needed short pipelines for lots of messy pointer heavy code most, while game B needed lots of CPU-side SIMD (which can't all be offset to the GPU) which just wasn't there. Who the heck knows.
 
How does the Expresso stack up against the Jaguar Cores in the XBox performance wise?

My understanding is that the Jaguar cores are low power, designed to compete against ARM chips and thus more likely to be seen in cheap netbooks than desktops.
 
I'm still having trouble understanding where the limits of the CPU are. If they could port Call of Duty, Skylanders and NFS carbon to the Wii, then why are they having problems on CPU that's all around better?

There are too many things not adding up about this CPU rhetoric.
You are assuming that the Wii ports were at feature parity to the PC versions. They probably were not; with dumbed down AI, physics and multi-player.
 
You are assuming that the Wii ports were at feature parity to the PC versions. They probably were not; with dumbed down AI, physics and multi-player.

the wii had some pretty physics heavy games (elebits for instance) also ai is general purpose code which the wii and wii u excel at
 
How does the Expresso stack up against the Jaguar Cores in the XBox performance wise?

My understanding is that the Jaguar cores are low power, designed to compete against ARM chips and thus more likely to be seen in cheap netbooks than desktops.

Bobcat was higher performing than Atom, Atom was higher performing than most ARM chips, Jaguar is higher performing than Bobcat. Jaguar has a lot more going for it than a base PPC750 core at the very least, a LOT more. AMD doubled the width of its FPU pipelines from 64-bit to 128-bit. The 750 also has 64 bit pipelines. It can do 256 bit AVX, has much larger branch prediction structures, etc etc. The 750 is probably the closer one of the two to modern ARM cores.

Yes Jaguar will go to cheap netbooks, they won't have 8 of them though, and the PPC750 has been used in ultra low power embedded uses, that doesn't mean they can't be used well in consoles.
 
Bobcat was higher performing than Atom, Atom was higher performing than most ARM chips, Jaguar is higher performing than Bobcat. Jaguar has a lot more going for it than a base PPC750 core at the very least, a LOT more. AMD doubled the width of its FPU pipelines from 64-bit to 128-bit. The 750 also has 64 bit pipelines. It can do 256 bit AVX, etc etc. The 750 is probably the closer one of the two to modern ARM cores.
The 750 is a line of processors that goes from early 1997 iterations to the newest one in form of the Espresso.
You can't grab a CPU without on-die L2 cache like the first 750 and put it at the same level than Espresso, which has 3MB of it.
You can't grab the first 750 FPU and put it at the same level of the GC one which introduced Paired Singles operations and boosted it's FP capability even to a higher level than Bobcat in a per clock basis.

And we still don't know to which extend the WiiU CPU, apart from the eDram, the clock increase or the 3 cores, has evolved in comparison to Broadway. Newer speculations points towards more registers for both general purpose and floating point code, which would have a considerable impact in the general efficiency of the processor.
 
The 750 is a line of processors that goes from early 1997 iterations to the newest one in form of the Espresso.
You can't grab a CPU without on-die L2 cache like the first 750 and put it at the same level than Espresso, which has 3MB of it.
You can't grab the first 750 FPU and put it at the same level of the GC one which introduced Paired Singles operations and boosted it's FP capability even to a higher level than Bobcat in a per clock basis.

And we still don't know to which extend the WiiU CPU, apart from the eDram, the clock increase or the 3 cores, has evolved in comparison to Broadway. Newer speculations points towards more registers for both general purpose and floating point code, which would have a considerable impact in the general efficiency of the processor.

Incredible. So Expresso is more powerful than we think.
 
Bobcat was higher performing than Atom, Atom was higher performing than most ARM chips, Jaguar is higher performing than Bobcat. Jaguar has a lot more going for it than a base PPC750 core at the very least, a LOT more. AMD doubled the width of its FPU pipelines from 64-bit to 128-bit. The 750 also has 64 bit pipelines. It can do 256 bit AVX, etc etc. The 750 is probably the closer one of the two to modern ARM cores.
This is a bunch of suppositions there. How about some simple facts?

1. ppc750cl @ 1.24GHz performs on part with bobcat 1.6GHz at such a quintessential SIMD task as 4x4 mat multiplications.
2. Jaguar does not feature 256-bit SIMD - it's 128-bit. That is still twice as much as Bobcat's 64-bit, but let's not pretend it's as good as 256-bit SIMD.
3. Atom performing higher than 'most ARM' chips is a nil statement. What are most ARM chips? V5? V6? V7? A8? A9? Most A9 surely beat most Atoms that I've seen.

You seem to have some rosy idea of Bobcat, and by extension, of Jaguar. Whereas in reality those are netbook chips. At the end of the day both Espresso and Jaguar are close enough to 'modern ARM cores' that you could not tell in advance with absolute certainty which would top which at what task.
 
I don't think the architecture is a problem. If Nintendo was really worried about performance of the CPU or GPU, they would of just not used such old node processes. Espresso at 28nm could likely achieve 1.6GHz quite easily, have a much lower power consumption, even adding a 4th core wouldn't of been hard. SIMD support being off loaded to the GPU is where the industry seems to be going, the main reason this hasn't happened yet is Intel's ability in that regard has been slow to adapt, but they will be there over the next few years.

Likewise moving the GPU down to 28nm would allow it to have even 640ALUs at a similar (though higher) power consumption. They could probably stay below 50watts and have .9 to 1TFLOPs of performance from that chip.

.

Wasn't 28 nm unavailable to them with all the problems it had in mid 2012? And after the problems were solved, would they have the priority for buying 28 nm chips when mobile market is more important (without omitting nVidia/AMD which already had contracts)?
 
Incredible. So Expresso is more powerful than we think.
Well, it's not that incredible. It's just that Nintendo has customized their CPUs with each iteration, and since the foundation was pretty robust already, the resulting CPU can still be excellent at performing what Nintendo wants it to perform.

Those claims about 1997 hardware is just trolling or people that doesn't have even the slightest idea of what are talking about. I'm not an expert by any means, of course, but at least I try to be objective here.
 
This is a bunch of suppositions there. How about some simple facts?

1. ppc750 @ 1.24GHz performs on part with bobcat 1.6GHz at such a quintessential SIMD task as 4x4 mat multiplications.
2. Jaguar does not feature 256-bit SIMD - it's 128-bit. That is still twice as much as Bobcat's 64-bit, but let's not pretend it's as good as 256-bit SIMD.
3. Atom performing higher than 'most ARM' chips is a nil statement. What are most ARM chips? V5? V6? V7? A8? A9? Most A9 surely beat most Atoms that I've seen.

You seem to have some rosy idea of Bobcat, and by extension, of Jaguar. Whereas in reality those are netbook chips. At the end of the day both Espresso and Jaguar are close enough to 'modern ARM cores' that you could not tell in advance with absolute certainty which would top which at what task.

It does 256 bit AVX through 2x128, I should have specified, but it does at least support AVX.

A9s beating Atom? Not in my universe. Medfield was lower performing than netbook Atoms, yet it beat every A9 out there not just per core per clock, but with just ONE core vs two a9s. . Bobcat beats Atom per core per clock. A15s beating Atom, I would believe. Until Silvermont at least.


I know browser benchmarks aren't ideal, but they're all consistent with each other (as in no funky benchmark optimizations), and running the same Android:

43533.png


43534.png


I'm perfectly aware that the 750-based core in the Wii U is not exactly a 750. It's also true that Jaguar in the PS4/One won't be exactly like the netbook implementations. None of them will have 4MB cache no doubt, etc. I can't speak to the enhancements any more than anyone here can. I'm just going off what we do know.

4x4 matrix multiply is a bit simplistic, here's POVray on the 750 and Bobcat:

http://forums.anandtech.com/showthread.php?t=2251730

http://hothardware.com/Reviews/AMD-...mance-Preview/default.aspx?page=4&PageIndex=2

I don't have rosy ideas of anything, I know where Jaguar comes from. But dismissing that for coming from netbooks is no better than dismissing the 750 from coming from ultra low power embedded use cases.
 
Heck, hear it from Anand himself:
For the next few months though, AMD will enjoy a position it hasn’t had in years: a CPU performance advantage.

(compared to Atom he means, which no one can reasonably deny was higher up than A9)


And another article, with direct Jaguar to Atom benchmarks, Atom is decimated.

http://www.anandtech.com/show/6974/amd-kabini-review/3


The 1.7GHz Ivy Bridge part is obviously quicker, but what's interesting is that if we limit the IVB CPU's frequency to 800MHz Kabini is actually a near identical performer.

And to put any end to the doubt about A9s being better:

Seeing as how Bobcat was already quicker than ARM's Cortex A15, its no surprise that Jaguar is as well.



So to sum it all up, my assertion that you tried to deny was correct, Jaguar > Bobcat > Atom > A9, and not only that but Jaguar has a huge lead over A15 too.
I'll bring the "simple facts", you bring the potato chips :P
 
It does 256 bit AVX through 2x128, I should have specified, but it does at least support AVX.
AVX surely should improve the efficiency of the SIMD block, if nothing else for the 3-argument model alone, but N-way ALUs are N-way ALUs. Whatever the ISA presents those as comes secondary. For instance, ARM's traditional VFPU can perform single-instruction operations on up to 8-way vectors in the form of chains of scalars, IIRC. Unfortunately that's not such a big deal when the ALU is 1-way and it has to do N passes to account for those N registers. Enter NEON.

A9s beating Atom? Not in my universe. Medfield was lower performing than netbook Atoms, yet it beat every A9 out there not just per core per clock, but with just ONE core vs two a9s. . Bobcat beats Atom per core per clock. A15s beating Atom, I would believe. Until Silvermont at least.

I know browser benchmarks aren't ideal, but they're all consistent with each other (as in no funky benchmark optimizations), and running the same Android:

43533.png


43534.png
Saying a JavaScript benchmark is not an ideal test for A9s is a severe understatement. Those CPUs are not even running the same engine - [ed: my bad - SunSpider does seem to be based on one particular JS engine; I still think JS tests are not a good datapoint though; see further] - traditionally, in real-world scenarios for x86 it's normally Google's excellent V8, whereas for A9 it's whatever the cat dragged home today. Are we trying to measure CPUs or Javascript performances?

I'm perfectly aware that the 750-based core in the Wii U is not exactly a 750. It's also true that Jaguar in the PS4/One won't be exactly like the netbook implementations. None of them will have 4MB cache no doubt, etc. I can't speak to the enhancements any more than anyone here can. I'm just going off what we do know.
If cache is all it take for you, you forgot Espresso also has a unique cache setup.

While the test is relevant, it was run on god-knows-what 750. Not all 750s are created equal. Gekko (and by extension Espresso) have improvements in both scalar and vector fp form. The good thing about 'simplistic' tests is that you know fairly well what you're measuring. Do you know where the common bottlenecks of that POV test are? Is it fp? Is it caching? Does it use SIMD at all?

I don't have rosy ideas of anything, I know where Jaguar comes from. But dismissing that for coming from netbooks is no better than dismissing the 750 from coming from ultra low power embedded use cases.
I'm not dismissing Jaguar by any stretch of the imagination - I think Bobcats are good CPUs for their class. I'm saying you need to check your datapoints before pronouncing a CPU of a given class a clear winner over another CPU of the same class.


Heck, hear it from Anand himself:
<snip>
So to sum it all up, my assertion that you tried to deny was correct, Jaguar > Bobcat > Atom > A9, and not only that but Jaguar has a huge lead over A15 too.
I'll bring the "simple facts", you bring the potato chips :P
You're getting way ahead of yourself. Now, before you bring up yet another googlesearched 'proof', would you care to slow down and try to analyze what each of those demonstrate? You do realize that it can be as trivial as a lack of compiler fine-tunning support for any given architecture and the relevance of any of those tests can fly out the window, right?
 
Wasn't 28 nm unavailable to them with all the problems it had in mid 2012? And after the problems were solved, would they have the priority for buying 28 nm chips when mobile market is more important (without omitting nVidia/AMD which already had contracts)?

32nm was far more widely available, and 28nm had been used for over a year by the time Wii U launched, I doubt it would of had a problem but 32nm solves all of those things too and would of brought Wii U's price down overall, even at the exact same tech specs it is at now, it's TDP would of come down to nearly Wii's.
 
If cache is all it take for you, you forgot Espresso also has a unique cache setup.

...All I meant by bringing up the cache was that it is unique, arguing for 750 enhancements is on equal footing to arguing for Jaguar enhancements in the PS4/One. I'm sure you understood what I meant, lets not be facetious.

And Espressos "unique" cache setup is still 1MB short of them (3 vs 4MB).If you mean the eDRAM on the GPU to be additional CPU cache, that's a lot of added cycles even with how close they are for one, and two the One also has eSRAM on the same DIE, not just package. The cache per core argument has been used, but I'd take a dual core with 12MB cache over a single core with 12MB all else being equal, even though the latter has twice the cache per core.


Look up other benchmarks of Medfield vs A9s then, the performance characteristics carry over from the browser tests.
 
...All I meant by bringing up the cache was that it is unique, arguing for 750 enhancements is on equal footing to arguing for Jaguar enhancements in the PS4/One. I'm sure you understood what I meant, lets not be facetious.

And Espressos "unique" cache setup is still 1MB short of them (3 vs 4MB).If you mean the eDRAM on the GPU to be additional CPU cache, that's a lot of added cycles even with how close they are for one, and two the One also has eSRAM on the same DIE, not just package. The cache per core argument has been used, but I'd take a dual core with 12MB cache over a single core with 12MB all else being equal, even though the latter has twice the cache per core.


Look up other benchmarks of Medfield vs A9s then, the performance characteristics carry over from the browser tests.
No, it's not. Jaguar's 4MB of cache is simply 2x the amount the cache on 4 core configurations, so double the cores -> double the cache is what we already expect when we talk about an 8 core configuration.
Of course, 4MB divided by 8 means 512KB per core, which is the same as the Espresso's secondary cores and 4 times less than Espresso's main core.

When you compare the Espresso to normal 1997 PPC 750 you are ignoring what has been a decade of evolutions, improvements and customizations.
 
...All I meant by bringing up the cache was that it is unique, arguing for 750 enhancements is on equal footing to arguing for Jaguar enhancements in the PS4/One. I'm sure you understood what I meant, lets not be facetious.

And Espressos "unique" cache setup is still 1MB short of them (3 vs 4MB).If you mean the eDRAM on the GPU to be additional CPU cache, that's a lot of added cycles even with how close they are for one, and two the One also has eSRAM on the same DIE, not just package. The cache per core argument has been used, but I'd take a dual core with 12MB cache over a single core with 12MB all else being equal, even though the latter has twice the cache per core.


Look up other benchmarks of Medfield vs A9s then, the performance characteristics carry over from the browser tests.

The cache isn't unique, it's 512kb per core, same as vanilla jaguar. Also during the PS4 event I believe, AMD stated that they will release an APU that has the same CPU that is in PS4 this year. Doesn't strictly state that it will be 8 cores, but that has little to do with architecture comparisons. The cache per core for PS4 and XB1 is less than or equal to Wii U's espresso cores, the main Wii U core happens to have 4x the cache of any PS4/XB1 core. If all we are talking about is architecture, Wii U's espresso has more cache feeding its cores than Jaguar.

Truth is FP operations are slowly being moved to GPUs more and more, this generation should see a huge push to that end from a game development perspective I believe, who knows how relevant GFLOP numbers will be for a CPU in 5 years as PCs will have APUs that have blended the GPU and CPU together at an even deeper level than they are now.
 
This long term planning has paid off for Nintendo with backwards
compatibility and pushing the boundaries of efficiency without sacrificing
decent & reliable performance. And most likely keeping costs
relatively low in production.

In conclusion, I think its foolish to underestimate Expresso.
This CPU is definitely not an off the shelf solution if we consider its an
evolution since the Gamecube. A lot of thought and design went into
making the product.

No, it's the complete opposite. Sony and Microsoft understood that the solutions they picked before was wrong for the long term - so they did the sensible thing and changed them. I bet this wasn't the easiest decision, especially with Sony and cell.

Nintendo is stuck in an old architecture.

The shittiest thing is that they have a CPU that is so old it's probably possible to emulate it if they just go for a modern and fast architecture. But no, they didn't. They took the easy way out, and made porting a lot (not all) engines even from 360/PS3 hard, and the next generation even harder. Stupid decision, that they are paying for now.
 
No, it's the complete opposite. Sony and Microsoft understood that the solutions they picked before was wrong for the long term - so they did the sensible thing and changed them. I bet this wasn't the easiest decision, especially with Sony and cell.

Nintendo is stuck in an old architecture.

The shittiest thing is that they have a CPU that is so old it's probably possible to emulate it if they just go for a modern and fast architecture. But no, they didn't. They took the easy way out, and made porting a lot (not all) engines even from 360/PS3 hard, and the next generation even harder. Stupid decision, that they are paying for now.
Seriously, it's a custom architecture at this point and fits inside Wii U's design. It's not the fastest system and it isn't trying to be, but compared to jaguar, it's not completely outclassed except in floating point operations, and that generally is handled better on a GPU anyways. I know you want to have your opinion heard but maybe you should realize that PS4/XB1 didn't pick high end CPUs for their boxes, they picked probably the cheapest option they could of gone with per core and simply taped 2 jaguars together. Remember AMD did come out and say they will release the CPU later this year that PS4 is using, while it probably isn't going to be 8 cores (though who knows?) it is going the be the same bargain CPU you'll find in many netbooks around xmas. So yes Espresso isn't i7 but it is actually very close to what jaguar ended up being, certainly in line with the rest of the specs Wii U has when compared to XB1.
 
No, it's the complete opposite. Sony and Microsoft understood that the solutions they picked before was wrong for the long term - so they did the sensible thing and changed them. I bet this wasn't the easiest decision, especially with Sony and cell.

Nintendo is stuck in an old architecture.

The shittiest thing is that they have a CPU that is so old it's probably possible to emulate it if they just go for a modern and fast architecture. But no, they didn't. They took the easy way out, and made porting a lot (not all) engines even from 360/PS3 hard, and the next generation even harder. Stupid decision, that they are paying for now.
This is not how it works. Sony and Microsoft HAD TO change architectures because their CPU designs were awful, it had nothing to do with when those CPUs where released. This is why they had to change the architecture from the foundations.

Nintendo is using, since the GC, a pretty solid architecture which can be evolved to achieve their goals, which is, great performance per watt.

Intel also had to abandon their P4 strategy and re-design their P3s in order to evolve to where they wanted to go, and this doesn't mean that the Core 2 series were inferior to the P4 ones, which was a bad design decision made by Intel and also IBM on the PS3/60 CPUs.
 
Nintendo is stuck in an old architecture.

The shittiest thing is that they have a CPU that is so old it's probably possible to emulate it if they just go for a modern and fast architecture. But no, they didn't. They took the easy way out, and made porting a lot (not all) engines even from 360/PS3 hard, and the next generation even harder. Stupid decision, that they are paying for now.


Well seeing how XboxOne & PS4 are getting negative responses for their lack of
backwards compatibility, I think Nintendo did the smart thing. And, it has been
mentioned many times now, its a custom chip; it has modern features; its been
designed to work with a newly designed custom GPU.

Nintendo is not stuck with old architecture, Nintendo, when they were working on the Gamecube, probably had probably had put together a twenty year roadmap.
 
http://forums.anandtech.com/showthread.php?t=2251730
Core i5 3317U (1.7 GHz): 199.26 pps ; 117.21 pps/GHz
PowerPC 750 (700 MHz): 20.47 pps ; 29.25 pps/GHz
Pentium !!! (450 MHz): 2.43 pps ; 27.62 pps/GHz
Atom N270 (1.6 GHz): 28.96 pps ; 18.10 pps/GHz
I find that pretty interesting, the PowerPC 750 is quite a bit more efficient than the Atom in that case. If it was clocked at 1.2Ghz, it would have a significantly better score, not to mention any changes the cache would make.

PIII is not too bad for efficiency, and the reason why Intel went back to it, when they developed the core series.

750 @ 1.2 * 3 cores theoretically would be around 105, which is half a single i5 thread... he he, I kinda wish Nintendo went with a low spec i5 clocked at 700 mhz instead :)
 
I find that pretty interesting, the PowerPC 750 is quite a bit more efficient than the Atom in that case. If it was clocked at 1.2Ghz, it would have a significantly better score, not to mention any changes the cache would make.

PIII is not too bad for efficiency, and the reason why Intel went back to it, when they developed the core series.

750 @ 1.2 * 3 cores theoretically would be around 105, which is half a single i5 thread... he he, I kinda wish Nintendo went with a low spec i5 clocked at 700 mhz instead :)

http://macspeedzone.com/archive/4.0/g4vspent3signal.html
 
Do they? Here's a CoreMark for you:
4HhCCjj.gif

I'll concede that I underestimated A9s compared to Atom, they do trade blows in other tests however. But my whole point in bringing Atom into this at all was the comparison of Jaguar to ARM cores. That still remains. Bobcat is still faster than A15 by Anands own statement, which was faster than A9. Jaguar is faster than bobcat in single threads by a good margin for CPUs, 22% on average. Bobcat already led A15 by a margin. So it follows that Jaguar is not in the same ballpark as present day ARM cores, it's closer to them than an i7, sure, but it's still way above them.

If it pleases you, I'll ammend Jaguar > Bobcat > Atom > A9 to Jaguar > Bobcat > A15 > A9 > Atom :P
 
The cache isn't unique, it's 512kb per core, same as vanilla jaguar. Also during the PS4 event I believe, AMD stated that they will release an APU that has the same CPU that is in PS4 this year. Doesn't strictly state that it will be 8 cores, but that has little to do with architecture comparisons.



As far as I know, all they said was "similar", and we knew something like that would come out anyways unless they suddenly decided to roll over and not release next gen Jaguar APUs.

http://www.pcworld.com/article/2029...based-on-modified-playstation-4-hardware.html


And they sure say custom a lot.
http://www.tomshardware.com/news/Xbox-One-APU-Jaguar-Radeon-Next-Generation,22726.html


This really is fascinating, I never denied the PPC750-like CPU in the U could be a very customized part (and indeed, that's what everyone has been going with this whole time), but the second I bring the suggestion up for consoles from two companies very capable of chip customization it's opposed. Sony in particular has done a lot of their own chip design before.
 
As far as I know, all they said was "similar", and we knew something like that would come out anyways unless they suddenly decided to roll over and not release next gen Jaguar APUs.

http://www.pcworld.com/article/2029...based-on-modified-playstation-4-hardware.html


And they sure say custom a lot.
http://www.tomshardware.com/news/Xbox-One-APU-Jaguar-Radeon-Next-Generation,22726.html


This really is fascinating, I never denied the PPC750-like CPU in the U could be a very customized part (and indeed, that's what everyone has been going with this whole time), but the second I bring the suggestion up for consoles from two companies very capable of chip customization it's opposed. Sony in particular has done a lot of their own chip design before.
It's not opposed, it's criticized because you make an apple to orange comparison.
You say: The WiiU is a 1997 CPU with modifications, and the PS4/XBone will have 2012 CPUs also modified (at least, to double the number of cores), so the difference between them is still of 15 years.

It's obvious that the WiiU has been MUCH-MUCH-MUCH more customized/evolved compared to the original PPC750 than PS4/XBOne CPU's compared to Jaguar.
 
As I said in another thread, bobcat (and therefore jaguar) has roots that go all the way back to k5. This isn't an uncommon thing in the world of CPUs, and the age of the underlying architecture is not what you should judge CPUs on.
 
You say: The WiiU is a 1997 CPU with modifications, and the PS4/XBone will have 2012 CPUs also modified (at least, to double the number of cores), so the difference between them is still of 15 years.

...No. No I do not say that.

The PPC750 has been used as recently as 2004 by the way. And as mentioned the Jaguar does go back to K5.

http://en.wikipedia.org/wiki/PowerPC_7xx#PowerPC_750GX

But this is all silly anyways, since when do dates of conception equate to how much a company may have modified a core?
 
This is not how it works. Sony and Microsoft HAD TO change architectures because their CPU designs were awful, it had nothing to do with when those CPUs where released. This is why they had to change the architecture from the foundations.

Nintendo is using, since the GC, a pretty solid architecture which can be evolved to achieve their goals, which is, great performance per watt.

Intel also had to abandon their P4 strategy and re-design their P3s in order to evolve to where they wanted to go, and this doesn't mean that the Core 2 series were inferior to the P4 ones, which was a bad design decision made by Intel and also IBM on the PS3/60 CPUs.

Well seeing how XboxOne & PS4 are getting negative responses for their lack of
backwards compatibility, I think Nintendo did the smart thing. And, it has been
mentioned many times now, its a custom chip; it has modern features; its been
designed to work with a newly designed custom GPU.

Nintendo is not stuck with old architecture, Nintendo, when they were working on the Gamecube, probably had probably had put together a twenty year roadmap.

There's more to it than backwards compatibility.

AMD provided them with the best heterogeneous solution.

Also, the switch to x86 should make ports between the Sony, MS and PC platforms a lot easier. The WiiU will have to contend with being a rung lower as well as having a different architecture.

Besides, it's not like PowerPC is without issues (i. e. poor performance scaling at higher power/temp).

The Atom discussion overlooks the imminent update, which looks to be a Core-level revamp, with all the tick-tock updates entailed.
 
You are assuming that the Wii ports were at feature parity to the PC versions. They probably were not; with dumbed down AI, physics and multi-player.

Where have i said anything about a PC? No console can match the PC version of anything. That's why I do most of my gaming on the PC.

Also, how did multiplayer fit into that equation?
 
...No. No I do not say that.

The PPC750 has been used as recently as 2004 by the way. And as mentioned the Jaguar does go back to K5.

http://en.wikipedia.org/wiki/PowerPC_7xx#PowerPC_750GX

But this is all silly anyways, since when do dates of conception equate to how much a company may have modified a core?
WoW I got confused because on the GPU thread there was a little talk about the CPU and there was people saying that PPC 750 is equivalent to a Pentium II and so the WiiU CPU was.
Sorry!
 
The PPC's destroyed the Pentiums clock for clock. All of them. Whoever said that was just trying to down talk the CPU without knowing much about what they were talking about.

The "basic" PPC740 outperformed the Pentium 2. The PPC750 outperformed the Pentium III. The PPC750CL's are what the Nintendo CPU's were based on . Gekko, Broadway and Espresso, which are all modified versions, are quite a distance ahead of that.
 
WoW I got confused because on the GPU thread there was a little talk about the CPU and there was people saying that PPC 750 is equivalent to a Pentium II and so the WiiU CPU was.
Sorry!

Not a problem, I was so confused where you were coming from though haha.
 
If you'll allow me to put some fuel in the fire

hardware-assisted memory compression that reduces memory requirements,

http://www.ibmsystemsmag.com/aix/trends/IBM-Announcements/new_power7/

Now, Power7+ is substantially different than Espresso of course but their developments would have overlapped, and even though we know the core types are not Power7/+ this technology would certainly be interesting in the Wii U.


http://www-03.ibm.com/systems/power/hardware/whitepapers/am_exp.html


http://domino.research.ibm.com/comm/wwwr_thinkresearch.nsf/pages/memory200.html
 
If you'll allow me to put some fuel in the fire



http://www.ibmsystemsmag.com/aix/trends/IBM-Announcements/new_power7/

Now, Power7+ is substantially different than Espresso of course but their developments would have overlapped, and even though we know the core types are not Power7/+ this technology would certainly be interesting in the Wii U.


http://www-03.ibm.com/systems/power/hardware/whitepapers/am_exp.html


http://domino.research.ibm.com/comm/wwwr_thinkresearch.nsf/pages/memory200.html

It would certainly throw more credence to the possibility that Expresso has Power7 functionality in it and explain the "Wii U is using Watson's brain" messages.
 
It would certainly throw more credence to the possibility that Expresso has Power7 functionality in it and explain the "Wii U is using Watson's brain" messages.

Not completely, Power7 powers the Watson, this hardware memory compression feature came out with Power7+. The Power7 can do software memory compression, but the hardware one is understandably the one worth using as it doesn't waste compute resources, especially as the Espresso is clocked so much lower than Power7 models to start with. From the first link:

The memory compression accelerator is a significant advancement over previous software-enabled memory compression. With a hardware assist, compression processing can be performed on the chip itself, which boosts efficiency and allows more cycles to be available to process other workload demands.
 
If you'll allow me to put some fuel in the fire



http://www.ibmsystemsmag.com/aix/trends/IBM-Announcements/new_power7/

Now, Power7+ is substantially different than Espresso of course but their developments would have overlapped, and even though we know the core types are not Power7/+ this technology would certainly be interesting in the Wii U.


http://www-03.ibm.com/systems/power/hardware/whitepapers/am_exp.html


http://domino.research.ibm.com/comm/wwwr_thinkresearch.nsf/pages/memory200.html
Good fine, Tipoo. It should be possible.
 
Not completely, Power7 powers the Watson, this hardware memory compression feature came out with Power7+. The Power7 can do software memory compression, but the hardware one is understandably the one worth using as it doesn't waste compute resources.
Gekko/ Broadway/ 750CL/ Espresso all have a similar feature, IBM designed it for Nintendo back in 1999. In this specific case, it's used to compress two to four 32bit floats into a single 32bit integer if I remember correctly. One of several weird Nintendo specific PowerPC extensions. Another odd feature is locked L1d DMA. Simply put, Nintendo PPCs have two busses: The standard FSB for both data and instructions, as well as a secondary, independent data bus that can directly read from or write to L1d (but only if L1d locking is enabled). Don't think any compiler automatically optimizes for those features, they require assembly routines.
 
Gekko/ Broadway/ 750CL/ Espresso all have a similar feature, IBM designed it for Nintendo back in 1999. In this specific case, it's used to compress two to four 32bit floats into a single 32bit integer if I remember correctly. One of several weird Nintendo specific PowerPC extensions. Another odd feature is locked L1d DMA. Simply put, Nintendo PPCs have two busses: The standard FSB for both data and instructions, as well as a secondary, independent data bus that can directly read from or write to L1d (but only if L1d locking is enabled). Don't think any compiler automatically optimizes for those features, they require assembly routines.

This is a different and new technology, the hardware DRAM compression on the processor die was only added with the most recent Power7+ refresh. Not in 1999, this year. I was not aware of Nintendos form of compression, but I feel sure this isn't that, this lets Power7+ double how much data is stored in DRAM with no performance penalty, and in all the years of Nintendo hardware I've never heard so crazy a claim as that.

I wouldn't even pretend I could guess the chances of it being in the Wii U, but if I'm going to read too deeply into that "unlimited memory" comment from that developer like everyone else this new technology would be my prime suspect :P
 
Gekko/ Broadway/ 750CL/ Espresso all have a similar feature, IBM designed it for Nintendo back in 1999. In this specific case, it's used to compress two to four 32bit floats into a single 32bit integer if I remember correctly. One of several weird Nintendo specific PowerPC extensions. Another odd feature is locked L1d DMA. Simply put, Nintendo PPCs have two busses: The standard FSB for both data and instructions, as well as a secondary, independent data bus that can directly read from or write to L1d (but only if L1d locking is enabled). Don't think any compiler automatically optimizes for those features, they require assembly routines.

Sounds pretty interesting
 
This is a different and new technology, the hardware DRAM compression on the processor die was only added with the most recent Power7+ refresh. Not in 1999, this year. I was not aware of Nintendos form of compression, but I feel sure this isn't that, this lets Power7+ double how much data is stored in DRAM with no performance penalty, and in all the years of Nintendo hardware I've never heard so crazy a claim as that.
It's obviously not the same feature, but I don't think that POWER7+ feature would add anything in a gaming context.
 
Doubling the RAM capacity for free?
That works on the systems POWER is designed for, it wouldn't work on a system like Wii U. Most of the data stored in RAM on Wii U is GPU bound, so routing everything through the CPU wouldn't help. Also, the data on Wii U is usually already compressed, and the entropy of compressed data makes further compression impossible.
 
That works on the systems POWER is designed for, it wouldn't work on a system like Wii U. Most of the data stored in RAM on Wii U is GPU bound, so routing everything through the CPU wouldn't help. Also, the data on Wii U is usually already compressed, and the entropy of compressed data makes further compression impossible.

I was unaware that you had documentation on the Wii U that states this. Care to share it with the rest of the class? Please explain to me why it wouldn't work on a system like the Wii U.

How exactly did the Two Tribes achieve their compression then? They made specifically clear that it was a new feature "on the Wii U" that allowed it.

http://gimmegimmegames.com/2012/10/developer-finds-new-hardware-feature-in-the-wii-u/

&#8220;Today we discovered a new hardware feature of the Wii U that shaves off 100 megabytes of texture memory usage in Toki Tori 2!&#8221;
Either your claim that data is already compressed is wrong, or they found a way to do the impossible and compress already compressed data.
 
I was unaware that you had documentation on the Wii U that states this. Care to share it with the rest of the class? Please explain to me why it wouldn't work on a system like the Wii U.

How exactly did the Two Tribes achieve their compression then? They made specifically clear that it was a new feature "on the Wii U" that allowed it.

http://gimmegimmegames.com/2012/10/developer-finds-new-hardware-feature-in-the-wii-u/


Either your claim that data is already compressed is wrong, or they found a way to do the impossible and compress already compressed data.
They may simply have discovered another texture format.
 
I'm getting tired of the whole "they must have re-invented the wheel" and clinging onto theories that would mean big changes for the CPU or whatever; someone suggested it, it has merit as an academic assumption of whatever; but let's not jump on that bandwagon unless someone comes out and corroborates it (and no, an ambiguous post by two tribes on twitter doesn't count). Usually the simplest explanation or lack of thereoff is indicative of the implementation; that's simply how it is. Also bare in mind Nintendo is not in it to be a test subject hence the withered technology philosophy; they'll go either for easy things implemented on top or well tested ones/no margin for error.

Like Azak said, they could have uncovered new gpu features that are not all that new for PC or the OpenGL implementation but are new for consoles, like BC6H (the most likely one, IMO), ASTC, ETC2. Hell, it could be down to compiling keychain/previewing code part of the SKU for all we know; for instance FFXII team had a tool to test assets in the engine at real-time so they could decide wether they were using too much resolution for the textures or not.

Don't forget these dudes started or tested the game at 1080p, then went down, I'm sure textures were at some point too good for 720p; shaving that resolution a little would be an impossible to notice at 720p; hence a target for compression; perhaps the "feature" they found was something that assisted them in doing just that.

I mean whatever; not some crazy implementation that would make espresso a Power7+ prototype transplant patient; most likely the only thing from Power7 it has is the eDRAM and let's suppose nothing else unless there's some insider information going for it.


Hell, they could have simply discovered said CPU/GPU data compression and optimization for it on the toolchain, as one would otherwise need to optimize for it. That could surely save 100 MB.
 
Top Bottom