December 2023 - wine-gitlab

[PATCH v4 0/3] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) 15 Dec '23

15 Dec '23

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. -- v4: tests: Use the vulkan runner to run SM1 compilation tests. tests/shader-runner: Call each runner only once. tests/shader-runner: Support reading multiple model range args for qualifiers. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514

2 4

[PATCH v3 0/3] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) 15 Dec '23

15 Dec '23

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. -- v3: tests: Use the vulkan runner to run SM1 compilation tests. tests/shader-runner: Call each runner only once. tests/shader-runner: Support reading multiple model range args for qualifiers. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514

2 4

[PATCH v3 0/1] MR4674: comctl32/listview: Ignore the lParam to WM_PRINTCLIENT and add tests.
by Alex Henrie (＠alexhenrie) 15 Dec '23

15 Dec '23

Based on simliar patch for comctl32/treeview: 231199bc46 WM_PRINTCLIENT paints the items of a listview, including the item backgrounds, but never the listview background. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54878 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55005 Co-authored-by: Alex Henrie <alexhenrie24(a)gmail.com> -- v3: comctl32/listview: Ignore the lParam to WM_PRINTCLIENT and add tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/4674

3 6

Re: [PATCH v5 0/5] MR519: vkd3d-shader/dxil: Support minimum precision.
by Conor McCarthy (＠cmccarthy) 15 Dec '23

15 Dec '23

On Thu Dec 14 16:34:26 2023 +0000, Giovanni Mascellani wrote: > Defining `SONAME_LIBDXCOMPILER` when the dxcompiler library is not > indeed available means that tests start failing. If no soname was > specified or detected at configuration time, I don't think we should > even try to use that library. I made this change so runner crosstests can be run in a Visual Studio command prompt, where dxcompiler.dll is in the path. `SONAME_LIBDXCOMPILER` is already defined even for crosstests, and there's no way to tell at compile time what its value should actually be for crosstest builds. It's convenient to have this work if dxcompiler.dll is available. It has no effect otherwise. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/519#note_56045

1 0

[PATCH v5 0/7] MR490: vkd3d-shader: Int64 support.
by Conor McCarthy (＠cmccarthy) 15 Dec '23

15 Dec '23

Many of these patches are small, but the series can be split in two if necessary. -- v5: 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

2 7

[PATCH v2 0/1] MR4683: ntdll: Restore fs32_sel only if pthread TEB was not set already in init_handler.
by Rémi Bernon (＠rbernon) 14 Dec '23

14 Dec '23

Fixes spurious crashes in Steam when downloading games. The download causes a huge amount of SIGUSR1 signals, and it becomes very likely that one signal will be received while being inside the syscall or unix call dispatchers. When this happens, it can be received within the small range of instructions where %fs has been restored but we have not yet switched to the syscall stack, or the other way around in the return path. The signal handler then was restoring the 32bit %fs while returning to the syscall dispatcher, then we are entering a syscall with %fs set to the wrong value. -- v2: ntdll: Avoid breaking leave_handler heuristics for fs32_sel restore. https://gitlab.winehq.org/wine/wine/-/merge_requests/4683

3 4

[PATCH 0/2] MR4699: wined3d: Store the resource heap memory pointer directly.
by Rémi Bernon (＠rbernon) 14 Dec '23

14 Dec '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55773 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4699

2 3

Re: [PATCH v3 0/1] MR4680: winewayland.drv: Consider implicit fullscreen clip for pointer locking. - approved
by Alexandre Julliard (＠julliard) 14 Dec '23

14 Dec '23

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

1 0

Re: [PATCH v4 0/1] MR4697: include: Add SampleGrabber coclass definition in qedit.idl. - approved
by Alexandre Julliard (＠julliard) 14 Dec '23

14 Dec '23

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

1 0

Re: [PATCH v2 0/1] MR4696: sapi/tests: Remove registry keys created by SetId() in the SpVoice tests. - approved
by Alexandre Julliard (＠julliard) 14 Dec '23

14 Dec '23

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

1 0

2025

2024

2023

2022

wine-gitlab December 2023