Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
Last edited by a moderator:
Yea, the CPU will work very well with DDR3. The esram is clearly there for the purpose of benefitting the GPU.
I don't think that the "CPU works really well with DDR3" means much. I think that a L2 might be a disaster as far as performances are concerned, with hundred of cycles lost. The OoO execution engine is far from being able to hide those kind of latencies.

Having scratchpad+move engines accessible by the CPU would have been nice, though feeding the GPU might have been the priority (rightly though).
 
I don't think that the "CPU works really well with DDR3" means much. I think that a L2 might be a disaster as far as performances are concerned, with hundred of cycles lost. The OoO execution engine is far from being able to hide those kind of latencies.

Having scratchpad+move engines accessible by the CPU would have been nice, though feeding the GPU might have been the priority (rightly though).

Why do you say ESRAM is not accessible by the CPU?. It is ( and coherent access for GPGPU greatness ), through the northbridge and GPU memory system.

memory_system.jpg
 
Why do you say ESRAM is not accessible by the CPU?. It is ( and coherent access for GPGPU greatness ), through the northbridge and GPU memory system.

memory_system.jpg

He probably meant access directly.
CPU certainly doesn't have the full bandwidth to the ESRAM from this diagram.
 
I'm no expert, but I would imagine that what will be happening is that the cpu will mostly be fetching from the DDR3, modifying that data, copying it back to the DDR3, where the GPU will then be able to read the data from DDR3 directly, operating on it directly, or the data can be first transformed over to the ESRAM, and then the GPU can go to work on it.

They can use either a shader to copy it from DDR3 to ESRAM to take advantage of the benefits, or they can use the move engines to do it, but either way they can do a combination of both things simultaneously on different pieces of data because the move engines can operate completely in parallel with gpu computation. So I imagine there is a path for things to work quite effectively when handled right.
 
I don't understand how a L1 & L2 cache hit on the other module makes latency worse than just a L2 cache hit on the other module.

The L1 is inclusive to the L2 and the L2 forwards requests to L1. Basically, if a line is in a foreign L1 and you hit L2, this forces the L1 line to be returned to the L2 first, and then you get it.

This is also how the SNB L3 works.
 
By the way, Vgleaks has commented on the article that their info is from 2013. I thought they had about 1 year old info on durango, but maybe they got a new source. If true, definitely no changes...

I wonder how reliable bgassasin's source is. We might have to wait a little longer to find out.
 
bgassassin has more than one source, it'll depend on who told him about the CPU.
Whoever it was probably wasn't technically inclined and misinterpreted the specs (dual issue, 2x regular 4 core Jaguar) similar to how people have speculated here.

There's also some Durango spec PDF doing the rounds of GAF, thuway is saying to people not to post it - someone should try to get their hands on it and see if there's anything.
 
Hmm. Is there any chance this CPU is being builded with 2 banks of 4 ARM Cortex cores?

Maybe something like the ARM Cortex A57?

Cortex-A57 at a Glance
  • Out-of-Order ARMv8 32/64 Core
  • Up to Quad-Core Design
  • 44-bit Virtual Memory Address
  • Up to 16TB RAM (LPDDR3 to DDR4)
  • 48KB L1 I-Cache (w/DED parity)
  • 32KB L1 D-Cache (w/ECC)
  • NEON SIMD Engine
  • FPU
  • 128KB - 2MB L2 Cache (w/ECC)
  • 128-bit CoreLink Interconnect (CCI-400 and CCN-504)
http://vr-zone.com/articles/arm-int...x-a53-and-cortex-a57/17652.html#ixzz2MGHFDGW7


http://www.xbitlabs.com/news/cpu/di...res_Cortex_A53_and_Cortex_A57_Make_Debut.html
 
Hmm. Is there any chance this CPU is being builded with 2 banks of 4 ARM Cortex cores?

Maybe something like the ARM Cortex A57?

Cortex-A57 at a Glance
  • Out-of-Order ARMv8 32/64 Core
  • Up to Quad-Core Design
  • 44-bit Virtual Memory Address
  • Up to 16TB RAM (LPDDR3 to DDR4)
  • 48KB L1 I-Cache (w/DED parity)
  • 32KB L1 D-Cache (w/ECC)
  • NEON SIMD Engine
  • FPU
  • 128KB - 2MB L2 Cache (w/ECC)
  • 128-bit CoreLink Interconnect (CCI-400 and CCN-504)
http://vr-zone.com/articles/arm-int...x-a53-and-cortex-a57/17652.html#ixzz2MGHFDGW7


http://www.xbitlabs.com/news/cpu/di...res_Cortex_A53_and_Cortex_A57_Make_Debut.html

Too soon... takes 18 months to design and tapeout + valodate a chip.
 
@ Xovek:

There definetly was a rumor that MS is going with ARM Cortex for TrustZone (I'm don't know whether it's still up to date) and it would be no problem for AMD to integrate it into the XBox APU. But TrustZone on consumer APUs will happen with Cortex A9 cores and not with A57 cores.
 
Last edited by a moderator:
There definetly was a rumor that MS is going with ARM Cortex for TrustZone (I'm don't know whether it's still up to date) and it would be no problem for AMD to integrate it into the XBox APU. But TrustZone on consumer APUs will happen with Cortex A9 cores and not with A57 cores.
More likely the even smaller A5 (A7 tops). And yes, AMD stated that their APUs/SoCs will support Trustzone starting in 2013. If that applies already to Kabini or only Kaveri? No idea.
 
Why no one questions Vgleaks the same way it is done with other sources?

Those separared Cus for computing: Wasnt that info from them?
 
More likely the even smaller A5 (A7 tops). And yes, AMD stated that their APUs/SoCs will support Trustzone starting in 2013. If that applies already to Kabini or only Kaveri? No idea.

Oh you're right with the Cortex A5 for AMD. I messed it up with this.

As far as I know Kabini will be the first APU that supports TrustZone. From 2014 on AMD plans to equip every processor with this feature.
 
More likely the even smaller A5 (A7 tops). And yes, AMD stated that their APUs/SoCs will support Trustzone starting in 2013. If that applies already to Kabini or only Kaveri? No idea.

I wouldn't be surprised if some kind of "hypervisor" stack is running on an ARM core on both Orbis and Durango doing authentication stuff at start-up (integrity check), Bluray security and checking games' disks etc next to acting as some kind of sleep mode processor.

But... keep in mind TrustZone for the CPU is nothing more than an extra CPU state, next to e.g. user mode and privilege mode... with the difference that you can limit to peripherals (e.g. a RTC timer) to Trustzone mode only... meaning that it's harder to tamper with security-related HW.
 
I wouldn't be surprised if some kind of "hypervisor" stack is running on an ARM core on both Orbis and Durango doing authentication stuff at start-up (integrity check), Bluray security and checking games' disks etc next to acting as some kind of sleep mode processor.

But... keep in mind TrustZone for the CPU is nothing more than an extra CPU state, next to e.g. user mode and privilege mode... with the difference that you can limit to peripherals (e.g. a RTC timer) to Trustzone mode only... meaning that it's harder to tamper with security-related HW.

In terms of Durango, a possible solution to a bunch of questions might be something like this?

http://www.montblanc-project.eu/press-corner/news/texas-instruments-puts-arm-dsp-processors-play-hpc

An ARM core alongside a hefty DSP used for audio?
 
Why no one questions Vgleaks the same way it is done with other sources?

Those separared Cus for computing: Wasnt that info from them?

Enough vocal people are happy with the news coming out of them . So they drum them up. We really don't know how old the info they have is or how accurate.
 
Status
Not open for further replies.
Back
Top