Xbox One November SDK Leaked

[Shifty Geezer]

If the second CP isn't described in the SDK, doesn't that pretty much confirm it's for OS use only? If it was being exposed for devs to use, it'd need to be documented. With XB1's complex OS structure, one pipeline for preemptive GPU control makes sense to me.

 

[shredenvain]

If the second CP isn't described in the SDK, doesn't that pretty much confirm it's for OS use only? If it was being exposed for devs to use, it'd need to be documented. With XB1's complex OS structure, one pipeline for preemptive GPU control makes sense to me.

I have always understood that the function of the dual graphics command processors was to use one CP for high priority work (Title Rendering) and the 2nd for low priority work ( UI functions). Now this usage isn't necessarily set in stone, but if the 2nd GCP is ever given to the title wouldn't that disable some system side functions like Snapping Apps? Sure 1.3 CPU cores are dedicated to system functions like snap, but they still have to be rendered don't they?

 

[mikee]

If the second CP isn't described in the SDK, doesn't that pretty much confirm it's for OS use only? If it was being exposed for devs to use, it'd need to be documented. With XB1's complex OS structure, one pipeline for preemptive GPU control makes sense to me.

Did Microsoft not say how many queues the compute command processors have, I am sure I read they are not equivalent to 1 ACE, seems odd they would double the graphics command processor allowing dual pipeline but not beef up the compute ? I should probably continue reading the document, it is very interesting makes you wonder

 

[3dilettante]

One side note is that the SDK discusses how one of the command queues for the second low-priority ACE is system reserved. I also have not seen reference to the second graphics front-end.

For comparison, Vgleaks has a system-reserved graphics front end and a (probably) system-reserved compute pipe for Orbis.
The exact proportions have shifted, but there may be a base motivation for both architectures to split the front ends.

 

[iroboto]

If the second CP isn't described in the SDK, doesn't that pretty much confirm it's for OS use only? If it was being exposed for devs to use, it'd need to be documented. With XB1's complex OS structure, one pipeline for preemptive GPU control makes sense to me.

This is more or less I think what I've settled on. I guess there's no point further in discussing it unless we see dual CPs come up in future AMD IPs.

 

[mikee]

That would be like saying the 7 ACES on the ps4 are only for cpu usage in which case why have that many. Apologies that is not meant to sound nasty, but reading it back I realise it could be taken that way, it is a genuine question. I am trying to understand the differences and what customisations have been made.

 

[Shifty Geezer]

Feel free to present your own theory. As far as seems described, MS added a second graphics command processor, the function of which we can only guess it. As it doesn't seem to be exposed to the devs to use, surely the logical conclusion is that it's for the system to use? And as the system multitasks with games including the system's own graphics drawing which needs to have higher priority drawing for smooth operation, doesn't it make sense to have a graphics command processor dedicated to the task with its own queues?

It has nothing in parallel with PS4's ACEs which are there for compute, not CPU anything.

 

[mikee]

Sorry dude was reading CP as the compute command processor not the graphics command processor, I was looking at the ieee xbox one diagram thinking the graphics part was geared to doing two graphics commands simultaneously. And as you guys said what is the compute part doing if it's not in the sdk. Excuse my ignorance not read all the documentation yet

Previously somebody mentioned xdma would that suggest some sort of dual usage somewhere, I thought if it has two graphics command processors this would add up.

I am sure I will be wrong lol

 

[mikee]

Oh hang on did somebody not say you had high priority render and low but either could overtake the other or use spare resources. Maybe that's what they are, you can use a % to do a task but can run two at once, instead of having it wait until the first one finished.

Sorry brain fart, probably makes no sense, time for bed

 

[iroboto]

Feel free to present your own theory. As far as seems described, MS added a second graphics command processor, the function of which we can only guess it. As it doesn't seem to be exposed to the devs to use, surely the logical conclusion is that it's for the system to use? And as the system multitasks with games including the system's own graphics drawing which needs to have higher priority drawing for smooth operation, doesn't it make sense to have a graphics command processor dedicated to the task with its own queues?

It has nothing in parallel with PS4's ACEs which are there for compute, not CPU anything.

I suppose if we go with this the OS cpu cores
are issuing draw call commands with specific flags so that it goes to 1 command processor over the other. Does make me wonder how ps4 is handling their OS or because snap does not exist or camera controls don't exist while a game title is playing it excludes them from requiring it.

I suppose it's not required though, but when running a game in windowed mode the graphics command processor needs to do both OS and game title right? It seems to handle it fine on Windows.

 

[mikee]

Is that what MS are calling display planes ? I thought they said it had 3, or was that virtual OS. The OS/UI is not that complicated, doubt it would need 3d or vector processing. As you said up till now one has managed fine for windows.

Though to contradict myself if MS can drop OS usage to 1.2 cores would suggest they did most of the processing in compute and did not use the second graphics command processor.

Kinda hope they release the dx12 notes, am I right in saying dx 11.2 or whatever they use currently can not use dual graphics command processors anyway, which might explain why is not in the documentation.

 

[iroboto]

Is that what MS are calling display planes ? I thought they said it had 3, or was that virtual OS. The OS/UI is not that complicated, doubt it would need 3d or vector processing. As you said up till now one has managed fine for windows.

Though to contradict myself if MS can drop OS usage to 1.2 cores would suggest they did most of the processing in compute and did not use the second graphics command processor.

Kinda hope they release the dx12 notes, am I right in saying dx 11.2 or whatever they use currently can not use dual graphics command processors anyway, which might explain why is not in the documentation.

No display planes are on GCN. IIRC GCN has 2, and if you decide you need to use more you can create additional display planes with your own solution as opposed to a complete hardware solution. Anything done in hardware can always be replicated in software.

I just walked home from transit. The thought that just occurred to me is that I've never checked if you could run 2 Direct3d accelerated games in windowed mode at the same time, at least using the same display driver. If you have 2 video cards you could theoretically assign 1 game 1 display driver, and the other a different one. Maybe xbox is capable of 2 direct3d one of which is currently reserved for OS and snap mode and one for the game title.

 

[powdercore]

If the second CP isn't described in the SDK, doesn't that pretty much confirm it's for OS use only? If it was being exposed for devs to use, it'd need to be documented. With XB1's complex OS structure, one pipeline for preemptive GPU control makes sense to me.

Is it possible this is not yet exposed because it requires an SDK that supports it? I have a guess it's waiting for DX12. We don't see much about DX12 in this leak that will likely exposed once DX12 reaches completion.

 

[Cyan]

how the heck MS able to do all xbox stuff with only 1 and a half core.. while sony needs 2 full cores for stutter-ey slugish and very barebone multitaskting and OS.

Actually, I am surprised at that too because the Xbox One is running 3 simultaneous OSs using a single core and 20% of a second core, and still while it doesn't have a superb fast dashboard, it runs fine. You also need to consider it is adding new functionalities quite swiftly too, from custom backdrops to DLNA support, etc etc, while performance remains the same.

I think that Sony are going to do something similar over time --except if they pretend to use a second core for Project Morpheus. Sony chose FreeBSD for the PS4 and the PS4 was created to use 512MB in mind. FreeBSD uses very little memory itself, something along the lines of 300/350 MB with a UI. So I guess a similar approach is to be expected.

https://www.freebsd.org/doc/en/books/design-44bsd/overview-memory-management.html

mosen is mythical!!

 

[Scott_Arm]

It's not running 3 operating systems using 1.5 cores. The title OS runs on the 6.5 cores for the game. The System OS would run on the other 1.5 cores, but the Host OS should use little to nothing in terms of resources. The Host OS is just a hypervisor.

I think a lot of people see "3 Operating Systems" and they imaging 3 Windows kernels running at the same time, but that's not what it is. The System OS is probably closest to Windows, while the Host OS is a hypervisor and the Title OS is probably an absolutely stripped down kernel that basically handles all the SDK API calls and that's pretty much it.

 

[oldschoolnerd]

Is it possible this is not yet exposed because it requires an SDK that supports it? I have a guess it's waiting for DX12. We don't see much about DX12 in this leak that will likely exposed once DX12 reaches completion.

Isn't this referred to in the sdk. Highlighted in this image.

 

[3dilettante]

The discussion was focused on the second graphics front end. That documentation in aligns with the two ACEs, which have various mentions in the document.

 

[SlickShoesRUCrazy]

Isn't this referred to in the sdk. Highlighted in this image.

This made by the misterxmedia guys? cause that's who i have seem post around the net, or did they get from somewhere else?

 

[oldschoolnerd]

This made by the misterxmedia guys? cause that's who i have seem post around the net, or did they get from somewhere else?

I didn't get it from there, but it does have the smell of it. However, if you just look at the bits from that actual sdk and ignore and added interpretation it does seem to support the view that more that one command processors (called pipes in the document?) will become available to titles once the sdk is updated.

 

[Shifty Geezer]

As 3dilettante says, that excerpt is talking about asynchronous compute, or the CCPs. The line of discussion you replied to was the second GCP. It would appear from your excerpt that only low priority compute jobs can be requested (defaulting to 4 CUs?), but in future the high priority compute requests will be enabled. Though the nature of asynchronous compute is that it works when the GPU is 'idle'. Higher priority jobs would divert GPU resources to compute and not be so asynchronous! It'd be more 'compute' in that case, as I understand it. This is of course essential for compute-based renderers in future.