Whats the DBZ power of these?
That's a lot of data per frame. More then enough.
That's a lot of data per frame. More then enough.
Hardware compression is nice.
But this is not jizz.
But the it doesn't look like thats all that possible on Durango either.
Also that LZ encode engine will be useful to allow off tv play like WiiU or to be able to stream Xbox720 to your tablet or smartphone.
They only assist, they don't handle the entire bandwidth. Maybe they are enough to make for a well balanced system overall.God no.
They only assist, they don't handle the entire bandwidth. Maybe they are enough to make for a well balanced system overall.
They only assist, they don't handle the entire bandwidth. Maybe they are enough to make for a well balanced system overall.
They only assist, they don't handle the entire bandwidth. Maybe they are enough to make for a well balanced system overall.
They don't seem strictly DMA's to me. Their main purpose seems to be moving pieces of data, in parallel of the gpu (specially in stages where the gpu is doing other stuff) so the data is where the gpu needs it to be when it's ready to access...
Well, Django will maybe be better balanced with these new Move Engine blocks...
So it is basically exactly as I expected. DMA engines. The only minor surprise here is hardware decompression.
It's just a way to make better use of the limited bandwidth and keep the GPU fed. It's not adding to FLOP count or anything as some of the rumors were trying to lead on.
It was the most likely scenario by far, but some of our resident "insiders" seemed to hint that there was more to it.I thought it was obvious from the start that these would compensate some what for the lack of bandwidth that DDR3 brings.
God no.
What's the obsession with comparing to Orbis?Well, Django will maybe be better balanced with these new Move Engine blocks... but it will still have less processing power than Orbit, who by the look of things, also has much easier architecture [balanced from the start].
That's about what I expected, and really doesn't make up for lower computational capabilities in any way.
In the end doesn't this effectively increase the bandwidth though or at least mean that the limited bandwidths a compensated for? Seems like 8GB of DDR3 with a lot of tricks to "increase" bandwidth might be the optimal solution?That's how memory management units generally work though, no? It's not like any GPU or CPU has to stall on a memory request if it has other things to work on. Memory operations are handled independently.
I wouldn't say that. These units are there because the memory system on Durango is so relatively all over the place. Orbis has a very simple, elegant setup. It doesn't need this kind of help on that front in the first place.
Ok total not tech guy here but if I am reading this correctly this would mean that as a programmer you would have to anticipate what was going through the move engines, ESRAM and system RAM all at once? Isnt that the kind of stuff people complained about the PS3 with the SPE's and 2 pools of RAM?
In the end doesn't this effectively increase the bandwidth though or at least mean that the limited bandwidths a compensated for? Seems like 8GB of DDR3 with a lot of tricks to "increase" bandwidth might be the optimal solution?
That's how memory management units generally work though, no? It's not like any GPU or CPU has to stall on a memory request if it has other things to work on. Memory operations are handled independently.
In the end doesn't this effectively increase the bandwidth though or at least mean that the limited bandwidths a compensated for? Seems like 8GB of DDR3 with a lot of tricks to "increase" bandwidth might be the optimal solution?
People mostly complained about smaller amount of memory available and lack of flexibility (fixed 256/256MB memory pools)Ok total not tech guy here but if I am reading this correctly this would mean that as a programmer you would have to anticipate what was going through the move engines, ESRAM and system RAM all at once? Isnt that the kind of stuff people complained about the PS3 with the SPE's and 2 pools of RAM?
Thanks for the clarificationYou don't have to. You could just keep it simple and do all your reads from DDR3 and use the eSRAM in a fairly simple way for GPU output buffers.
But that may not get the most out of the system. If you want to use eSRAM as anything other than a write buffer, you will have to get into data juggling in a bigger way. And you could get more or less optimal approaches to that requiring more or less pain.
Ok total not tech guy here but if I am reading this correctly this would mean that as a programmer you would have to anticipate what was going through the move engines, ESRAM and system RAM all at once? Isnt that the kind of stuff people complained about the PS3 with the SPE's and 2 pools of RAM?
Perhaps so, but since it's MS i would bet that they are coming with some compiler tricks to make this, at least to some extent, transparent to developers.
It's a different use. What GPUs do is they can directly read the compressed textures specifically for their rendering purposes. As such they're compression systems designed for textures an nothing else. What the ones described here do is much more generic decompression (LZ) and you can put back the decompressed data, be it text, sounds, whatever, wherever you want, like in ram, something which used to be done on the CPU. It's generic compression acceleration, not specifically texture compression.can't current GPUs just use compressed textures directly from ram? so the ability to decode from a compressed storage to a texture isn't new, its just something they'd need to support anyway?
Nope, it's just to move data around within the console (ie you'll have encode/decode done at each end of the data bus in hardware, effectively invisible to software). The compression ratio isn't going to be anything amazing, anyway, especially compared to lossy video compression that'd be used for streaming.
This accelerators are truly fixed-function, in the sense that their algorithms are embedded in hardware. They can usually be considered black boxes with no intermediate results that are visible to software. When used for their designed purpose, however, they can offload work from the rest of the system and obtain useful results at minimal cost.
No. It's like being able to transfer data from your main memory on PC to your GPU memory without using up CPU or GPU time. And while transparently doing some compression/decompression. Useful, but by no means groundbreaking.So it's basically like having a separate physics card in your PC without any memory?
That's a pity. I guess we can rule out off tv play from Xbox 720 then. Unless there is something we don't know in the GPU.
Perhaps so, but since it's MS i would bet that they are coming with some compiler tricks to make this, at least to some extent, transparent to developers.
The durango has a video compress/decompress unit that can do that, and is separate from these DMEs. The Orbis has the video compress/decompress unit also, so I expect both of them to be able to stream to other devices just like the Wii U and its gamepad.
No. It's like being able to transfer data from your main memory on PC to your GPU memory without using up CPU or GPU time. And while transparently doing some compression/decompression. Useful, but by no means groundbreaking.
And entirely unnecessary in a true UMA system such as Orbis.
The durango has a video compress/decompress unit that can do that, and is separate from these DMEs. The Orbis has the video compress/decompress unit also, so I expect both of them to be able to stream to other devices just like the Wii U and its gamepad.
The Cell has a DMA engine for each SPU and the main PPE core. It did help the PS3 make better use of it's given bandwidth. But I don't recall anyone trying to sell it as a ground breaking feature or anything. It was just a way to keep the CPU fed with data more efficiently. But no one way saying PS3 had more bandwidth because of DMA engines. But all of a sudden now...
AFAICS, you are comparing apples to oranges.
Think of this scenario: You have a 1mb texture on the main ram. you know that will have to read it, so you take half of it, copy to the esram, and when the gpu needs to read it, it will be able to read from both memories, effectively increasing the bandwidth.
Now, throwing everything that has been said about durango together, i think the system would actually operate like this: You have a 1mb texture on the main memory, early analysis of the scene indicates that only a portion of it is actually visible in this frame, so you gather some of the tiles of this texture that would be visible, move them to the esram, and when the gpu needs them, it can read the tiles from both memory pools. The difference now is that the total read would be less than 1Mb because you eliminated the portions of the texture that wouldn't be rendered any way.
But in the end, even in that idealized scenario, you are still using more memory bandwidth than Orbis, which simply reads only the parts of the texture it needs from its one memory pool.AFAICS, you are comparing apples to oranges.
Think of this scenario: You have a 1mb texture on the main ram. you know that will have to read it, so you take half of it, copy to the esram, and when the gpu needs to read it, it will be able to read from both memories, effectively increasing the bandwidth.
Now, throwing everything that has been said about durango together, i think the system would actually operate like this: You have a 1mb texture on the main memory, early analysis of the scene indicates that only a portion of it is actually visible in this frame, so you gather some of the tiles of this texture that would be visible, move them to the esram, and when the gpu needs them, it can read the tiles from both memory pools. The difference now is that the total read would be less than 1Mb because you eliminated the portions of the texture that wouldn't be rendered any way.
No. They use the existing memory bus. They alleviate CPU/GPU time from memory transfers. These are not additional buses.So these are just express-lane highways, to get around the slow-as-shit main memory then?