Support NeoGAF

[Chobel]

That must be the theoretical maximum that the hardware can guarantee under any circumstances, which is not necessarily the amount of real bandwidth that the running software will demand. How the other number comes into existence, nobody really understands.

That would make sense if GPU can read/write simultaneously all the time, but DF said that happens only in certain operations. In the other operations GPU can't write and read simultaneously so the max bandwidth will be 109GB/s so the minimum BW will be less than 109GB/s.

 

[BruiserBear]

Don't say "they managed this" and then post a fucking bullshot which looks 10times better than the actual game and doesn't factor in the bad framerate. From a technical standpoint, Last of Us is a severly flawed game. And it's quite bad for 2013 standards. If anything your pointing out quite the opposite of what you intended - consoles are too weak and it shows, making devs compromissing the quality of their titles on technical AND gameplay layers.

I suspect this is an opinion from people who play games on PC regularly. I don't, and never once did I feel like the performance of TLOU was a problem.

 

[Klocker]

Seriously, can we ditch "XBOne"? It sounds stupid and juvenile. Can't we just all agree to use "XBO" instead? .

I thought it was stupid but have now embraced it much like people now embrace "Obamacare"... use it yourself and it takes away the power of the insult.

 

[Radec]

Make it X1 one letter less to type..

Xbone is better.

 

[Drek]

If you don't believe that the eSram is capable of simultaneous read/write and MS is full of it, then the true theoretical peak is only 109GB/s, although MS specifically notes that they've already been able to achieve 133GB/s with alpha blending operations (FP16x4) So take that with as many grains as you like.

I'd imagine the ESRAM in the 360 is capable of "simultaneous" read/write ops if by simultaneous they mean only using half of the bus for each or if it's actually interleaved read/write ops.

Otherwise, sorry, no, electrons are still matter. You can't put 8 cars side by side on a four lane highway and you can't push more data down a pipe than it can fit at one time. You don't get to magically double the numbers and act like it's legitimate.

Just like how their "133GB/s" number is bullshit if it's meant to refer strictly to the ESRAM and is likely double stuffing the GPU from both the ESRAM and the DDR3 (109GB/s + 68GB/s, minus some cost to keep filling the 32MB of ESRAM aligns pretty well with 133GB/s).

 

[Klocker]

Ok so lets wait until they explain how it works. In the meantime there is no reason to doubt that they clearly have indicated that it is happening.

so to me its no different than believing something Sony has told us about their hardware.

 

[vdo]

Xbone is better.

Looks like it's time to dig up this pic

 

[SEGAvangelist]

Xbone is better.

That's like saying Poopstation. Hmm... I like the sound of that.

 

[xxracerxx]

Xbone is better.

XBO is better still.

 

[Chobel]

Ok so lets wait until they explain how it works. In the meantime there is no reason to doubt that they clearly have indicated that it is happening.

so to me its no different than believing something Sony has told us about their hardware.

Everything Sony said can be proved mathematically. So it's not just believing.

 

[Zatoichi's Cane]

Don't say "they managed this" and then post a fucking bullshot which looks 10times better than the actual game and doesn't factor in the bad framerate. From a technical standpoint, Last of Us is a severly flawed game. And it's quite bad for 2013 standards. If anything your pointing out quite the opposite of what you intended - consoles are too weak and it shows, making devs compromissing the quality of their titles on technical AND gameplay layers.

oh Jesus, please stop. Just nonsense....

 

[Vizzeh]

With the 32mb EsRam, is it not just easy to ignore this memory and assume microsoft will "possibly" be able to achieve a 1080p picture with or without MSAA and focus on the other memory.

We know the GDDR5 pool will easily be able to match what the EsRAM does in its 8GB pool (unless latency is an issue, which apparently its not, or a Negligible difference)

Also assuming the cpu's are fed efficiently with their bandwidth (30/20GB/s) it boils down to "GPU spec X1 v PS4 + 68GB/s DDR3 vs 176GB GDDR5", so focusing on those features we will see more stable fps, higher resolution/detailed textures and more possibilities happening at once. This excludes ofc Huma, programing skill, API's, GPGPU. I know this is a massive generalization. Just curious how this will work realworld.

 

[kitch9]

That's like saying Poopstation. Hmm... I like the sound of that.

Yeah.

No.

 

[SenjutsuSage]

It's hard to say actually, because 10MB of EDRAM seemed to serve the Xbox 360 rather well for quite some time, and even that wasn't considered to be enough in a variety of ways at the very start of the Xbox 360's life, but developers made do.

In the case of 32MB, it's been said that this is perfect for a part targeting 1080p with a decent level of AA, so while it may not be a more aggressive 64MB, or an even more insane 128MB, 32MB may end up being all they really ever need this gen.

Everything Sony said can be proved mathematically. So it's not just believing.

This isn't really a versus thread, but don't you think Microsoft's people would at least be smart enough to make the bandwidth perfectly add up to 218GB/s? Simply because you can't find a mathematical rationale for it doesn't mean there's no way it can be true. Going based on past evidence, a lot of people also greatly questioned Microsoft's claim about the 256GB/s from the EDRAM on the Xbox 360, and that turned out to be true, so I don't see why there's this desire to think that Microsoft are being completely dishonest with this. They've just about acknowledged everything else. GPU TFLOPs, GPU clock speed, CPU clock speed, and a range of other figures. Even leaving out the 204GB/s 109 + 68 already gives you a higher number than the competition if that's truly all they were after, so clearly there's more going on here than we think, and our lack of understanding doesn't have to automatically mean it isn't true. The only difference between then with the 360, and now with the Xbox One, is that we don't have an article from Dave Baumann this time explaining what's going on with the EDRAM's bandwidth.

http://www.beyond3d.com/content/articles/4/3

And with regards to many things that Sony tells us about the PS4, it isn't accurate to say that everything they've ever told us about the PS4 can be verified mathematically, because that isn't exactly true. There's things Sony has said where math simply isn't a factor that can be used to verify what they've said. You either believe them that they took these kinds of steps to better optimize the PS4 hardware and so have the kind of capability that they claim, or you don't. Just as I see very little cause for doubting what Sony tells us about their hardware, I also similarly see very little reason in doubting what Microsoft tells us about theirs. We now have it directly from MS that eSRAM is capable of reading and writing simultaneously. I'm certain an explanation will come, and when it does, it will be up to people to accept it and move on, or treat it as a dishonest claim.

 

[omonimo]

With the 32mb EsRam, is it not just easy to ignore this memory and assume microsoft will "possibly" be able to achieve a 1080p picture with or without MSAA and focus on the other memory.

We know the GDDR5 pool will easily be able to match what the EsRAM does in its 8GB pool (unless latency is an issue, which apparently its not, or a Negligible difference)

Also assuming the cpu's are fed efficiently with their bandwidth (30/20GB/s) it boils down to "GPU spec X1 v PS4 + 68GB/s DDR3 vs 176GB GDDR5", so focusing on those features we will see more stable fps, higher resolution/detailed textures and more possibilities happening at once. This excludes ofc Huma, programing skill, API's, GPGPU. I know this is a massive generalization. Just curious how this will work realworld.

wait a minute... now it's ps4 who need to match the esram? I think the problem was otherwise.

 

[Vizzeh]

wait a minute... now it's ps4 who need to match the esram? I think the problem was otherwise.

I dont mean match as such in that sense, i mean nullify it. In theory the GDDR5 can do what the esram and more (as I said providing latency isnt an issue, which cerny said isnt.)

 

[Jonboy]

No more. My head hurts. Lets just play games.

Seriously. All these threads should be locked immediately. There's just no point anymore until we have an actual teardown of the retail units and even more importantly...start seeing more games.

 

[omonimo]

I dont mean match as such in that sense, i mean nullify it. In theory the GDDR5 can do what the esram and more (as I said providing latency isnt an issue, which cerny said isnt.)

It's not Cerny who said this, it's the logic. CPU is not 64 bit.

 

[ekim]

With the 32mb EsRam, is it not just easy to ignore this memory and assume microsoft will "possibly" be able to achieve a 1080p picture with or without MSAA and focus on the other memory.

We know the GDDR5 pool will easily be able to match what the EsRAM does in its 8GB pool (unless latency is an issue, which apparently its not, or a Negligible difference)

Also assuming the cpu's are fed efficiently with their bandwidth (30/20GB/s) it boils down to "GPU spec X1 v PS4 + 68GB/s DDR3 vs 176GB GDDR5", so focusing on those features we will see more stable fps, higher resolution/detailed textures and more possibilities happening at once. This excludes ofc Huma, programing skill, API's, GPGPU. I know this is a massive generalization. Just curious how this will work realworld.

Disclaimer: I'm not really knowledgable on this topic but I do my best to educate myself by reading articles and forums. So please correct me if I'm wrong.

The latency of the Esram on Xb1 is another league compared to the latency of GDDR5. A cache miss on the X1 GPU won't end up with hundreds of wasted cycles for the CU waiting for the data - maybe rather a two digit number.

 

[Zatoichi's Cane]

In typical rendering workflows you read and write a lot from and into pixelbuffers. Those buffers have sizes that depend (1) on the target resolution and (2) on the information stored per pixel (e.g. color). Buffers may holdthe actual screen content or intermediate information in two-pass renderers [1]. The size of such buffers is the product of the number of pixels and the information per pixel, e.g. ~23,8MB at 1080p with 12 bytes of information per pixel. So a pool o 32MB is big enough for many scenarios but might be limited for some. KZ:SF, for instance, has render targets with over 40MB of total size.

Nevertheless, statements like "Only 32MB, lol" are plain wrong.

[1] http://en.wikipedia.org/wiki/Deferred_shading

If let's say KZ:SF was to be released on XB1, would the developer have to decrease the total number of pixels to get render targets below 40mb of total size since the eSRAM is 32mb?

could someone please help me make sense of this?

 

[Zatoichi's Cane]

EDIT:
This is the best I could come up with, sorry if its too large.

 

[Drek]

Disclaimer: I'm not really knowledgable on this topic but I do my best to educate myself by reading articles and forums. So please correct me if I'm wrong.

The latency of the Esram on Xb1 is another league compared to the latency of GDDR5. A cache miss on the X1 GPU won't end up with hundreds of wasted cycles for the CU waiting for the data - maybe rather a two digit number.

Which has an incredibly low rate of occurrence in game related tasks, and if you have a cache miss the 32MB of ESRAM's super low latency isn't going to suddenly resolve the impact of that on the DDR3, so unless it is an incredibly low memory requiring app you're still going to have a comparable number of wasted cycles as GDDR5 while the main memory catches up.

 

[anexanhume]

So how would that make it any cheaper to build XB1's APU than PS4s, assuming they are getting worse yields? If they both listed BOMs assuming 100% yield then they both would be wrong and you could theoretically calculate the cost of any chip based on size alone. I'm pretty sure that's not how it works and I'm having trouble getting your point. If two manufactures list identical BOMs and one or both fudge the numbers, then how does that benefit anyone.

How do we even know that BOM estimators assume different yields? Would they be privy to that information? They also don't know the APU size on the PS4. There's not enough info out there.

 

[Chobel]

A big chunk of text + something about adding bandwidths

1) First of all please don't just add up bandwidths, that's not how things work.

2) MS (representatives) lied multiple times, so it's really hard to trust them now, especially when they announced numbers that can't be proved (for now). They may be not lying, and this what we're doing in this thread discussing the possibilities and trying to see what we're missing.

3) I should change what said about Sony to this "The numbers Sony gave don't contradict real world" and that's what they got a pass from me.

 

[Vizzeh]

It's not Cerny who said this, it's the logic. CPU is not 64 bit.

Is it not X86-64 - - ok Cerny also said it :

Mark Cerny: "Latency in GDDR5 isn’t particularly higher than the latency in DDR3. On the GPU side… Of course, GPUs are designed to be extraordinarily latency tolerant so I can’t imagine that being much of a factor"

 

[Klocker]

1) First of all please don't just add up bandwidths, that's not how things work.

2) MS (representatives) lied multiple times, so it's really hard to trust them now, especially when they announced numbers that can't be proved (for now). They may be not lying, and this what we're doing in this thread discussing the possibilities and trying to see what we're missing.

3) I should change what said about Sony to this "The numbers Sony gave don't contradict real world" and that's what they got a pass from me.

just because they have not yet revealed to us how the ESRAM is getting 204 GB/s exactly does not mean it's not true. Just because we can not figure it out does not mean it's not true.

they have said clearly and multiple times that they CAN read and write on same cycle (evidently with some overhead) so until we know the details it is not out of line IMO to take their word...

assuming everyone is lying to us all the time is fair in a few places in society but in general not a real fair way to approach things being told to us that will eventually be able to be proven IMO

question or ask for proof? sure. assume liars? not really

 

[SenjutsuSage]

1) First of all please don't just add up bandwidths, that's not how things work.

2) MS (representatives) lied multiple times, so it's really hard to trust them now. especially when they announced numbers that can't be proved now. Now they may be not lying, and this what we're doing in this thread discussing the possibilities and trying to see what we're missing.

3) I should change what said about Sony to this "The numbers Sony gave don't contradict real world" and that's what they got a pass from me.

I've heard this you don't just add bandwidth thing a number of times now, and, listen, people understand that the two pools of memory are separate and not the same thing, but the graphics card, from the very earliest of leaks, has been confirmed as seeing both in a similar fashion, and is able to read and write from both eSRAM and DDR3 simultaneously. So, think about it however you wish to think about it, but just know the graphics card on the system can access both pools of memory simultaneously, so you're never dealing with a case where the GPU only has access to the 68GB/s from the DDR3, or a situation where the GPU only has access to the 109GB/s minimum from eSRAM, and I'll just overlook the peak theoretical, because it's not important to the core point.

And, beyond that, it wasn't my intent to just combine them as if they are apart of a single pool, but both pools of memory are capable of contributing to overall system performance simultaneously, so they are literally working together. The memory bandwidth isn't magically disappearing on one of the two pools when both are utilized, so whether or not you choose to add them or not, the console derives bandwidth benefits from both pools at all times, never just one.

And, beyond that, Microsoft gave an honest presentation at the hot chips presentation about the Xbox 360, and I see no signs that they aren't being honest about the Xbox One, so I believe their peak theoretical number for eSRAM. I see no reason for them mentioning the 109GB/s minimum if they intend to deceive us. Just like I take Sony at their word on their hardware, I'm doing the same with regards to Microsoft.

 

[Portugeezer]

We can't criticise MS for using DDR3, it was expected. PS4 using GDDR5 for everything was an unexpected surprise.

The 32MB ESRAM is great, but 32MB seems tiny.

 

[SenjutsuSage]

We can't criticise MS for using DDR3, it was expected. PS4 using GDDR5 for everything was an unexpected surprise.

The 32MB ESRAM is great, but 32MB seems tiny.

So did 10MB on the 360.

With tiled resources 3GB worth of texture data can be fit on just 16MB of memory.

http://www.tomshardware.com/news/DirectX-11.2-Tiled-Resources-Xbox,23322.html

Suddenly 32MB starts to seem like quite a bit. And it's confirmed that you can texture from the eSRAM.

 

[turk3y]

So using Microsofts logic in working out Memory bandwidth including gpu/cpu cach etc, PS4 is 216GB/S then?

no, remember the esram is different physical ram so its bandwidth per second is on top of system memory as you can access both at once, but its still only 68 to the ddr3 portion not the combined figure.

wasnt 130GB/s the practical peak though.

that was a "real" figure obtained on hardware apparently through testing and not off a spec sheet, there has been no equivalent Sony numbers.

 

[heelo]

How do we even know that BOM estimators assume different yields? Would they be privy to that information? They also don't know the APU size on the PS4. There's not enough info out there.

I've never seen a detailed breakdown of the BOM, and when I've seen the rough estimates with PS4 costing ~$100 more, I've always chalked it up entirely to the cost of Kinect being slightly more expensive than $100, and MS saving about $20 on the GPU.

 

[Chobel]

just because they have not yet revealed to us how the ESRAM is getting 204 GB/s exactly does not mean it's not true. Just because we can not figure it out does not mean it's not true.

they have said clearly and multiple times that they CAN read and write on same cycle (evidently with some overhead) so until we know the details it is not out of line IMO to take their word...

assuming everyone is lying to us all the time is fair in a few places in society but in general not a real fair way to approach things being told to us that will eventually be able to be proven IMO

question or ask for proof? sure. assume liars? not really

I didn't they're 100% lying. I think you missed this part from my comment "They may be not lying, and this what we're doing in this thread discussing the possibilities and trying to see what we're missing."

 

[3rdamention]

I think it is time to draw the digital line. Xbox One will be out in November and I think there is going to be a lot of trolls crying here. Either way when the console comes out this forum will likely be on fire. So in order to try to put it out some gasoline on this fire I will ask those interested to stand up and be counted.

I feel Xbox One is a great console, likely to be better than most that will come out this year. I certainly feel it is the best console Microsoft has ever made. I also believe the press and gamers alike will believe this. This puts me in the “For” camp.

I know there are many who feel strongly in opposite camp. I also would ask you to stand up and say “Against”.

When the console is released and everyone plays the games all the speculation will be over. If I am wrong and gamers in general think the console is “crap” then I am comfortable with getting tagged “Owned by the GAF”.

However, if I am right and it is received well, I would like to see those “Against” to be tagged with “Owned by Xbox One”.

I would like to make a honorary invitation to EvilLore and Duckroll who help fuel the fire on a regular basis – assuming you both would be “Against”. In the end though, it is your decision and I want to remind everyone that I have an advantage of actually playing the games.

I invite anyone who seeing someone trolling Xbox One in other threads to point them here.

So it’s time to be stand and be counted:

GavinGT - “For”

So you think what about the esRAM? I am totally confused now.


On topic.....


How the esRAM is used and how it helps game development will be determined by developers. We will have to wait for game performance, especially from multiplats..

 

[SEGAvangelist]

So you think what about the esRAM? I am totally confused now.


On topic.....


How the esRAM is used and how it helps game development will be determined by developers. We will have to wait for game performance, especially from multiplats..

It's a joke. He worded it just like the famous Denis Dyak post.

 

[PSGames]

I view Xbone in the same vein as M$. Just seems a bit juvenile but whatever.

So did 10MB on the 360.

With tiled resources 3GB worth of texture data can be fit on just 16MB of memory.

http://www.tomshardware.com/news/DirectX-11.2-Tiled-Resources-Xbox,23322.html

Suddenly 32MB starts to seem like quite a bit. And it's confirmed that you can texture from the eSRAM.

Doesn't the frame buffer take up the vast majority of the esram space?

 

[tinfoilhatman]

So you think what about the esRAM? I am totally confused now.


On topic.....


How the esRAM is used and how it helps game development will be determined by developers. We will have to wait for game performance, especially from multiplats..

My question is how well "automated" will it be for developers......for example MS announced awhile back that tiling will now be handed auto-magically for devs but what about other uses for the ESRAM how much work will be involved for the devs?

 

[SenjutsuSage]

I view Xbone in the same vein as M$. Just seems a bit juvenile but whatever.

lol surprised the thread turned into this, but, yes, people who refer to it that way are usually doing so in a derogatory fashion, and it usually helps you predict whether their statement on the console will be a positive one or a negative one.

 

[Klocker]

I didn't they're 100% lying. I think you missed this part from my comment "They may be not lying, and this what we're doing in this thread discussing the possibilities and trying to see what we're missing."

yes at work sorry missed that.

 

[Prince Vultan]

I feel Xbox One is a great console, likely to be better than most that will come out this year.

Indeed, I think we can all agree that Xbone is definitely going to be better than most of the new consoles coming out. Should at least be the second best console to come out this year.

 

[Chobel]

This time a big chunk of text about adding up bandwidth

Sorry for this late response I had to do some research in Neogaf.
Now, it's Actually bad for GPU to use DDR3, because it's slow external memory bandwidth. Don't take my word for it, Take yours .

Also a fast read/write on chip memory scratchpad (or a big cache) would help a lot with image post processing. Most of the image post process algorithms need no (or just a little) extra memory in addition to the processed backbuffer. With large enough on chip memory (or cache), most post processing algorithms become completely free of external memory bandwidth. Examples: HDR bloom, lens flares/streaks, bokeh/DOF, motion blur (per pixel motion vectors), SSAO/SSDO, post AA filters, color correction, etc, etc. The screen space local reflection (SSLR) algorithm (in Killzone Shadow Fall) would benefit the most from fast on chip local memory, since tracing those secondary rays from the min/max quadtree acceleration structure has quite an incoherent memory access pattern. Incoherent accesses are latency sensitive (lots of cache misses) and the on chip memories tend to have smaller latencies (of course it's implementation specific, but that is usually true, since the memory is closer to the execution units, for example Haswell's 128 MB L4 should be lower latency than the external memory). I would expect to see a lot more post process effects in the future as developers are targeting cinematic rendering with their new engines. Fast on chip memory scratchpad (or a big cache) would reduce bandwidth requirement a lot.

And, beyond that, Microsoft gave an honest presentation at the hot chips presentation about the Xbox 360, and I see no signs that they aren't being honest about the Xbox One, so I believe their peak theoretical number for eSRAM. I see no reason for them mentioning the 109GB/s minimum if they intend to deceive us. Just like I take Sony at their word on their hardware, I'm doing the same with regards to Microsoft.

I could swallow that 204 number, but 109GB/s min it's just so weird. DF said that simultaneous read/write happens only in certain operations. In the other operations GPU can't write and read simultaneously so the max bandwidth will be 109GB/s so the minimum BW will be less than 109GB/s, way less.

 

[marvin83]

Is it not X86-64 - - ok Cerny also said it :

Mark Cerny: "Latency in GDDR5 isn’t particularly higher than the latency in DDR3. On the GPU side… Of course, GPUs are designed to be extraordinarily latency tolerant so I can’t imagine that being much of a factor"

I can't believe people are still bringing up latency in these PS4/Xbone threads. It's been proven, on the memory manufacturers data sheet, that the latency of GDDR5, in nanoseconds, is less than that of DDR3. The memory is manufactured by Hynix and someone posted it somewhere some months back.

This is not at you, just in general in earlier posts in the thread.

 

[SEGAvangelist]

lol surprised the thread turned into this, but, yes, people who refer to it that way are usually doing so in a derogatory fashion, and it usually helps you predict whether their statement on the console will be a positive one or a negative one.

Not to mention the word derails interesting threads like this one. I really hope we get that AMA with an engineer like A-Pen mentioned. It should clear things up quite a bit... maybe. lol

 

[Curufinwe]

I call it Xbone because it's easier to type than Xbox One

Especially on a phone.

 

[BruceLeeRoy]

Gavin that was pretty well done.

 

[ekim]

Which has an incredibly low rate of occurrence in game related tasks, and if you have a cache miss the 32MB of ESRAM's super low latency isn't going to suddenly resolve the impact of that on the DDR3, so unless it is an incredibly low memory requiring app you're still going to have a comparable number of wasted cycles as GDDR5 while the main memory catches up.

Well isn't it that CU cores mostly wait for data? Assuming this is true and the data to be read lies in the ESRAM and not the main RAM you have barely idle cycles especially since the move engines can independently move data from the DDR RAM into the ESRAM in parallel while processing this data in the same time.(compression/decompression of textures, tiling, untiling - which are normally also GPU tasks)

 

[astraycat]

Disclaimer: I'm not really knowledgable on this topic but I do my best to educate myself by reading articles and forums. So please correct me if I'm wrong.

The latency of the Esram on Xb1 is another league compared to the latency of GDDR5. A cache miss on the X1 GPU won't end up with hundreds of wasted cycles for the CU waiting for the data - maybe rather a two digit number.

L1, which is on the CU, probably has >100 cycles of latency. A miss is going to cost more than that.

 

[SenjutsuSage]

I view Xbone in the same vein as M$. Just seems a bit juvenile but whatever.



Doesn't the frame buffer need to be held in esram though? How much space would that take?

Apparently the entire framebuffer doesn't have to be inside ESRAM from the looks of things.

Early dev documentation that I'm looking at seems to suggest that the front buffer is in DRAM, so that should be helpful as far as space inside ESRAM is concerned. In addition to that, a dev isn't exactly required to pump 3GB of texture data into ESRAM at one time. They can just as easily get away with using less, and then use the move engines to bring in more data into ESRAM as it's required.

L1, which is on the CU, probably has >100 cycles of latency. A miss is going to cost more than that.

But presumably still quite a bit less than if that ESRAM were a pool of GDDR5 when a cache miss occurred, right?

 

[squidyj]

I suspect this is an opinion from people who play games on PC regularly. I don't, and never once did I feel like the performance of TLOU was a problem.

I play games on PC all the time, I didn't have any problems with TLOU

 

[artist]

In the case of 32MB, it's been said that this is perfect for a part targeting 1080p with a decent level of AA, so while it may not be a more aggressive 64MB, or an even more insane 128MB, 32MB may end up being all they really ever need this gen.

The ESRAM is in 8MB blocks right? Not sure why they would need to double or quadruple it? That (128MB ESRAM) was not what I was insinuating at all ..

I figure 8MB more ESRAM would ~30mm2 at most.

Keep saying Xbone. It's an immediate indication of where your allegiance lies.

Oh wow .. first the "Poopstation" comment and this. Some people are seriously trying hard to derail this thread for obvious reasons.

 

[ekim]

L1, which is on the CU, probably has >100 cycles of latency. A miss is going to cost more than that.

L1 is really that much? I actually used this article:
http://www.sisoftware.net/?d=qa&f=gpu_mem_latency&l=en&a=

And extrapolated these numbers from there. Maybe I was to generous towards the ESRAM but my point was, that the number of wasted cycles is lower.