Blast, I originally replied to this in the wrong thread. Moving it here, but keeping the original quote that I quoted.
Some of that is pretty interesting. I wasn't expecting 2 of the DME's to be different in nature.
Depending on whether data is compressible/decrompessible using LZ77 (apparently many EA games use this) that could either increase effective bandwidth to the CPU/GPU and/or decrease the CPU/GPU load required to decompress data stored in LZ77 format. The CPU/GPU load could potentially be significant as the JPEG XR decode for Rage's assets could be quite slow without GPGPU assistance, and even then could be quite slow if not enough GPGPU resources were available. I'm not sure how resource intensive decompression of LZ77 is compared to JPEG XR, however. I'm going to guess less resource intensive, but I'm not sure by how much.
It also implies that the method they go with can result in up to an 8:1 compression ratio, which effectively means up to an 8x increase in effective bandwidth (25.6 GB/s for one DME, up to ~200 GB/s data throughput after compression/decompression). Without using the DME, you'd have to use CPU or GPU resources for this. So that effectively makes it "free" on Durango as long as the compression used (if pre-shipped with compressed assets) is that which the DME supports. Which in the case of console titles for Durango, will most likely be the case.
BTW - before fans of one console or another jump on this. That isn't a magic bullet. If the data is highly compressible, that can result in more effective bandwidth. On the other hand if it is already highly compressed using LZ77, that just reduces the potential CPU/GPU load. If it uses some other form of compression and thus isn't highly compressible then the benefits are significantly lower. However, it's likely that developers targeting a game at Durango will likely try to take advantage of this.
A fan of Durango might point out that provides a theoretical 350+ GB/s bandwidth if all the stars aligned (accessing DDR3, ESRAM, and highly compressible data simultaneously) but that's only a wet dream. It's not going to happen, not even close. Non fans of Durango might point out that it has no benefit if everything is highly compressed in something other than LZ77 or the supported JPEG formats. That also isn't going to happen. The benefit lies somewhere in between.
Somewhat disappointed that the JPEG decoder doesn't support more advanced JPEG formats such as JPEG XR. But it's another bandwidth reducing and/or CPU/GPU resource reducing function.
The rest is pretty standard, though the tile/untile is potentially interesting.
If tiling in small chunks then you don't need the use of all the bandwidth. And as mentioned if they did use all the bandwidth then other parts of the system become bandwidth starved and at that point what's the point of having them? These are meant to do their function when the bandwidth isn't being fully utilized or when it could use a part of it better than whatever else is accessing it.
Increased compression complexity also increases complexity of the silicon used to decode it. I'm willing to bet that LZ77 was chosen as a good compromise between efficiency and cost of implementation.
In other words, how much bloat do you want to add to the SOC for how much benefit? If it requires 4x the silicon space for 1.5x the speed, is it worth it?
But the whole point of this is to free up GPU resources. Why have the GPU do it if you can have something else do it while the GPU goes along with the rendering tasks and fetching what it needs from ESRAM when possible.
As well with the added functionality in 2 of the DMEs that allows for things to be done which would require GPU resources in the form of compute resources or CPU resources. Again things that could be better used for running the game than compressing/decompressing data.
Regards,
SB