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

[Starx]

Advanced Graphics Techniques Tutorial Day: Developing The Northlight Engine: Lessons Learned
Northlight is Remedy Entertainment's in-house game engine which powers Quantum Break. In this presentation we discuss how various rendering performance and efficiency issues were solved with DirectX, and suggest design guidelines for modern graphics API usage.
Takeaway
How to write a fast and efficient DirectX 12 / Vulkan engine, and how to use the new HW features to implement new graphics techniques. Learn from real shipping game developers experiences
http://schedule.gdconf.com/session/...eloping-the-northlight-engine-lessons-learned

 

[Starx]

Fable Legends will use DirectX 12 (DX12) and we wondered why. Whyte said that by using DX12, the team was able to achieve “a significant amount of horsepower – resulting in increased visual fidelity, higher frame rates, and improved shadows and effects.” Whyte further said that, depending on the graphics card, the team saw “up to 40% faster performance” on DX12 as compared to DX11. He believes anything that helps improve the graphical quality in games will definitely be loved by gamers and developers alike, and we couldn’t agree more.

The Xbox was based on Direct X technology, and that’s where the X comes from. Since Fable Legends is also being released on the Xbox One and allows cross-play, we were curious to know how Microsoft’s latest machine would benefit from DX12. And from the looks of it, apparently quite a bit.

“Fable Legends is using a number of features on Xbox One,” said Whyte, “including asynchronous compute and efficient multi-threaded rendering.” This has led to improvements in rendering efficiency, which means that the developer can “push the visual bar higher than would otherwise be possible.” This also means that the Xbox One now has better graphical and computing capabilities without actually increasing the hardware, all thanks to DirectX 12.

http://www.bidnessetc.com/62286-inside-fable-legends-an-exclusive-interview-with-stuart-whyte/

 

[Shifty Geezer]

The quote says it's using a number of features of XB1, not a number of DX12 features newly available on XB1. Asynch compute was available without DX1 AFAIK. Not entirely sure what 'efficient multithreaded rendering' alludes to. There already exist multithreaded renderers on consoles, but he may be referring to multithreaded draw calls? Which has already been discussed regards impact.

 

[iroboto]

The quote says it's using a number of features of XB1, not a number of DX12 features newly available on XB1. Asynch compute was available without DX1 AFAIK. Not entirely sure what 'efficient multithreaded rendering' alludes to. There already exist multithreaded renderers on consoles

Yes

but he may be referring to multithreaded draw calls? Which has already been discussed regards impact.

I believe it does likely mean draw calls. I think we had a general guidance that more draw calls performed worse than less draw calls. That there is no reason to use more draw calls if you could use less. The exception to the rule being increased draw calls for enhanced graphical fidelity, or that the multithreaded draw calls were calling async compute calls which is an ideal scenario vs calling them serially l.

But ignoring that multithreaded draw calls should improve performance (especially on a weak CPU) over non multithreaded draw calls. (Pending how many draw calls) if at the very least provide a mug more consistent frame rate as a result of more things appearing on screen.

Edit: lastly, it's possible there are other potential gains in multithreaded draw calls that may have yet to be discovered! Looking forward to seeing what devs do

Edit 2: if we were to tie this back to Xbox, it is possible that XBO command processors may have been tweaked to do more heavy lifting when concerning multithreaded draw calls; such that the benefit being either improved performance (unproven but the assumption is that it can schedule better) or lessening the degree of optimization required by the developers to side step possible pitfalls of multithreaded draw calls (better scheduling once again)

 

[forumaccount]

his also means that the Xbox One now has better graphical and computing capabilities without actually increasing the hardware, all thanks to DirectX 12.

This is pretty much PR spin. DX12 is great but neither of the XB1 features mentioned are directly related. The sad part is that the whole thing about better capabilities without increasing the hardware is because they've been playing catchup since day 1 on their software stack. :-/

 

[iroboto]

This is pretty much PR spin. DX12 is great but neither of the XB1 features mentioned are directly related. The sad part is that the whole thing about better capabilities without increasing the hardware is because they've been playing catchup since day 1 on their software stack. :-/

I'm honestly not even sure how you guys made it lol. I suppose working with dx11 in 2011 and it is still undergoing changes

 

[Themrphenix]

This is pretty much PR spin. DX12 is great but neither of the XB1 features mentioned are directly related. The sad part is that the whole thing about better capabilities without increasing the hardware is because they've been playing catchup since day 1 on their software stack. :-/

I think they are going to start letting Devs use second GCP now.I discussed this month's ago.That some time after next Xbox One OS is launched and dx12 was in the wild this would be next.

Multithreading the draw calls and use of the second GCP.Look at my post history to confirm.

 

[function]

Are there any rumours you've seen on the webs about this?

 

[Deleted member 86764]

I think they are going to start letting Devs use second GCP now.

Yes, because it makes perfect sense to prevent software developers from using hardware features until several years after the hardware is released.

 

[Cyan]

Yes, because it makes perfect sense to prevent software developers from using hardware features until several years after the hardware is released.

do you pour your heart out to others at the first opportunity? You can't pour your heart out to someone in no time..

 

[Deleted member 86764]

do you pour your heart out to others at the first opportunity? You can't pour your heart out to someone in no time..

I have high standards.

 

[iroboto]

do you pour your heart out to others at the first opportunity? You can't pour your heart out to someone in no time..

We just need proof cyan. And I'd also like some sort of (why or in what way would this second GCP) help.

Why is it even important or why we should care as a tech forum? I mean for myself it's plausible that yes MS knew about dx12 while designing XBO and perhaps in their testing they found the multithreaded draw call performance under performing so they reworked in a bit to bring it up to par or at least make it usable for XBO without having devs to heavily optimize their code.

But I don't have any reason to believe that the GCP is a boost in performance, it's meant to schedule work. It would be nice that it can now have more work to schedule so that the GPU Isn't waiting for work. But we are talking about improving the yield of the existing hardware, not adding more performance.

Even that should have its limits.

 

[Lalaland]

Is this the second GCP on the dark silicon 3 D stacked 2.6 TF programmable ARM cores gjskdjhdgsjaksljejdhdhdge......


Yeah I'm going with Cyan here MS is just a shy date, if we'd paid them more attention in the first year maybe they'd have had the confidence to talk about their embarrassing second GCP sooner...

Real talk why the hell would something like a second scheduler be held back? Are multiple GCPs analogous to Hyperthreading in that they allow for more efficient uses of existing resources rather than adding capability (IE approach 100% utilisation of existing ALU & ROP resources).
Edit Which is what iRoboto said right above me, reading fail on my part

 

[Themrphenix]

Is this the second GCP on the dark silicon 3 D stacked 2.6 TF programmable ARM cores gjskdjhdgsjaksljejdhdhdge......


Yeah I'm going with Cyan here MS is just a shy date, if we'd paid them more attention in the first year maybe they'd have had the confidence to talk about their embarrassing second GCP sooner...

Real talk why the hell would something like a second scheduler be held back? Are multiple GCPs analogous to Hyperthreading in that they allow for more efficient uses of existing resources rather than adding capability (IE approach 100% utilisation of existing ALU & ROP resources).
Edit Which is what iRoboto said right above me, reading fail on my part

I have never made statements about dark silicon,3D stacks etc etc.I have leaked many things on this site that has been accurate and proven right.

Here's a link to a post on this forum discussing my track record here.

Xbox One November SDK Leaked

 

[Pixel]

I think they are going to start letting Devs use second GCP now.I discussed this month's ago.That some time after next Xbox One OS is launched and dx12 was in the wild this would be next.

Multithreading the draw calls and use of the second GCP.Look at my post history to confirm.

Given AMDs eroding gpu marketshare, if the upcoming mid-high to high end 14nm Polaris gpus don't have a second GCP in their gpu lineup given the relative small silicon real estate it takes up, then I think think we can debunk the idea that it can offer moderate to large performance improvements.

14nm is around the corner and by AMD's own words that allows for more than a doubling of transistor count in the same mm^2so with DX12 right around the corner why wouldn't they they include a second GCP especially in their high end?

 

[Themrphenix]

Given AMDs eroding gpu marketshare, if the upcoming mid-high to high end Polaris gpus don't have a second GCP in their gpu lineup given the relative small silicon real estate it takes up, then I think think we can debunk the idea that it can offer moderate to large performance improvements.

I don't believe there to be performance gains as much as efficiency gains..I also believe at some point Nividia and AMD will start adding second GCP to GPU'S.Just because hasn't happened yet doesn't mean it will not.

I'm also not an expert with Nividia GPU's.I believe better utilization of said hardware and efficiency will be like performance gains to those who search for it.The hardware it self will as remain the same.

 

[Pixel]

I don't believe there to be performance gains as much as efficiency gains..I also believe at some point Nividia and AMD will start adding second GCP to GPU'S.Just because hasn't happened yet doesn't mean it will not.

Efficiency gains would in many circumstances lead to improved performance, akin to hyperthreading.

14nm is coming, more than doubling of transistor count is coming, DX12 is right around the corner, AMD gpu marketshare is eroding, AMD is financially bleeding badly, so you are trying and say that AMD may sitting on something that could improve efficiency in DX12 games on Polaris Arch? What is the rational of that?

 

[Infinisearch]

There already exist multithreaded renderers on consoles, but he may be referring to multithreaded draw calls? Which has already been discussed regards impact.

Where? I'm curious as to what was said.

“Fable Legends is using a number of features on Xbox One,” said Whyte, “including asynchronous compute and efficient multi-threaded rendering.” This has led to improvements in rendering efficiency

I believe it does likely mean draw calls. I think we had a general guidance that more draw calls performed worse than less draw calls. That there is no reason to use more draw calls if you could use less.

Actually I would think reducing overdraw by ordering your drawcalls in such a way that breaks batching could increase performance by being more efficient by using more draw calls.

 

[Shifty Geezer]

Where? I'm curious as to what was said.

https://forum.beyond3d.com/search/1546178/?q=multithreaded&t=post&o=relevance&c[thread]=55487

 

[forumaccount]

Actually I would think reducing overdraw by ordering your drawcalls in such a way that breaks batching could increase performance by being more efficient by using more draw calls.

Yeah this is the next step... I just got done working on reducing draw calls as much as possible. Now the next iteration of my stuff needs to throw all that out and use some extremely large number of draw calls due to the flexibility it gives (when done on GPU). In the future I hope the concept of a draw call goes away... these days we have less and less need to use them to break up blocks of fixed-function state.