hated_individual said:
drkohler said:
hated_individual said:
binary solo said:
drkohler said:
Oh look, it's MisterXMedia all over again. Didn't know there is such a moron in the WiiU camp, too..
And yes, 550MHz*1024bit is 560 gigaBITS/s, NOT gigaBYTES/s.... (you forgot to input that Wii U eDRAM in GPU is not a single macro, it is eight macro's, your calculation/math is correct for a single macro but not all eight of them). |
So actually 70.4GB/s then. (per macro)
|
drkohler's calculation is for a single macro not all eight macro's combined, he forgot to input in his own calculation that Wii U has eight and not one macro.
A proper calculation would have bee; 550MHz times 1024 bit times 8 equals 563.2 GB/s
|
Good Lord... I actually spent (wasted..) almost an hour googling around on the internet to see where these numbers come from. I found one troll on a forum who got to a 8192bit wide bus and this mystical 560GB/s number. Unfortunately this troll was posting on a technology forum, so he was immediately ridiculed into silence. That "troll" was probably right and there is proof to his theory while nobody presented any proof/evidence against it also if 563.2GB/s bandwidth was mystical then Sony would not have considered an option to have a bandwidth of 1 TB/s for PlayStation 4 if they used eDRAM/eSRAM.
Apparently "macro" is the new buzzword now that magically creates big numbers.
Since when a word "macro" is a buzzword?? Because it is not a buzzword and since when it apparently magically creates big numbers?
I have no idea what the expression "macro" means here, It is not an expression, it is a word used involving eDRAM since meaning of "macro" is basically a blocks. One macro is a block.
so would any of you "macropeople" answer the following questions:
1. Do you know how much die space and how much power memory controlers require for driving a 8192bit bus? - assuming 32 (!) proprietary 256bit controlers or 128 (!!) conventional 64bit controlers at 40 (45?)nm process nodes? If you got the same number as me, didn't it raise a flag in your brain, just by looking how large the entire gpu die actually is?
Do you know that we aren't talking about 8192bit bus at all, we are talking about 8 buses each having being 1024bit not a single 8192bit bus. @underlined It would have, a decade ago and this didn't stop Xbox 360 with internal bandwidth with each of 5 2MB macros having 1024bit bus in 2005.
2. Where on the die shot are all those memory controlers? Ho many metal layers would you find to connect all of this (Hint: the Jaguar cpu only needs 11, and it has a measly 256bit bus)?
Why you ask me, you can't see? Also CPU=/=GPU.
3. Why on earth would Microsoft go with a measly 109GB/s bus in the XBox One apu managed cache, if they could easily achieve twenty times the bandwidth with this magic WiiU technology?
Since when something possible is magic, don't make me laugh. I guess you are not competent enough to answer your own questions, I don't know if I should laugh at you or pity you for not being able to answer simple and for you being narrow minded. Microsoft choose (2x512bit?)eSRAM with "measly" 109GB/s of bandwidth because it was either good enough for them or to lower percentage of defective yields/chips rather than use more complex/expensive eDRAM. They balanced on both cost and percentage of successful chips plus eDRAM is risky on 28nm node and that is why you don't see any producting using it and Intel is only manufacturer that makes chips with eDRAM on 22nm.
40nm is now mature and well developed node while chip/fabrication manufacturers are "just now" at 28nm while Intel is leading one with 22nm for couple of years and has struggles with 14nm node. The lower node the higher is chances of a defective/failed chip.
4. Why would Nintendo engineers create a cache system that is way, way, way, way, way, too fast for the cpu/gpu system?
Nothing is too fast and you could easily come up with an answer on your on. First of all Shin'en confirmed that in Wii U the CPU can access and use eDRAM in GPU as a "scratchpad memory" thus it could also be used as an L3 Cache(?) plus considerable benefits for performance of a GPU, twice the bandwidth can benefit up to 30-40% higher performance.
So after we have correctly pondered over all those minor (lol) questions, the result can be summarised as follows: 550MHz * 128Byte/s = 70GB/s is the WiiU edram bandwidth speed. For a single macro/block...
|
|
sorry, wrong guy
as for why micro went with esram instead of sticking with edram well that has been exposed already
here
http://www.eurogamer.net/articles/digitalfoundry-vs-the-xbox-one-architects
"
"This controversy is rather surprising to me, especially when you view as ESRAM as the evolution of eDRAM from the Xbox 360. No-one questions on the Xbox 360 whether we can get the eDRAM bandwidth concurrent with the bandwidth coming out of system memory. In fact, the system design required it," explains Andrew Goossen.
"We had to pull over all of our vertex buffers and all of our textures out of system memory concurrent with going on with render targets, colour, depth, stencil buffers that were in eDRAM. Of course with Xbox One we're going with a design where ESRAM has the same natural extension that we had with eDRAM on Xbox 360, to have both going concurrently. It's a nice evolution of the Xbox 360 in that we could clean up a lot of the limitations that we had with the eDRAM.
"The Xbox 360 was the easiest console platform to develop for, it wasn't that hard for our developers to adapt to eDRAM, but there were a number of places where we said, 'gosh, it would sure be nice if an entire render target didn't have to live in eDRAM' and so we fixed that on Xbox One where we have the ability to overflow from ESRAM into DDR3, so the ESRAM is fully integrated into our page tables and so you can kind of mix and match the ESRAM and the DDR memory as you go... From my perspective it's very much an evolution and improvement - a big improvement - over the design we had with the Xbox 360. I'm kind of surprised by all this, quite frankly."
"
basically they went with esram so that they could flow data into the ddr3 ram
but of course there is a trade off
esram is way more expensive than edram, you require about 4x to 6x more transistors depending on the design, so obviously if micro would have gone edram again they could have afforded for edram with huge bandwidth, but since they wanted to use that trick of micing esram and ddr3 well some sacrifices had to be done, but 200GB/s and fully integrated in the gpu and not having it in a separerate die and also the adventages of almost no latency and of course that trick that mico wanted to implement seems the right choice
as for instance, 360 edram 256GB/s were only accessible by the ROPS cause the edram and ROPS were in the same die chip, but later the result that had to be passed to the GPU framebuffer had be done trough a extrnal bus of 32GB/s. Now there is no external bus on xbox one or wii u, the edram is completely accessible to all the GPU, not just the ROPS
at the edn of the day, those 200GB/s with less latency could perform as good as the 563GB/s (or more cuase the example uses the old 1024bits design from nec 7 years ago) if well used, and also has the adventage of mixing the compoennt with ddr3 could maybe outperform it at some degree
