January 2024 - Wine-GitLab - list.winehq.org

Re: [PATCH v4 0/5] MR550: vkd3d-shader/ir: Validate SSA and TEMP usages. - approved
by Alexandre Julliard (＠julliard) Jan. 15, 2024

Jan. 15, 2024

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/550

1 0

Re: [PATCH v2 0/2] MR548: vkd3d-shader/spirv: Support vector source param for FIRSTBIT_HI and FIRSTBIT_SHI instructions. - approved
by Alexandre Julliard (＠julliard) Jan. 15, 2024

Jan. 15, 2024

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/548

1 0

[PATCH v2 0/1] MR558: vkd3d-shader/hlsl: Emit fixmes on non-constant vector addressing.
by Francisco Casas (＠fcasas) Jan. 15, 2024

Jan. 15, 2024

vkd3d-shader/hlsl: Emit fixmes on non-constant vector addressing. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56162 Storing to a vector component using a non-constant index is not allowed on profiles lower than 6.0. Unless this happens inside a loop that can be unrolled, which we are not doing yet. For this reason, a validate_nonconstant_vector_store_derefs pass is added to detect these cases. Ideally we would want to emit an hlsl_error on this pass, but before implementing loop unrolling, we could reach this point on valid HLSL. Also, as pointed out by Nikolay in the mentioned bug, currently new_offset_from_path_index() fails an assertion when this happens, because it expects an hlsl_ir_constant, so a check is added. It also felt correct to emit an hlsl_fixme there, despite the redundancy. -- v2: vkd3d-shader/hlsl: Emit fixmes on non-constant vector addressing. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/558

5 4

[PATCH 0/7] MR563: vkd3d-shader/tpf: Avoid DWORDs.
by Henri Verbeet (＠hverbeet) Jan. 15, 2024

Jan. 15, 2024

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/563

3 8

[PATCH 0/1] MR562: vkd3d-common: Get rid of InterlockedAdd().
by Henri Verbeet (＠hverbeet) Jan. 15, 2024

Jan. 15, 2024

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/562

3 2

[PATCH v12 0/6] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) Jan. 15, 2024

Jan. 15, 2024

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. -- v12: tests: Use the vulkan runner to run SM1 compilation tests. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514

3 7

[PATCH v11 0/6] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) Jan. 15, 2024

Jan. 15, 2024

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. -- v11: tests: Use the vulkan runner to run SM1 compilation tests. vkd3d-shader/ir: Lower texkill instructions to discard_nz. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514

3 8

[PATCH 0/1] MR4849: mf/tests: Skip tests if video renderer can't be created.
by Nikolay Sivov (＠nsivov) Jan. 15, 2024

Jan. 15, 2024

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4849

3 2

[PATCH 0/1] MR4848: dbghelp: {stabs} Support redefinition of a range statement.
by eric pouech (＠epo) Jan. 15, 2024

Jan. 15, 2024

Wine-Bug-Id: https://bugs.winehq.org/show_bug.cgi?id=56168 Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4848

2 1

[PATCH v2 0/2] MR4846: gitlab: Fix and optimize cache configuration.
by Rémi Bernon Jan. 15, 2024

Jan. 15, 2024

This partially reverts commit 67f2da2a8d1f219f528bf820b3d6002c5f34d5e4 which broke ccache cache as the job configurations were overriding the default cache configuration from .wine-build instead of extending it. It then also updates the ccache cache config to add a key and try to avoid cache invalidation between jobs with different compilers. -- v2: gitlab: Add key to the jobs ccache cache config. gitlab: Use a common configure cache key prefix. https://gitlab.winehq.org/wine/wine/-/merge_requests/4846

1 3