D3D12 renderer crash when it can't create buffer #93670
Comments
|
That's so interesting, running your command on my build works just fine, the project manager launches. .\windows_editor_x86_64_console.exe --rendering-driver d3d12 --debugThough as soon as I close the project manager it crashes Godot Engine v4.3.beta.custom_build.4d229ce00 (2024-06-19 12:50:19 UTC) - https://godotengine.org
D3D12 12_0 - Forward+ - Using Device #0: AMD - Radeon RX 580 Series
WARNING: PSO caching is not implemented yet in the Direct3D 12 driver.
at: pipeline_cache_create (drivers/d3d12/rendering_device_driver_d3d12.cpp:4947)
ERROR: 1 shaders of type HddagiFilterShaderRD were never freed
at: ~ShaderRD (servers/rendering/renderer_rd/shader_rd.cpp:845)
ERROR: Pages in use exist at exit in PagedAllocator: 25VersatileResourceTemplateIJN26RenderingDeviceDriverD3D1210BufferInfoENS0_11TeE
at: ~PagedAllocator (./core/templates/paged_allocator.h:170)
================================================================
CrashHandlerException: Program crashed with signal 11
Engine version: Godot Engine v4.3.beta.custom_build (4d229ce00019661706e147ac02e9e405be0ff0ea)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] error(-1): no debug info in PE/COFF executable
[2] error(-1): no debug info in PE/COFF executable
[3] error(-1): no debug info in PE/COFF executable
[4] error(-1): no debug info in PE/COFF executable
[5] error(-1): no debug info in PE/COFF executable
[6] error(-1): no debug info in PE/COFF executable
[7] error(-1): no debug info in PE/COFF executable
[8] error(-1): no debug info in PE/COFF executable
[9] error(-1): no debug info in PE/COFF executable
[10] error(-1): no debug info in PE/COFF executable
[11] error(-1): no debug info in PE/COFF executable
[12] error(-1): no debug info in PE/COFF executable
[13] error(-1): no debug info in PE/COFF executable
-- END OF BACKTRACE --
================================================================ |
|
I get this same error. I bisected and found the problematic pr and commit hash: PR: #91769 Edit: To clarify, I get @akien-mga's error |
|
CC @DarioSamo @TCROC @MBCX Can both of you provide a bit more information, namely:
|
|
Unable to reproduce. The relevant code is this. ComPtr<ID3D12Resource> buffer;
ComPtr<D3D12MA::Allocation> allocation;
HRESULT res;
if (barrier_capabilities.enhanced_barriers_supported) {
res = allocator->CreateResource3(
&allocation_desc,
&resource_desc,
D3D12_BARRIER_LAYOUT_UNDEFINED,
nullptr,
0,
nullptr,
allocation.GetAddressOf(),
IID_PPV_ARGS(buffer.GetAddressOf()));
} else {
res = allocator->CreateResource(
&allocation_desc,
reinterpret_cast<const D3D12_RESOURCE_DESC *>(&resource_desc),
D3D12_RESOURCE_STATE_COMMON,
nullptr,
allocation.GetAddressOf(),
IID_PPV_ARGS(buffer.GetAddressOf()));
}
ERR_FAIL_COND_V_MSG(!SUCCEEDED(res), BufferID(), "Can't create buffer of size: " + itos(p_size) + ", error " + vformat("0x%08ux", (uint64_t)res) + ".");So basically, it could be failing to create a resource altogether as it goes through CreateResource3 instead of the older API. This could very well be the result of the driver reporting enhanced barriers are supported but the actual function itself misbehaving (CreateResource3 will only work properly on a driver that supports them but is clearly not working as intended given the error code). If anyone with the error could break-point into the code and see what enhanced barriers supported returns, we can confirm pretty quickly that is the case. I had this very same problem with NVIDIA until they fixed the issue in a driver update, but if it's not reliable enough then we may want to opt to just disable enhanced barriers until the support is more stable. And also, please try compiling with the latest version of the Agility SDK to see if it behaves any differently (your project must also have the corresponding version that you compiled the engine with for this to work). |
Here is the system info: I'm building godot-nir-static from source on master branch here: https://github.com/godotengine/godot-nir-static Hopefully that answers your question on dxc_***.dll. If not, how do I find that? |
|
@TCROC For dxc_, see this instruction |
Yep that's how I'm building it from source. But how do I tell what version it is? All I know is I'm on the master branch- Oh I see! Lol I had it in my build script this whole time. Anywho: That is the dxc version. And this is the command I'm using to build godot-nir-static: Which is slightly different from a normal scons build command. I have a draft PR in to give more flexibility to the build command and allow specifying different compilers such as the zig one I am using. Will updating dxc potentially fix this? |
No, please refer to gathering the information I posted about on my comment if you can.
Finding out if The two pieces that are more relevant here are your driver being up to date and whether you're using the Agility SDK or not (and the Agility SDK version has to match the setting in the project as well). |
I just tested before heading up north for the weekend. On my AMD GPU and AMD CPU windows machine, enhanced_barriers_supported is false. Up north I have an NVIDIA Windows machine that I can test this against. Hopefully this helps tho! I won't be able to get any more info on my AMD machine until Tuesday. |
If that's really the case I'm not entirely sure why resource creation would fail when it's false. There's two other changes that were made to that creation path.
The change to initial_state was mostly to simplify the code paths a bit, but perhaps it's worth testing that in isolation to see if it fixes it. You can see the relevant changes around that code in the commit and attempt to restore them to see if it allows it to get past the buffer creation. It'd also help if you can just enable --gpu-validation and see if the D3D12 Debug Layer gives you anything helpful. It's not triggering in my case at all when I force enhanced barriers to false so it does seem like a driver-dependent issue. |
|
@clayjohn Here's the information you requested:
OS: GPU:
scons -j4 platform="windows" arch="x86_64" precision="single" use_mingw="yes" use_llvm="yes" \
module_text_server_fb_enabled="yes" \
steamapi="yes" \
d3d12="yes" \
agility_sdk_multi_arch="yes" \
use_pix="yes" \
dxc_path=$HOME/Documents/d3d12/dxc \
mesa_libs=$HOME/sources/godot-nir-static \
agility_sdk_path=$HOME/Documents/d3d12/agilitysdk \
pix_path=$HOME/Documents/d3d12/pix \
angle_libs=$HOME/sources/godot-angle-static/bin
|
|
Interesting to note that both @MBCX and I are using AMD Radeon GPUs. I will be very curious to see how the NVIDIA gpu performs tomorrow |
System InfoGPU InfoCompilation Info: Running godot on powershellRunning godot on vscode"args": [ "--rendering-driver", "d3d12", "--debug", "--verbose"]
Running godot on vscode with gpu validation"args": [ "--rendering-driver", "d3d12", "--gpu-validation"]
|
|
@DarioSamo
|
Yeah I think we can abandon that theory. When you ran it with the debugging layer you're getting an error way earlier than that during device creation.
|
Yes (as shown before in my build script) scons -j4 platform="windows" arch="x86_64" precision="single" use_mingw="yes" use_llvm="yes" \
module_text_server_fb_enabled="yes" \
steamapi="yes" \
d3d12="yes" \
agility_sdk_multi_arch="yes" \ # Here
use_pix="yes" \
dxc_path=$HOME/Documents/d3d12/dxc \
mesa_libs=$HOME/sources/godot-nir-static \
agility_sdk_path=$HOME/Documents/d3d12/agilitysdk \ # And Here
pix_path=$HOME/Documents/d3d12/pix \
angle_libs=$HOME/sources/godot-angle-static/bin
Never. The default value is
Yes and no.
Yes I removed them, and now neither (removed and not removed) are failing anymore (on a separate master, and on my custom fork). On a separate note, I have a custom fork of Godot here in which I merge some in-development features to test out (one of is HDDAGI, etc.) and recently, a draft of Mesh Shaders (and to my disappointment, it appears my GPU is not supported). The reason I mention this is because it was my custom fork that has/had that weird error before device creation, though I tested it again and is not failing 🤷. So, I guess that was a fluke? Not sure though... |
|
Though now I tried opening one of my projects (not with my custom build) and I force the driver to be d3d12, and now I get this when I exit ================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.beta.custom_build (04bf7d4cade645a5923cc80d87ac1c6109e2cdfe)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] Microsoft::WRL::ComPtr<ID3D12DeviceFactory>::InternalRelease (C:\Program Files (x86)\Windows Kits\10\include\10.0.2)
[1] Microsoft::WRL::ComPtr<ID3D12DeviceFactory>::~ComPtr<ID3D12DeviceFactory> (C:\Program Files (x86)\Windows Kits\10\i)
[2] RenderingContextDriverD3D12::~RenderingContextDriverD3D12 (E:\Repos\godot\drivers\d3d12\rendering_context_driver_d3)
[3] RenderingContextDriverD3D12::`scalar deleting destructor'
[4] memdelete<RenderingContextDriver> (E:\Repos\godot\core\os\memory.h:119)
[5] DisplayServerWindows::~DisplayServerWindows (E:\Repos\godot\platform\windows\display_server_windows.cpp:6029)
[6] DisplayServerWindows::`scalar deleting destructor'
[7] memdelete<DisplayServer> (E:\Repos\godot\core\os\memory.h:119)
[8] finalize_display (E:\Repos\godot\main\main.cpp:351)
[9] Main::cleanup (E:\Repos\godot\main\main.cpp:4321)
[10] widechar_main (E:\Repos\godot\platform\windows\godot_windows.cpp:186)
[11] _main (E:\Repos\godot\platform\windows\godot_windows.cpp:206)
[12] main (E:\Repos\godot\platform\windows\godot_windows.cpp:220)
[13] WinMain (E:\Repos\godot\platform\windows\godot_windows.cpp:234)
[14] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[15] <couldn't map PC to fn name>
-- END OF BACKTRACE --
================================================================ |
If the unmodified build works, wouldn't that imply something else changed in your setup? Perhaps the existence of the Agility SDK DLLs in the Godot path? |
|
If I remove the DLLs from my build and master I first, won't have access to the D3D12 driver and second Godot won't start because of pix (I compile with pix, and is absolutely required for the DLL to be there). |
|
I tested on my Windows 10 NVIDIA 1050-TI and can confirm this crash still occurs. I'll gather additional system info / stacktraces when I wake up :) Thanks to everyone helping out and looking into this! :) |
I was mistaken. The GPU is actually an NVIDIA 1070. Here's the system info and stacktrace: System InfoStack Trace |
|
Can confirm the PR fixes both AMD and NVIDIA issues on Windows 10 |
This is a bug report by @matheusmdx, I just branched it off from #93249 to a new ticket.
@matheusmdx wrote:
I followed the steps to reproduce the bug but in my case the crash happens after set the rendering device to d3d12 and restart the editor so i'm not sure if my crash is exactly the same cause, also if i start using --rendering-driver d3d12 imediatly crash the engine even if i don't try open any project. Here the errors + backtrace:
If my case is a different bug please inform me and i'll open a separated issue
Originally posted by @matheusmdx in #93249 (comment)
The text was updated successfully, but these errors were encountered: