Search Issue Tracker
Won't Fix
Votes
21
Found in
2022.3.18f1
2023.2.7f1
2023.3.0b4
Issue ID
UUM-62702
Regression
No
Editor crashes on "GfxDeviceD3D12Base::DrawBuffersCommon" when selecting a specific shader with Rendering Path set to "Forward+"
Reproduction steps:
1. Open the attached "ReproProj" project
2. In the Project window, click on the "Assets/MI_Light_01" material
3. In the Shader dropdown, search for "MI_Light_01" and select it
4. If it doesn't crash instantly, wait for a few seconds
5. Observe the crash
Expected results: Unity Editor does not crash
Actual results: Unity Editor crashes
Reproducible with: 2022.3.18f1, 2023.2.7f1, 2023.3.0b4
Could not test with: 2021.3.34f1 (No Forward+)
Reproducible on: Windows 11 Pro
Not reproducible on: No other environments tested
Notes:
1. Reproducible with other shaders in the project, such as "MI_DecalsGeo_01"
2. Not reproducible when Rendering Path is set to “Forward“ or “Deferred“
3. Reproducible with DirectX11 and DirectX12
4. When using DirectX11 A pop-up appears when the crash occurs with the following information:
”Failed to present D3D11 swapchain due to device reset/removed. This error can happen if you draw or dispatch very expensive workloads to the GPU, which can cause
Windows to detect a GPU Timeout and reset the device. (see [https://docs.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery).|https://docs.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery).] If you believe this error is due to built-in Unity functionality, please submit a bug. This is an unrecoverable error and the editor will shut down.”
5. When using DirectX12 the Editor crashes with the following stack trace:
0x00007FF9AB48A02C (Unity) GfxDeviceD3D12Base::DrawBuffersCommon
0x00007FF9AB489B56 (Unity) GfxDeviceD3D12Base::DrawBufferRanges
0x00007FF9AB489E19 (Unity) GfxDeviceD3D12Base::DrawBuffers
0x00007FF9ACC7F8F4 (Unity) GfxDeviceWorker::RunCommand
0x00007FF9ACC82CFF (Unity) GfxDeviceWorker::RunExt
-
relativegames
Feb 10, 2024 22:56
Actually, the fix was to just add the Forward+ macro to all the shaders
#pragma multi_compile _ _FORWARD_PLUS
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note:
Hey Luis,
I figured I'd post a longer reply to explain a bit.
I managed to get a repro on your project, and I looked into it quite a bit. It's a GPU crash caused due to your custom code.
Your shader in question includes a file called `MI_Light_01.hlsl`. This file further includes stuff that looks like Unreal Engine code. As far as I can see, you're calling into that file as an intermediary between Unity's vertex shader and the surface description that gets passed into our fragment shader.
I deleted passes unrelated to Forward+ to narrow things down, and the crash kept happening. This solidified my hypothesis that the crash was due to interactions between your custom code and Forward+.
Then I removed your custom hlsl file and replaced the 2-3 lines where it was used, with basic values to populate the SurfaceDescription. The crash was fixed.
This means that your custom code is filling in our SurfaceDescription in a way that's causing Forward+ to crash, most likely due an infinite loop on the GPU. This means that you're passing in an invalid surface description. The crash doesn't happen in earlier versions because Forward+ doesn't exist in them. Forward+ uses light clustering, which relies on the surface description being robust and valid. Forward and deferred might be more immune to these issues because the light list logic is simpler in them. Customizing materials with an Unreal-esque wedge isn't a use-case we officially support. We have shader graph for this kind of use case.
This is why I'm closing this bug again. I think you'd have to look at the surface description values that your code is filling in.
Also, I'd be happy to look at the bug again if you manage to reproduce this bug with shader graph.