w1gglyjones
Member
Nintendo picked 32 MB also so it must be enough... rite?
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
About the Xbone's ESRAM size ..
- Thread starter artist
- Start date
Very old article before ms revised its esram bw... now total aggregate is over 270 iirc
Actual esram is 204. Theoretical peak
REMEMBER CITADEL
Banned
Old articles are old. Good job, as usual.
Not sure to understand... you mean 204 GB of bandwith? How?
Intel probably needs more memory given the type of CPU (general purpose); and nature of the workload IMO.
wasnt 130GB/s the practical peak though.
If we know anything at all about console development it's that
a) they are always outdated quicker than we hope
b) developers are always crafty about finding workarounds
You could have said the exact same thing about the PS3 having 256MB of main RAM and 256MB VRAM in 2005 compared with the 6-8GB main RAM and 2GB+ VRAM they have now. And it still managed this:
I honestly don't see why this is different.
Problems start with Multiplatforms that don't want to take the extra time to optimize for that.
anexanhume
Member
Yes. No one is arguing that 32MB is a bad size. It's just turning into another debate about what the "real" bandwidth is and how much it helps.
CassidyIzABeast
Member
Well I guess you can since anand said this
and from what we know so far, Microsoft intended to use it as a cache. But i wouldn't be the one ask about this tech stuff, I just thought it was interesting to see DDR3/eRam vs GDDR comparison from someone besides Microsoft so I posted that.
So we should see more than likely 1080p running smooth, just plenty of staircases?
ShinMaruku
Member
Thinking like this is why doscourse has fallen to the way side. You must learn and question or you will get sub par shit.
He's basically pointing out that adding up the various bandwidths within the system are how MS came up with 200GB/s, though that's obviously disingenuous. So yes, he's effectively saying "This is how they come up with the number, and yes it's bullshit."
For what it's worth, this article is old. It's from before MS started parading 192GB/s or whatever they're currently running with as their ESRAM bandwidth number.
Beerman462
Member
What does it matter if it's listed or not? No one gets 100% yield. So whether it's listed on the BOM or not makes no difference, because the cost is still there.
Yes and gddr5 176GB/s is theoretical max as well as is 204 esram and 68 ddr3
OG_Original Gamer
Member
Can you use compression on a render target?
freezamite
Banned
LOL What??? And why would anyone waste that memory on this way? Once the final buffer is calculated you store that buffer onto the main RAM. Having it on the eDram would be a waste of 16MB of that memory in order to save a mere 15MB/frame of memory bandwidth.
You want all the eDram working on actual calculation, not storing useless data that at that point is simply waiting there until it's transferred to the TV.
Didnt cerny do something onChip and the 256 bus to make sure they got the entire 176GB tho
http://www.dualshockers.com/2013/06...r5-ram-and-bus-work-and-why-they-were-chosen/
The The lack of rops suggests alternatives to MSAA (which is going the way of the dodo anyway.) will be prevalent.
anexanhume
Member
But if the BOM estimators figure cost by wafer and how many dies a wafer gives, they may not be accounting for yield. That's my point.
Yes.
Beerman462
Member
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.
If we know anything at all about console development it's that
a) they are always outdated quicker than we hope
b) developers are always crafty about finding workarounds
You could have said the exact same thing about the PS3 having 256MB of main RAM and 256MB VRAM in 2005 compared with the 6-8GB main RAM and 2GB+ VRAM they have now. And it still managed this:
I honestly don't see why this is different.
They sure as heck didn't manage "this" in terms of the final image quality of that game. The game is great, and incredibly well-executed in both gameplay and technical achievement, but please don't post a bullshot (in terms of filtering and AA) as an indication of what was achieved in the hardware, as it either shows you aren't familiar with the game, or you're hoping others aren't.
And using the split 256/256 memory pool for the PS3 did cause constant issues that had to be worked around in a way which wasted resources that would otherwise have allowed more efficient development efforts.
Really? Where I was studying you had the choice to specialise in all 3 fields of cs - technical (hw), practical (sw) and theoretical cs.
I really appreciated these possibilities as they made sure there were always interesting courses available.
Normally, when we talk about cache on a chip, we are talking about a hardware system to automatically buffer main memory into faster store. Then we just go to memory for data, and if it happens to be in the cache we get it much faster. It just happens.
I would call a chunk of fast RAM "scratchpad" instead of "cache." Yes, one might think to manage it with software to work sort of like a cache, but the overhead and complexity would make it a far different animal than a hardware cache.
From the Anandtech article: "All information points to 32MB of 6T-SRAM, or roughly 1.6 billion transistors for this memory. Its not immediately clear whether or not this is a true cache or software managed memory. Id hope for the former but its quite possible that it isnt."
http://www.anandtech.com/show/6972/xbox-one-hardware-compared-to-playstation-4/3
And then from the more recent SemiAccurate series: "To translate from technical minutia to English, good code = 204GBps, bad code = 109GBps, and reality is somewhere in between. Even if you try there is almost no way to hit the bare minimum or peak numbers. Microsoft sources SemiAccurate talked to say real world code, the early stuff that is out there anyway, is in the 140-150GBps range, about what you would expect. Add some reasonable real-world DDR3 utilization numbers and the total system bandwidth numbers Microsoft threw around at the launch seems quite reasonable. This embedded memory is however not a cache in the traditional PC sense, not even close.S|A"
http://semiaccurate.com/2013/08/30/a-deep-dive-in-to-microsofts-xbox-one-gpu-and-on-die-memory/
Seriously, can we ditch "XBOne"? It sounds stupid and juvenile. Can't we just all agree to use "XBO" instead? I mean, on one hand we all demand to be taken seriously by the industry, yet on the other we're still making dildo jerk off boner jokes at every passing opportunity. C'mon, sons.
On topic: I know nothing about tech specs, but I do know that clever artists and engineers will find ways to use the hardware to their advantage and still make beautiful games.
On topic: I know nothing about tech specs, but I do know that clever artists and engineers will find ways to use the hardware to their advantage and still make beautiful games.
w1gglyjones
Member
XB1 is fine with me. Though I usually demand that the industry becomes serious first before I stop my dildo jerk off boner jokes.
Fair enough, lol.
It's only offensive or annoying if you let it be. Seriously, it's just "Xbone" or just "The 'bone" by this point. Unless the poster is explicitly making a boner comparison or some such, there's no harm in it in and of itself.
Erm, neither, actually. I just Googled for the game and posted one of the first screenshots I saw. Does filtering and AA have much to do with RAM quantity? I was under the impression it doesn't. My point was more about texture quality and the like.
Yes, it caused issues. I was making a point about canny developers finding workarounds.
The point is; is there any evidence (yet) that the 32MB of embedded RAM is a significant handicap? If not, then this strikes me as just more Xbone FUD, because similar things can be said about every console. You think developers aren't going to be annoyed by the restrictions of these tablet CPUs in a few years?
LiquidMetal14
hide your water-based mammals
Pretty much. I use Xbone all the time and it just fits for me. I don't mean it in an insulting way. I laugh a little when I read "I'm getting Halo for the bone" though. It is what it is.
dragonelite
Member
Make it X1 one letter less to type..
If we know anything at all about console development it's that
a) they are always outdated quicker than we hope
b) developers are always crafty about finding workarounds
You could have said the exact same thing about the PS3 having 256MB of main RAM and 256MB VRAM in 2005 compared with the 6-8GB main RAM and 2GB+ VRAM they have now. And it still managed this:
I honestly don't see why this is different.
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.
Terbinator
Member
That isn't in-game though.
You're in a very small minority with that opinion.
Using it as a 32MiB cache will only work if the hardware has support to use it as part of its cache hierarchy, and I have seen no evidence so far to indicate that it does. Otherwise, a user-managed cache is little better than a scratchpad, even if that scratchpad has theoretically high bandwidth.
To pull another quote from Anandtech:
To pull another quote from Anandtech:
Anandtech said:
I don't think it's totally unfair. I enjoyed the game in spite of a framerate and image quality that did distract from the presentation. What was achieved on the PS3 is impressive relative to its age and architecture (and it does stand on its own), but compared to what's been achieved elsewhere, I can understand some annoyance at people calling it anything close to a marvel. Flawed is a fair word for it. Severely flawed is overstating it, but as a response to an image that doesn't represent the quality of the game, I get it.
dragonelite
Member
Any reason except redundancy why they would make the esram in blocks of 8Mb?
A 1080p@32bit rendertarget is almost 8Mb
A 1080p@32bit rendertarget is almost 8Mb
They're not in blocks of 8MiB. Each 256-bit controller is responsible for 8MiB, but as far as a developer is concerned the pool size is 32MiB. Main memory is connected to their controllers in a similar fashion.
Agreed. TLoU was a great game but anybody using it as an example of amazing graphics is just fooling themselves. The image quality is nothing like that screenshot thrown around in this thread and the framerate was very unstable especially during larger outside areas. Heck I even saw seams popping up in some dark areas of the environment.
Don't want it to get confused with:
Seriously, with Microsoft touting TV capabilities so much, I wonder if any consumer would hear the abbreviations for Xbox One and get confused between these two.
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.
ChainsawFilms
Member
I've never considered the ESRAM a proper cache. It's there to improve dataflow to and from the GPU, which would usually have DDR5 to feed them. As such, I fail to see how 32mb of "faster than DDR3 but slower than DDR5" memory is going to really make up that bandwidth shortfall.
Even if it was blisteringly fast, I think I'm right in saying it's still going to have to pull the data (say large HD textures) from the main DDR3 pool, so you're immediately bandwidth limited - unless you're using a very low texture asset footprint. You can't get the textures to the ESRAM faster than the DDR3 bandwidth.
I've not looked at them recently, but last I saw, the ESRAM can only go between GPU and main memory, not the CPU, so the idea of being Cache, at least in the way most people use the term, would be incorrect anyway. If you know what I mean.
Even if it was blisteringly fast, I think I'm right in saying it's still going to have to pull the data (say large HD textures) from the main DDR3 pool, so you're immediately bandwidth limited - unless you're using a very low texture asset footprint. You can't get the textures to the ESRAM faster than the DDR3 bandwidth.
I've not looked at them recently, but last I saw, the ESRAM can only go between GPU and main memory, not the CPU, so the idea of being Cache, at least in the way most people use the term, would be incorrect anyway. If you know what I mean.
The Anandtech article is old but the information pertinent to the discussion of this thread (32MB ESRAM) is still relevant. Not sure, why your jab was required though.
If they spend a ton of money and resources on optimizing, which isn't what we want. I hope next gen systems will be much easier to develop for down the road so that we can see great looking games from any developer.
Faster memory improves GPU performance, in PC GPUs (that don't have ESRAM ofc) you'll usually see AA and resolution make less of an impact on performance if the RAM is fast. Because it is one big pool you don't have to think about what goes into the fast RAM pool.
LittleJohnny
Banned
But what is the practical peak for PS's GDDR5?
I understand some people get annoyed when talking theoretical peak which may never be attainable, but I think at the same time most people don't know that the GDDR5 in PS4 is also listing the theoretical maximum.
I remember seeing something at Anandtech.com where they somehow were able to calculate the amount of bandwidth utilized from GPUs but it was definitely way off the peak figured by the formula.
Bandwidth =
For the PS4 the base clock of the GDDR5 = 1,375Mhz. The signal rate = 4 because GDDR5 is quad pumped memory. The bus that the PS4 is using is 256-bit wide, divide that by 8 = 32. 32 x Effective speed will give you the absolute maximum possible bandwidth, the theoretical peak.
Now lets see if the PS4's listed bandwidth is theoretical peak or the practical peak:
Following the formula:
32(256-bit/8) x 1,375Mhz(GDDR5 base speed) x 4 (Effective speed of GDDR5) = 176GB/s
Now for eSram:
eSram a 1024-bit wide bus (Dayum!)
The clock of eSram to my understanding is the same as the speed of the SOC where it's embedded, therefore in XBO's case 853Mhz.
128 (1024-bit/8) x 853Mhz x 2 (Effective speed of eSram according to MS) = 218GB/s
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.