godot
godot copied to clipboard
godotengine
Direct3D 12 Rendering Driver
Direct3D 12 Rendering Driver
This is a feature-complete Direct3D 12 RenderingDevice implementation for Godot Engine. It works as a drop-in replacement for the Vulkan one. It is selectable in the project settings as an alternative to use on Windows.
By supporting Direct3D 12, Godot gains support for multiple new platforms, such as:
- Windows Store (UWP).
- Windows on ARM.
- GDK.
- XBox —which can't be supported officially by Godot, but for which Direct3D 12 support is essential—.
This PR includes some preparatory changes, to uncouple the RenderingDevice from Vulkan, that is, abstracting the modern Godot rendering architecture from whatever rendering API is used. Moreover, instead of a monolithic commit, the code of the driver itself is split into three, much more manageable commits.
Highlights
Performance
Depending on the complexity of the scene, effects used, etc., this first version of the renderer performs generally worse than the Vulkan one. In some tests, D3D12 has not been able to deliver more than 75% of the Vulkan frames per second. In some other, D3D12 has been able to outperform Vulkan by a small margin. Performance improvements will be ironed out over time.
Homogeneity
The D3D12 rendering driver has been written taking the Vulkan one as a basis and keeping as much as possible from the original. This effort gives two-fold benefits: on the one hand, the overall structure of the code files, including auxiliary structures and other elements, is very similar, which makes maintenance easier; on the other hand, both renderers are more similar at the functional level. An example of this is that the D3D12 renderer will be as picky as the Vulkan one when it comes to validation and error checking, even in areas where the Microsft API wouldn't impose such strict constraints.
Specialization Constants
In Vulkan it is possible to create multiple variations of a pipeline with different values for certain parameters that end up as compile-time constants in the shader generated under the hood. Those parameters are called specialization constants.
In Direct3D there's no counterpart of that mechanism. However, Godot rendering relies on it for some of its shaders. A way to have specialization constants in the Direct3D/DXIL world had to be researched. It was finally found and is used in this code. The technique is explained in this Twitter thread: https://twitter.com/RandomPedroJ/status/1532725156623286272.
Code Comments
To avoid making this PR description unnecessarily long, the reader is advised to find additional insight in the comments.
Assertions
Given that some data crosses many stages from its inception to where it's finally used, the code is full of dev-only checks ensure the sanity of many different data structures at different points in time. The expectation is that this will make easier to catch bugs —even subtle ones— in areas of high complexity.
Known Issues
- Multiview rendering does not work. Only the left eye is rendered.
- SDFGI glitches on AMD GPUs. At least, it does on integrated AMD Radeon. Deep investigation led to the finding that it's a bug in some third-party element — e.g. the Radeon driver, Direct3D or the DirectX Shader compiler. The clue is that graphics debugging tools show the pipeline status as if some of the needed bindings hadn't been set. Moreover, the affected shaders work fine if compiled with optimizations disabled.
- No MinGW supported. So far only building with MSVC works, due to some vendor-specific stuff in third-party code.
Compilation & Distribution
- Grab the (main, not PDB) .zip file corresponding to the 1.7.2207 version of the DirectX Shader Compiler from https://github.com/Microsoft/DirectXShaderCompiler/releases.
- Unzip the file to some path.
- Optional (only for developers wanting to debug graphics with the PIX tool, only for debug builds):
- Locate the WinPixEventRuntime package (version 2206.20 is the latest tested), at https://devblogs.microsoft.com/pix/download/. You’ll be finally taken to a NuGet package page where you can click Download package to get it.
- Change the file extension to .zip.
- Unzip the file to some path.
- Build Godot with the following additional parameters to SCons:
d3d12=yes DXC_PATH=<...>plusPIX_PATH=<...>if you want PIX.
NOTE: The build process will copy dxcompiler.dll and dxil.dll from the bin/x64/ directory in the DXC zipfile to the Godot binary directory. D3D12-enabled Godot packages for distribution to end users must include those files, both for the editor and games.
Future Work
Besides fixing the known issues described in another section, there are many options for potential improvement, the most important of which are described below. The code also has a number of TODO items that refer to these and other, generally smaller, potential enhancements or nice-to-haves.
Render Pass API
The D3D12 renderer uses what in the Vulkan world is called dynamic rendering. In other words, it doesn't use render pass —and subpass— APIs. This was done to make things simpler, but came with a couple of downsides.
- First, a lot of code to do the proper setup of rendering passes is avoided, but some of the things the API would do by itself still require an amount of code —operations like clearing or discarding a framebuffer—.
- Second, this mentioned sort of emulation of builtin render subpasses won't perform as well on TBDR hardware because of the performance gains that input attachments provide can't be obtained from manual management of subpasses. This performance limitation only affects the mobile backend, though.
Actionable item: Re-work render pass management with the proper APIs, which may be needed to squeeze performance from certain kind of devices.
Enhanced Barriers
Direct3D 12 was released with a way to synchronize the GPU work consisting in resource barriers. In short, they are not nearly as fine-grained as Vulkan's memory and pipeline barriers are, the biggest consequence of this being comparatively worse performance. Microsoft has later powered Direct3D with the so-called enhanced barriers, which are the same that Vulkan has. Recent GPU drivers and Windows versions already support them.
Actionable item: Re-work synchronization based on enhanced barriers, which will give more performance and make the code more similar to the one in the Vulkan renderer.
More Reasonable Dependencies
Currently, this is using SPIRV-Cross for shader translation to HLSL and an important chunk of DXC for the specialization constants hack. When the Microsoft provided support for DXIL in Mesa is mature —when checked for the purpose of this work it wasn't yet—, we may be able to use it —via NIR— instead of that two other dependencies for those purposes. Microsoft is donating engineer time to Mesa for this effort, so we hope it will be in an usable state soon for us.
Actionable item: Watch the status of DXIL in Mesa and replace SPIRV-Cross and the DXC source code as soon as feasible.
Deprecate Texture Aliasing
In Vulkan it is possible to tell upfront which formats a texture will be interpreted as, and it'll just work. In Direct3D 12 there was traditionally no way to do the same. Therefore, there are limitations on which reinterpretations one can do.
Godot needs to do two of them that are illegal in D3D12: write as R32 and read as R9G9B9E5, and write as R16 and read as R4B4G4A4. The Direct3D 12 renderer code works around that limitation by abusing texture aliases, which, according to some tests across different GPUs, seems to work fine in practice.
The legal approach would be to make copies of the textures when the time to read comes. However, that won't still work for the R4B4G4A4 case. Therefore, the aliasing workaround is used for every case by now.
Luckily, Direct3D has recently added a new API CreateCommittedResource3() that provides the same nicety as Vulkan, but it's still not widely available and, at the time of this writing, the D3D12 Memory Allocator library still doesn't support it (there's a PR, though: https://github.com/GPUOpen-LibrariesAndSDKs/D3D12MemoryAllocator/pull/44).
Thanks go to Matías N. Goldberg, which was of great help in this investigation.
Actionable item: Add check support and prefer CreateCommittedResource3() to the aliasing hack where possible.
Further Homogeneity
Actionable item: Fuse as much as possible the elements that Vulkan and D3D12 have in common —staging buffer, static arrays of data format names, etc.—. This should reduce the codebase size and make it easier to maintain (and eventually add more platforms).
More
Just to make it complete, there are a few more potential improvements that may or may not be already in a TODO in the comments:
- Try to assign HLSL bindings manually and inform SPIRV-Cross in a deterministic way. That would make reflection, management of root signature and population of handle heaps simpler and more efficient. (Credit: @reduz.)
- More sensible use of the shared heap (i.e., track which resources/samplers are already bound and reuse somehow).
- Leverage promotion and decay of the state of buffers.
- While still using resource barriers, do split barriering where possible. (Maybe by taking the now neglected
p_post_barrierparameters as a hint somehow?) - A way to use the HLSL implementation of
fsr_upscale.hdirectly, given the appropriate defines. - Consider promoting some samplers (
material_samplers) to static samplers and/or descriptors to root descriptors when possible. - In case of
D3D12_FEATURE_DATA_ARCHITECTUREbeing UMA, useWriteToSubresource()instead ofmemcpy(). - Consider
D3D12_BUFFER_SRV_FLAG_RAWfor CBV, or another usage.
🍀 This work has been financed and kindly donated to the Godot Engine project by W4 Games. 🍀
Do you have a plan to try Godot using Hololens Emulator?
It would be interesting, but I have other priorities on my horizon.
Windows on ARM.
I guess it's time to get proper arch instead of bits (https://github.com/godotengine/godot/pull/55778) and add support for ARM Windows builds, with DX support it should be a valid option.
For the reference, using https://github.com/mstorsjo/llvm-mingw tool chain, it's possible to build current master for ARM Windows. With exception to a few modules (as usual raycast, denoise and theora using wrong assembler code, and mbedtls which is trying to use UNIX gettimeofday for some reason). But I do not have any ARM Windows setup to test it.
If someone has an HDR display (preferably OLED or miniLED) and Windows 11, it might be worth trying to enable Auto HDR on Godot while using the Direct3D 12 renderer. This could address https://github.com/godotengine/godot-proposals/issues/1004 on Windows until there is a native implementation :slightly_smiling_face:
Are additional SDKs required for compilation? (Windows 11, VS 2019)
Errors
D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2065: 'IDxcUtils': undeclared identifier D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2923: 'Microsoft::WRL::ComPtr': 'IDxcUtils' is not a valid template type argument for parameter 'T' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): note: see declaration of 'IDxcUtils' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2955: 'Microsoft::WRL::ComPtr': use of class template requires template argument list C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt\wrl/client.h(211): note: see declaration of 'Microsoft::WRL::ComPtr' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2065: 'IDxcUtils': undeclared identifier D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2923: 'Microsoft::WRL::ComPtr': 'IDxcUtils' is not a valid template type argument for parameter 'T' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): note: see declaration of 'IDxcUtils' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2955: 'Microsoft::WRL::ComPtr': use of class template requires template argument list C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt\wrl/client.h(211): note: see declaration of 'Microsoft::WRL::ComPtr' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2065: 'IDxcUtils': undeclared identifier D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2923: 'Microsoft::WRL::ComPtr': 'IDxcUtils' is not a valid template type argument for parameter 'T' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): note: see declaration of 'IDxcUtils' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2955: 'Microsoft::WRL::ComPtr': use of class template requires template argument list C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt\wrl/client.h(211): note: see declaration of 'Microsoft::WRL::ComPtr' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2065: 'IDxcUtils': undeclared identifier D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2923: 'Microsoft::WRL::ComPtr': 'IDxcUtils' is not a valid template type argument for parameter 'T' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): note: see declaration of 'IDxcUtils' D:\godot-dx12\drivers/d3d12/rendering_device_d3d12.h(96): error C2955: 'Microsoft::WRL::ComPtr': use of class template requires template argument list C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt\wrl/client.h(211): note: see declaration of 'Microsoft::WRL::ComPtr'
Actionable item: Watch the status of DXIL in Mesa and replace SPIRV-Cross and the DXC source code as soon as feasible.
Is there a particular feature set you need at which point you'd consider that translator mature?
Actionable item: Watch the status of DXIL in Mesa and replace SPIRV-Cross and the DXC source code as soon as feasible.
Is there a particular feature set you need at which point you'd consider that translator mature?
@jenatali, on the one hand, it's stability; last time I checked (months ago) I got the impression that the functions I needed were still changing a lot in the recent history of the repo. On the other hand, it's really about having enough features to replace one or both of SPIRV-Cross and DXC-LLVM's IR handling. The latter (IR parse/serialize) may never be a thing, I guess.
@RandomShaper Understood. If you do take a closer look, and find it lacking for whatever reason, please reach out and let me know what's missing or what you'd need to make it viable for this use case.
@DarkMessiah, my first impression is that the DXC_PATH is wrong and the compiler is getting an old version of dxcapi.h which doesn't declare IDxcUtils. Can you build with verbose=yes and paste the compiler command that generates errors?
@RandomShaper Understood. If you do take a closer look, and find it lacking for whatever reason, please reach out and let me know what's missing or what you'd need to make it viable for this use case.
@jenatali, thank you very much. I'll do as soon as possible.
For new ones joining this discussion to get other related perspectives. Dozen is Vulkan Over DirectX12. Available in Windows, WSL2 (Linux)
It is great to see @jenatali is here to offer his experience.
- Get Godot Engine to work in Hololens through OpenXR supported by Dozen
- hardware accelerated Vulkan: Dozen now works in WSL2 => However, Godot4 Vulkan does not run yet in Graphics hardware accelerated mode YET.
How Godot4 vulkan failed to run in Dozen
Wouldn't adding DX restrict the platforms that games using it can target?
- Windows Store (UWP).
I thought Godot already supported UWP? Or is there something I've missed?
@LikeLakers2
I thought Godot already supported UWP? Or is there something I've missed?
Godot3 supports UWP through Angle (OpenGL over DirectX).
Wouldn't adding DX restrict the platforms that games using it can target?
It's not a replacement for Vulkan but an alternative. If anything, it adds a choice where both are available and also allows to reach platforms not possible formerly.
This is a nice PR to see. Definitely feel like that Godot could definitely use a DXGI Interop of sorts in Vulkan/OpenGL on Windows for Flip Model presentation (as the current method doesn't work that well with VRR displays, has a ton of hurdles in regards to implementing HDR support that doesn't rely on NVIDIA APIs, and incurs a latency cost), and I've seen forks of Godot that implement ANGLE to kind of get around some of this, but a DX12 rendering option would essentially fix that, as you're forced into using it.
EDIT: Figured I'd add this in case anyone was wondering about the whole latency thing, If anyone is wondering why there's a hivemind opinion in certain online circles about about exclusive fullscreen mode being "superior" (When it really isn't considering the long alt-tabbing times, and screen refresh rates usually not being adjustable on the user side of things), is because of older implementations of borderless windowed modes having notable problems due to using blt composition (Although nowadays, there's still games that end up making this mistake).
@LikeLakers2
Based on this remark, I hope more people see WHY moving to Vulkan Over DirectX12 is REALY a fantastic decision!
This is a nice PR to see. Definitely feel like that Godot could definitely use a DXGI Interop of sorts in Vulkan/OpenGL on Windows for Flip Model presentation (as the current method doesn't work that well with VRR displays, has a ton of hurdles in regards to implementing HDR support that doesn't rely on NVIDIA APIs, and incurs a latency cost), and I've seen forks of Godot that implement ANGLE to kind of get around some of this, but a DX12 rendering option would essentially fix that, as you're forced into using it.
Also, we probably should enable it in the Windows CI build.
Good point. ~Enabled.~ ~UPDATE: Well, not so fast.~
UPDATE: Done, I think. Maybe @faless wants to take a look to the most recent commit where D3D12 is enabled in CI.
@jenatali, I've checked the status of SPIR-V to DXIL via NIR and it looks amazing at this point. It really looks as it will be possible to use so this PR can be much slimmer, by avoiding the need to use SPIRV-Cross, and the DXC (both the chunk of the source and the pre-built DLLs).
When I'm back from holidays, I'll work on that. Therefore, I'm marking this as Needs work since it's probably not a good idea to merge this PR as it is now when there's a high chance of making it much nicer.
There's one thing that would require us to make custom changes to the Mesa dependency: the specialization constants hack by which we are able to patch DXIL with new values without having to go back to HLSL. @jenatali, do you think is there some possibility to have something similar implemented in Mesa so there's no need to do the translation to DXIL every time we want new values for the specialization constants?
I'm thinking that maybe Godot could just cache the NIR version and start from it every time new SC values are wanted. However, that would be still slower than just patching a few offsets in the DXIL.
Currently, the SPIR-V parser in Mesa has all responsibility for handling specialization constants. They're translated into literals at that level and don't appear in the NIR at all. For OpenCL, when I added specialization constant support to OpenCLOn12, I decided this was probably fine.
I'd suggest evaluating the tradeoff in performance vs complexity for re-doing the translation from SPIR-V to DXIL when applying a specialization constant change, vs trying to patch the raw DXIL. I wouldn't be surprised to find that given the low overhead of this compilation path (relatively speaking, of course) that it ends up being comparable in performance and drastically simpler in complexity.
Before going all-in, I'd also just suggest you double-check if there's features that are required, e.g. subgroup/wave ops, that aren't hooked up yet. Not sure what features you were using in the SPIRV-Cross version of this, but we might need to add some more stuff before it's fully ready.
@jenatali, pretty good points. I'll assess. Regarding subgroup ops, we are using them if supported indeed. In any case, I think I'll start the integration work regardless some features may be even completely missing or incomplete at this point, since NIR is the future anyway for this renderer. When I finally deep dive into that work I'll have more solid arguments to determine if the current approach is worthy merging or not, depending on how much it will take to have a complete enough NIR-based version. So, in the future you may hear from me again with further questions. Thank you very much for the insight you've given so far.
This is not the place to discuss DX12 vs Vulkan. Please use forums, discord, discussions, proposals, irc, etc. or other suitable/appropriate platforms for that. Avoid comments that are not relevant to the PR/logic.
This is a PR to discuss, track and merge the implementation/code of DX12 backend in Godot. (better description is in OP comment). For any more clarifications, comments or replies on this, use discord and other community platforms.
Also, as stated quite a few times already by core devs, Vulkan and DX12 will both be available as options in Godot after this is merged. Godot is not moving from one backend to another nor are we dropping either one.
The root COPYRIGHT.txt has not been updated with the new dependencies. Even if the dependencies are possibly changing it's probably good to keep it in sync for now.
Suggested changes
@@ -83,11 +83,28 @@ Copyright: 2018, Eric Lasota
2018, Microsoft Corp.
License: Expat
+Files: ./thirdparty/d3d12ma/
+Comment: D3D12 Memory Allocator
+Copyright: 2019-2022 Advanced Micro Devices, Inc.
+License: Expat
+
+Files: ./thirdparty/directx_headers/
+Comment: DirectX Headers
+Copyright: Microsoft Corporation
+License: Expat
+
Files: ./thirdparty/doctest/
Comment: doctest
Copyright: 2016-2021, Viktor Kirilov
License: Expat
+Files: ./thirdparty/dxc/
+Comment: DirectX Shader Compiler
+Copyright: Microsoft Corporation
+ LLVM Team
+ 2003-2015 University of Illinois at Urbana-Champaign
+License: NCSA
+
Files: ./thirdparty/enet/
Comment: ENet
Copyright: 2002-2020, Lee Salzman
@@ -277,6 +294,11 @@ Comment: RVO2
Copyright: 2016, University of North Carolina at Chapel Hill
License: Apache-2.0
+Files: ./thirdparty/spirv-cross/
+Comment: SPIRV-Cross
+Copyright: 2015-2021, Arm Limited
+License: Apache-2.0 or Expat
+
Files: ./thirdparty/spirv-reflect/
Comment: SPIRV-Reflect
Copyright: 2017-2018, Google Inc.
@@ -1584,6 +1606,34 @@ License: MPL-2.0
This Source Code Form is "Incompatible With Secondary Licenses", as
defined by the Mozilla Public License, v. 2.0.
+License: NCSA
+ Permission is hereby granted, free of charge, to any person obtaining a copy of
+ this software and associated documentation files (the "Software"), to deal with
+ the Software without restriction, including without limitation the rights to
+ use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+ of the Software, and to permit persons to whom the Software is furnished to do
+ so, subject to the following conditions:
+ .
+ * Redistributions of source code must retain the above copyright notice,
+ this list of conditions and the following disclaimers.
+ .
+ * Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimers in the
+ documentation and/or other materials provided with the distribution.
+ .
+ * Neither the names of <Name of Development Group>, <Name of Institution>,
+ nor the names of its contributors may be used to endorse or promote
+ products derived from this Software without specific prior written
+ permission.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+ FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
+ SOFTWARE.
+
License: OFL-1.1
PREAMBLE
The goals of the Open Font License (OFL) are to stimulate worldwide
I'm not sure what it's like in the D3D12 world but supposedly on Vulkan not all devices support all contiguous MSAA sample counts. E.g. some support 4x but not 2x. If this also applies to D3D12 then the current implementation of _find_max_common_supported_sample_count() would need to be changed to instead generate a mask and then be iterated over similar to how Vulkan's _ensure_supported_sample_count() works.
I can't provide a full change suggestion here as it's fairly involved and my Godot fork has a different MSAA API. To summarize I changed _find_max_common_supported_sample_count() to be the following (which returns a mask similar to VkPhysicalDeviceLimits::framebufferColorSampleCounts) and modified the rest of the logic to match Vulkan.
RenderingDeviceD3D12::_find_supported_sample_count_mask()
uint32_t RenderingDeviceD3D12::_find_supported_sample_count_mask(const DXGI_FORMAT *p_formats, uint32_t p_num_formats) {
D3D12_FEATURE_DATA_MULTISAMPLE_QUALITY_LEVELS msql = {};
uint32_t common = UINT32_MAX;
for (uint32_t i = 0; i < p_num_formats; i++) {
if (supported_sample_count_cache.has(p_formats[i])) {
common &= supported_sample_count_cache[p_formats[i]];
} else {
msql.Format = p_formats[i];
uint32_t mask = 0;
for (TextureSamples sample_count = TextureSamples(TEXTURE_SAMPLES_MAX - 1); sample_count >= TEXTURE_SAMPLES_1; sample_count = TextureSamples(sample_count - 1)) {
msql.SampleCount = rasterization_sample_count[sample_count];
HRESULT res = device->CheckFeatureSupport(D3D12_FEATURE_MULTISAMPLE_QUALITY_LEVELS, &msql, sizeof(msql));
if (SUCCEEDED(res) && msql.NumQualityLevels) {
mask |= 1 << sample_count;
}
}
supported_sample_count_cache.insert(p_formats[i], mask);
common &= mask;
}
}
return common == UINT32_MAX ? 1 : common;
}
It's worth noting that Vulkan's mask is global to all formats but D3D12's mask will be specific to individual formats.
Hi, @RandomShaper thanks for your amazing job.
When we try to build your d3d12 branch with the above instructions, the build succeed, but when we start Godot with switching to d3d12, we got lots of errors, please help us to figure out what we should do to solve the problems, thanks!
Godot Engine v4.0.beta.custom_build.0988ab4a9 - https://godotengine.org
Using D3D12 Device #0: NVIDIA GeForce RTX 3090
ERROR: Shader signing at stage Fragment failed:
Validation failed.
at: RenderingDeviceD3D12::_shader_sign_dxil_bytecode (drivers\d3d12\rendering_device_d3d12.cpp:4300)
ERROR: Shader signing at stage Fragment failed:
Validation failed.
at: RenderingDeviceD3D12::_shader_sign_dxil_bytecode (drivers\d3d12\rendering_device_d3d12.cpp:4300)
ERROR: Shader signing at stage Fragment failed:
Validation failed.
at: RenderingDeviceD3D12::_shader_sign_dxil_bytecode (drivers\d3d12\rendering_device_d3d12.cpp:4300)
ERROR: Shader signing at stage Fragment failed:
Validation failed.
at: RenderingDeviceD3D12::_shader_sign_dxil_bytecode (drivers\d3d12\rendering_device_d3d12.cpp:4300)
ERROR: Shader signing at stage Fragment failed:
Validation failed.
at: RenderingDeviceD3D12::_shader_sign_dxil_bytecode (drivers\d3d12\rendering_device_d3d12.cpp:4300)
ERROR: Shader signing at stage Fragment failed:
Validation failed.
at: RenderingDeviceD3D12::_shader_sign_dxil_bytecode (drivers\d3d12\rendering_device_d3d12.cpp:4300)
ERROR: Shader signing at stage Fragment failed:
Validation failed.
Hi, @RandomShaper thanks for your amazing job. When we try to build your
d3d12branch with the above instructions, the build succeed, but when we start Godot with switching to d3d12, we got lots of errors, please help us to figure out what we should do to solve the problems, thanks!
This PR is not finished yet. It may be a bit premature to be testing it out.
From what I understand RandomShaper is halfway through migrating to a different shader compilation pipeline which is likely why you are getting shader compilation errors when you run the branch as-is. The best solution will be to wait until the PR is finished before testing it.
~I'm indeed overhauling the approach to shader compilation-patching in another branch. However, this one should already work. Reasons for it not to work at the moment may include the following:~
- ~Since it's still not been rebased on top of latest changes to Godot, it may be no longer compatible with editor data from the master branch. It'd be a good idea to run it from another directory in self-contained mode.~
- ~Bugs, of course.~
~In the specific situation @John-Gdi is at, I wonder what is causing the generated DXIL shaders to fail validation. Can you please run the editor with --verbose and attach a full log?~
UPDATE: I've been able to reproduce the problem. The reason was a user-after-free bug. Now fixed.