Native translation to FXC binaries

gfx-rs / wgpu

A cross-platform, safe, pure-Rust graphics API.

https://wgpu.rs

Apache License 2.0

11.51k stars 858 forks source link

Native translation to FXC binaries #4300

Open kvark opened 6 years ago

kvark commented 6 years ago

The FXC is not publicly specified, but there is some information about its structure: http://timjones.io/blog/archive/2015/09/02/parsing-direct3d-shader-bytecode

It would be very nice to be able to generate it natively from SPIR-V. This would greatly improve the performance of (uncached) pipeline creation when working with API abstraction libraries that take SPIR-V input (https://github.com/gfx-rs/gfx/issues/1374). This in turn could give us an edge comparing to NXT and MoltenVK.

The downsides are:

difficult to debug
working without clear specification

jrmuizel commented 6 years ago

Wine and https://github.com/GPUOpen-Tools/common-src-ShaderUtils/tree/master/DX10 should give you enough information to fully understand DXBC

antiagainst commented 6 years ago

Contributions to add such functionalities into rspirv is definitely welcome! :-)

Just curious about DXBC vs. DXIL:

I'm more familiar with Vulkan/SPIR-V and its tooling than DirectX/DXBC. But I do have some experience with DXIL. (We are developing a SPIR-V codegen in DirectXShaderCompiler: https://github.com/Microsoft/DirectXShaderCompiler/issues/216.) AFAICT, DXIL is at a lower level than SPIR-V (DXIL has no requirement for structured control flows; DXIL scalarized all vectors; etc.) So translating from SPIR-V to DXIL should be feasible; although I would expect certain semantic differences will cause problems. I'm not quite clear about the level of abstraction of DXBC though.

Compared to translating SPIR-V to DXIL, I think the main advantage of converting to DXBC is that DXBC is widely accepted in drivers right now? Microsoft does have plan to shift to dxc and DXIL gradually from here.

Skepfyr commented 4 years ago

This seems out of scope for rspirv but in scope for javelin, it might make sense to raise this there.

kvark commented 4 years ago

Interestingly, this issue was filed before Javelin existed :) Moving now

kvark commented 3 years ago

@Kangz pointed out that DXBC binaries need to be signed, and there isn't really a good way today to avoid going through HLSL when targeting DX11. Let's find out if it's necessary.

magcius commented 2 years ago

FYI, DXBC is not signed, it is just checksummed, and the algorithm can be found here:

https://github.com/GPUOpen-Archive/common-src-ShaderUtils/blob/master/DX10/DXBCChecksum.cpp https://github.com/bkaradzic/bgfx/blob/a2ad0667397d82b921907870de45ca47d3e2526d/src/shader_dxbc.cpp#L726

cwfitzgerald commented 2 years ago

This is the same for dxil, just that dxil.dll also validates, not just checksum (iirc the algorithm is the same)