On 11/24/20 3:21 PM, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni mbruni@codeweavers.com
Okay, this is getting into pretty deep madness. Nice tests btw.
I forgot that sometimes D3DPreprocess() returns success and "some" output even when it reports actual errors. I don't know that we should also check for those errors (for some value of "check") in the test. I'd say no until we have a very good reason.
I'm inclined to agree.
The other side is the sometimes peculiar output of the preprocessor, in particular WRT macro expansion. Unfortunately we might eventually want to check the exact output because, as it's invariably the case, there are applications that depend on it (https://bugs.winehq.org/show_bug.cgi?id=31701).
That's an interesting point.
I did try to avoid testing exact spacing, because it does constrain the implementation, but if that's a necessary constraint, then it may make the most sense just to check exact output anyway. Somewhat fortunately, my current implementation actually matches the spacing of native relatively closely.
I'm not sure how this interacts with the shader_test format. It's easy enough to have multiple tests in the same file; this could even be done for the other shader tests such as swizzle-*; I only avoided it for the sake of visual clarity, but perhaps that's not worthwhile.
Somewhat related, I don't know if it makes sense to add a test option to dump the output of D3DPreprocess(). Just putting it out there, I hacked a trace() in the test runner and that's good enough for me anyway.
It's probably not unreasonable to do that on VKD3D_TEST_DEBUG=3.