Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
Point me to it and I will happily ask it there, and besides, this is the durango thread so I don't know what you mean about the appropriate thread. If you don't want to answer it just ignore it.
Search, and if nothing comes up, post a new thread. ;)
 
I know it's been asked, but can someone run through the disclosure and tell us what's actually different from GCN, besides the ESRAM?

ESRAM & data move engines.

Doesn't fully answer my question. Please can somebody give me an answer to my question; what is the function of ROPs in relation to rendering and framerate? Also how many texturing units does durango have?

ROPs write pixels. The rate at which you can write pixels to memory of a particular buffer format is the fillrate (given enough bandwidth). Fillrate is used to draw the scene, subject to various overheads due to overdraw (e.g. transparencies, poor culling of overlapped objects, multipass rendering, multiple render targets).
 
It's 4 TMU's per GCN CU if durango is typical GCN CU's. That'd be 48 TMU's then for the 12 CU's. Of course they aren't called CUs so who knows and it's also surprising they aren't on the Durango diagram either.

That's why I was asking really. Couldn't find it in the article or the diagram.

Thanks Al.
 
ESRAM & data move engines.

Speculation: The data move engines could be used for decoding high compression ratio textures (JPEG XR) to fixed compression ratio formats.

The data move engines would not only transcode textures from permanent storage, but also encode dynamically generated textures. The L1 and L2 texture caches both store compressed textures. To take full advantage of the on-die memory, the data move engines might encode shadow maps, environment maps and imposters on the fly.

In particualar, hardware encoding of BC6 and 7 formats would constitute 'secret sauce'.

Cheers
 
Last edited by a moderator:
Speculation: The data move engines couls bw used for decoding high compression ratio textures (JPEG XR) to fixed compression ratio formats.

The data move engines would not only transcode textures from permanent storage, but also encode dynamically generated textures. The L1 and L2 texture caches both store compressed textures. To take full advantage of the on-die memory, the data move engines might encode shadow maps, environment maps and imposters on the fly.

In particualar, hardware encoding of BC6 and 7 formats would constitute 'secret sauce'.

Cheers

That was one of the things I was speculating (to myself) that the DME's could possibly do to alleviate the bandwidth constraints. More complex texture compression/decompression methods. As they aren't a standard part of DirectX then it wouldn't be something you'd find in a standard PC GPU. Hence requiring custom hardware.

It's interesting to note that iD's Rage uses JPEG XR for texture compression, and uses GPGPU to decompress them, IIRC, when possible. But falls back to much slower CPU if it can't.

Regards,
SB
 
So it seems that the three custom blocks were: ESRAM, the data move engines and the audio block.

The special sauce isn't that special after all, there were no hidden blocks in the GPU as many thought (and as aegies was hinting)
 
Which can happen if you don't understand what you are looking at.

Yeah, I think this is precisely what happened with aegies ;)

If you remember, when the 1.2 TF, 12 CUs @ 800mhz rumour came out we had fanboys trying to rubbish the rumour claiming he said it was 'impossible' on GAF and sounded far too weak compared to what he was hearing.
 
The docs mention low latency access quite a few times both in regards to the ESRAM and other parts of the cache/memory system. Seems like this was more of a priority than straight bandwidth. I have no idea what the implications of this are, but since you failed to mention it, I thought it was worth bringing up.

Numbers, or it never happened.

Latencies are important but if you re-read my post I point out that based on the leak the actually disclosed specs all pretty much support Durango being a 7770 class GPU.

This isn't to say it won't be faster: it is a closed box with a unique design, of course it will be.

This isn't to say it won't produce better looking games than a comparable PC: lower overhead and targeted specs as well as exploiting platform specific features (instead of general API) will go a long way.

And having 102GB/s of bandwidth on-die will be a big win for those able to manage 32MB.

But I think it is well past time, until something substantial is disclosed, to continue grasping at "special sauce this" and "latencies that."

What special sauce? <crickets>

What are the latencies? <crickets>

If you asked my opinion I think Durango's 12 CUs actually could run 7850 quality graphics/performance in the launch window when you factor in targeting a closed platform, thinner API, ESRAM, etc. So I am not knocking Durango's abilities. But in the same breath quoting people like Proelite saying it will mimic a 2.5GFLOPs GPU (yeah, at 720p?) ignores the fact I bet Orbis in the same situation is going to look better than a 7870 when the the hardware inside is less than a 7850 for all the same reasons.

But I don't see people clamoring, "Secret Sauce is going to make Orbis effective FLOPs skyrocket because of unknown ingredient!"
 
Status
Not open for further replies.
Back
Top