Xbox One (Durango) Technical hardware investigation

Actually, those additions, especially the DMEs, do have a specific role to play in the architecture of the new box. They will perform tiling/untiling of textures and resources. And of course they include texture compression/decompression hardware and also texture swizzle/unswizzle. All this in addition to their typical DMA functions. They seem to be gearing the system towards virtual/mega texturing and mega meshes as they link to the pdf of id tech 5 and the lionhead's mega mesh pdf. Although this can be done by any system, it seems they are trying to provide hardware support to make it easier and cheaper to use.

And we already know what the ESRAM can do. In addition to providing the space and bandwidth for the gpu, it is low latency, something they keep pointing out as, apart from its use in compute jobs, it seems ROP are also sensitive to latency, going by the info on vgleaks. Also it doesn't have the limitations of the EDRAM in the 360. So while these components can help alleviate bandwidth bottleneck, that is not the only reason why they choose to use them. Quite simply, it seems like the have a vision on the way graphics development will go and they designed a system to support it, and one that should provide optimum performance given the resources available in it.

 

No, I wasn't saying anything other than there can be other reasons why we're not seeing ex-IBM engineer's obvious involvement in the CPU and GPU design. There are plenty of other possibilities too. My point is only a challenge to the notion that "MS hired senior IBM engineers, ergo there must be major customisation to the CPU and GPU."

 

I don't know I didn't read the story from the website, as I say what is worth the article is quite extensive and they quote a source who is familiar with both machines.

 

MS once did had a custom IBM CPU in development, which then was taped out in December 2011. But bad yields resulted to a switch to AMD x86 architecture then, I suppose.

 

I assume that's GPU cycles. That would still be very fast if that is the case.

Cheers

 

fast in relation to what exactly?

 

What if the IBM engineers are there for some kind of backwards compatibility adjustments to Durango? Alternatively they could be there to help integrate the eDRAM on the 360 in order to perhaps reduce the size of the chip on 28nm. Maybe one of their SKUs has the Xbox 360 chip installed as a backwards compatibility device and developers are not aware and cannot leak simply because they do not need to know about backwards compatibility at this point?

 

What you're kidding, that seems high, no? anyway I'm not really sure what you guys are getting at with this. Are you saying the embedded memory is of a higher bandwidth then we are thinking?

 

8-16 GPU cycles are 16-32 CPU cycles, so GPU-to-ESRAM latency would be comparable to a CPU L2 cache hit (20 cycles). In general, it is easier to design a low-latency scratchpad memory than a low-latency cache.

 

how about you post these snippets since since we are all speculating here anyway?

 

I doubt it could be done on the CPU side. But even if technically it could be brute forced thorough software BC, I think it was bkilian that said the time/manpower/cost of doing it is very high.

Xbox BC for 360 was dropped fairly quickly. I may be wrong, but I think software BC would be even harder this time?

 

Would you mind sharing, if and how, efficiency is defined in the document? Are they using a benchmark or is it all generalities?

 

I don't believe the 4-500 cycles number for a moment.

The internal structure of GDDR5 modules is similar to DDR3, the command/address bus rate is comparable, it just has twice the data rate.

The high latency seen in som GPU benchmarks is likely the result of the memory system delaying individual requests to bunch several requests to indentical banks together for higher aggregate throughput (fewer stall waiting for banks to open).

This is probably performance enhancing for a GPU which can tolerate the added latency, but not for a CPU, requests from the CPU should be serviced ASAP.

I'd expect main memory latency to be on the order 50-100ns, ESRAM (if the 8-16 cycles is true) is 10-20 ns.

Cheers

 

They benchmarked SIMD usage for a specific shader. It is not a general case.

 

Thanks. I guess then it just depends how representative that benchmark is of an average workload in a game.

 

MS once did a design with 8 x86 cores, 32MB of embedded memory, and 12 shader blocks....

<crickets>

 

Do you really think CPU showed by VGL is ALSO ready to control the OS of Durango?
In this case, isn't it somewhat weak for that purpose too?

 

Yes.
No.

 

Well, let´s see.