DX12 is out of experimental since 2022.2.0a17

[tvirolai]

Hello,

As everyone might know, the DX12 backend has been slow, and somewhat unstable, for as long as there has been one. Back in 2020 the per drawcall overhead on the CPU was a bit over double what it was on other backends. With recent improvements the DX12 backend is now as fast as (or in some cases faster than) DX11 when it comes to CPU usage for the vast majority of use cases. In scenarios with a large amount of drawcalls, DX12 beats DX11 handily in standalone with regards to CPU performance. Results based on our testing show that there isn’t a substantial difference between DX12 and our other Editor backends to warrant an Experimental tag anymore. Therefore:

We are happy to announce that as of 2022.2.0a17, the DX12 graphics backend is officially out of experimental state.

What does this mean in practice? You can now make a player that has only the DX12 backend. Experimental tag forced you to add at least one non experimental backend but now DX12 can be the sole backend in a player build. This is the only functional change you see with the removal of the experimental tag.

Another feature which has been unique to DX11 is the memory residency management. Windows allows you to essentially use more GPU memory than what you have. In DX11 this is fully automatic but DX12 requires us to give it a slight helping hand so to speak. This has now been implemented so you can overprovision GPU memory. It’s not quite as good as in DX11 as we do this essentially on a per frame basis. But otherwise huge scenes should be far more stable now.

However DX12 is not always the fastest. The DX11 driver can do things like reorder compute shader dispatch calls, which it does aggressively. With DX12 the driver cannot do this, the same applies to Metal and Vulkan. And even when possible, such as in many OpenGL drivers, the driver doesn’t always do it. So if you have a complex set of compute shaders it is likely that in DX11 it will be faster. There are plans to do this sort of reordering in Unity but that will take time. At the moment, heavily GPU bound scenes with a complex workload are likely to run faster on DX11.

A major painpoint in Unity is the Editor performance. In order to alleviate this DX12 allows you to run native graphics jobs in Editor. This feature is still experimental but you can already try it by launching the Editor with the following command line argument:
-force-gfx-jobs native
User feedback has been that in massive projects running the Editor with native jobs is essentially mandatory, but we’re not quite there yet to confidently enable them by default for everyone. Therefore we’d love feedback and bug reports for any issues that pop up when using them.

tl;dr: 2022.2.0a17+ You are GPU bound = Use DX11. You are CPU bound = Use DX12. If you are brave and need Editor perf run DX12 with native graphics jobs in Editor.

[rz_0lento]

@tvirolai Since on this topic, could someone at Unity explain Unity’s use of D3D11On12 API? Direct3D 11 on 12 - Win32 apps | Microsoft Learn. Unity seems to use this at least on HDRP (nsight does complain about it but nsight still works).

Why does Unity use such wrapper and not use DX12 directly? What are the pros and cons of this (other than Unity being able to reuse old API calls internally)? Does this have performance implications?

[tvirolai]

@rz_0lento

@tvirolai Since on this topic, could someone at Unity explain Unity’s use of D3D11On12 API? https://docs.microsoft.com/en-us/windows/win32/direct3d12/direct3d-11-on-12. Unity seems to use this at least on HDRP (nsight does complain about it but nsight still works).

Why does Unity use such wrapper and not use DX12 directly? What are the pros and cons of this (other than Unity being able to reuse old API calls internally)? Does this have performance implications?

We do use DX12 directly. However we do create a D3D11On12 device on top of it due to some internal shenanigans related to how DXGI works. The only downside of this is that Nsight complains about it. It probably could be refactored now if MS has improved things. We do not actually perform any API calls through it when rendering. It’s only used for a tiny sliver of time during startup.

We also create a full fledged D3D11 device in some cases and use interop with that. And that’s because the video decoding in Windows didn’t support DX12 back in the days. Now there is a DX12 way too but no-one has just gotten around to implement it because the interop way works fine.

[PutridEx]

Since HDRP is all about compute, doesn’t this mean that if you use HDRP, DX12 is still ‘experimental’?
As in you can’t really get better performance with DX12, instead you’ll always get lower performance compared to DX11 unless you use absolutely no effects and create your own.

I imagine you can see this with a simple scene that uses some post processing, volumetric fog. Although I haven’t really done it so I can’t say for sure.

[rz_0lento]

Experimental state is more of Unity’s way of saying: “things can change and we will not be accountable for your troubles if you use this in production”. Now that it’s out of experimental, expect higher level support and less chances for API breakage etc. And if they now change API, you can expect some API upgrading scripts now to run automatically. Plus like mentioned already, now you can actually do DX12 only builds.

I don’t quite get the compute being experimental assumption. HDRP has been released long time ago and have used compute since day one. How I see it, whatever experiments you do yourself with it is up to you

[tvirolai]

@PutridEx

Since HDRP is all about compute, doesn’t this mean that if you use HDRP, DX12 is still ‘experimental’?
As in you can’t really get better performance with DX12, instead you’ll always get lower performance compared to DX11 unless you use absolutely no effects and create your own.

I imagine you can see this with a simple scene that uses some post processing, volumetric fog. Although I haven’t really done it so I can’t say for sure.

It doesn’t mean that one always gets lower GPU performance compared to DX11. It means it’s way easier to get good performance in DX11, well at least on one particular vendors DX11 that is really great at reordering things optimally for the user. On others the DX12 backend can actually be faster also on the GPU.

Right now every backend works in the way that things are submitted exactly as they are given to us. So you can make it faster by giving it in different order, we just don’t do it automatically. HDRP team does things quite well in this regard. And in standalone the async compute HDRP uses also makes it go bit faster.

As we are Unity we must be able to work easily for the user and not require super detailed knowledge of the pipeline and dependencies even if the user is capable of writing their own compute shaders. When we do reordering on the backend we’ll do it in a way that will speed up all the other backends too. It wouldn’t make sense to do it just for DX12.

[Saniell]

So if DX12 is out of preview, maybe we could also get support for ExecuteIndirect/DrawIndirectCount (vulkan) APIs, please?

[merpheus]

Okay, but does this mean VRS and mesh shaders are directly supported now?

[PerunCreative_JVasica]

@tvirolai

Hello,

As everyone might know, the DX12 backend has been slow, and somewhat unstable, for as long as there has been one. Back in 2020 the per drawcall overhead on the CPU was a bit over double what it was on other backends. With recent improvements the DX12 backend is now as fast as (or in some cases faster than) DX11 when it comes to CPU usage for the vast majority of use cases. In scenarios with a large amount of drawcalls, DX12 beats DX11 handily in standalone with regards to CPU performance. Results based on our testing show that there isn’t a substantial difference between DX12 and our other Editor backends to warrant an Experimental tag anymore. Therefore:

We are happy to announce that as of 2022.2.0a17, the DX12 graphics backend is officially out of experimental state.

What does this mean in practice? You can now make a player that has only the DX12 backend. Experimental tag forced you to add at least one non experimental backend but now DX12 can be the sole backend in a player build. This is the only functional change you see with the removal of the experimental tag.

Another feature which has been unique to DX11 is the memory residency management. Windows allows you to essentially use more GPU memory than what you have. In DX11 this is fully automatic but DX12 requires us to give it a slight helping hand so to speak. This has now been implemented so you can overprovision GPU memory. It’s not quite as good as in DX11 as we do this essentially on a per frame basis. But otherwise huge scenes should be far more stable now.

However DX12 is not always the fastest. The DX11 driver can do things like reorder compute shader dispatch calls, which it does aggressively. With DX12 the driver cannot do this, the same applies to Metal and Vulkan. And even when possible, such as in many OpenGL drivers, the driver doesn’t always do it. So if you have a complex set of compute shaders it is likely that in DX11 it will be faster. There are plans to do this sort of reordering in Unity but that will take time. At the moment, heavily GPU bound scenes with a complex workload are likely to run faster on DX11.

A major painpoint in Unity is the Editor performance. In order to alleviate this DX12 allows you to run native graphics jobs in Editor. This feature is still experimental but you can already try it by launching the Editor with the following command line argument:
-force-gfx-jobs native
User feedback has been that in massive projects running the Editor with native jobs is essentially mandatory, but we’re not quite there yet to confidently enable them by default for everyone. Therefore we’d love feedback and bug reports for any issues that pop up when using them.

tl;dr: 2022.2.0a17+ You are GPU bound = Use DX11. You are CPU bound = Use DX12. If you are brave and need Editor perf run DX12 with native graphics jobs in Editor.

Great work. Are these improvements across all the RP? (BRP, URP and HDRP)

[tvirolai]

@merpheus

Okay, but does this mean VRS and mesh shaders are directly supported now?

Not yet. We don’t want to just expose something DX12 specific because it will lead the feature to be only working on DX12.

Or more realistically it would be exposed directly with the promise “Yeah we don’t need to support it elsewhere” and then massive panic emulation on other platforms because of course it must be supported everywhere and incredible amount of bugs because not all the edgecases work exactly identically everywhere.

When we bring those features they must work on all the platforms with similar features. Because if you make a game in Unity it must work the same across all the platforms you want to publish it in (with the obvious limitation that the feature must actually exist in the platform in at least some form).

@PerunCreative_JVasica

Great work. Are these improvements across all the RP? (BRP, URP and HDRP)

It’s across all. From the low level perspective there isn’t really much difference between SRP and BRP. The only exception to this is the SRP Batcher which also has gotten several rounds of speedups.

[rz_0lento]

@tvirolai

When we bring those features they must work on all the platforms with similar features. Because if you make a game in Unity it must work the same across all the platforms you want to publish it in (with the obvious limitation that the feature must actually exist in the platform in at least some form).

To be fair… current Raytracing already only works on select platforms and on DX12 only with Unity. VRS is also tech that could easily be optional for some platforms only as it’s more of optimization than whole new way to author new content. I get the argument for Mesh shaders though.

[hippocoder]

[quote=“tvirolai, post:10, topic: 886235, username:tvirolai”]
It’s across all. From the low level perspective there isn’t really much difference between SRP and BRP. The only exception to this is the SRP Batcher which also has gotten several rounds of speedups.
[/quote]HDRP has a quite-high CPU cost vs URP, and is that because of the SRP part or something your team’s work will also indirectly help with? Thanks for any insights.

[merpheus]

@tvirolai

Not yet. We don’t want to just expose something DX12 specific because it will lead the feature to be only working on DX12.

Or more realistically it would be exposed directly with the promise “Yeah we don’t need to support it elsewhere” and then massive panic emulation on other platforms because of course it must be supported everywhere and incredible amount of bugs because not all the edgecases work exactly identically everywhere.

When we bring those features they must work on all the platforms with similar features. Because if you make a game in Unity it must work the same across all the platforms you want to publish it in (with the obvious limitation that the feature must actually exist in the platform in at least some form).

Then honestly, I don’t really understand why it will be out of preview. Since clearly, this is one of the key points of the dx12. Do we even have SM 6.6 support or sth? It has two main advantages from what I can get: 1- Better editor performance sometimes 2- we don’t have to add dx11 as fallback api.

Dx12 should allow things to run much faster if the gfxdriver abstracted rendering code is written in a way that can allow it. It doesn’t appear to be the case from what I get. Plus, new APIs coming with it are also not supported. I understand you folks have done some pipeline cleanup work but as an end-user, plus stuff like mesh shaders are supported in other gfxdrivers such as vulkan and metal but I don’t think this “out of preview” news covers the cases it should have after months and months of waiting.

[hippocoder]

Well to be fair, it wasn’t being developed at all for “months and months”. The team on this is relatively new and working hard despite being small. So I think they’re doing well and have a picture of where they’re going.

[Henrarz]

@tvirolai

When we bring those features they must work on all the platforms with similar features. Because if you make a game in Unity it must work the same across all the platforms you want to publish it in (with the obvious limitation that the feature must actually exist in the platform in at least some form).

So… when can we see ray tracing being available for Vulkan and Metal? Both APIs have ray tracing extensions.
And when can we see HDRP being compatible on iOS devices? It runs on M1 Macs, but for some weird reason it doesn’t work on M1 iPads.

[merpheus]

@hippocoder

Well to be fair, it wasn’t being developed at all for “months and months”. The team on this is relatively new and working hard despite being small. So I think they’re doing well and have a picture of where they’re going.

team on the core rendering/gfx driver code is small and new? Because surely this is the gfx device code-related feature.

[dnach]

@merpheus

Then honestly, I don’t really understand why it will be out of preview. Since clearly, this is one of the key points of the dx12. Do we even have SM 6.6 support or sth? It has two main advantages from what I can get: 1- Better editor performance sometimes 2- we don’t have to add dx11 as fallback api.

Dx12 should allow things to run much faster if the gfxdriver abstracted rendering code is written in a way that can allow it. It doesn’t appear to be the case from what I get. Plus, new APIs coming with it are also not supported. I understand you folks have done some pipeline cleanup work but as an end-user, plus stuff like mesh shaders are supported in other gfxdrivers such as vulkan and metal but I don’t think this “out of preview” news covers the cases it should have after months and months of waiting.

The DirectX12 backend is out-of-preview due to a significant mass of performance and stability improvements, and can now be targeted reliably for both editors and runtime players. One of the main advantages of targeting DX12 is the support of native graphics jobs which can reduce CPU bottlenecks and in many cases improve performance compared to DX11.

We will continue to improve performance moving forward, and eventually promote DX12 as the default graphics API for Windows platforms.

High level features like Mesh Shaders or VRS would need to be supported in a cross platform fashion as @tvriolai mentioned above. If these features are important to you, we would appreciate taking a minute to upvote these features in our public roadmap:

• Variable Rate Shading Support
• Mesh Shaders Support

@Henrarz , same thing! would help if you could upvote these:

• Vulkan Raytracing Support
• Metal Raytracing Support

[sarbiewski]

@dnach

High level features like Mesh Shaders or VRS would need to be supported in a cross platform fashion as @tvriolai mentioned above. If these features are important to you, we would appreciate taking a minute to upvote these features in our public roadmap

This is how the Roadmap entry looked recently

[rz_0lento]

Wording on that card is quite unfortunate. I’m pretty sure what they meant was that they can support new APIs with DX12 and just list those things as examples. There’s no way they planned to have mesh shaders inplemented by the time DX12 got out of preview.

[Matjio]

@sarbiewski Indeed, this card was created a year and a half ago “Under consideration” to gather feedback on DirectX12. The result of our investigation was that performance and stability were the top issues, and number one usage was raytracing / path tracing, while APIs like variable rate shading, mesh shading seemed less of a blocker for going out of experimental.
We have only updated recently the description of the card when we moved it to “Released”.
Apologies for the confusion.