-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix D3D12Core.dll loading problem for debug build #5315
Fix D3D12Core.dll loading problem for debug build #5315
Conversation
With this PR, the "Windows/Debug" test in CI shows the following,
Note that D3D12 is supported for Debug build. Without this PR, the previous output shows that D3D12 was not supported for Debug build
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but can the test be disabled instead of commenting out the assert?
The assert seems to be just because of some file extension specific logic, and should otherwise hold.
D3D12Core.dll had been copied to a wrong directory and slang has been using D3D12Core.dll from the system directory, C:\windows\system32. D3D12Core.dll has to be copied from external/slang-binaries/bin/windows-x64 to build/Release/bin/D3D12 not to build/Release/bin. The same is true for the debug build and it had to be copied to build/Debug/bin/D3D12 not build/Debug/bin. It hasn't been a problem for Release build, because the debug-layer is not enabled for Release build and it didn't cause the version mismatching problem with D3D12SDKLayers.dll. The Release build was loaded from either build/Release/bin or from C:\windows\system32, and it didn't matter which one was used. The Debug build, however, got into a problem where D3D12Core.dll was loaded from the system directory whereas D3D12SDKLayers.dll was loaded from build/Debug/bin and it failed to load D3D12.dll entirely. This caused D3D12 to be "Not supported" for "Windows/Debug" configuration. Note that our CI explicitly excludes DX12 tests for the "Windows/Debug" configuration with a command-line argument "-api all-dx12", and DX12 tests were going to be ignored anyway. The actual problem was observed when WGPU is implemented. WGPU started printing explicit errors for the load failure of D3D12.dll. See more detailed explanation: https://devblogs.microsoft.com/directx/gettingstarted-dx12agility/#d3d12sdkpath-should-not-be-the-same-directory-as-the-application-exe Closes shader-slang#5305
a727245
to
4bc48ef
Compare
There will be another PR that addresses this problem properly.
D3D12Core.dll had been copied to a wrong directory and slang has been using D3D12Core.dll from the system directory, C:\windows\system32.
D3D12Core.dll has to be copied from
external/slang-binaries/bin/windows-x64
tobuild/Release/bin/D3D12
not tobuild/Release/bin
.The same is true for the debug build and it had to be copied to
build/Debug/bin/D3D12
notbuild/Debug/bin
.It hasn't been a problem for Release build, because the debug-layer is not enabled for Release build and it didn't cause the version mismatching problem with D3D12SDKLayers.dll. The Release build was loaded from either
build/Release/bin
or fromC:\windows\system32
, and it didn't matter which one was used.The Debug build, however, got into a problem where D3D12Core.dll was loaded from the system directory whereas D3D12SDKLayers.dll was loaded from
build/Debug/bin
and it failed to load D3D12.dll entirely. This caused D3D12 to be "Not supported" for "Windows/Debug" configuration. Note that our CI explicitly excludes DX12 tests for the "Windows/Debug" configuration with a command-line argument "-api all-dx12", and DX12 tests were going to be ignored anyway.The actual problem was observed when WGPU is implemented. WGPU started printing explicit errors for the load failure of D3D12.dll.
See more detailed explanation:
https://devblogs.microsoft.com/directx/gettingstarted-dx12agility/#d3d12sdkpath-should-not-be-the-same-directory-as-the-application-exe
Closes #5305
Closes #5276