Why is DX12 so much slower than DX11?

For my project, DX12 seems to be much much slower than DX11. Any clue as to what would cause this?

DX12:


DX11:

 

Bump. It extremely slow for me aswell, in many scenarios. Even if raytracing mark is turned off it's pretty much 30% slower than DX11 out of the box. On more complicated scenes with a lot of object performance is even worse, it can be even to 70% slower than DX11 or Vulcan.

 

^ this is still the case in 2019.4, its kind of crazy how much slower it is. I thought one of the big perks of DX12/Vulkan were jobified render queue, but even with my ryzen 9 it just seems slower on DX12.

 

I think Unity 2020.2 has some D3D12 performance improvements - I'm curious what sort of difference it would have in your tests.

 

@slime73 I'll check it out. But I doubt there will be significant improvement. I'm testing DX12 since Raytracing introduction in HDRP and nothing has changed yet, but I'll look into 2020.2a

 

yes

 

What is graphics jobs? I read the page on it: https://docs.unity3d.com/ScriptReference/PlayerSettings-graphicsJobs.html

Has so little information.... aren't GPUs already massively parallel why do we need to enable it for it to do ?

 

The CPU must schedule work for the GPU to do. Traditionally, your game engine will have one thread called the "render thread," which handles scheduling work for the GPU to do (which the GPU will then do in parallel). Recently, game engines have had multiple "render threads" which will all try to schedule work for the GPU to do at the same time, this is only possible because the graphics APIs (dx12/vulkan/etc) have recently made their APIs thread-safe. Unity's Graphics Jobs, from the sound of the name, are probably using their Job System internally to schedule things from the CPU to the GPU in parallel. In theory, this should lift a huge bottleneck for a lot of Unity games, since pure draw calls is often the biggest issue with rendering in Unity.

 

Yes, same with my project.
https://forum.unity.com/threads/unity-2019-3-performance-overview.735185/page-2#post-5616073

 

Will this mean the game is restricted to DX 12 users and latest Vulkan ?

 

what??

 

Well you said it uses the graphics api dx12 / vulkan that they made thread safe....

So i am asking if i use graphics jobs, would it mean my game is only compatible with dx12/vulkan compatible hardware.... aka would phones/tablets be unable to use it?

 

Ah okay thanks. Is there any reason its off by default instead of on by default if it auto disables anyway?

 

Are there plans atm to improve DX12 performance? Is this on the radar? Or is focus more on Vulkan? I've personally feel like I've been waiting for years for some of the better features from DX12/Vulkan to make it into Unity (instant compute shader data readback, graphics jobs really replacing the render thread, stuff like that)

 

Hi! We tried to upgrade our project to HDRP recently to check out the DXR posibilities. There's a huge performance hit, first after going for DX12 API and second after turning Realtime Raytracing (Preview) check on (Even without any RT effect on the screen).

I made some benchmarks to check the results. Visualization scenes are heavy, we are always trying to hit 30fps on new turing cards in Build so there's a lot of draw calls, it scales pretty well in DX11. DX12 from the other hand doesn't, lack of performance hits interior scenes aswell. We are running on 2020.2.0a15 HDRP 8.1 but it doesn't metter because we had the same problems in previous versions with previous HDRP.

I made benchmarks for our static scene, no animations, numbers are frames per second. FPS is stable so it's pretty much avarage. There are only Lit and LayeredLit shaders in the scene. HEAVY stands for performance heavy scene, a lot of buildings with tons of foliage.



Large version with all the profilers:



As you can see the difference is pretty massive. Vulcan from the other hand works very well, but there's no raytracing currently so that's not suitable for us. I tried with graphics job turned on and off but it doesn't seem to make a difference.

I also have my own interior project with the same performance issues. Any ideas?

 

Is there is simple API call to check current jobs state from C# ?

 

So any ideas? It seems for me like every draw call hurts DX12 couple times more than DX11, it's easy to test raytracing on pretty empty scenes but when it comes to actual production or something more ambition it's unfortunately useless for us.

 

DX12 support was released sometime in the 5.x cycle I think, ~ four+ years ago (!), but it is still considered "Experimental" and has clearly not reached performance parity with DX11 yet. Not to be an overly cynical developer, but it is hard not to feel a bit dubious this will ever occur and disappointed it hasn't already happened.

 

We've sent a few in-development snapshots of our git repo to Unity a few times for bug fixing, is there somewhere we could forward a new snapshot in the hopes of improving DX12/Vulkan performance, realistically? @DirtyHippy is spot on, we've been waiting so long for it to not longer be experimental that it simply feels like it never won't be experimental. Anything we could do on our end to reach better performance in Unity, we would happily do.

 

Unity did overhaul their render pipelines and introduced their job system which likely took a huge priority over optimising for the 5% of developers that needed the push unity to its real limits, and for the most part those 2 features took them years to do - but i suspect 2020/2021 we will see far more rapid development in optimisations now that those 2 features are pretty much in production ready states.

 

I guess this thread confirms not to bother with DX12 for any actualy development work. I appreciate the Unity staffer being honest but its sad to see another example of Unity 'tick the box' development.

If there is no plan to optimise for DX12 then why leave it in the engine? Its completely vestigial at this point.

 

If you want performance look to Unreal. Unity is not built with performance in mind given it uses C# for a start.

 

That's what IL2CPP is for. C# code getting converted to C++. You've also got the C# Job system and Burst compiler. Unity is busy with developing the Data Oriented Tech Stack (DOTS) for even more performance gains. Which is being advertised as "Performance by Default". But DOTS still has a long way to go sadly.

As for the comparison, both engines have their ups and downs. Personally I like C# over C++.

 

IL2CPP doesn't really compare to writing it in pure C++ lots of limitations invovled.

I've already addressed the fact unity is dealing with DOTS and other more important features two posts up etc.

My point was - few people make games on unity that crank the hardware to 11. It might be like 5% of games if not less than that which requires pushing performance to its limits.
So unity is trying to cater to the 95% first... thus optimising things where 95% don't need it will never take priority for them because people want features implemented over optimisations.

It never has been a huge priority through out unity's development cycles - optimisation is done last and some times not at all. That was my point.

It took them literally years to improve the profiler and its still not performant now, and the garbage collection could do with improvements - i believe thats planned but i doubt its a priority. Their vectors and math libraries didn't take advantage of performance gains like numeric vectors do either. I believe they have only just now added a better one called unity mathematics but i don't know if that can be SIMD or not.

So if you do need to push the limits you might be better off with unreal which taps into raw performance from the start.

 

DX12 is needed for Raytracing, and Unity likes ticking their boxes. Can you actually ship an Unity game that uses ray tracing? That's another matter entirely.

The code IL2CPP produces is, overall, not very efficient. It adds a lot of boilerplate because it needs the converted C++ code to behave as the original C# code would, which limit how much the C++ compilers can optimize it. Don't get me wrong, as a "modern" language, C# is indeed more pleasant to work with than C++, but it was never designed for pushing hardware.

Burst, now that I consider the biggest (arguably only) real great advancement in Unity in the past 5 years.

 

How is progress on this? Is DX12 starting to become usable? Did anything change in the last 8 months?

 

That's good to hear, specially because Xbox Series X|S is DX12 only.

 

Who should we contact for this?

 

Aside from it being better or not, do you actually have to do any specific coding to make Vulkan or DX12 work or is it a behind the scenes thing?

 

i have an HDRP scene and it goes from 130fps in DX11 to around 80-90 in DX12. i don't see what i'm supposed to be able to do differently in order to get around this, and DX12 is starting to become quite important. not only does performance collapse, but the profiling tool ceases to provide useful frame info too.

i'm totally happy to wait for things to pick up but when are we supposed to start seeing these improvements? so far 2021.1 isn't really progressed for me.

 

> DirectX12 is... still Experimental

They're kidding, right? DirectX12 is 6 years old - it's not exactly bleeding edge technology. Has there been any update from Unity on this since their last comment on this thread in January?

I have to admit I'm starting to get quite dismayed by the amount of posts I'm seeing like this that seem to suggest Unity have lost their way in terms of priorities. I used Unity some years back and thought it was phenomenal. I thought I would come back now to find the same experience, except with a bunch of shiny new bells and whistles, but it seems my expectations were too high.

I'd love to hear from Unity to tell me how they've nailed DirectX12 performance and to expect wonderful things in the next release. Please?

 

We have a similar experience in our project. 114FPS with D3D11 and 72FPS with D3D12 API. There are other low level APIs like D3D12 on XBOX handled well by Unity already. Why is the PC one such a special case? I think it's just embarrassing that such a large and successful company like Unity can't allocate enough developer time to finish basic technical debt. Especially when UE5 is really pushing. I remember Unity trying to convince my previous employer to use the engine for an AAA project years ago, instead of CryEngine we were using. Performance of large projects was our main concern and the reason we didn't do that.

 

You have misunderstood his answer.

DirectX12 is an experimental Graphics API in Unity.

 

I don't think it was misunderstood, the point seemed quite clear. DirectX 12 is over 6 years old, its about time unity support for it was not 'experimental'.

 

It doesn't matter that it's about time or not. The stated fact was that DX12 in Unity is experimental. They never said they are not working on it, on the contrary. The reply was a misunderstanding on what was considered experimental.

 

So what you're saying is, they've been obsessively working on dx12 for 6 years straight, it is their number 1 priority, and then 6 years later...

It's still experimental.

c o o l

 

One question, internally, does unity use something like d12on11 driver sort of thing which states managed by the driver instead of unity's graphics backend?

 

Wow the level of toxicity here is quite impressive.
Don't put words in my mouth. I never said that.

 

The fact is Unity doesn't put a lot of resources behind some things, and some things sit in experimental or preview an absurd length of time.

I think Acid is more making a comment about Unity (which is where his ire is directed going by the last couple of years of posts).

 

Really good clarification, thanks!