Xbox One (Durango) Technical hardware investigation

[Deleted member 86764]

Everything appears exactly as expected.

One of the diagrams states 'main SOC', but there's nothing to suggest there is anything else more interesting.

 

[3dilettante]

Like I noted earlier, the bar for HSA's coherent memory is lower than it is for CPU cores. Coherence between the CPU and other domains is apparently at a page level, given the use of synchronized page tables.
This is why I didn't see a problem on the coherence front for hUMA.
(edit: On second thought, this could be page-granularity, but that might be an over-interpretation on my part without more data than is in the slide.)

The 109 min/204 peak eSRAM bandwidth disparity remains. Perhaps a transcript or writeup on the eSRAM can further illuminate why they make that particular distinction. Perhaps it is the inverse of the usual way bandwidth is disclosed, with peak ignoring banking conflicts. There may be a sustained number with some kind of bank hit or access combining that can yield the peak value.

edit: Note the 2.5% fully gated idle power. With a ~100W SOC, that would leave 2-3W at idle, hence why some designers may be tempted to have a secondary processor for networked idle.

 

[AstoundingHolmes]

Perhaps eSRAM behaves more like the 360 eDRAM than was thought prior, and the 204GB/s is some sort of intra-communication peak?

 

[BRiT]

Perhaps eSRAM behaves more like the 360 eDRAM than was thought prior, and the 204GB/s is some sort of intra-communication peak?

The eSRAM and CPU/GPU are all on the same chip so it's always intra-communication, thus the 204 GB/s peak bandwidth.

 

[astrograd]

The 109 min/204 peak eSRAM bandwidth disparity remains. Perhaps a transcript or writeup on the eSRAM can further illuminate why they make that particular distinction. Perhaps it is the inverse of the usual way bandwidth is disclosed, with peak ignoring banking conflicts. There may be a sustained number with some kind of bank hit or access combining that can yield the peak value.

Seems to vindicate the DF article (and a certain someone else, hehe). 204GB/s is boost gotten from going to 853MHz (was 192GB/s peak at 800MHz). But that's only really achievable for...well, basically nothing. This would seem to also confirm that the eSRAM reads and writes on the same cycle for what seems to be 7/8 of the cycles.

 

[MrFox]

Did you guys figured out the 47MB figure ?
I can only end up with 42480kb, where's the 4MB I'm missing?

12x CU:
- 4x64kb vector registers
- 64kb local store
- 8kb scalar registers
- 16kb L1
== 4128kb

3x groups of 4 CU:
- 16k icache
- 32k vector cache
== 144kb

4x memory controllers L2 128kb:
== 512kb

2x jaguar CU L2
== 4096kb

- 8x jaguar cores
- 32kb icache
- 32kb dcache
== 512kb

- 32mb esram

- 64kb GDS

- 240kb audio

 

[AstoundingHolmes]

I meant more in the sense of communication between the 4x 8MB eSRAM pools. "Intra-communication" was a poor choice of words.

 

[Rockster]

This would seem to also confirm that the eSRAM reads and writes on the same cycle for what seems to be 7/8 of the cycles.

Not sure how you've come to that conclusion.

 

[Solarus]

so the df leak was correct? if 109 is min and 204 is max. does that mean its possible the 133gb/s "average" that you guys talked about in the esram thread made by astgrad is right or close?

another thing are the

graphics command processors

aces?

 

[XpiderMX]

Seems to vindicate the DF article (and a certain someone else, hehe). 204GB/s is boost gotten from going to 853MHz (was 192GB/s peak at 800MHz). But that's only really achievable for...well, basically nothing. This would seem to also confirm that the eSRAM reads and writes on the same cycle for what seems to be 7/8 of the cycles.

Is it an "useless" info?

 

[Deleted member 7537]

Not sure how you've come to that conclusion.

This comes from the discussion around the DF article, not sure if true.

 

[dobwal]

The 109 min/204 peak eSRAM bandwidth disparity remains. Perhaps a transcript or writeup on the eSRAM can further illuminate why they make that particular distinction. Perhaps it is the inverse of the usual way bandwidth is disclosed, with peak ignoring banking conflicts. There may be a sustained number with some kind of bank hit or access combining that can yield the peak value.

Can it be some form of cycle stealing?

 

[Rockster]

Mr. Fox, probably not 1 large 4mb block you're missing, but rather a bunch of little things spread around the chip. Audio processor looks to have 256k for example. Not sure about caches in various MMU's, but lots of opportunity there as well.

 

[3dilettante]

so the df leak was correct? if 109 is min and 204 is max. does that mean its possible the 133gb/s "average" that you guys talked about in the esram thread made by astgrad is right or close?

The average number given was from unknown source using some kind of blending code as a bandwidth benchmark. With a minimum value below and a peak value above, some kind of code should fall inbetween. There's no reason to doubt 133 with those values being official. What exactly is being tested by that code, and the mechanism for the two bounding values has not yet been explained.

another thing are the aces?

ACEs are for compute, and there are boxes for compute command processors.

 

[AstoundingHolmes]

MR.Fox, what about the audio caches?

64KB sram
16Kb + 16KB controller I/O cache
16KB + 32KB scalar I/O cache
16KB + 32KB vector I/O cache
16KB + 32KB vector I/O cache

= 240KB

 

[astrograd]

Is it an "useless" info?

If it is what I thought it was before it would be notably less representative of what can actually be achieved in a realistic game scenario than other forms of 'peak BW'. It'd be 7 cycles where you read + write and then an 8th cycle where you do one or the other. Sounds like something you'd basically have to write a deliberate code to get to instead of something resembling an actual game. I could be wrong though. I was told in May that it was not close to achievable and real world usage was at 133GB/s (on 800MHz GPU at the time). With the clock bump I'd assume that is now at around 142GB/s.

 

[Shifty Geezer]

Can it be some form of cycle stealing?

read + write = 2 ops

That gives you 7(2) + 1(1) = 15 ops per 8 cycles. ...etc...

As HotChips hasn't so far provided any insight into that discussion, we can't add anything more than we've already had. Can we please leave that conversation to the existing thread and only touch upon it here when we get something concrete.

 

[MrFox]

MR.Fox, what about the audio caches?

64KB sram
16Kb + 16KB controller I/O cache
16KB + 32KB scalar I/O cache
16KB + 32KB vector I/O cache
16KB + 32KB vector I/O cache

= 240KB

thanks, added.

Still 4MB missing

 

[Alucardx23]

Some interesting twitts.

XBox One SOC has a CPU, GPU, and 15 special-purpose processors. Total of 47MB of storage on-chip. #HC25
https://twitter.com/Daniel_Bowers/status/372039785453346816

Hot Chips: At 363mm2 with over 5b transistors the Xbox One SoC designed by Microsoft and AMD is a very complex SoC.
https://twitter.com/TekStrategist/status/372041324871946240

Audio offload processor in XBox One SoC are "completely designed by Microsoft" and have "more than a CPU core worth of processing" #HC25
https://twitter.com/Daniel_Bowers/status/372041578639929345

XBox One CPU has eight "modified" AMD Jaguar x86-64 cores, in two clusters of four cores. Modifiations to memory sharing & bandwidth. #HC25
https://twitter.com/Daniel_Bowers/status/372040673618182144

 

[GrimThorne]

Okay, dare I ask? What are these 15 special-purpose processors?

More importantly, where are the DMEs?