Recent content by ROG27

Correct, so I'm assuming the GPU is reading from the ESRAM pool at 68 GB/s (because it can't transfer more data than that per second through the DRAM bus to main memory) and the GPU is also then writing to the DRAM pool at 68 GB/s for a total of 136 GB/s consumed over 2 buses. Is that not the...

The ~133 GB/s number was pre-uptick. Between 140 and 150 GB/s seems to make sense post-uptick. It's strange how Leadbetter's article seems to imply it is not a normal throughput (i.e., an outlier for certain post-processing operations) where Charlie's says otherwise. Charlie also seemed to think...

You are actually correct here because the table is illustrating bandwidth consumed, not throughput at anyone point in time for just the ESRAM I believe, no?

I noticed this, as well. It seems like their own internal documentation is almost contradictory at times. System DRAM certainly is not capable of simultaneously reading and writing.

I believe in Leadbetter's article, MS themselves purported that the best real world throughput in an ideal alpha blending scenario was ~133 GB/s. I believe they also said that achieving simultaneous read and writes was on a limited basis and not how the ESRAM normally functions most of the time...

Looking at the leaked documentation on VGLeaks (http://www.vgleaks.com/durango-memory-system-overview/), I'm not sure how MS now arrives at 109 GB/s (102.4 GB/s prior to uptick) being the minimum bandwidth available for the ESRAM and 204 GB/s (192 GB/s prior to uptick) being the maximum, when...

I see. Makes sense since first party devs develop exclusively in a console environment and are not exposed to the new techniques employed by more modern, more powerful PC hardware.

I am assuming they are customized moreso than just GCN based on the wording of the leaked durango gpu documentation found on vgleaks. Then again, they could just be referring to the GCN architecture improvements over AMD's last iteration of gpu architecture.

They seem to be enhance in x1 gpu to work with compressed data and esram. Apparently there are certain hardwired functions that can effectively truncate or totally avoid the path throough the pixel pipeline in some instances.

It seems that there are retrictions and limited use cases to getting the increased efficiencies from the enhanced Depth Blocks and Color Blocks in the XBOX One GPU, as per the vgleaks documentation: "For performance reasons, it is important to keep depth and color data compressed as much as...

Which is why I am waiting for the inevitable follow up article giving a technical explanation for how this is all happening and describing the limited use case(s) for what seems like esram hackery.

But how in the world would MS's hardware engineers be unaware of these attributes this late in the game? This seems highly unlikely. I'm wondering if the journalist here is misinterpreting a technical explanation he heard through the grapevine. Seems more plausible to me.

Is what you are describing a common way for dual rate I/O ESRAM to function (I.e., bidirectional 7 cycles out of 8 and unidirectional the other cycle)?

It sounds like the news about the ESRAM is being misinterpreted in the Eurogamer article. If MS is claiming simultaneous read/write operations in certain instances yielding a theoretical total bandwidth of 192 GB/s, that means unidirectional bandwidth would be 96 GB/s (i.e., 192 / 2 = 96). This...

I tried to tell you guys before: MS created an underpowered all-in-one cable box. Sony created an adequately-powered games box with multimedia functionality (philosophically similar to the X360/PS3 generation--or a natural extension of it, rather). Fanboys did not want to listen. It...