Xbox One November SDK Leaked

[psorcerer]

But there are 2 separate CPs so there must be some sort of communication happening between the two to make sure that they are retiring in order right?

Yes, obviously there is, there are special flags/memory tokens on CUs that support that (synchronization). AFAIR, you can even setup graphs of execution between CPs/ACEs.

 

[iroboto]

Yes, obviously there is, there are special flags/memory tokens on CUs that support that (synchronization). AFAIR, you can even setup graphs of execution between CPs/ACEs.

Thanks.

So this is going to be my last post about command processors, but there could be a subtle mistake/difference here, at this point in time I'll have to wait for the SMEs to weigh in.
We know the Xbox has 2 ACE. And according to previous documentation 2 CPs.
Looking at the white paper diagram from AMD we see that the Command Processor is fetching and submitting to the Geometry engines and the ACE.

According to this Xbox SDK, we see the following:

If the Dispatch is the ACE/Compute Queue, then perhaps the change was that the Xbox Command Processors have the ACE integrated right into them as well? So 2 CPs for 2 ACE? Each CP is acting as an ACE.

Here is the original diagram from previous documentation

 

[liquidboy]

@iroboto Here is the AMD GCN white paper http://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf

So far, I haven't seen anything in detail that would suggest Xbox One's command processor is anything but normal. Maybe that was a mislabeled slide as you suggest.

True from the leaked SDK however from the architects interview, and from past \\build\ presentations

Andrew Goossen: To a large extent we inherited a lot of DX11 design. When we went with AMD, that was a baseline requirement. When we started off the project, AMD already had a very nice DX11 design. The API on top, yeah I think we'll see a big benefit. We've been doing a lot of work to remove a lot of the overhead in terms of the implementation and for a console we can go and make it so that when you call a D3D API it writes directly to the command buffer to update the GPU registers right there in that API function without making any other function calls. There's not layers and layers of software. We did a lot of work in that respect.

We also took the opportunity to go and highly customise the command processor on the GPU. Again concentrating on CPU performance... The command processor block's interface is a very key component in making the CPU overhead of graphics quite efficient. We know the AMD architecture pretty well - we had AMD graphics on the Xbox 360 and there were a number of features we used there. We had features like pre-compiled command buffers where developers would go and pre-build a lot of their states at the object level where they would [simply] say, "run this". We implemented it on Xbox 360 and had a whole lot of ideas on how to make that more efficient [and with] a cleaner API, so we took that opportunity with Xbox One and with our customised command processor we've created extensions on top of D3D which fit very nicely into the D3D model and this is something that we'd like to integrate back into mainline 3D on the PC too - this small, very low-level, very efficient object-orientated submission of your draw [and state] commands.

 

[Scott_Arm]

@liquidboy The second part of his answer, after he mentions taking the opportunity to "highly customize" the command processor, it sounds like he's talking about Draw Bundles, which will be featured in D3D12, and are currently implemented on Xbox One with a slightly different API. D3D11 supports Command Lists, but Draw Bundles are an Xbox One feature. The thing with APIs is a device might support an API function in software rather than fully support it in hardware, so it's hard to know what they've done at the hardware level without them coming out and saying it. It would be interesting to know if there is an analogous feature in Mantle, and if it is fully supported across GCN variants

 

[liquidboy]

@liquidboy The second part of his answer, after he mentions taking the opportunity to "highly customize" the command processor, it sounds like he's talking about Draw Bundles, which will be featured in D3D12, and are currently implemented on Xbox One with a slightly different API. D3D11 supports Command Lists, but Draw Bundles are an Xbox One feature. The thing with APIs is a device might support an API function in software rather than fully support it in hardware, so it's hard to know what they've done at the hardware level without them coming out and saying it. It would be interesting to know if there is an analogous feature in Mantle, and if it is fully supported across GCN variants

there's no doubt in my mind we wont find this out till half way or near the end of this console cycle, if ever. It's why I'm not going crazy with assumptions about what may be in there ..

p.s. I loved the end of each console cycle when they would retrospectively discuss past architectures and their influence on next gen ..

 

[DJ12]

Personally I think people are reading it wrong. In my opinion it is referencing the multiple dma/move engines.

For example multi-(gpu dma) block.

As there doesn't appear to be reference to the gpu dma/move engines anywhere else on the image provided I think this is most likely.

 

[Shifty Geezer]

That was my first guess, but the MCC and MCD's are described as 'any of these blocks'. Why wouldn't the GPU DMA's be similarly described? The XDMA is referenced as singular.

Not that it matters, because we know the architecture, but it gives us something to talk about...

 

[function]

It's probably just related to re-tasked Crossfire hardware, and simply carrying over the naming conventions (so pretty much what DJ12 is saying). Gotta move that data in and out of esram, after all. Interestingly ...

http://www.anandtech.com/show/7457/the-radeon-r9-290x-review/4

The fact that there’s even a phase 2 brings us to our next topic of discussion, which is a new hardware DMA engine in GCN 1.1 parts called XDMA. Being first utilized on Hawaii, XDMA is the final solution to AMD’s frame pacing woes, and in doing so it is redefining how Crossfire is implemented on 290X and future cards. Specifically, AMD is forgoing the Crossfire Bridge Interconnect (CFBI) entirely and moving all inter-GPU communication over the PCIe bus, with XDMA being the hardware engine that makes this both practical and efficient.

... it might be confirmation of the 'Bone being based at least in part on GCN 1.1.

 

[DJ12]

That was my first guess, but the MCC and MCD's are described as 'any of these blocks'. Why wouldn't the GPU DMA's be similarly described? The XDMA is referenced as singular.

Not that it matters, because we know the architecture, but it gives us something to talk about...

Very true but ms have a policy of naming things to make standard stuff seem exotic this round so who knows

I think the complete lack of other reference to the move engines is the clincher here, but I am a semi-knowledgeable enthusiast not an expert by any means.

 

[Deleted member 86764]

It mentions a few lines below

"The System DMA (SDMA2) block is busy"

and then:

"The System DMA (SDMA3) block is busy"

So the individual DMAs. I'd therefore guess that XDMA, signifies that the group of DMAs. X sometimes has the designation of a group of numbers, or a changing number(s).

 

[Polyteres]

Hi everyone. The XboxOne GPU is Bonaire (GCN 1.1) and like this has XDMA, where is the mystery?. It is like the 7790, it has that feature but is not in use. Sometimes remove a (very simple) hardware feature is more expensive than leaving it but not use it.

Bye.

 

[iroboto]

Hi everyone. The XboxOne GPU is Bonaire (GCN 1.1) and like this has XDMA, where is the mystery?. It is like the 7790, it has that feature but is not in use. Sometimes remove a (very simple) hardware feature is more expensive than leaving it but not use it.

Bye.

Yes no one is debating that.

It does confirm that the GPU is GCN1.1.

We have never really had true full confirmation that the X1 is Bonaire; or at least I have never read an official report that X1 GPU is. It certainly lines up well, but the details since they are available for discussion it is fair game for technical discussion.

 

[Shifty Geezer]

Hi everyone. The XboxOne GPU is Bonaire (GCN 1.1) and like this has XDMA, where is the mystery?

The mystery is some people wondering why XB1 would have a crossfire DMA block and how it could be busy in XB1 without multiple GPUs.

 

[Scott_Arm]

That was my first guess, but the MCC and MCD's are described as 'any of these blocks'. Why wouldn't the GPU DMA's be similarly described? The XDMA is referenced as singular.

Not that it matters, because we know the architecture, but it gives us something to talk about...

If you read through the API docs, there are tons of references to Windows Server 2012 and stuff like that. Completely irrelevant to Xbox One. What I imagine is that some of this stuff is just cut and paste out of other docs, and XDMA is a reference to a hardware counter for AMD Crossfire that really has no use in the console.

 

[iroboto]

The mystery is some people wondering why XB1 would have a crossfire DMA block and how it could be busy in XB1 without multiple GPUs.

From my reading of XDMA it seems very, well, like Scott said, ctrl+c ctrl+v documentation.
Even if we assume the false evidence is true, ie X1 does have 2 GPUs, it still wouldn't require XDMA.
From my understanding XDMA exists to copy the rendered frames and back and forth between the 2 GPUs without requiring that external bridge.
That external bridge would still be in place today except that it doesn't have enough bandwidth, so they created XDMA.

If X1 had 2 GPUs, they'd still share the same pool of memory and therefore there'd be no reason to leverage something like XDMA.

 

[function]

The crossfire block might have some kind of use, given some the changes to the system. Just spitballin', but there's the two memory pools and the need to sync DMAs, additional processors like the audio block, that fancy bus MS use for the CPU and CPU<->GPU stuff, the two command processors that might be talking to each other ...

... basically I have no idea and am just naming things, but, yunno, if you have a suitable block that could be re-tasked, why not save the work?

 

[Scott_Arm]

So far, in reading up on Draw Bundles, I can't see why any it would require any special hardware modifications for a GPU that already supports Command Lists, but I'm no expert. D3D12 Command Lists seem to be analogous to AMD Mantle's Command Buffers, and Draw Bundles just seem like a special type of Command List to be handled by the driver. I'm confident that Draw Bundles are what they're referring to when they talk about modifying the Command Processor interface. So I don't know what the deal is. In any case, "highly customized" sounds like a bit of a stretch from that particular answer.

 

[iroboto]

So far, in reading up on Draw Bundles, I can't see why any it would require any special hardware modifications for a GPU that already supports Command Lists, but I'm no expert. D3D12 Command Lists seem to be analogous to AMD Mantle's Command Buffers, and Draw Bundles just seem like a special type of Command List to be handled by the driver. I'm confident that Draw Bundles are what they're referring to when they talk about modifying the Command Processor interface. So I don't know what the deal is. In any case, "highly customized" sounds like a bit of a stretch from that particular answer.

\IIRC Someone else on this forum made mention that Draw Bundles, Descriptor Heaps and Tables as well as Pipeline State Objects were something that also exists in PS4 since launch. It should be part of every GCN based GPU, as D3D12 is available to all GCN1.0+ video cards. However the Command Processor is custom, the customization is not based on the Direct3D12.

 

[Scott_Arm]

\IIRC Someone else on this forum made mention that Draw Bundles, Descriptor Heaps and Tables as well as Pipeline State Objects were something that also exists in PS4 since launch. It should be part of every GCN based GPU, as D3D12 is available to all GCN1.0+ video cards. However the Command Processor is custom, the customization is not based on the Direct3D12.

Well, his answer about customizing the command processor is all about Draw Bundles, so either the customizations he asked for made it into GCN as a whole, the customizations they asked for are not particularly massive or the command processor is not actually customized at all.

 

[shredenvain]

Yes no one is debating that.

It does confirm that the GPU is GCN1.1.

We have never really had true full confirmation that the X1 is Bonaire; or at least I have never read an official report that X1 GPU is. It certainly lines up well, but the details since they are available for discussion it is fair game for technical discussion.

The XB one GPU isn't necessarily an exact replica of Bonaire. It has been confirmed to be Sea Islands since the DF architecture interview. From everything I have read Sea Islands is what they refer to as GCN 1.1 (naming scheme isn't actually used by AMD). Basically the Bonaire was the first Sea Island GPU and shares the same architecture as the R9 290x.