There may be some value in trying without VKD3D_SHADER_PARSE_DXBC_IGNORE_CHECKSUM first, to determine whether the checksum was valid or not.
And what would happen depending on whether it's valid or not?
I'm a little worried about painting ourselves into a corner with this. In particular, there are a couple of features I'd like to add in the future:
- Updating the contents of DXBC sections.
- Appending DXBC sections.
- Extracting the contents of DXBC sections.
That last feature in particular potentially implies having multiple output files. You could e.g. imagine syntax like this:
# Extract the ISGN, OSGN, and SHDR sections to the corresponding files. vkd3d-dxbc -o shader.ISGN -x t:ISGN -o shader.OSGN -x t:OSGN -o shader.SHDR -x t:SHDR shader.dxbc # Extract the SHEX section, pipe to hexdump. vkd3d-dxbc -x t:SHEX shader.dxbc | hexdump -C # Update the SHDR section from shader.SHDR, write the new DXBC to shader2.dxbc. vkd3d-dxbc -i shader.SHDR -u t:SHDR -o shader2.dxbc shader.dxbc # Update the SHDR section from shader.SHDR, pipe to xxd. vkd3d-dxbc -u t:SHDR shader.dxbc < shader.SHDR | xxd -iI.e., -i specifies the input file for subsequent operations, -o specifies the output file for subsequent operations, when unspecified stdin/stdout is used, and there's an implied "write output if modified" at the end. The question then becomes how rewriting the checksum fits in. One option would be to make that an explicit operation. E.g.:
vkd3d-dxbc --ignore-checksum --recalculate-checksum shader.dxbc > shader2.dxbc vkd3d-dxbc --ignore-checksum -o shader2.dxbc --recalculate-checksum shader.dxbcThoughts?
* I don't completely understand how you perform input: you seem to have the concept of a "main input" (using the positional argument at the end), which is interpreted as the beginning of a pipeline on which a few filters operate, possibly using auxiliary inputs (using `-o`). Is that the intention? The main input is allowed to be the stdin too? * You seem the consider `-o` an option (changing the command line parsing state but not performing actions themselves) and the various filter (`-x`, `-u`) as the actions, i.e., points at which the program does something for real. Maybe it might be more expressive to reverse the point of view? I.e., `-x` and `-u` merely configure a filter on the pipeline (with the possibility to chain many, or zero) and `-o` takes the current pipeline state, executes it and writes to the specified file. My proposal rather fits this model (except that no filter is currently defined, i.e., you can only write the same shader you just read), which looks more flexible to me. For example you can chain or otherwise compose filters and operators, which seems harder if filters immediately trigger an action. * `--recalculate-checksum` doesn't sound right to me: in my model the checksum is recalculated merely by virtue of the fact that each time we emit a DXBC file we put the right checksum. There is no explicit action to do so. To me `vkd3d-dxbc --ignore-checksum -o shader2.dxbc shader.dxbc` means: "Read `shader.dxbc` and rewrite it to `shader2.dxbc` without changing nothing, and without caring if when reading the checksum is not correct". The write will naturally put the correct checksum, because it's the only thing it's able to do.