vkd3d-shader: Dump shaders as soon as possible.
Merge request reports
Activity
There are a few details that probably need some finishing touches:
- I used
vkd3d_array_reserve()
in the new test program, with some tricks to have it working. Not sure whether we want that, or what do we want instead. - The new test is, ahem, a test, though it makes no sense as a test by itself. It is run as part of the test suite, but it only makes sense when called manually with some shaders on the command line. The idea is that every developer can keep their own repository of shaders collected in the wild, which for copyright reasons cannot be distributed with vkd3d.
- I used
I pushed some changes to take the input filenames from standard input instead from the command line (which doesn't support more than, say, a few thousands arguments) and to customize the output format a little bit. Hopefully that's not too impactful on reviewers who have already looked at this (but if it is I can remove the last two commits).
added 4 commits
Toggle commit listWell, 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.
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.
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.
What do you mean by "batch mode"?
In the meantime, I'm leaving just the first two patches in the series.
added 40 commits
-
c0723cad...ecdc3f39 - 38 commits from branch
wine:master
- ab09c0b4 - vkd3d-shader: Expose the whole profile when dumping an HLSL shader.
- dd96fe50 - vkd3d-shader: Dump shaders as soon as possible.
-
c0723cad...ecdc3f39 - 38 commits from branch
What do you mean by "batch mode"?
I was going to reply to this, then promptly forgot. Essentially, it would give vkd3d-compiler the ability to compile multiple shaders in a single invocation. In one of its most basic forms it could take input like this:
-o /dev/null -p vs_4_0 ./vkd3d-shader-1-vs_4_0.hlsl -o /dev/null -p ps_4_0 ./vkd3d-shader-2-ps_4_0.hlsl ...