Xbox One (Durango) Technical hardware investigation

[3dilettante]

That's Southern Islands, which is from an era where words applied to things.

 

[dobwal]

That's Southern Islands, which is from an era where words applied to things.

LOL. My bad. I have it pinned to chrome and went "what?" when I saw your post. Reading comprehension ftl.

 

[Betanumerical]

This is not exactly clear and depends on how MS decided to draw the block diagram (they took strange decision for the SIMD setup, too; they also managed to give borderline [in a strict sense wrong] descriptions of the scheduling of instructions in GCN).
It looks that with "GCN1.1" as seen in Kabini and Bonaire (which features also 4 ACEs contrary to the apparently wrong block diagrams which got published) the ACEs come in blocks of four (if someone wants to check for himself, afaik found by mczak, btw., there is also some other stuff in there). Kabini and Bonaire both have one "MEC", or compute micro engine containing 4 "pipes" or ACEs, each of it handling 8 queues. According to that initialization code Kaveri will have two of these MECs (and hence 8 ACEs and 64 queues), the same number as the PS4 has. So MS could have decided to draw the MECs and not the individual ACEs in it. It may be a stretch, but not impossible.

Spoiler

from the linked file (KV=Kaveri, KB=Kabini, CI apparently refers to all "GCN1.1" discrete GPUs, CIK to CI+Kabini+Kaveri):

/*
 * CP.
 * On CIK, gfx and compute now have independant command processors.
 *
 * GFX
 * Gfx consists of a single ring and can process both gfx jobs and
 * compute jobs.  The gfx CP consists of three microengines (ME):
 * PFP - Pre-Fetch Parser
 * ME - Micro Engine
 * CE - Constant Engine
 * The PFP and ME make up what is considered the Drawing Engine (DE).
 * The CE is an asynchronous engine used for updating buffer desciptors
 * used by the DE so that they can be loaded into cache in parallel
 * while the DE is processing state update packets.
 *
 * Compute
 * The compute CP consists of two microengines (ME):
 * MEC1 - Compute MicroEngine 1
 * MEC2 - Compute MicroEngine 2
 * Each MEC supports 4 compute pipes and each pipe supports 8 queues.
 * The queues are exposed to userspace and are programmed directly
 * by the compute runtime.
 */

[..]
	 * KV:    2 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 64 Queues total
	 * CI/KB: 1 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 32 Queues total
	 */
	if (rdev->family == CHIP_KAVERI)
		rdev->mec.num_mec = 2;
	else
		rdev->mec.num_mec = 1;
	rdev->mec.num_pipe = 4;
	rdev->mec.num_queue = rdev->mec.num_mec * rdev->mec.num_pipe * 8;

Other documentation that is not publicly available on the web has named 2 pipes with 8 queues each i am led to believe. That should be a straight up 2 ACE's no?

 

[3dcgi]

Are you allowed to say more specifically? I assume in the case of Bonaire that is the two geometry engines? Anything else?

Unfortunately I know you can't say for VI/Hawaii even if you did know.

Cayman had 2 geometry engines. That is not new for Bonaire, just new for a Bonaire class GPU.

 

[3dilettante]

Other documentation that is not publicly available on the web has named 2 pipes with 8 queues each i am led to believe. That should be a straight up 2 ACE's no?

I think the number of queues per hardware pipe is also different from the original ACE implementation. The summary of differences between Sea Islands and Southern Islands included that in the list.

The flat addressing mode introduced with the next iteration looks like it aligns with the way HSA divides its memory space. If Microsoft is interested in HSA, it wouldn't hurt to have a relative of Bonaire in Durango.

 

[Betanumerical]

I think the number of queues per hardware pipe is also different from the original ACE implementation. The summary of differences between Sea Islands and Southern Islands included that in the list.

The flat addressing mode introduced with the next iteration looks like it aligns with the way HSA divides its memory space. If Microsoft is interested in HSA, it wouldn't hurt to have a relative of Bonaire in Durango.

I thought the default was 8 per pipe?. Unless thats changed somewhere along the line.

 

[3dilettante]

My recollection was that there was a ring buffer per ACE, but that might not indicate what the unexposed part of the implementation was.

 

[Gipsel]

I thought the default was 8 per pipe?. Unless thats changed somewhere along the line.

As 3dilettante said already, all the GCN1.0 GPUs have only a single queue (ringbuffer) per ACE (pipe). "Multiqueue compute" was one of the bullet points for the changes of C.I. over SI in that retracted ISA manual.

 

[Betanumerical]

As 3dilettante said already, all the GCN1.0 GPUs have only a single queue (ringbuffer) per ACE (pipe). "Multiqueue compute" was one of the bullet points for the changes of C.I. over SI in that retracted ISA manual.

Oh okay, wish the ISA doco was still up would love to read it, no one has it saved anywhere do they?.

 

[Gipsel]

Oh okay, wish the ISA doco was still up would love to read it, no one has it saved anywhere do they?.

Of course someone has saved it.

 

[(((interference)))]

I know Durango is GCN and not say GCN 2.0

 

[AstoundingHolmes]

Seems strange. MS partnered with AMD later than Sony, so they should have started with a clearer, further along road map of what AMD had to offer for whatever they might need, no? If so and if the architectural changes are beneficial (and 3Dilettante seems to see a use), why ignore it? Did they need something already complete to modify for eSRAM inclusion?

 

[Gipsel]

I know Durango is GCN and not say GCN 2.0

Not that it is impossible, but where did you get your knowledge from?

 

[dumbo11]

Seems strange. MS partnered with AMD later than Sony, so they should have started with a clearer, further along road map of what AMD had to offer for whatever they might need, no? If so and if the architectural changes are beneficial (and 3Dilettante seems to see a use), why ignore it? Did they need something already complete to modify for eSRAM inclusion?

Another possibility is differing strategic design decisions:
- MS, from the leaks, seem to have targeted a performance metric, and aimed for the best priced implementation. (6x 360, 3.5GB OS RAM, HDMI in etc.).
- Sony, from their comments, targeted a price, and attempted to make the best console for sale at that price.

There are pros/cons to both approaches. In this case - if the XB1 APU hit the relevant performance targets then there's no obvious reason for it to be changed.

 

[liolio]

Another possibility is differing strategic design decisions:
- MS, from the leaks, seem to have targeted a performance metric, and aimed for the best priced implementation. (6x 360, 3.5GB OS RAM, HDMI in etc.).
- Sony, from their comments, targeted a price, and attempted to make the best console for sale at that price.

There are pros/cons to both approaches. In this case - if the XB1 APU hit the relevant performance targets then there's no obvious reason for it to be changed.

I think that Sony acted cleverly sticking to mostly "off the shelves parts" as a bitter MSFT execs said.
I think they let their options opened for a longer time than MSFT.
I suspect that this approach might have lowered the time between the moment Specs (for the silicon) are decided and the moment silicon comes back from the foundry.

MSFT went with a more custom custom, a more "complex" chip, with unproven parts (sram, audio dsp), I would think that they have to lock the specs a tad earlier than SOny.

 

[Kb-Smoker]

Seems strange. MS partnered with AMD later than Sony, so they should have started with a clearer, further along road map of what AMD had to offer for whatever they might need, no? If so and if the architectural changes are beneficial (and 3Dilettante seems to see a use), why ignore it? Did they need something already complete to modify for eSRAM inclusion?

We know amd made changes based off design changes with their work on ps4. Those changes were not shared with ms.

Seem a lot of gcn 2.0 changes were based on work with sony.

 

[liolio]

We know amd made changes based off design changes with their work on ps4. Those changes were not shared with ms.

Seem a lot of gcn 2.0 changes were based on work with sony.

Imo you put way too much weght on Sny it could really well be the other way around.
AMD is silent on the matter and will remain silent but the engineers are on their side, Cerny makes a nice PR campaign and MSFT is bitter about their "off the shelves parts", think what you will we will never know.
And GCn 2.0 is quite pushing it, AMD don't even call it GCN 1.x.

 

[Kb-Smoker]

Imo you put way too much weght on Sny it could really well be the other way around.
AMD is silent on the matter and will remain silent but the engineers are on their side, Cerny makes a nice PR campaign and MSFT is bitter about their "off the shelves parts", think what you will we will never know.
And GCn 2.0 is quite pushing it, AMD don't even call it GCN 1.x.

http://forum.beyond3d.com/showpost.php?p=1761352&postcount=2343

And here about the changes sony made.

http://forum.beyond3d.com/showthread.php?p=1761150#post1761150

 

[Silent_Buddha]

http://forum.beyond3d.com/showpost.php?p=1761352&postcount=2343

And here about the changes sony made.

http://forum.beyond3d.com/showthread.php?p=1761150#post1761150

That first link applies to both Microsoft and Sony, so doesn't exactly bolster your argument that Sony has made more changes than MS. It only reiterates that any custom changes that MS requested won't be available for Sony. And any custom changes that Sony requested won't be available for MS. Unless, by chance, both MS and Sony just happen to request identical changes. However, any changes that either MS or Sony requested may appear in a later AMD GPU if AMD feel those changes are beneficial enough to implement in a non-console GPU.

Second one he can ONLY comment on what has been revealed, so again it does nothing to bolster your argument that Sony has made more custom changes than MS. He obviously can't comment on any changes MS has made or any changes that Sony has made if they haven't yet talked about them.

Regards,
SB

 

[Kb-Smoker]

That first link applies to both Microsoft and Sony, so doesn't exactly bolster your argument that Sony has made more changes than MS. It only reiterates that any custom changes that MS requested won't be available for Sony. And any custom changes that Sony requested won't be available for MS. Unless, by chance, both MS and Sony just happen to request identical changes. However, any changes that either MS or Sony requested may appear in a later AMD GPU if AMD feel those changes are beneficial enough to implement in a non-console GPU.

Second one he can ONLY comment on what has been revealed, so again it does nothing to bolster your argument that Sony has made more custom changes than MS. He obviously can't comment on any changes MS has made or any changes that Sony has made if they haven't yet talked about them.

Regards,
SB

never was the debate. The whole point was we know the changes made by sony and those changes were rolled into 1.x or 2.0 or whatever you want to call it. so this how ms could of have started later but only have access to older design. Since ms wouldn't have access to this design develop by amd and sony which were rolled into amd gpu designs.


What are the changes ms made? Seem we have a ton of info on the gpu.