blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Are you talking hypothetically or?
Wii U CPU |Espresso| Die Photo - Courtesy of Chipworks
- Thread starter Fourth Storm
- Start date
Brad Grenz
Member
That was a hypothetical example based on what devs like DICE have said about their engines.
prag16
Banned
Wait, what? What consumer is going to be running 40TF rigs in 2015? Four Titans don't even get you halfway there...
Unless with everything unified as they're stating (no separate CPU/GPU) FLOPS are measured differently or something?
phosphor112
Banned
Wait, what? What consumer is going to be running 40TF rigs in 2015? Four Titans don't even get you halfway there...
Unless with everything unified as they're stating (no separate CPU/GPU) FLOPS are measured differently or something?
3D Stacking should be finally coming out around then... Don't think it'll hit "mainstream" until 16 or 17 though.
prag16
Banned
Haven't researched it a whole lot (or at all) but I can't understand how this technique won't be murderous with regard to heat. I'll have to do some reading.
phosphor112
Banned
That is the only reason why it isn't out yet. Cooling issues. Cooling involves a multifaceted cooling mechanism as opposed to just a single heat spreader and heat sink up top.
But power is going to increase significantly. Our jump from PS4 to 5 and Durango to whatever will be the biggest we'll ever see. The absolute biggest. And it'll all still be x86 too.
Wow. How awesome would it be if Nintendo released a console in 2017 or something that did even a fraction of that. Lets say 10 gflops, which would still be considered low powered if Dice thinks 40gflops pcs are going to be around in 2015, but would easily outpower ps4720.
On the other hand it would keep Nintendo in the odd man out mid-cycle refreshes, do we want that? I think I'd rather wait until the other two eighth gen consoles are up and have the refreshes bring the three ninth gen consoles to pretty close spec parity, and that certainly won't be in just less than 4 years.
phosphor112
Banned
I'm not sure how far the development is for 3D stacking PPC's... anyway, PS4 and Durango will be dropped once that tech is available for the masses, otherwise they'd be severely outclassed by every day tech. I expect these guys to make a jump around the same time.
Do you expect devs to used fixed point math?
Brad Grenz
Member
Wait, what? What consumer is going to be running 40TF rigs in 2015? Four Titans don't even get you halfway there...
Unless with everything unified as they're stating (no separate CPU/GPU) FLOPS are measured differently or something?
The 40 TF projected figure from 3 years ago isn't the relevant portion of the slide.
cartman414
Member
I'd hope Nintendo would be done with PPC by then.
I don't see why coding towards integers and coding towards floating point would be that different in practice.
The results should be the same. The only difference I can see is that one would be more advantageous on hardware that was designed to for it than the other.
I'm not sure if it is the same, but I've written a few small 2D games before and I've always used nothing but integers. I don't like dealing with floating point numbers when programming.
CPU's have limits, but math itself has no limits. All that matters are your algorithms and syntax. Optimizing code to use integers instead of floating points should not be that difficult. The few things that absolutely required floating point math(if there are any) could still be done using it.
The results should be the same. The only difference I can see is that one would be more advantageous on hardware that was designed to for it than the other.
I'm not sure if it is the same, but I've written a few small 2D games before and I've always used nothing but integers. I don't like dealing with floating point numbers when programming.
CPU's have limits, but math itself has no limits. All that matters are your algorithms and syntax. Optimizing code to use integers instead of floating points should not be that difficult. The few things that absolutely required floating point math(if there are any) could still be done using it.
Hmm... If precision matters, I don't see how you can turn floating point data to integer data without drastically reducing precision.
For example, how would you represent pi in integer? I guess you could assume a certain power as "decimals", but then you'd lose that number of powers in scale, and you'd still lose a huge chunk of precision on the decimal part. Seems sketchy.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
And then you feed you fixed-point results to the fp-optimised GPU and choke it.
On an unrelated note, I've added multi-threading to the matmul test, which does help in the PPE case, when results get aggregated back to one core
This is true. Pi would be hard to represent but also, as you said, you could assign a separate variable for it.
Though that would be unnecessary. Like I said, you would still use floating point operations where it is needed. They don't break the CPU. I bet that is how must games are using it now and they are still running.
I'm just saying that devs should utilize integers unless it is absolutly necessary(floating points would give all around better results situation) since the PPC750 architecture seems to do so much better with integers than floating points. It would all depend just what was overall the most advantages given a situation. An exmaple would be situation where you could do something calculating 1 floating point number or 3 integers(1 to address the who number, one to address the decimal, 1 1 to hold the translation). If the performance was 4X better with integers then the integer route would be better in that situation, hypothetically.
Also, you could just take a different approach that would not require you to use pi at all. My favorite thing about programming, is that there are so many means to and end. This is the same thing we encountered in the GPU thread when people came in insisting that Normal Mapping was impossible on the Wii because it didn't have modern shaders when it was done many times http://www.neogaf.com/forum/showpost.php?p=56901814&postcount=3690. All that was needed was a change in how it was performed.
I think the problem with performance on the Wii U CPU is people are simply not coding to its strengths. After all, a CPU with 1/10 the strength did this http://www.youtube.com/watch?v=3xJXvFqhCk0. I say people a greatly underestimating the power of the Wii U CPU based on nothing more than it having a lower clock than the Cell and Xenon.
Schnozberry
Member
I think blu already discounted the idea of using integer math for graphics. GPU's just aren't tuned to handle it. It would die a horrible death trying to parse fixed point results.
Using fixed point math for AI and other code unsuited to run on the GPU should run fine on Espresso. The paired singles aren't entirely worthless either, but it seems the Wii U was designed around doing some level of floating point compute on the GPU. How much that penalizes graphics performance we don't know, as we have no idea how the ALU's were customized. Their size would indicate more going on than what meets the eye.
And I never said to do so. That's a null point.
I said use integers unless floating points absolutely gave a better result. Its all about coding towards strengths. The bulk of the code should be done using integers wherever plausible. Though, if the GPU does floating point math, and it is GPGPU, then I don't see why we would need any floating point math on the CPU.
Schnozberry
Member
Well, your original point made it seem like there should be a wholesale conversion from floating point to fixed point match. Sorry for the misinterpretation.
Its no problem. Though, what I really want to know is just how much better the CPU does integers as compared to floating point.
Now that I think of it, it can actually be tested on a Wii. Aren't there some homebrew dev engines for it on the net?
cartman414
Member
I'm more concerned with Nintendo not contemporizing a bit more with regards to the real next gen. Keeping it simple did nothing for ease of development in HD. They are NOT going to get a leg up on Western 3rd party support. I wouldn't be surprised if you told me the PS4 would turn out to be easier to code for while still getting far superior results.
I have 2 questions.
1. What is the likelihood that Espresso borrowed some functionality/components from the Power7? I cannot disregard all of the claims that it would have a Power7 in it up until near release.
2. Since we have the manual for Broadway, exactly what was enhanced on it over Gecko or standard PPC750s besides its clock speed?
1. What is the likelihood that Espresso borrowed some functionality/components from the Power7? I cannot disregard all of the claims that it would have a Power7 in it up until near release.
2. Since we have the manual for Broadway, exactly what was enhanced on it over Gecko or standard PPC750s besides its clock speed?
Schnozberry
Member
According to the always reliable wikipedia, there were 50 new SIMD instructions added geared towards 3D gaming. What that means is a mystery to me. I'm not competetent enough in that area to know. Plus, you'd have whatever customizations from a stock 750CL were made for broadway, and likely even moreso on top of that for Espresso. Knowing Nintendo, we're probably overthinking it.
As far as relation to Power 7, it uses EDRAM as cache and is Power PC, but other than that it would be nearly nothing.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
As Schnozberry mentioned, for all we know it could be the EDRAM L2. That's IBM's signature tech - they've been advancing it for the past few POWER generations.
Gekko/Broadway/750CL have the exact same architectural enhancements over the rest of the 750's. Re what those are - IBM have a paper discussing that. Google for a pdf named "To CL - CL Special Features".
I got some interesting answers to my questions about the PPC 750 a few places if anyone is interested:
http://forums.anandtech.com/showthread.php?p=35016916#post35016916
http://arstechnica.com/civis/viewtopic.php?f=8&t=1205049&p=24490267#p24490267
http://forums.anandtech.com/showthread.php?p=35016916#post35016916
http://arstechnica.com/civis/viewtopic.php?f=8&t=1205049&p=24490267#p24490267
thanks for those links. I'll share one too.
I was googling around looking for info on cisc vs risc stuff as it relates to Wii U in an attempt to justify a purchase. I was hoping the old logic that RISC was inherently better if developers created quality code for it was still true.
I stopped looking after I found a tweet from John Carmack:
I am a little disappointed, I was hoping that a RISC chip would have significant advantages over x86 if developers put the effort in, but it looks like that is not the case anymore.
And given that people like Marcan have written things like:
I've pretty much given up on rescuing the wii u from the "hard to program for/weak/crappy/ancient tech" bin given that the Ouya has a friggin phone cpu.
The other dissappointing thing I found was that the fact that x86 compilers etc are leagues ahead of anything Nintendo will ever be able to create and that programming on Espresso requires developers to learn whole new skill sets which few seem to want to do.
Oh well, I'm using airmiles for my purchase so I'm treating it like it is free.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
jhu's POVRay test linked there is interesting. Re Exophase's belief that Jaguar should have a clearly better pipeline - that's something that awaits its proof, lest we get another 'bobcat should trounce espresso at SIMD!'. It warrants mentioning that 750CL has some enhancements over its predecessors (e.g. an extra reservation station at the fp pipe, improving the fp IPC). Also, my basic impression from the matmul test is that paired-singles are notably better than P3's SSE (which had 64bit datapath anyway).
From the latest Wwise release notes, to demonstrate how close to "maxed out" the Wii U actually is/ was:
I believe most/ all of these things are processed on the CPU, not the DSP (not that it really matters). This is from May 14th, previous release was late last year. There have been improvements on other platforms as well, though they were generally a lot smaller. Except for tremolo, which saw a massive speedup on 360 as well, and LPF.
That's neat, but it doesn't tell us much if we don't know what baseline they started from. A 4x increase is less impressive if the processor was executing at 1/6th that of another existing processor (numbers pulled from my bum of course).
And of course gains from optimization would be lower on older processors.
And there's also the matter of how much of that translates to actual game code speedup, ie you can use AVX extensions and get massively more power for the code that uses it, but in a large program that may only be a small chunk of the code.
I'm not sure you got the point of my post. This is about the level of optimization compared to launch, not about comparing Espresso to any other CPU.
I think it has become clear in the recent months that, for a lot of people, some posters interest in Wii U hardware discussions are for little more than comparing it to the other consoles with some even trying their hardest to pin everything it does beneath the last gen consoles. and the lowest performance they can logically estimate.
Not sure if this is such a case, but it is starting to stand out.
That's certainly not what I was going for. I'm just saying a bajillion times speedup wouldn't mean much to me without knowing the start point (not just of the CPU, but how terribly optimized the initial code was too) as well as how broadly that speedup could be applied to real game code. .
The start point is what you've seen (well, heard) in several multiplatform launch games - Batman, Assassin's Creed, Mass Effect 3, Darksiders 2, Epic Mickey 2, Sonic Racing and Trine 2 all use Wwise for example. Actually, I believe launch games must have used an even older, even less optimized version of Wwise. It's of course not possible to quantify the improvements in absolute terms, but any game that ran into CPU performance issues back then would probably have a lot less problems now. And when even common middleware had this much room for improvement, one can only guess how badly optimized everything else was/ is.
So, can we now make the assessment that there are at least some situations in which Espresso will give superior performance in games over the Xenon and/or the Cell?
lightchris
Member
In my opinion this was never in question. And if it were really bad, multiplatform games would run much worse. Espresso seems to fit well enough to the rest of the hardware, just don't expect any miracles.
prag16
Banned
Additionally, I don't think Espresso will be QUITE as massively outclassed by 8xJaguar for EVERY operation as some are expecting. Espresso loses big on clock rate and core count, but could hold its own in certain cases due to the drastically shorter pipeline.
That said, it doesn't mean I expect a game optimized for 8 (or 6; whatever's available to games) cores will have no issues down porting.
We don't have that much longer to wait until Nintendo blows their load at and leading up to E3. Should be interesting in terms of getting a better idea of where the ceiling might be.
This is nice and all, but I was hoping for some real world examples and comparison, or some more detailed explanation of its capabilities. I want something that contradicts this "horrible, slow CPU" mantra I see everywhere. The overall belief on the net is that Espresso is outclassed in ever way by the other two CPUs.
Just CPU to CPU, what type of gains can Espresso get over Xenon in a more real world sense?
Brad Grenz
Member
See, the problem is you are literally demanding evidence that fits your preconceptions rather than drawing conclusions based on all the evidence out there.
I would be very interested too. I couldn't find much that wasn't in bitchy forum threads written by anonymous posters.
What I did find was Marcan's blog post about the Wii U, and why developing homebrew wasn't all that interesting: "Spend $100 and you can get an Ouya, which beats the Wii Us CPU and doesnt have too shabby graphics at one third the cost." I don't know how the tegra3 stacks up to the Xenon, but the fact that in Marcan's opinon Esspresso cannot match up to a 2011 phone cpu...
Also, I've read a bunch of posts about 'short pipeline kicking ass' etc. But after I saw this tweet from John Carmack about the whole short pipeline thing not mattering with a link to an academic paper: "At modern levels of performance, RISC vs CISC is irrelevant for performance, power, and energy" I stopped believing that Esspresso is going to anywhere near ps720 in the cpu dept.
Btw, I'm not hating on the Wii U. I just wanted to have a solid understanding of what exactly I'm going to be buying so as to avoid dissappointment.
frankie_baby
Member
and you are guilty of the same level of preconception, espresso does have massive improvements over xennon in some areas, when talking about real world though it would have to be assessed on a case by case basis
You are exaggerating my position. I'm not here to prove preconceptions nor am I "demanding" anything. I'm simply asking if there is anything that would back the findings available and could concretely show gains of the CPU or next gen capabilities.
There are blu's benchmarks but we need someone to run thm on Jaguars.
You mean we have actual benchmarks for espresso?
I'm hoping for something from someone with credentials not on a forum, like when Timothy Lottes wrote that cool blog post about coding through apis vs coding to the metal and why consoles can punch so far above their weight. I don't think it will happen though because like that Lotte blog proved, saying anything about consoles is like sticking your dick in a wasp nest.
prag16
Banned
I think the point is he would like to see benchmarks. Of course he'd be happier with the results if they happen to favor Espresso in some areas. But the main point is it'd be very interesting to see some benchmarks, comparing Cell, Xenon, and Espresso (and 8xJaguar) in various scenarios, regardless of the victor.
This is exactly my stance on the matter.
Time to clear up what i said here, here and in some other messages a few months ago, as i've already revealed it on IRC.
One of the Wii U core wasn't used throughout the development of several launch window games. It's an "engine related issue", meaning it's the way the teams behind those titles have programmed their engine for the Wii U CPU. It wasn't widespread, not universally seen on all the games, but witnessed on at least a few of those. The developers found and resolved this problem mere months/weeks prior release, and most of them gained a nice increase in FPS. It's one the origin of the huge boost in framerate i reported a long time ago that some studios managed to get (from 30 fps to 60 fps for some games), along with new dev kits, etc.
You heard it right, a whole core of the Wii U CPU wasn't put in use for most of the dev cycle of several titles, before it was fixed.
It's rather telling either: - on the crucial need of studios, accustomed to the HD-Twins framework, to adapt their code to the Wii U specifics - or the perfectible state of documentation/dev kit/SDK's at the time - or [insert your own conclusion/guess derived from this info]
One of the Wii U core wasn't used throughout the development of several launch window games. It's an "engine related issue", meaning it's the way the teams behind those titles have programmed their engine for the Wii U CPU. It wasn't widespread, not universally seen on all the games, but witnessed on at least a few of those. The developers found and resolved this problem mere months/weeks prior release, and most of them gained a nice increase in FPS. It's one the origin of the huge boost in framerate i reported a long time ago that some studios managed to get (from 30 fps to 60 fps for some games), along with new dev kits, etc.
You heard it right, a whole core of the Wii U CPU wasn't put in use for most of the dev cycle of several titles, before it was fixed.
It's rather telling either: - on the crucial need of studios, accustomed to the HD-Twins framework, to adapt their code to the Wii U specifics - or the perfectible state of documentation/dev kit/SDK's at the time - or [insert your own conclusion/guess derived from this info]
Someone remind me, I'm sure we've discussed it, how does Espresso match Broadways l2 cache? Broadway's L2 cache takes only 7 cycles to transfer an entire line to L1, the critical word latency is even lower, AFAIK only 4 cycles. How can the Wii U's eDRAM based L2 deliver such low latencies? Or was there a separate SRAM chunk in there too for BC, like the GPU has?
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
That chunk would have to be of the actual size of Broadway's L2. I can't remember if we've discussed it, but that's a good question nevertheless. My wild guess would be they'd do it fairly i.e. they meet the requirements, as the alternatives would just not work - fooling around with cache latencies is something immediately noticeable.