Well, you can see that program as a small script that launches vkd3d-compiler, except that all executions happen in the same process! :-)
I see a few small advantages to have everything happening in the same process:
- There is some time save because you don't have to create and teardown the process each time.
- In particular, it's easier to have cleaner measurements, because you don't have to exclude the time used for creating and tearing down the process.
- In the future one might want to gather statistics about shaders, for example to see which features are more in use, to direct development. This is easier to do in a single process rather than serializing and parsing the statistics state every time.
I'll admit none of these points is really strong, but on the other hand maintaining that program doesn't look complicated either.
It's also a fair bit less flexible than vkd3d-compiler though. E.g., one of the small scripts I have looks roughly like this:
`find . -name '*.dxbc' -print0 | sort -z | xargs -0 -I '{}' bash -c 'echo -e \n{}; vkd3d-compiler -b d3d-asm {}' >shaders.txt`
This disassembles DXBC shaders stored in a directory, and outputs them in order to a file, allowing easy comparison with the previous vkd3d release, for example.
I think on Linux systems process creation overhead generally isn't much of a concern. It may be a bit more of a consideration on Windows and/or Wine, but if this is something we're concerned about, I'm inclined to suggest extending vkd3d-compiler with a "batch mode" instead.