As discussed on Discord, this could be used to make writing tests less painful by allowing us to simply run the exe within a directory that contains HLSL shaders and spits out plain C headers. Draft for now to gauge whether this is going in the right direction.
Currently, this works as follows:
For DXIL, dxcompiler.dll must be in the search path (either next to the exe or in the wine prefix). As for headers, I added a new IDL with the necessary interfaces, but it does not cover the entire DXC API.
For DXBC, we require d3dcompiler_47.dll as the latest version. I haven't added a custom IDL for the d3dcompiler APIs since MinGW ships the necessary headers anyway, but I can add a minimal IDL here as well if we want to go that route.
Input directory defaults to CWD, can be changed via command line. This currently does not scan directories recursively.
Output directory defaults to headers within the source directory.
Input files must named something like frog.vs_6_0.vs_5_0.hlsl, with support for up to one DXIL target and up to one DXBC target (of course, specifying only one also works). The output file name would be frog.h, and names of the corresponding D3D12_SHADER_BYTECODE constants are frog_dxil and frog_dxbc.
The entry point must be called main. When porting our existing shaders, this would to be adjusted in some places.
Debug and reflection info are currently always stripped out of the binaries to keep the size small.
In terms of naming, we assume ASCII characters for everything excluding directory paths. This is kind of necessary anyway since C wouldn't be overly happy about having 🐸 as a variable name, but also simplifies string conversions in various places because of course the shader compiler APIs are inconsistent about requiring wide strings vs utf-8 strings.
All of this could be changed or expanded if necessary (e.g. to allow for changing entry point names, or supporting multiple entry points per file), but for now I went with a fairly minimal approach. I haven't really looked into whether special options are necessary when compiling raytracing/workgraph shaders or shaders with embedded root signatures.
As discussed on Discord, this could be used to make writing tests less painful by allowing us to simply run the exe within a directory that contains HLSL shaders and spits out plain C headers. Draft for now to gauge whether this is going in the right direction.
Currently, this works as follows:
dxcompiler.dllmust be in the search path (either next to the exe or in the wine prefix). As for headers, I added a new IDL with the necessary interfaces, but it does not cover the entire DXC API.d3dcompiler_47.dllas the latest version. I haven't added a custom IDL for the d3dcompiler APIs since MinGW ships the necessary headers anyway, but I can add a minimal IDL here as well if we want to go that route.headerswithin the source directory.frog.vs_6_0.vs_5_0.hlsl, with support for up to one DXIL target and up to one DXBC target (of course, specifying only one also works). The output file name would befrog.h, and names of the correspondingD3D12_SHADER_BYTECODEconstants arefrog_dxilandfrog_dxbc.main. When porting our existing shaders, this would to be adjusted in some places.All of this could be changed or expanded if necessary (e.g. to allow for changing entry point names, or supporting multiple entry points per file), but for now I went with a fairly minimal approach. I haven't really looked into whether special options are necessary when compiling raytracing/workgraph shaders or shaders with embedded root signatures.