Load FXC dynamically to remove the dependency on d3dcompiler_47.dll
#7588
Conversation
Yeah the lifetime is there to make sure the library isn't unloaded while the function pointer is hanging around. It's perfectly sound to pull a pointer and continue using it for the life of the module. if something needs to move the instructions around, it would expose a trampoline function with a stable address. |
… repeated usage. Fixed clippy warnings. Fixed merge conflicts.
| unsafe { | ||
| let lib = crate::dx12::DynLib::new(Self::PATH) | ||
| .map_err(|e| GetContainerError::FailedToLoad(FxcLib::PATH, e))?; | ||
| let d3dcompile_fn: D3DCompileFn = *lib.get::<D3DCompileFn>(c"D3DCompile".to_bytes())?; |
There was a problem hiding this comment.
Can this use pD3DCompile instead of needing to ahve the definition ourselves?
There was a problem hiding this comment.
pD3DCompile is an Option<fn> but we are using the fn directly, not sure if there is a way to use it.
Connections
Implements #7531.
Description
Currently, wgpu statically links
d3dcompiler_47.dll, even though it is only required for FXC, which is probably very rarely used. This increases the size of the executable and reduces compatibility, even if only slightly.This PR loads
d3dcompiler_47.dlldynamically, removing the dependence on it.To achieve this, we change
dxc_containerto a genericcompiler_containerwhich is an enum that holds the relevant data for each compiler variant: Fxc, DynamicDxc, and StaticDxc. Only the DX12 shader compiler variant specified by the user is loaded.Previously, the
shader_compilationmodule exposed multiple functions to create a container and compile shaders.Now, everything has been unified under the new
CompilerContainerenum which exposesnew_*functions to create the appropriate compiler container, and acompilefunction which will call the appropriate implementation for each of the different compilers.There is one thing I am unsure about and would like to get your feedback on: In this PR, every call to
D3DCompilereloads the function from the dll usinglibloadingdue to the lifetime imposed bylibloading. I chose this route because it is safe, but it is clearly not very performant. A better option would be to obtain a pointer to the function, and reuse that pointer every time. The thing that stopped me from going down that route is that I don't know if the library is pinned in memory once it is loaded. If it is, we can simply keep a pointer to the function in the same struct that holds the library; If the library is not pinned in memory, it would be incorrect to store the pointer.Testing
Tested using
cargo testand running my wgpu/bevy based application, both work as expected.Additionally, using windows'
dumpbin /dependents <executable>no longer showsd3dcompiler_47.dllas a dependent.Squash or Rebase?
Squash
Checklist
cargo fmt.cargo test.cargo xtask testto run tests.CHANGELOG.mdentry.