Official DX12 is out of experimental since 2022.2.0a17

@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?

 

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.

 

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

 

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

 

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

 

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

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

This is how the Roadmap entry looked recently

 

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.

 

My foliage/detail rendering system is based on RenderMeshIndirect and GPU culling. I'm using compute shader and Dispatch calls for multiple instancing chunks every frame for frustum culling, distance culling, LOD selection etc.

On my GPU it costs about 0.50ms (I mean dispatch calls, not the whole rendering) on average on DX11. Do you think that it can increase significantly on DX12 in 2022.2?

Thanks.

 

In my case I would like to have just HDRP support for iOS devices and ray tracing support in Metal in general (for macOS, but then again, M1 chips are in iPads already, so ray tracing support for iPads would be easy to implement).

 

Immortalis-G715 GPU seems like a good companion to metal going forward (for the droids etc). Seems like CPU would still be a big issue for phones though (HDRP etc).

 

Games use and yes, I believe so (for RT support in Vulkan/Metal for macOS).

HDRP support for mobile is not a priority, but then again - the chips used in Macs and iPads are slowly becoming the same and one platform is artificially limited now.

 

Somewhat unrelated, but are there any plans to have Shader Model 6.0 features (needs #pragma use_dxc currently) cross compile to both DX12 and Vulkan, or is it going to stay DX12 only? If there are plans, is it being actively worked on or is it low priority for now?

 

A bunch of them should be working (e.g. wave operations, barycentrics etc.) on both Vulkan and Metal. If some/any of them does not work, file a bug.

 

Nice work! Since the focus is DX12 and ray tracing, is there any plan to support inline raytracing and bindless resources?
It's hard to get proper performance and enough flexibility without those features.

 

I tested version 2022.2.0b4 with directx 12, it really is much faster than directx11. Will you bring these changes to the other LTS versions? or is this exclusive to 2022.2?

bug I found, I can't put an HDRP project to directx12, Unity gets stuck in a loop when restarting.

 

It can also be slower than DX11 depending on which asset store assets are used (compute shaders and the like).

 

Games targeting high end mobile apple devices like the M1 that are starting development today.
And when the game is finished in 4 years everyone has upgraded the phone to a faster model.
so the user base today is less relevant than the user base after dev time.

 

Is there any documentation out there of which DX12 features are supported/unsupported/planned? A few such features are in the roadmap (links are in this thread), which would seem to imply that all other features are supported, but I doubt that's the case.

I'm interested in unbounded arrays, descriptor heaps, register spaces, in particular.

 

So raytracing is allowed to be DX12 only but bindless resources are not?

 

Yeah I understand why you wouldn't want SRP experience (lol). Was just worried that features might get ignored at all because they "don't work everywhere"
Thanks for the answer for confirming that features are actually coming but just not right now

P.S. I do hope, however, that "eventually" doesn't mean "in 2 years"

 

It is good to see that DirectX 12 is getting some love. Obviously, Unity needs to cater to the lowest common denominator. Maybe in 3 or 4 years the HDRP will require DX12. The Steam survey already shows that the vast majority of PC gamers 91.4% are on DX12 systems. Not sure about Xbox but it must be high.

 

You can actually no longer make new Xbox games with DX11. Microsoft stopped accepting game submissions made using the old SDK (XDK) and the new SDK (GDK) is DX12-only.

 

Indeed, these are internal things, but that's precisely what I'm asking about - as a developer who wants to write their own ScriptableRenderPipeline, I want to use those features.

I'm not asking that Unity should just dump all the platform specific features into its public API or rush any new features. That would probably be a nightmare for all involved. I also realize that the leap from last gen graphics APIs to modern graphics APIs is huge.

My question is really about what sort of timeframe we would expect to see a public API in Unity which exposes some underlying graphics features in a platform independent way (which is pretty much exactly what you've described). If these features are on the radar at all or if they are already in progress. I see no mention of these things on the "official" Unity roadmap, which is why I'm asking about it.

Based on this thread it seems that Unity is thinking about these things but "eventually" sounds like 2-5 years.

 

Will the support for DirectX12 be backported to earlier versions? Or will they forever have experimental directx12 support?

 

Great to hear that dx12 is out of experimental, but I'm surprised with the rather conservative language being used as to performance gains. I thought the whole point of dx12 was a complete shift in approach to talking to the gpu that would offer substantial benefits over previous versions ( same with Vulkan too ). Granted that would not mean that every case was faster, but in terms of demanding games it would be a huge boost.

Saying that it 'handily' beats dx11 with large amounts of drawcalls feels a bit lacklustre, I would be expecting 'considerable' gains in performance. Perhaps its just a langue issue here, 'handily' vs 'considerable' are not helpful terminology as they have no consistent meaning. In that case I would have expected some actual performance numbers, direct comparisons using Unity's catalogue of samples/demos. However the lack of numbers is also worrying, it suggests to me at least that the performance benefit is really not very impressive or possibly even worth it.

Which leads me to wondering why?

Is it that dx12 really isn't that much faster? For quite a while I don't remember it making much of an impression outside of a handful of games. I still have the feeling that many games are running in dx11 and maybe some dx12 games are actually just D3D11on12.

Conversely maybe Unity simply does not have the architecture to take advantage of the benefits that dx12 offer?

Regardless my question is will Unity continue to improve the Dx12 renderer?
Do you expect to find more performance, but perhaps limited to using SRP?

Guess I'm just a bit disappointing having waited for so long to get such a meh release for dx12 support. I mean I wouldn't even have known it came out of experimental if I hadn't been browsing the forums as I was bored. I remember being so excited by its marketing of reduced driver overheads, but I guess after 7 years ( though several revisions ) its just no longer a exciting news event.

 

I think the whole industry realized that after all the initial fanfare of "new low level APIs will unlock so much more performance!" (dx12, vulkan, metal), the actual results ended up much smaller. The drive for way lower level APIs was done primarily by people (wishfully) thinking they can do a much better job than GPU driver developers. And some of them do, like maybe 10 people in the world For the "rest of us", well guess what -- turns out it's quite hard to beat something like 400 driver developers that say nvidia has (I picked the number out of thin air), who have spent the last two decades doing nothing but making the driver faster & better.

 

Hi every time i startup the editor in 20222.2.0b10 i get this message:

Code (CSharp):

1. d3d12: Profiler is enabled, but stable power state is not. GPU timing errors are expected.

I dont know what this is, or what i should do with it.

​

 

Does that mean 2022.2 is planned to have it as default? Or will that be 2023 or later. Is there some kind of roadmap for this? (lots of questions, I know!)

 

Sounds good, would be nice to get some more realistic benchmarks in the future.

Just to be clear, when I talk about the Dx12 support in Unity being a bit 'meh' or lacklustre I don't mean it directed purely at Unity, more that the marketing by Microsoft promised so much, yet it appears to be very difficult or very specific to obtain those sort of gains. I suspect this is even more true of a generalised engine like Unity, though its good to hear that work will continue on the dx12 support and hopefully provide further improvements in the future.

Was wondering about this myself, though more from the case that unless its changed to be the default ( i rarely use recent Unity versions so wasn't sure if it was or not yet ) I don't see developers choosing to use it.

While it might be out of experimental I suspect there is still a 'chicken/egg' situation where experienced developers will likely be more resistant to switching until they know that bugs/issues will be minimal, but of course the fewer people who switch the less feedback and bug discovery etc.

I'm trying to remember what happened with dx11 support. I do remember being very happy with dx9 support and initial dx11 support was a bit ropey, but nothing on the scale that dx12 seems to have had. What I can't remember is when I switched to defaulting to dx11 or if I switched before Unity made it a default. Was it even made the default or was it simply the defacto default after dx9 was removed?

I guess something to keep in mind is it may not be sensible to switch to dx12 unless using the version of Unity where it has been promoted out of experimental tag, as older versions are likely to more issues. So I guess i'll probably not switch until I start using 2023 as my default unity version, which is probably in about 3-4 years

 

Could you elaborate on this a bit, I was under the impression they ran in order?

eg. If i have a dispatch twice like the following:

Code (CSharp):

1.  
2. myShader.dispatch(0, 64 , 1, 1);
3. myShader.dispatch(1, 64 , 1, 1);
4.  

If both kernels shared a buffer, and kernel 1 had dependencies on kernel 0's output wouldn't this cause issues?

Or am I misunderstanding this reordering.

Thanks

 

It would not reorder this case. But across a bunch of dispatches, on "old" APIs (like DX11 / OpenGL), the driver can look at them, figure out which ones have dependencies on which other ones, and reorder (or issue in parallel) the ones that don't have dependencies. How much of that is done depends on the particular GPU and driver (and probably driver version); AFAIK NVIDIA on Windows traditionally has been extremely into these types of things (and any other optimizations they can legally get away with).