Does this mean that even in Proton, vkd3d and vkd3d-proton coexist, and it’s not possible to completely replace vkd3d?
Yes, upstream vkd3d is still used for the HLSL compiler, which vkd3d-proton doesn't implement at all (it's also not part of d3d12 and most games don't ship HLSL, but rather DXBC/DXIL bytecode). There is no need or reason to complete remove upstream vkd3d. If you don't want to use upstream vkd3d's HLSL compiler, you can just install d3dcompiler_47 to the wine prefix with winetricks and use microsoft's implementation.
Does this mean that even in Proton, vkd3d and vkd3d-proton coexist, and it’s not possible to completely replace vkd3d?
Yes, upstream vkd3d is still used for the HLSL compiler, which vkd3d-proton doesn't implement at all (it's also not part of d3d12 and most games don't ship HLSL, but rather DXBC/DXIL bytecode). There is no need or reason to complete remove upstream vkd3d. If you don't want to use upstream vkd3d's HLSL compiler, you can just install
d3dcompiler_47to the wine prefix with winetricks and use microsoft's implementation.
Thank you, that’s exactly what I wanted.
I tried replacing Wine’s built-in DLLs with the d3d12.dll compiled from vkd3d-proton and the dxgi.dll compiled from dxvk.
However, I noticed that Wine’s built-in D3DCompile2 still calls vkd3d_shader_compiler(https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/d3dcompiler_43/compiler.c?ref_type=heads#L573), which belongs to vkd3d, not vkd3d-proton.
Does this mean that even in Proton, vkd3d and vkd3d-proton coexist, and it’s not possible to completely replace vkd3d?
So if there’s a bug in it, I would still need to fix the issue in vkd3d rather than being able to replace it with functions from vkd3d-proton. Is that correct?