WiiU "Latte" GPU Die Photo - GPU Feature Set And Power Analysis

Status
Not open for further replies.
my mistake. MU is the first film for ALL of the lighting to be ray traced.

Wrong again. It's just the first Pixar movie to use Raytracing completely. That said pretty much every Blue Sky Studios movie has featured Raytracing, they use a proprietary renderer that tries to simulate real life as much as possible. They've been Raytracing things for a long time. Pixar makes a software known as Photorealistic Renderman, or just Renderman. Renderman is also a standard that other companies can use to write renders based on. That said Renderman I don't think has always supported Raytracing, I believe the earliest versions of it were just a scan line renderer. I forget at what point Raytracing was added as an option in Renderman, it's been there for a bit though I believe.
 
Pretty compelling argument for 320 SP again over on b3d:

http://forum.beyond3d.com/showpost.php?p=1764009&postcount=5253

I'm having trouble deciding as both sides of the debate seem so sure even at this stage!

This is a great find. I find his argument more logical then ones I've seen for it being 160.

He doesn't even get into games, and company policies. He just uses straight facts of hardware. I'm sticking to the 320 analysis for now. The amount of roundabout explanation, and moreso, ignoring that must be done to justify 160 ALU's just doesn't seems logically sound to me now when all is said in done. The 160 setup would be needlessly more expensive and harder to utilize properly. There would be no benefit to it on any front that I can imagine.

It makes more problems with deciphering the GPU than not doing so.
 
DocTre81 posted a vid on Youtube. Mark Cerny talking about the advantage/disadvantage of using eDRAM on a chip...

http://www.youtube.com/watch?v=uFaKX2YnH0I

Looks like Wii Us memory might not be as slow as people think it is. But he also talks about the downsides of it wich is TOTALLY in line what Shin'en said. That every engine/game needs to be specifically optimized for the system. (The stuff DocTre81 is reading in the video was from a Shin'en interview)
 
DocTre81 posted a vid on Youtube. Mark Cerny talking about the advantage/disadvantage of using eDRAM on a chip...

http://www.youtube.com/watch?v=uFaKX2YnH0I

Looks like Wii Us memory might not be as slow as people think it is. But he also talks about the downsides of it wich is TOTALLY in line what Shin'en said. That every engine/game needs to be specifically optimized for the system. (The stuff DocTre81 is reading in the video was from a Shin'en interview)

Wii U's eDRAM is not 1000GB/s like his example.
 
Wii U's eDRAM is not 1000GB/s like his example.

We know it's not 1000GB. You are missing the point. The point is that with the way the Wii U is using eDRAM it's bandwitdth can be comparable if not faster than the 176GB/s ps4 has using DDR5. I don't believe there's been a confirmation on the exact speed of the edram in the Wii but it's been mentioned of being in the triple digits.
 
Wii U's eDRAM is not 1000GB/s like his example.

We know it's not 1000GB. You are missing the point. The point is that with the way the Wii U is using eDRAM it's bandwitdth can be comparable if not faster than the 176GB/s ps4 has using DDR5. I don't believe there's been a confirmation on the exact speed of the edram in the Wii but it's been mentioned of being in the triple digits.

Well, this is only talking about memory bandwith. PS4 bandwith according to Cerny's talk is 176 GB/s. Even if Wii U hardware's theoretical bandwidth was similar and it was utilized through competent (and time consuming) programming, it still would be deficient in other areas (compared to PS4).

Isn't the more important question "How much harder is optimizing for the Wii U eDRAM to achieve peak bandwidth" than on PS4, PC and/or Xbox One.

Considering that each of development will be a major factor at play this entire generation, and that third parties don't need another reason not to port to Wii U, that seems to be crucial.

How challenging will it be to optimize a game to make full use of the eDRAM and that bandwidth, and is such an effort going to deter third parties?
 
What I get from all of this, is that Wii U's architecture is similar to Xbone's, at least on the RAM pools distribution and priority of GPU over CPU. Of course, the performance is not the same. Wouldn't these architecture similarities help Wii U's case by making it easier for developers to port Xbone's games to Nintendo's console?
 
For the sake of it....let's assume that WiiU's Ram B/W is a bit lower than the PS4 so how much would the RAM amount matter since last I heard WiiU only allows 1GB RAM to be used for games? and to gain the best possible results even on such a measly amount devs have to work much harder than usual.
 
What I get from all of this, is that Wii U's architecture is similar to Xbone's, at least on the RAM pools distribution and priority of GPU over CPU. Of course, the performance is not the same. Wouldn't these architecture similarities help Wii U's case by making it easier for developers to port Xbone's games to Nintendo's console?
That really depends on whether the so-called "similarities" are actually practical to leverage in the same ways. We have no idea how these things are actually hooked up, and to what, and resultantly how devs can use them effectively.

For instance, look at the 360's daughter die. You can go ahead and say that the bandwidth between the ROPs and the eDRAM is 256GB/s... but you're not going to make useful sense out of that until you describe:
-How the ROPs are connected to the GPU main die,
-how big the eDRAM pool is (and, similarly, how big framebuffers tend to be),
-how the eDRAM pool interfaces with other memory locations in the 360, and
-what "256 GB/s" actually means (i.e. it's meaningful when discussing peak geometric sample rate on the backbuffer, and there are other bandwidth values that are more often than not more useful.)

So basically, "maybe."
(In this case, probably not.)
 
What I get from all of this, is that Wii U's architecture is similar to Xbone's, at least on the RAM pools distribution and priority of GPU over CPU. Of course, the performance is not the same. Wouldn't these architecture similarities help Wii U's case by making it easier for developers to port Xbone's games to Nintendo's console?

No. There is a lot more going on under the hood of X1's memory subsystem and Wii U's than just saying they both have DDR3 + embedded ram.
 
That really depends on whether the so-called "similarities" are actually practical to leverage in the same ways. We have no idea how these things are actually hooked up, and to what, and resultantly how devs can use them effectively.

For instance, look at the 360's daughter die. You can go ahead and say that the bandwidth between the ROPs and the eDRAM is 256GB/s... but you're not going to make useful sense out of that until you describe:
-How the ROPs are connected to the main GPU components,
-how big the eDRAM pool is (and, similarly, how big framebuffers tend to be),
-how the eDRAM pool interfaces with other memory locations in the 360, and
-what "256 GB/s" actually means (i.e. it's meaningful when discussing peak geometric sample rate on the backbuffer, and there are other bandwidth values that are more often than not more useful.)

So basically, "maybe."

That is a bad example since the daughter die has a different bandwidth to the GPU, basically great for transparencies and post processing like AA, but with Wii U and XB1, the GPU has the embedded memory on die, not a separate bus. Meaning they are far more alike than anything 360 related.

The GPUs are also very similar in architecture by virtue of actually coming from Radeon, obviously the structure of VLIW5 (or whatever U ends up being) and GCN (XB1) handle threads differently, but are still very likely going to execute code similarly with only performance levels (efficiency) really setting them apart.
 
What I get from all of this, is that Wii U's architecture is similar to Xbone's, at least on the RAM pools distribution and priority of GPU over CPU. Of course, the performance is not the same. Wouldn't these architecture similarities help Wii U's case by making it easier for developers to port Xbone's games to Nintendo's console?
Why is it "Xbone's" games?

For all we know, next gen starts with PS4 or better yet, PC. If it's the former, XBO is going to require alot of special attention to keep up with PS4/PC. Not sure how that bodes well for Wii U when it requires its own "optimizing".

Personally, I think the boat has sailed expecting Nintendo was smart enough to design a console with PS4/XBO in mind (the lack of Nintendo even contacting next gen developers to work with Wii U speaks volumes).
 
That is a bad example since the daughter die has a different bandwidth to the GPU, basically great for transparencies and post processing like AA, but with Wii U and XB1, the GPU has the embedded memory on die, not a separate bus. Meaning they are far more alike than anything 360 related.
There are a lot of relevant factors. Factors which mean different things when placed against different systems. A 32MB pool attached to a 1.2TFLOP GPU doesn't necessarily have the same types of uses as a 32MB pool attached to whatever the hell Latte is. Even if the high-level architectures are nigh-identical, "easy portability" wouldn't necessarily mean good, easily-optimized portability.

The "they're both on the same die" argument starts to lose even more meaning when you consider that the other stuff on those dies looks nothing alike. It's not like we're dealing with GPU+eDRAM in both cases. What all has access to Xbone's eSRAM, and in what ways? Ditto for Latte? That's crucial stuff.
 
There are a lot of relevant factors. Factors which mean different things when placed against different systems. A 32MB pool attached to a 1.2TFLOP GPU doesn't necessarily have the same types of uses as a 32MB pool attached to whatever the hell Latte is. Even if the high-level architectures are nigh-identical, "easy portability" wouldn't necessarily mean good, easily-optimized portability.

The "they're both on the same die" argument starts to lose even more meaning when you consider that the other stuff on those dies looks nothing alike. It's not like we're dealing with GPU+eDRAM in both cases. What all has access to Xbone's eSRAM, and in what ways? Ditto for Latte? That's crucial stuff.

Wasn't it already decided that Latte's embedded ram had to act like sram otherwise it would have problems emulating Wii? and didn't the hacker guy who came up with the clocks already decide that it was at least "pseudo" sram? Since both are on die, the entire GPU has access to the entire pool, the only difference in this memory set up would be Nintendo's extra chunks of true sram sitting around the die for other purposes.

I'm not trying to argue about ports, I think those who understand what that entails never really took any debate on the matter seriously. The only thing I'm talking about is the way the embedded ram is connected to the GPU, Wii U also has more cache in its CPU as well (per core) so the chance that Wii U has a bandwidth problem is a reasonable assumption at launch in the face of Call of Duty but has lost almost all steam going forward.

Wii U is in an infinitely better position from a hardware standpoint to receive ports from XB1 and PS4 than Wii was in getting ports of 360 and PS3 games, however the real problem is that, from a user base perspective, it is the complete opposite.
 
For the sake of it....let's assume that WiiU's Ram B/W is a bit lower than the PS4 so how much would the RAM amount matter since last I heard WiiU only allows 1GB RAM to be used for games? and to gain the best possible results even on such a measly amount devs have to work much harder than usual.

I would expect Nintendo to release at least another 256MB of that RAM to games in the next year or so as the OS matures and solidifies in features. We might even see 512MB.
 
I don't know. That's why I find it presumptuous why Xbox One is being considered the platform for ports when PS4/PC stand good enough chances of that too.

The general thinking is that XB1 is the weakest of the platforms that are being targeted, so it will likely be the "basic" platform that developers target and use PS4's extra power to improve frame rate, resolution, AA, physics and other effects that might lack from the XB1 version. Also XB1 will probably have the same contract 360 has, which is that if developers want to release a game for XB1 it can't be a late port (This happened with 360 and was one of the reasons Rayman Legends was delayed on Wii U, though might not be the main reason it wasn't released)

If XB1 trails too far behind PS4, I see developers caring less and less for it, but with the rumor that the GPU clock was increased (putting the GFLOPs around 1500 iirc) it might not be far behind PS4. It would certainly make next gen a bit more interesting.
 
The general thinking is that XB1 is the weakest of the platforms that are being targeted, so it will likely be the "basic" platform that developers target and use PS4's extra power to improve frame rate, resolution, AA, physics and other effects that might lack from the XB1 version. Also XB1 will probably have the same contract 360 has, which is that if developers want to release a game for XB1 it can't be a late port (This happened with 360 and was one of the reasons Rayman Legends was delayed on Wii U, though might not be the main reason it wasn't released)

If XB1 trails too far behind PS4, I see developers caring less and less for it, but with the rumor that the GPU clock was increased (putting the GFLOPs around 1500 iirc) it might not be far behind PS4. It would certainly make next gen a bit more interesting.
I have doubts that Xbox1 specs will go up, especially this close to launch. Anyway, it port issue will likely depend more on sales than specs. As long as the xbox1 doesn't completely bomb (and Microsoft continues with the moneyhats), devs will likely continue to port to it. If/when Wii U recovers momentum, games will likely be released for the system too. Current-gen consoles will likely continue to get releases, and they may last even longer if next-gen has trouble establishing an userbase.
 
The general thinking is that XB1 is the weakest of the platforms that are being targeted, so it will likely be the "basic" platform that developers target and use PS4's extra power to improve frame rate, resolution, AA, physics and other effects that might lack from the XB1 version. Also XB1 will probably have the same contract 360 has, which is that if developers want to release a game for XB1 it can't be a late port (This happened with 360 and was one of the reasons Rayman Legends was delayed on Wii U, though might not be the main reason it wasn't released)

If XB1 trails too far behind PS4, I see developers caring less and less for it, but with the rumor that the GPU clock was increased (putting the GFLOPs around 1500 iirc) it might not be far behind PS4. It would certainly make next gen a bit more interesting.
Matt has already debunked that BS rumor.

http://www.neogaf.com/forum/showpost.php?p=69314956&postcount=122

I've thinking that the WiiU should be capable of creating something similar to 1313.
It's good to dream.
 
I've yet to hear a single reason why the aggregate bandwidth discussions make any more sense than aggregate clockspeed nonsense.

Can someone fill me in?
 
I've yet to hear a single reason why the aggregate bandwidth discussions make any more sense than aggregate clockspeed nonsense.

Can someone fill me in?
Aggregate clockspeed? What is this?
Aggregate bandwidth is what you have when you can access multiple memory pools with independent buses at the same time.
 
Aggregate clockspeed? What is this?
Aggregate bandwidth is what you have when you can access multiple memory pools with independent buses at the same time.

Ah, so is the key "independent buses"? That's what's stops this being an imaginary figure and something that can be achieved?
 
Ah, so is the key "independent buses"? That's what's stops this being an imaginary figure and something that can be achieved?
Well, I still don't understand what the hell is "aggregate clockspeed" so maybe I didn't answer your question properly, but let's see how the eDram works on the WiiU:
You have 2 pool of eDram, both accessible (confirmed by marcam on twitter) (32MB and 2MB respectively).
Furthermore, you can access the 2GB of RAM.

If you want something from the 2GB pool, you're limited to 12.8 GB/s of memory bandwidth available.
If you want something from the 32MB pool, you're limited to that pool's maximum bandwidth.
The same for the 2MB pool.

When can you aggregate those bandwidth? Always as long as you don't need something from another pool of memory.
But you can retrieve some shader data from the 2MB pool, some buffers from the 32MB pool and some textures from the 2GB pool, and if there isn't any disappointing news regarding that, you should be able to load all that at the same time, since everything goes through it's own buses, to its own memory controllers to wherever they have to go.

Of course, you have to work your code so it can work this well but that's the point on having big caches of eDram.
Imagine it as if those were caches. The fact that the processor is reading from its L2 cache doesn't hit the main memory at all and you could still be loading data from it.
 
Ignore the aggregate bandwidth comment. It was just a comparison to things I've seen in the past by people that really don't understand (3 cores at 1.2ghz?? Omgz it's a 3.6Ghz chip!!!).

So I'm just trying to understand if this aggregated bandwidth claim actually bears any resemblance to real life, or if its just put together in a similar manner.

I guess it's like you said, provided you work your code properly you can make the most of that bandwidth. If its just a cache then it's still got to be filled from main memory. As soon as that happens you're only as fast as your slowest part and you're back to your 12.8gb/s (at best). I think this is where my head stops being able to add bandwidth up in this manner.

Thanks for your explanation though.
 
Ignore the aggregate bandwidth comment. It was just a comparison to things I've seen in the past by people that really don't understand (3 cores at 1.2ghz?? Omgz it's a 3.6Ghz chip!!!).

So I'm just trying to understand if this aggregated bandwidth claim actually bears any resemblance to real life, or if its just put together in a similar manner.

I guess it's like you said, provided you work your code properly you can make the most of that bandwidth. If its just a cache then it's still got to be filled from main memory. As soon as that happens you're only as fast as your slowest part and you're back to your 12.8gb/s (at best). I think this is where my head stops being able to add bandwidth up in this manner.

Thanks for your explanation though.

Maybe that's what 2mb is for, you store whatever's necessary in booth pools, leaving 1GB just for the frame buffer's and textures.
 
Ignore the aggregate bandwidth comment. It was just a comparison to things I've seen in the past by people that really don't understand (3 cores at 1.2ghz?? Omgz it's a 3.6Ghz chip!!!).

So I'm just trying to understand if this aggregated bandwidth claim actually bears any resemblance to real life, or if its just put together in a similar manner.

I guess it's like you said, provided you work your code properly you can make the most of that bandwidth. If its just a cache then it's still got to be filled from main memory. As soon as that happens you're only as fast as your slowest part and you're back to your 12.8gb/s (at best). I think this is where my head stops being able to add bandwidth up in this manner.

Thanks for your explanation though.
Nope. All the game data is stored on the 2GB pool, but every graphical operation you do doesn't read or write on it, so the maximum bandwidth is of course higher.

The difference between using those caches and not doing it it's one read from the main memory and then multiple reads and writes on the eDram versus doing all those reads and writes on the main memory.
And of course, while you're writing/reading from eDram you can also read/write to main RAM if you want.

Aggregate bandwidth is much closer to reality than aggregate clocks.
 
Aggregate bandwidth is much closer to reality than aggregate clocks.

Ok, so it is valid, and not just an academic exercise by fanboys to make things seem better.

However, as you seem to understand this far better than me, what is the ability to use the aggregated bandwidth for a single process? Is that likely to happen? I understand a steady stream of data from main memory, then lots of processing back and forth to edram, but wouldn't that be for two separate stagesi of the pipeline? Are there instances where the same stage can benefit from the combined IO of both buses?
 
Ok, so it is valid, and not just an academic exercise by fanboys to make things seem better.

However, as you seem to understand this far better than me, what is the ability to use the aggregated bandwidth for a single process? Is that likely to happen? I understand a steady stream of data from main memory, then lots of processing back and forth to edram, but wouldn't that be for two separate stagesi of the pipeline? Are there instances where the same stage can benefit from the combined IO of both buses?
You don't have to go to such a low level to see the benefits of it. I mean, most of the operations will be done even without having to search outside the GPUs caches (not the eDram or the 1MB SRam pool, I mean the SPUs caches and such).
A process can of course use both pools if required depending on the operations it has to do, but I can't think of a situation where you would split the data required for a certain operation and store it on different memory pools with different specifications and get any benefit out of it.

I don't think it has much sense to approach things like you say, because you will be always limited by the lowest denominator.

But speaking of aggregate bandwidth, think of it as if the most frequent (and small enough) operations doesn't impact the main RAM. Not only you can be streaming from both pools of memory at the same time (and you will do this most of the time) but also you will get better performance from the DDR3 pool (less accesses means less time spent on searching the data, so less time wasted on latencies) since you will use it for streams of big chunks of data and you will avoid most of the small read/writes you would normally do on it.
 
Am I the only one who finds it funny that people expected games back in the early PS3 era to be using ray tracing while the only film to use it up to this point was Monsters University?
Not sure, but one of the first fully ray traced movies was The Last Starfighter from 1984.. ;)
 
Here's a great article about ray-tracing

http://www.cs.utah.edu/~jstratto/state_of_ray_tracing/

"A bit about the Movie Industry

So, most people think ray tracing dominates movie effects as rasterization dominates the game industry. Some graphics enthusiasts that have ray traced little scenes in some modeler like Maya or Modo might expect the movie industry to use the same kind of ray tracers to get the same high-quality scenes. However, just as the game industry uses rasterization for fast rendering, so does the movie industry. They too have a deadline to meet and rasterization is typically the implementation of choice to get their shots looking good in time. A great paper by Dreamworks explains the typical rendering system used at top production studios. You can grab the slides here.

Many effects are not only just as visually compelling as their ray-traced counterparts, but many ray-traced implementations are much, much more expensive to implement and sometimes completely impractical."

"What about motion blur? That's easier with ray tracing, right? Sure is. Just fire 1000x more rays. Wait, ray tracing is already slow. Well, back to rasterization. Pixar, Dreamworks, Rhythm and Hues, and many others use rasterization or other tricks for motion blur because it looks great and is fast. Rhythm and Hues has used a 2D technique in some of their films.

Want to use displacement mapping? Better use a rasterizer like the REYES algorithm. You can send hundreds of primitives gigabytes in size down the pipeline and do tiny surface displacements on each fragment. With a ray tracer, you have to load the entire scene into memory. Have fun telling your render-farm manager that you need a terabyte of RAM for each frame. And no, out-of-core ray tracing research is not close to solving this inherent problem.

Okay, but reflections are always ray traced, right? Well, I can't say how often a given company ray traces or rasterizes their reflections, but I can say that Pixar, Dreamworks, Rhythm and Hues, and many others have used HDR environment maps for years and not many viewers have complained, so we may never know on this one...

Soft shadows? Why use ray tracing? Think you can just fire off 1000 shadow rays when ray tracers are already this slow? Pixar, Dreamworks, Rhythm and Hues, and many others use special shadow maps for most if not all shadows. They are rather zippy and can handle a huge variety of effects. A lot of research has been done in the gaming industry already to make shadows look great and techniques for shadow maps in the film industry are slowly making their way into games as GPUs get more robust.

What about caustics or other effects? You may say ray tracers are physically realistic while rasterizers are only physically plausible--score one for ray tracing. If I see an image and can't tell the difference, who cares?

So if production companies have hours to render a frame and usually choose rasterization for most of the scene because it makes the shots look better, why should video games, which have milliseconds to render use ray tracing?"
 
Here's a great article about ray-tracing

http://www.cs.utah.edu/~jstratto/state_of_ray_tracing/

"A bit about the Movie Industry

So, most people think ray tracing dominates movie effects as rasterization dominates the game industry. Some graphics enthusiasts that have ray traced little scenes in some modeler like Maya or Modo might expect the movie industry to use the same kind of ray tracers to get the same high-quality scenes. However, just as the game industry uses rasterization for fast rendering, so does the movie industry. They too have a deadline to meet and rasterization is typically the implementation of choice to get their shots looking good in time. A great paper by Dreamworks explains the typical rendering system used at top production studios. You can grab the slides here.

Many effects are not only just as visually compelling as their ray-traced counterparts, but many ray-traced implementations are much, much more expensive to implement and sometimes completely impractical."

"What about motion blur? That's easier with ray tracing, right? Sure is. Just fire 1000x more rays. Wait, ray tracing is already slow. Well, back to rasterization. Pixar, Dreamworks, Rhythm and Hues, and many others use rasterization or other tricks for motion blur because it looks great and is fast. Rhythm and Hues has used a 2D technique in some of their films.

Want to use displacement mapping? Better use a rasterizer like the REYES algorithm. You can send hundreds of primitives gigabytes in size down the pipeline and do tiny surface displacements on each fragment. With a ray tracer, you have to load the entire scene into memory. Have fun telling your render-farm manager that you need a terabyte of RAM for each frame. And no, out-of-core ray tracing research is not close to solving this inherent problem.

Okay, but reflections are always ray traced, right? Well, I can't say how often a given company ray traces or rasterizes their reflections, but I can say that Pixar, Dreamworks, Rhythm and Hues, and many others have used HDR environment maps for years and not many viewers have complained, so we may never know on this one...

Soft shadows? Why use ray tracing? Think you can just fire off 1000 shadow rays when ray tracers are already this slow? Pixar, Dreamworks, Rhythm and Hues, and many others use special shadow maps for most if not all shadows. They are rather zippy and can handle a huge variety of effects. A lot of research has been done in the gaming industry already to make shadows look great and techniques for shadow maps in the film industry are slowly making their way into games as GPUs get more robust.

What about caustics or other effects? You may say ray tracers are physically realistic while rasterizers are only physically plausible--score one for ray tracing. If I see an image and can't tell the difference, who cares?

So if production companies have hours to render a frame and usually choose rasterization for most of the scene because it makes the shots look better, why should video games, which have milliseconds to render use ray tracing?"

In otherwords, we shouldn't expect ray tracing in games for another 2...maybe 3 generations of consoles?
 
All I know is seriously nintendo needs to hold Wii U development classes for 3rd parties. I think the Wii U is a very capable console. Its seems as if developers are clueless on how to make games work properly on this machine. The tools should be available now so there are no more excuses. Nintendo can't make this strange ass console and don't explain how to use it. Splinter cell blacklist comes out in about a month and we haven't heard anything about Wii U development and if it will run better than ps360 versions but I doubt it. Its seems developers are gonna be happy with just getting ports up and running at 360 levels with Wii U and calling it a day after that. Sad truly sad if its not underpowered as Iwata has said its a misconception then take the time Nintendo to make sure developers know what the hell they are doing and how to utilize the strange architecture you put in Wii U.

I don't think the Wii U architecture presents a huge challenge for devs. It's just that the extra time put towards optimization isn't going to pay off unless the Wii U starts selling better, so most aren't going to bother.
 
Well, who's ready to start guessing at the specs for Nintendo's next-next generation console? I'm guessing... an 8-Core PowerPC CPU @ 2GHz with a 10nm manufacturing process, an AMD GPU clocked at 850MHz with an output of 4.5TFLOPS, 12GB of GDDR5 RAM (10GB usable) aaaand...maybe a 64MB eDRAM framebuffer? (by the year 2018, there will be significantly faster RAMs than GDDR5).
 
2018? if Wii U sales don't pick up this holyday season, i can totally see Nintendo killing off the system early, and going for a new console in 2016.
 
What you also have to keep in mind is that Espresso is only a 32-bit CPU, which limits the RAM to ~3,5GB. So they will have to switch to a different architecture in any case.
Power-A2 is a 64-bit CPU, but an in-order design, so maybe a die-shrinked custom chip based on the Power7 (again *g*).
Power8 will also come next year on a 22nm process, so could very much be based on this one.
ibm_power_processor_roadmap.jpg

In any case I wouldn't expect anything that isn't at least on the horizon (both architecture and process node wise) already at the moment.
Other possibilities would be a successor to the Jaguar chips in PS4/XB1 or something ARMv8 based.
 
i was little bit shocked to discover the OS for the Wii U takes up about 3-4GB.

It made me wonder if some of the flash memory is accessible to devs for low bandwidth applications.

Has there been any discussion on this? Is it even possible? because it seems like a neat solution.
 
What you also have to keep in mind is that Espresso is only a 32-bit CPU, which limits the RAM to ~3,5GB. So they will have to switch to a different architecture in any case.
Power-A2 is a 64-bit CPU, but an in-order design, so maybe a die-shrinked custom chip based on the Power7 (again *g*).
Power8 will also come next year on a 22nm process, so could very much be based on this one.
ibm_power_processor_roadmap.jpg

In any case I wouldn't expect anything that isn't at least on the horizon (both architecture and process node wise) already at the moment.
Other possibilities would be a successor to the Jaguar chips in PS4/XB1 or something ARMv8 based.

would moving from a 32-bit CPU to a 64-bit CPU really cause that many problems?
 
Well, who's ready to start guessing at the specs for Nintendo's next-next generation console? I'm guessing... an 8-Core PowerPC CPU @ 2GHz with a 10nm manufacturing process, an AMD GPU clocked at 850MHz with an output of 4.5TFLOPS, 12GB of GDDR5 RAM (10GB usable) aaaand...maybe a 64MB eDRAM framebuffer? (by the year 2018, there will be significantly faster RAMs than GDDR5).

GDDR5 wouldn't make sense at that point in time since it'd be going out of production (probably) i'd say DDR4
 
Status
Not open for further replies.
Top Bottom