Conflicts with !450 but can probably go upstream before it since backend changes here are minimal.
--
v7: vkd3d-shader/dxil: Handle the DXIL SWITCH instruction.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/dxil: Handle the DXIL PHI instruction.
vkd3d-shader/dxil: Handle the DXIL BR instruction conditional variant.
vkd3d-shader/dxil: Handle the DXIL BR instruction unconditional variant.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/491
Recap:
My previous proposals to extend the shader_runner to SM1 were focusing on separating compilation tests ([shader] directives) from execution tests ([test] directives), and let the generic shader_runner.c:compile_shader() in charge of the former.
However, Henri was more inclined to aim for making the parser agnostic to the language of the tests so we can potentially extend the shader_runner tests to other languages such as d3d-asm. This means, removing the burden of compilation from the parser altogether, and moving it to the runners, probably through a runner->compile function pointer (even if most of them end up doing the same thing, compiling with vkd3d-shader or the native compiler, depending on availability).
Agreeing with going in this general direction, this MR contains patches to do SM1 compilation calling run_shader_tests() for SM1 profiles from the Vulkan runner (skipping execution for now), and some improvements to the qualifiers syntax.
Despite this, there are parallel discussions on:
- Whether to name the shader models individually in the [require] directives or expressing the range of shader models where the test should pass. In the latter case, whether to run for all shader models, only the lowest one in the SM1, SM4, and SM6 groups, or to allow the runner to select a shader model within the range (I feel strongly against this now, I think the runner should just retrieve a boolean in runner->check_requirements).
- Where to do the iteration across different shader models, if in run_shader_tests() or expect each runner to call run_shader_tests() several times as we do now.
But there is no need to settle on something for these yet.
---
Now, what may be the most noisy part of this MR is that even though we are calling run_shader_tests() through the Vulkan runner, this will result in calling shader_runner.c:compile_shader() instead of shader_runner_vulkan.c:compile_shader(), but if we follow the "making the parser agnostic" plan, we eventually should get rid of shader_runner.c:compile_shader() and introduce the runner->compile pointer instead.
--
v6: tests: Use the vulkan runner to run SM1 compilation tests.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
So that ddraw isn't always loaded, esp. for app not requesting vmr7.
Could lower memory pressure on 32bit.
Note: on win10, the native 32bit and 64bit quartz DLL delay imports ddraw.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4753
Currently, if a probe fails, it will print the line number of the [test]
block the probe is in, not the line number of the probe itself. This
makes it somewhat difficult to debug.
This commit makes it print the line number that a test fails at.
This code was actually written by @hverbeet for my first attempt at fixing this, !499.
CC @zfigura
--
v3: tests: Print the failing line numbers when a test fails.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/516
Many of these patches are small, but the series can be split in two if necessary.
--
v6: vkd3d-shader/spirv: Handle ITOI and UTOU in spirv_compiler_map_alu_instruction().
vkd3d-shader/spirv: Support UINT64 source in spirv_compiler_emit_bool_cast().
vkd3d-shader/spirv: Support 64-bit sources in spirv_compiler_emit_int_div().
vkd3d-shader/spirv: Introduce a UINT64 component type.
vkd3d-shader/spirv: Introduce a data_type_is_64_bit() helper function.
vkd3d-shader/spirv: Use data_type_is_integer() in spirv_compiler_emit_neg().
vkd3d: Pass int64 capability info to vkd3d-shader.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/490
Currently there is `NtContinue()` test only for `aarch64` so implement it for amd64 aswell.
This implementation is very similar to `aarch64` and it's very basic test.
It doesn't change/test `ContextFlags` so it won't catch https://bugs.winehq.org/show_bug.cgi?id=56050 but that can be implemented later on top of this.
--
v5: ntdll/tests: Implement test_continue() for amd64
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720
I think this is a security issue. Listening to 0.0.0.0 instead of my VPN address that is not yet up is a problem.
With the fix, the bind fails if the address is invalid.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4760