January 2024 - wine-gitlab

Re: [PATCH v6 0/4] MR537: vkd3d-shader/ir: Expand index range write masks to cover all element masks. - approved
by Alexandre Julliard (＠julliard) 17 Jan '24

17 Jan '24

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

1 0

Re: [PATCH v10 0/5] MR463: hlsl: Fix some type handling for ternaries. - approved
by Alexandre Julliard (＠julliard) 17 Jan '24

17 Jan '24

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

1 0

Re: [PATCH v26 0/10] MR450: vkd3d-shader/ir: Flatten structured control flow instructions. - approved
by Alexandre Julliard (＠julliard) 17 Jan '24

17 Jan '24

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

1 0

[PATCH v2 0/4] MR568: vkd3d-shader: Miscellaneous changes in view of the CFG structurizer.
by Giovanni Mascellani (＠giomasce) 17 Jan '24

17 Jan '24

-- v2: vkd3d-shader: Make relative address sources mutable too. vkd3d-shader/spirv: Normalise the shader before allocating registers. tests: Test a couple of degenerate switch instances. tests: Add a test with non-trivial control flow. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/568

2 4

[PATCH v14 0/5] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) 17 Jan '24

17 Jan '24

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. -- v14: tests: Use the vulkan runner to run SM1 compilation tests. vkd3d-shader/ir: Lower texkill instructions to discard_nz. vkd3d-shader/d3dbc: Emit fixme for HLSL_RESOURCE_SAMPLE_LOD. 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 6

[PATCH v13 0/6] MR514: tests: Use the vulkan runner to run SM1 compilation tests.
by Francisco Casas (＠fcasas) 17 Jan '24

17 Jan '24

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. -- v13: 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

5 10

[PATCH 0/4] MR568: vkd3d-shader: Miscellaneous changes in view of the CFG structurizer.
by Giovanni Mascellani (＠giomasce) 17 Jan '24

17 Jan '24

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

3 5

[PATCH 0/1] MR4863: concrt140: Add stub for _Cancellation_beacon::_Confirm_cancel().
by Vijay Kiran Kamuju (＠infyquest) 17 Jan '24

17 Jan '24

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

3 2

[PATCH 0/3] MR4862: mach.c build warning fixes
by Marc-Aurel Zent (＠mzent) 17 Jan '24

17 Jan '24

This replaces the deprecated `syscall()` to `__pthread_kill` with its wrapper version, which will continue working when the syscall numbers change (happens luckily very rarely on XNU compared to NT). Also replaces the deprecated `bootstrap_register` with `bootstrap_register2` (which although being private is being used by `-[NSMachBootstrapServer registerPort:name:]`, and what `bootstrap_register` calls into as well). Both of these are available on at least OSX 10.5+ as far as I can tell, so should be fine support wise. I took the liberty to also slightly adjust the formatting of `void init_tracing_mechanism(void)` to better fit into the surrounding code. For me this makes it so mach.c now builds with 0 warnings all in all. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4862

2 3

[PATCH 0/1] MR4855: combase: Make RoGetActivationFactory hookable.
by Brendan Shanks (＠bshanks) 17 Jan '24

17 Jan '24

The Steam overlay hooks this for various game controller input interfaces. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4855

3 2

2025

2024

2023

2022

wine-gitlab January 2024