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.
--
v9: tests: Use the vulkan runner to run SM1 compilation tests.
vkd3d-shader/ir: Lower texkill`s to discard_nz`s.
vkd3d-shader/d3dbc: Emit fixme for HLSL_RESOURCE_SAMPLE_LOD.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
Apparently, this wasn't enough to fix it in all WMs. It's simpler to just use the same sequence as normal fullscreen windows and avoid headaches with virtual desktops, and Béla reported it working as well (I couldn't reproduce it, but nothing broke for me, at least).
I know the whole NtUserGetPrimaryMonitorRect thing is wrong and only works for one monitor, but that was already the case before, so I kept it the same since it won't fix a regression and we're in code freeze.
--
v2: winex11: Move the update_desktop_fullscreen callsite to update_net_wm_states.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4823
Apparently, this wasn't enough to fix it in all WMs. It's simpler to just use the same sequence as normal fullscreen windows and avoid headaches with virtual desktops, and Béla reported it working as well (I couldn't reproduce it, but nothing broke for me, at least).
I know the whole NtUserGetPrimaryMonitorRect thing is wrong and only works for one monitor, but that was already the case before, so I kept it the same since it won't fix a regression and we're in code freeze.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4823
--
v10: vkd3d-shader/dxil: Handle the DXIL SWITCH instruction.
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.
vkd3d-shader/dxil: Introduce a code block terminator struct.
vkd3d-shader/ir: Include an initial label instruction in the first control flow block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/491
--
v9: vkd3d-shader/dxil: Handle the DXIL SWITCH instruction.
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.
vkd3d-shader/dxil: Introduce a code block terminator struct.
vkd3d-shader/ir: Include an initial label instruction in the first control flow block.
vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten SWITCH/CASE/DEFAULT/ENDSWITCH control flow instructions.
vkd3d-shader/ir: Flatten LOOP/BREAK/CONTINUE/ENDLOOP control flow instructions.
vkd3d-shader/ir: Flatten IF/ELSE/ENDIF control flow instructions.
vkd3d-shader/spirv: Handle RETP in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Handle DISCARD and TEXKILL in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/491
--
v22: vkd3d-shader/ir: Include an initial label instruction in the first control flow block.
vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten SWITCH/CASE/DEFAULT/ENDSWITCH control flow instructions.
vkd3d-shader/ir: Flatten LOOP/BREAK/CONTINUE/ENDLOOP control flow instructions.
vkd3d-shader/ir: Flatten IF/ELSE/ENDIF control flow instructions.
vkd3d-shader/spirv: Handle RETP in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Handle DISCARD and TEXKILL in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
For all mach vm operations this removes the task suspend and resume, which are not needed.
This uses `mach_vm_read_overwrite` to read into a caller-specified buffer, saving the `mach_vm_deallocate` call (bringing all read operations down to 1 syscall from 4).
The only alignment restriction on `mach_vm_write` according to the original CMU documentation is that data is
> [pointer to page aligned in array of bytes] An array of data to be written.
(In practice it also works with arbitrary addresses on macOS, but it probably doesn't hurt to follow the original specifications here).
The only other reference that these read/writes should be page-aligned is from the GNU Hurd documentation
> The current implementation requires that address, data and data_count all be page-aligned. Otherwise, KERN_INVALID_ARGUMENT is returned.
which I assume was the reason why this was originally done (plus it sounds to me like they will fix that in the future and 4fe19777 already broke GNU Hurd support anyways, if that was supposed to be working).
Also this includes the missing mach part of 5b1f3b14, which was only applied to the ptrace backend, and together with the `write_process_memory` rework, this gets rid of all fixmes in mach.c
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4826