Wii U hardware discussion and investigation *rename

I think he is referring to on die edram.

 

Well, Microsoft did it two times on the XB360, so it probably pays off.

 

Quoting myself: Could someone please answer this? Thx!

 

That wasn't the relationship. But as it's OT I'll have to let it go!

Yeah, I was referring to on die edram with the comment AIStrong quoted, but as I've jumped around a lot, talking about a number of consoles (including a lot of 360) that wasn't clear. The 360 seems to be a bit of an anomaly with it's never-integrated daughter die, and it's fair to point out there are additional costs associated with it.

I can't see Nintendo going this route though. I hope they use an "APU" (to use AMD's term) and that it has a large pool of on die edram that can be used as developers wish. I think that's probably the ideal way to structure a console chip where you want to maximise performance per watt and performance per $ over the life of the system.

Paying for all your memory to have high bandwidth makes a lot of sense on a PC graphics card, but to me not so much on console where buffer sizes are probably smaller and more predictable. I think Nintendo probably see it this way too.

 

Yeah, bandwidth to on die edram is unlimited for all intents and purposes.

 

Didn't know about the first one. So it was 3 times in fact, because they are already @45nm, no?

 

I think the edram might still be 65 nm. The move from NEC 90nm to TSMC 80nm may have also been driven by the need to reduce thermal issues contributing to RROD. Did MS ever confirm 80nm or did they keep quiet about it?

It could be that they can't shrink the daughter die (containing the edram) any further because of I/O requirements and so there's no point in going further, or it could be there's no suitable process that's smaller or that's cost effective.

 

Hurm, well, on-chip buses can burn quite a bit of power too, probably a reason why Cell's on-chip bus runs at only half core clock for example.

 

eDRAM on-die or on a daughter chip, like any memory pool, requires a bus to be addressed. And that has a variable cost depending on the type of interface the engineers choose to go with.

And since someone talked about the memory requirement for the various frame buffers for the Xbox 360, I'll just point to Wavey's excellent article on C1 for the formula:
http://www.beyond3d.com/content/articles/4/5

While I'm at it, I'll also link to the PS3 hardware scaling capabilities article, since it has also been mentioned:
http://www.beyond3d.com/content/articles/16/

Oh, and thanks y'all for the positive feedback on the article!

 

It's tiny so it could be workable but for some reason it doesn't add that well with earlier rumors about system even though I know devs doesn't seem to know the final specifications.

Say we're looking at four low clocked OoO powerPC cores sharing between 2 and 4 MB of L2, a 320SP custom GPU R7xx and 16 MB of on board scratch pad memory, I feel like most returns and rumors would have been a bit more flattering for the system. My belief is that the system would run most games @ 1080p with the same perfs as the PS360 (or close to 1080p as lot of games are close to 720p nowadays). Even @720p the advantage would also be significant (not a generational jump for sure but still), more shading power (more and more efficient architecture), high quality textures filtering, and some neat gains vs what happened with the 360 as the scratch pad memory would be available to the GPU ALUs without having to write back to main RAM. Then there is the amount of RAM 1 GB would be enough to make a significant difference too.
All this taken in account I believe that the difference would be perceivable even at early level of development.

Anyway I somehow hope you're right as my wife would happily welcome a N system in our place and so I will if the system get rid on some of the most offending defaults of this gen even if it doesn't bring the whole thing to another level.

 

They cost anywhere between 10x to 100x less power than off die buses.

 

I just looked through the IBM press release again, and I'm now almost certain that we're looking at an SoC and the eDRAM won't be L3 cache:

The way they describe the purpose of the eDRAM doesn't scream L3 cache to me. Were it cache, they'd probably have written just that. "Feeding data" sounds like a memory pool to me. And the press release calls it a "silicon package", which could very well mean an APU, in which case that memory pool would almost certainly be shared between CPU and GPU.

 

But they decisive wrote [...] capable of feeding the multi-core processor large chunks of data [...]. This is exactly what a cache does, no?
You are right on the "silicon package" passage though, this really sound like a SoC.

 

Sure, but I still think they'd say cache if it were cache. Looking through IBM's archives, they actually built chips were the eDRAM wasn't used as L3 cache (Cu-32).

 

They are building the POWER A2/EN where it's used as L2, that's it.

 

http://www.computerweekly.com/Artic...il-true-superfast-network-chip-technology.htm

 

If IBM wanted to say SoC dont you think they would have just said it?
Instead, maybe they are actually saying SoP.

System on a Package.

http://itmanagement.earthweb.com/datbus/article.php/3881086/Is-IBMs-Foundry-Business-Next-to-Go.htm

http://news.cnet.com/IBM-connects-chips-for-better-bandwidth/2100-1006_3-6175355.html


Check out the 3D system roadmap

http://wenku.baidu.com/view/38da00d9d15abe23482f4d59.html

http://fuji.stanford.edu/events/spring01/slides/shermanSlides.pdf


Could this be the direction that Nintendo is taking with the WiiU?

http://ecadigitallibrary.com/pdf/58thECTC/s13p1p49.pdf