This is what you can find in the VGLeaks documents regarding the latency.check out the wording Boyd Multerer uses:
Regarding cache latency.
" Having the right data in the right caches at all the right time makes all the difference in the world [for this architecture]"
Are colour blocks and depth blocks important for framerate, thus my theory is right? :smile2:
Those measurements are dubious at best (I would say some blatantly contradict other available information) and wouldn't apply to GCN based GPUs anyway (GCN got an almost complete redesign of the cache structure [everything besides the ROP caches]).
That 4way/64way L1 cache thing is a misinterpretation (confusion between number of ways and number of sets). All GCN based GPUs have a 64way set-associative L1 cache (older GPUs HD4000 through 6000 series had even a fully associative L1 [meaning 128way, the whole L1 cache consisted of only 128 64Byte cachelines]). There are 256 cachelines in total, meaning there are 4 sets (this is why it was mixed up, AMD mentioned both in presentations).
Empirical evidence from synthetic fillrate tests on discrete GPUs doesn't appear to confirm this. There may be some effect, but apparently nothing major.
All this stuff has been previously discussed, so I won't go into detail. Are there jobs low latency can help with? Yes. Do we know how much lower latency the ESRAM has and what impact that have on those jobs? No. We just have vague statements "lower latency == better." Therefore attributing any degree of improvement on the latency property is pure guesswork, which is what you're doing. You like the sound of it so you're running with that theory. Read up all the previous discussion and you'll see it's not at all clear cut, which is evidence aplenty that chance of massive improvements are minimal. I'll leave you with the response from the XB1 architects when asked directly about the benefits of lower latency in the DF interview:
That's all they had to say, and not, "By optimising for low latency, devs will see significant gains in [these areas of rendering] and substantial boosts in framerate."
Having the _ability_ to pull data at 30GB/s means that when you do need a short burst of a lot of data, the One can get that data into the CPU caches 50% faster than the PS4. It's still meaningful, it's just not what I would call a competitive advantage. Sony engineers are not dumb, they wouldn't have limited the PS4 to 20GB/s CPU bandwidth if a CPU required a lot more than that on a normal basis.So... you are essentially saying that the (one of the only remaining?) Xbox One advantage(s) of having 30GB/s CPU bandwidth when compared to the 20GB/s competitor..
is meaningless
And here I was, thinking Xbox One was all about balance.
If they cap the CPU bandwidth access (in software) they can probably limit the amount of framestalls when they system is under heavy load. I'd have to check up with some developers, but most of them are of the complaining types anyway, and they have already been very vocal about ESRAM... "performance" so I'll doubt they have anything nice to say about the overall GPU bandwidth when they system is under heavy load.
I'll update you regardless!
So it is the same GCN in the end... I hope I got this right because I am terrible at those numbers and I don't fully understand what certain concepts mean.
Could this impact framerates more than low latency? I wonder.... Afaik, one of the main limitations to achieve good framerates is usually the CPU.
Yes, at its core it's GCN, plain and simple.
That was an answer to the talk of MS that the low latency eSRAM is helping the ROPs (comprised of color and depth blocks) to achieve their maximum throughput. While there may be a positive effect in some scenarios, discrete GPUs without eSRAM routinely achieve their maximum throughput in fillrate tests while dealing with the higher latency (unknown to what extent compared to eSRAM) of GDDR5. The ROPs include small specialized caches which allow the ROPs to tolerate the RAM latency for the common operations. That means, it isn't clear at all, how much the eSRAM is able to help. I mean, AMD kept the size of the ROP tile caches constant for quite some time. Guess one gets only very limited returns from a size increase so they never did it. But while the size was kept unchanged, the GCN1.1 generation (Bonaire, Hawaii and obviously also Durango and Orbis) appear to have a somehow modified caching policy or some other internal changes helping the efficiency for 4xFP16 render targets, completely without eSRAM. And as Shifty has written above, when asked explicitly, MS basically backed off that statement that the lower latency is crucially important to improve GPU performance (which includes the ROPs).
At that capacity, eDRAM could have been somewhat faster.
They get to enjoy the same benefits when they decide to move to a smaller node, too. No need to worry about DRAM-friendly processes in the future.
Fast memory busses are big. Big busses require more space, and so does the logic managing them. In general, you want to make a bus large enough to satisfy your bandwidth needs and the requirements of the bus architecture, but no larger.
