In all our tests with DX12 we reach a point where we get weird and inconsistent performance behavior, next to several other bugs. On some machines performance is fluctuating with ±60FPS, so pretty severe.
Is there ongoing work on DX12?
6 Likes
I am also interested in the answer to this question. i.e. to what extent does Unity recognize that DX12 behavior is a work-in-progress? What efforts are underway?
1 Like
I have the same question. While I can find scenarios where DX12 is faster than DX11, I can also find plenty of posts in the community where DX12 performs way worse than DX11. For example, this recent one:
https://x.com/unitycoder_com/status/1900978640860704783
This makes me seriously doubt whether there are still developers in Unity’s graphics department who truly understand DX12 —a standard that was released 10 years ago.
If not, shouldn’t Unity prioritize R&D budget allocation for this area?
PS: Considering that the graphics team doesn’t seem particularly interested in integrating DLSS either, I really wonder how many state-of-the-art developers are even left in this department.
3 Likes
*oh wait that was my link : D
yup, simple heavy test scene:
DX12: ~222fps
DX11: ~327fps
** I do want to test the build, if its better there..
and even empty editor is sluggish when DX12 is enabled..
Is this with split graphics jobs etc enabled?
Not sure what you are referring to, but in my experience DX12 is always slower than DX11, no matter the settings (split graphic jobs is default). I basically tried all of them. The bigger pain is that it’s also very inconsistent across machines, and sometimes on the same machine; I did a build of a scene which runs like 50 FPS constant in DX11, but on same machine it’s fluctuating between 4FPS and 40 FPS in DX12. And by fluctuating I mean that it’s then constantly running at 4FPS!
And then there are the crashes; working in DX12 crashes Editor every 20 minutes, while there might be one crash per day on DX11 (on same production project). I heard from other users that it’s same in builds, but I never tried to run a build longer than 10 minutes so far.
I guess everyone who did serious work in DX12 can agree that there is a good bit of work left to do to make it usable. It was not correct to declare it as production ready. There used to be a taskforce at Unity for this to happen, it seems the taskforce got resolved too early ( I think they even mentioned back then that there is still work to do on the GPU / compute side of DX12).
Edit: I am referring to HDRP here in all posts, never tried URP with DX12.
3 Likes
Interesting, lots of variation in results after testing again.
Winners are DX11 and DX12+Legacy jobs (roughly +400fps in editor, dx12 maybe even faster now!)
In builds, similar results, dx11 moves between 260-420, dx12+legacy 350-420fps bit more stable..
Split jobs was slightly slower this time.
and using BIRP.
test scene had many teapots with meshlods:
1 Like
I saw that. But it’s not really clear from the presentation if there are further improvements coming, as the presentation somehow partly puts features on 6.1 which are already available in 6.0.
Release notes of 6.1 also don’t show any DX12 improvements.
1 Like
DX11 in U6 still holds up better than DX12 in avg by 20% in my HDRP gpu-bound heavy scenarios. That said, DX12 gameplay with lower frames somehow feels snappier, having like less input delay or better 1% framerates. Can anybody confirm that?
Gonna wonder if any of those “Office hour” questions will be answered by Unity staff? I thought this was the purpose of that week. I saw many unanswered ones, including this one here.
Hi all, thanks for the question and sorry it’s taken so long to come back to you with anything.
This is indeed still an area we want to improve. Right now, we are still somewhat limited by the design of our Graphics API code, which has evolved right through from the D3D9 era to D3D11 and now D3D12. As a result, there are some historical things preventing us from making the most of the more modern APIs.
However, we are working on improving that situation and will have more to share on that in the future!
6 Likes
Thanks for getting back, and good to know that Unity is aware of the issues…
It did not sound like it from blog posts I saw about DX12, mentioning that performance is on par now with DX11, which seems to be incorrect for most use cases.
I see stability as the bigger issue, though, are there short term plans to improve on this?
Yes, the team has made a huge effort on bugfixing DX12, because having it work robustly is more of a priority than the performance. But we do need both.
1 Like
Hi again, one of my colleagues who works in this team has kindly offered to write up a far more detailed response about the plans and work happening in this area. Here it is!
For the impatient:
The current state of DX12 in Unity is:
- CPU performance. DX12 combined with split jobs should be the fastest option in most real-world use cases. This is based on our internal testing as well as profiling several customer projects. In general, any scenario with complex scenes benefits from going wide, which means split jobs shine.
- GPU performance. DX11 is just faster. The difference isn’t large, but measurable. This is mainly due to architectural reasons and to a lesser extent because GPU vendors have spent decades optimizing their DX11 drivers and having more control over their hardware at driver level.
- Stability. On the majority of hardware and use cases, we’re stable. There are edge cases and specific older hardware that still cause issues. These are being addressed.
In short. While it is possible to set up a scenario where DX12 performs poorly compared to DX11, in a majority of real world use cases, DX12 should be faster.
So we stand behind our recommendation to use DX12 and split jobs as default.
We would like to take a look at the test projects you’ve been using to get results that do not align with our assessment. So if you feel that’s something you can share, please do so.
Long form answer:
To answer the original question. Yes, feature parity between DX11 and DX12 is planned and to a majority of use cases, already there.
Let me elaborate a little. We’ve been discussing internally how to best respond to the points raised in this thread. It’s not an easy reply to craft, because the most accurate answers are rooted in complex realities and while we’d like to avoid finger-pointing, we do want to be transparent.
First and foremost, DX12 is a high priority for Unity, both from a strategic customer commitment perspective and from our own internal goals. We absolutely recognize its importance for modern rendering workflows and high-performance applications. We have a dedicated team for just DirectX and we’re increasing the size of that team permanently by quite a few talented engineers.
Regarding DX12 quality and performance today.
- Our current DX12 implementation should generally outperform DX11 on the CPU when using split jobs. The exceptions to this are relatively rare and workload-dependent.
- However, our DX12 implementation is slower than DX11 on the GPU side. This is a known limitation of the current architecture, one that isn’t realistically fixable within the current implementation. It is not a large difference, but given a very GPU bound situation, easily measurable.
- There are known bugs in the current implementation. That is a fact. They are being addressed, but progress is slower than we’d like due to the complexity and organic growth of this part of the code over the years. That said, stability on the majority of hardware should be solid. If that’s not your experience, we absolutely want to hear about it and address specific issues.
Looking ahead, future rendering improvements.
We’re actively working on significant architectural changes to our rendering systems, work that has been in progress for some time and is now starting to take shape. These changes will fundamentally improve how we approach performance, particularly on DX12.
Our goal is to close the GPU performance gap with DX11 and in certain scenarios, we’re optimistic that we might even surpass it. That said, DX11 drivers have been refined for decades by hardware vendors and have deep control over GPU execution, so matching that efficiency is a challenging task.
Beyond GPU-side improvements, these changes will also enable Scriptable Render Pipeline (SRP) code to adopt more modern rendering practices, allowing for better CPU performance through reduced binding overhead and more efficient resource management.
It’s worth noting that this is a long-term effort. The initial rollout will still operate within the existing rendering framework, but with smarter, more efficient systems underneath. Over time, as we continue to evolve the architecture, we expect these changes to unlock further performance gains and modern rendering workflows for Unity developers.
On some of the performance comparisons discussed here:
We’ve seen some test cases shared, such as pushing 0.6 billion triangles to the GPU and observing DX12 being slower. To put that in perspective, on a 4K screen, that’s roughly 72 triangles per pixel. There’s limited practical value in that scenario outside of stress-testing culling efficiency.
While we understand comparisons to “some” other engines are natural, it’s important to note that some of the technologies involved, like GPU-based occlusion culling or software rasterizers for extremely small triangles, are not yet part of Unity’s feature set. These comparisons are valid for certain types of technical analysis, but aren’t always reflective of realistic game development scenarios.
On why split jobs can sometimes be slower than legacy/native jobs:
Split jobs leverages multithreading to go wider on multiple levels but that inherently means doing more work. If the workload doesn’t naturally decompose well into smaller pieces (like rendering a single, massive mesh), then legacy/native can be faster. However, these situations are uncommon in real-world game scenarios.
In summary, we fully acknowledge the challenges and limitations of our current DX12 implementation. It’s an area of active investment, and we’re committed to delivering meaningful improvements both short-term and long-term. We genuinely appreciate the detailed feedback and the patience of our users, it helps guide our priorities and sharpen our focus.
Please keep the reports and constructive criticism coming, it does make a difference.
8 Likes
I’d like to share our project with Unity to demonstrate how much slower Unity DX12 is compared with DX11. But for now, I’m blocked by broken physics performance in Unity v6 (Unity 6000.x Physics Performance Degredation? - #12 by stonstad).
With physics disabled, I’m seeing a difference of 75 fps (DX11) vs 58 fps (DX12) for an identical scene.
3 Likes
I have many reports of similar bad DX12 performance by multiple users also and in my tests the DX11 is also faster, i suppose due to the GPU side of things as i am heavy on image effects.
Currently DX12 seems like a non option tbh and very far away from such.
Hi Richard. I’m happy to share a Steam key for my game. I’m seeing ~75 FPS in DX12 vs ~83 FPS in DX11 w/ this scene: https://stellarconquest.blob.core.windows.net/tmp/unity/DX_FPS.png.
Thanks,
Shaun
1 Like
Best to file a bug report within the project In Help → file a bug report
QA will test it and if they reproduce send it to Unity devs
I still have open issues I reported including test project, e.g.:
Not sure how much additional bug reports help on this, as it’s pretty obvious and easily reproducible.
I don’t think the statement of Unity about DX12 being faster in majority of use cases is true, actually I always hear the opposite from Users. As soon as a project is GPU bound, which probably will be most projects running DX12, DX11 ist faster, for the reasons Unity stated above.
What did increase is stability, but there is still no good reason besides RTX to switch to DX12.
4 Likes