DirectX 12: The future of it within the console gaming space (specifically the XB1)

My guess would be that the current API on Xbox One is low overhead, but it does not expose the hardware to the developers to the same extent that DirectX12 will. In other words, what's there is efficient, but limited in function. It really does sound like Nvidia has worked with Microsoft to totally re-architect major parts of the Direct3D.
 
liolio said:
A couples of things leave me with strange feelings:
* First time line why wait that long? Nvidia has a neat demo running already.
* What i the XB1 running now so jumping to Directx 12 will actually improve performances? Certainly not a really low level API.
* late 2015, the XB1 will turn into a PC more or less from developers pov.

Overall it doesn't compute, hardware companies have been knowing about Dx 12 for a long while it seems, with demo running now I would think that it could be launched fall 2014.
MSFT may also need that boost on its mobile devices. Why the wait, 2 years is a lot of time.

I've my idea, I think they have greater plan. It is not directx 12 that is going to take 2 years but their next OS. They have stated that they want to have a single OS across all their platforms, so I think that by fall 2015 they are going to release a new OS working on both X86 and ARM CPU.
I think they are to push it aggressively everywhere, along with their Live network.
I expect a great change by that time and a leveled played field wrt to was used to be PC, mobile, console gaming.
Click to expand...


My guess for the 2 years ... testing. If they really are re-writing major portions and changing the programming model, it's a huge undertaking. Working with Nvidia, AMD, Intel to make sure everything is up to snuff and well tested would be a massive undertaking. It doesn't sound like they're finished with making changes yet either.
 
Guys you all seem to be forgetting this one slide from the event?
thumb900_phpsvgfplp1010612.jpg

"Some features alreay on Xbox"
D3D nearly zero resource overhead.
 
My biggest takeaway from that slide would be that some features from DX12 are present, but not all features. It's just a question of what is and isn't present.
 
NRP said:
I don't know what any of this means, but I do think people are getting far too hung up on it.
Click to expand...

lol me too. This is way over me at this point in time. I think only the engine coders can really comment on this stuff. Anyone working on X1 is likely already under NDA, so it's doubtful we'll hear anything.
 
DJ12 said:
I don't think it's likely that the first option is true. Maybe if this was their first console and they were blagging it but this is their third.

There has been no talk of how this is going to improve the Xbox with any sort of conviction or statistics so I am not expecting miracles (apart from on my pc when they finally get round to releasing it)

I think with the performance increases we've been told about pre release and post release we can reasonably assume that it's not a high over head api any more even if it was on the first place (which is just add unlikely in my opinion)

Xbox one's involvement in this had been a smoke screen in my opinion to keep the pr going. We were assured to "watch this space" at gdc to find out the benefit to Xbox one by a Microsoft mouth piece on Twitter yet gdc rolls around and there was nothing.

They have been very specific about what's happening on the pc and very vague about Xbox.

This is all about bringing the pc api closer to the console much like mantel. Improvements will be made in the process but we are not talking
About drastic performance increases here.

The biggest boost will come when they release some of the system reservation.
Click to expand...

Not sure how people can say that when they actually touched on some specific things the Xbox One isn't doing yet, but actually will with DX12. I'd understand if Microsoft weren't readily admitting that some features of DX12 are already in place on the Xbox One (such as the much lower levels of access that are being promised for PC as well as other platforms, or the DX12 bundles feature), but that's not what they've done. They've explicitly admitted that some features are, in fact, already available to Xbox One and that others are coming, even specifically listing what some of those things are.

And, really, what is the big deal with Microsoft choosing to call improvements of their console's SDKs and development tools that they provide to game creators, DirectX 12? There won't be some miraculous boost that suddenly makes all Xbox One games 1080p @ 60fps or anything crazy such as that, but there seems to be a general downplaying of the types of tool and SDK improvements that have become so commonplace on consoles now for years. Hasn't this kind of thing been done successfully on the Xbox 360? I don't get the skepticism. We already knew that tools would improve and performance optimizations would happen, as well as some software 'best practices' scenarios would emerge, didn't we?

How does the below slide constitute 'there was nothing'?

phpsvgfplp1010612.jpg
Click to expand...

'Some features are already on Xbox One'

to

'Other features map well to our usage patterns' followed by 'These will also be available on Xbox One'

Pipeline state objects and Resource binding both received paragraphs to themselves in Microsoft's official DirectX 12 blogpost on what some of the big additions were.

http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-12.aspx

They are both being described as two of the bigger feature additions to Direct3D 12 so far, and each one is implied as not yet being available on the Xbox One. If I'm wrong and these two things are just completely irrelevant things that should lead to no improvements at all, then, by all means, please correct me. They're described as things specifically for the purpose of reducing GPU overhead.

Pipeline State Objects Description.

Pipeline state objects

Direct3D 11 allows pipeline state manipulation through a large set of orthogonal objects. For example, input assembler state, pixel shader state, rasterizer state, and output merger state are all independently modifiable. This provides a convenient, relatively high-level representation of the graphics pipeline, however it doesn’t map very well to modern hardware. This is primarily because there are often interdependencies between the various states. For example, many GPUs combine pixel shader and output merger state into a single hardware representation, but because the Direct3D 11 API allows these to be set separately, the driver cannot resolve things until it knows the state is finalized, which isn’t until draw time. This delays hardware state setup, which means extra overhead, and fewer maximum draw calls per frame.

Direct3D 12 addresses this issue by unifying much of the pipeline state into immutable pipeline state objects (PSOs), which are finalized on creation. This allows hardware and drivers to immediately convert the PSO into whatever hardware native instructions and state are required to execute GPU work. Which PSO is in use can still be changed dynamically, but to do so the hardware only needs to copy the minimal amount of pre-computed state directly to the hardware registers, rather than computing the hardware state on the fly. This means significantly reduced draw call overhead, and many more draw calls per frame.
Click to expand...

New Resource Binding Model Description

Descriptor heaps and tables

Resource binding in Direct3D 11 is highly abstracted and convenient, but leaves many modern hardware capabilities underutilized. In Direct3D 11, games create “view” objects of resources, then bind those views to several “slots” at various shader stages in the pipeline. Shaders in turn read data from those explicit bind slots which are fixed at draw time. This model means that whenever a game wants to draw using different resources, it must re-bind different views to different slots, and call draw again. This is yet another case of overhead that can be eliminated by fully utilizing modern hardware capabilities.

Direct3D 12 changes the binding model to match modern hardware and significantly improve performance. Instead of requiring standalone resource views and explicit mapping to slots, Direct3D 12 provides a descriptor heap into which games create their various resource views. This provides a mechanism for the GPU to directly write the hardware-native resource description (descriptor) to memory up-front. To declare which resources are to be used by the pipeline for a particular draw call, games specify one or more descriptor tables which represent sub-ranges of the full descriptor heap. As the descriptor heap has already been populated with the appropriate hardware-specific descriptor data, changing descriptor tables is an extremely low-cost operation.
Click to expand...
 
Last edited by a moderator:
Scott_Arm said:
My guess for the 2 years ... testing. If they really are re-writing major portions and changing the programming model, it's a huge undertaking. Working with Nvidia, AMD, Intel to make sure everything is up to snuff and well tested would be a massive undertaking. It doesn't sound like they're finished with making changes yet either.
Click to expand...
My guess is that it is not testing :LOL:

Lots of the "efforts" (though they have been doing this on consoles for ages, possibly in a less controlled environment) will be on the devs. They stated that they've been talking about it for a while already. We saw a pretty advanced demo.

I think it will be tied to a certain OS. They could be communicating that early because they want plenty of games and software to make use of this at launch (vs the usual slow adoption of new API).
If they release an OS that replaces Windows phone and RT, that runs both on ARM and X86 they may want a lot of things (/software and tools) to be ready not only gaming related to maximize the final announcement.

I would think that direct x12 games are going to be "apps" using Windows runtine 2.0.
Virtualization on the Xb1 makes sense in that context.
So it could be that the extra time is also to iron things out on the CPU side.

EDIT

to some extend the XB1 looks like a gigantic beta test for such a move. Having the hypervisor doing its things, the OS handling background tasks on CPU and GPU compute (kinect) and the sand boxed games also using the GPU.
Next step is having a programming model for the cpu that is as ISA agnostic as possible and performs as close as possible to "native" programs.

EDIT 2
I also wonder about the desktop of Windows, it is otish but I think it could be a goner in quite some versions on their next OS (think phones, tablets, stb, even casual laptops) with it support for legacy apps. It could be open in a virtual machine /sandbox for legacy support and pro /specific usages (more expensive version of the OS). In a world in which more and more people are fine with ChromesOS, I think the desktop is no longer mandatory for windows.
 
Last edited by a moderator:
liolio said:
My guess is that it is not testing :LOL:

Lots of the "efforts" (though they have been doing this on consoles for ages, possibly in a less controlled environment) will be on the devs. They stated that they've been talking about it for a while already. We saw a pretty advanced demo.

I think it will be tied to a certain OS. They could be communicating that early because they want plenty of games and software to make use of this at launch (vs the usual slow adoption of new API).
If they release an OS that replaces Windows phone and RT, that runs both on ARM and X86 they may want a lot of things (/software and tools) to be ready not only gaming related to maximize the final announcement.

I would think that direct x12 games are going to be "apps" using Windows runtine 2.0.
Virtualization on the Xb1 makes sense in that context.
So it could be that the extra time is also to iron things out on the CPU side.

EDIT

to some extend the XB1 looks like a gigantic beta test for such a move. Having the hypervisor doing its things, the OS handling background tasks on CPU and GPU compute (kinect) and the sand boxed games also using the GPU.
Next step is having a programming model for the cpu that is as ISA agnostic as possible and performs as close as possible to "native" programs.

EDIT 2
I also wonder about the desktop of Windows, it is otish but I think it could be a goner on some version on their next OS. It could be open in a virtual machine /sandbox for legacy support and pro /specific usage. In a world in which more and more people are fine with ChromesOS, I think the desktop is no longer mandatory for windows.
Click to expand...

I don't know, can't see it considering that's the OS meant to allow modern apps to run in windowed mode on the desktop alongside native desktop apps. It's also the OS expected to bring back the start menu, but with a much expected 'new look'. The desktop, believe it or not, is almost certainly here to stay for a very, very, very long time. It's just going to see, at times, simultaneous evolution along with the Modern UI, and then there will be moments when they alternate.
 
SenjutsuSage said:
I don't know, can't see it considering that's the OS meant to allow modern apps to run in windowed mode on the desktop alongside native desktop apps. It's also the OS expected to bring back the start menu, but with a much expected 'new look'. The desktop, believe it or not, is almost certainly here to stay for a very, very, very long time. It's just going to see, at times, simultaneous evolution along with the Modern UI, and then there will be moments when they alternate.
Click to expand...
I think I was not clear, MSFT wants to have only one OS that doesn't mean that all its features are going to be activated on all its versions or any piece of hardware.
For example why activate the desktop on a tablet or a phone? Imo it is not the experience that type of users are searching for. The same is true for STB / HTPC, pretty much most people would be better served by the modern UI (/xbox).

Now as I said that for some specific usages you need it, and actually making it better is welcome.

Now I think MSFT could go (/may want...) further, if you disable the desktop on some Windows versions, you also disabled legacy support which means that any installed software is likely to come from the Windows store: quite a win for MSFT. They are cutting Windows license fees, actually they could with free or cheap license for Windows versions in which the desktop and legacy support is disabled and making up for it through the store revenue.
For example if Directx 12 games are Apps they by pass Steam.

You misread what I said I think we agree on the need for a 'desktop' and a better one on top of it.
 
SenjutsuSage said:
http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-12.aspx

Descriptor heaps and tables

Resource binding in Direct3D 11 is highly abstracted and convenient, but leaves many modern hardware capabilities underutilized. In Direct3D 11, games create “view” objects of resources, then bind those views to several “slots” at various shader stages in the pipeline. Shaders in turn read data from those explicit bind slots which are fixed at draw time. This model means that whenever a game wants to draw using different resources, it must re-bind different views to different slots, and call draw again. This is yet another case of overhead that can be eliminated by fully utilizing modern hardware capabilities.

Direct3D 12 changes the binding model to match modern hardware and significantly improve performance. Instead of requiring standalone resource views and explicit mapping to slots, Direct3D 12 provides a descriptor heap into which games create their various resource views. This provides a mechanism for the GPU to directly write the hardware-native resource description (descriptor) to memory up-front. To declare which resources are to be used by the pipeline for a particular draw call, games specify one or more descriptor tables which represent sub-ranges of the full descriptor heap. As the descriptor heap has already been populated with the appropriate hardware-specific descriptor data, changing descriptor tables is an extremely low-cost operation.

Pipeline State Objects Description.

New Resource Binding Model Description
Click to expand...

Console API's eg Xbox DX derivative didn't have that draw call issue. That is one advantage consoles already currently have. You are mixing up improvements the PC API desperately needs.
http://forum.beyond3d.com/showthread.php?t=61567
http://forums.tripwireinteractive.com/showthread.php?t=69260
http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/2
Bittech:
On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call.
 
Last edited by a moderator:
Pixel said:
Console API's eg Xbox DX derivative didn't have that draw call issue. That is one advantage consoles already currently have. You are mixing up improvements the PC API desperately needs.
http://forum.beyond3d.com/showthread.php?t=61567
http://forums.tripwireinteractive.com/showthread.php?t=69260
http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/2
Bittech:
On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call.
Click to expand...

I'm already quite aware of the fact consoles have far less problems with draw calls. However, even so, the features as described sound like more fundamental changes to the way Direct3D has worked in preparing graphics for rendering compared to past versions, even in comparison to how it's done on Microsoft consoles.

If it was already being done the way as described in those two new features, why are they clearly implying those features are not yet available to the Xbox One in their slide? These things sound like further efforts to reduce overhead on top of what's commonly available to consoles, am I wrong? The features that I highlighted.. is that commonly how Direct3D has worked on the Xbox 360 or even currently on the Xbox One? There's a clear implication on the presentation slide that it isn't, at least not yet. They've said these things will be available, not that they already are.

Well, only someone who has developed would possibly know, and I'm clearly not that person, so maybe I'm wrong.
 
On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call.
Click to expand...
Anyone know how many you can draw with mantle ?
 
You know, Pixel, from reading that post that you linked to, that's labeled as being from a Codemasters programmer (not sure if it is or isn't, but I'm just going based on what I saw stated), even he seems to place the real issue for PCs as being more CPU related due to the lack of being able to issue more draw calls as easily as the consoles can.

The two specific things I highlighted about DX12, however, are specifically GPU overhead related changes that makes core changes to the way programmers set up the work they need to have processed in Direct3D. So the post seems to, I think, further creates space between the two specific DX12 related improvements from what might normally be considered a "common thing" for consoles.

Edit: What exactly does this mean?

http://newsle.com/article/0/132860618/

There are other optimizations to reduce system loads in DirectX 12 as well, Gosalia said. Since "most apps and games have a lot of similarity in what they draw from one frame to another," DirectX 12 has algorithms to reduce the overhead from recalculating minor state changes in a scene. A new heap implementation will amortize the creation and destruction of resources, limiting system costs. DirectX 12 will introduce a new, faster resource binding model and allow for faster reuse of memory freed up by used resources that are no longer needed. Developers will also be able to decompress ASTC and JPEG images in hardware
Click to expand...

If I remember, I think one of the Xbox One's move engines have a fixed function unit for decoding JPEG.
 
Last edited by a moderator:
BTW:

Barbarian said:
As a developer I'm truly excited about this development.
If Nvidia come out with a similar API, DX will become almost instantly obsolete.
Porting to a couple of APIs is not a big deal. HLSL compatibility is key though.
I'm willing to bet, Mantle will be the only way to match next-gen consoles draw call performance.
If you think PCs have trouble with 5k draw calls right now, imagine what will happen when consoles start pushing 100k draw calls in a year or two ...
Click to expand...

http://forum.beyond3d.com/showpost.php?p=1789288&postcount=32
 
You must log in or register to reply here.

Similar threads

D
Video Game Console Cooling - A Hot Topic (pun kind of intended).
Replies
14
Views
3K
Shifty Geezer
Shifty Geezer
N
Console space contribution in the evolution of gaming.
Replies
4
Views
2K
Cyan
Cyan
Cyan
  • Locked
Which console was more powerful, the PS3 or the Xbox 360?
Replies
3
Views
12K
Shifty Geezer
Shifty Geezer
Cyan
Back into the PC Master Race. It was never a total absence but still.
9 10 11
Replies
200
Views
38K
Malo
Malo
BRiT
  • Locked
  • Poll
Nintendo Switch Price Speculation (Last Week Poll)
3 4 5
Replies
92
Views
13K
BRiT
BRiT
Back
Top