The last major feature for compute shader support.
The tests are a bit ad-hoc, and ideally would be extended beyond d3d12. The
nonuniform readback is what makes this difficult.
My plan is to refactor the shader runner so that it exposes an interface usable
both from a file interpreter frontend and also directly from C code. That would
allow, in this case, declaring the shaders and drawing as a shader_test file
would, but then making use of C loops to test the readback. It would also make
it generally easier to port loop-based tests in e.g. d3d12.c.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/64
Allowing the job to fail to avoid failing the pipeline. Some new tests
are failing with it, and some are succeeding todo_wine.
--
v2: gitlab: Run user32 32-bit tests with nulldrv driver.
user32/tests: Update todos specific to the X11 display driver.
user32/tests: Check graphics driver and add todos for nulldrv.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1259
> I do think that as a matter of principle having test coverage for the different intrinsics we implement is simply a good idea. These tests don't necessarily need to be complicated; see e.g. "sqrt.shader_test" for a straightforward example.
For the record, at some point I duplicated some tests so that both the constant folding path and the real codegen path would be tested. See for example `arithmetic-float.shader_test` vs `arithmetic-float-uniform.shader_test`. It wouldn't probably be a bad idea to make that more systematic, but I agree that's not a requirement for this MR. Just saying.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/68#note_21781