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

[PATCH v8 0/3] MR777: vkd3d-shader/dxil: Support SV_Depth, SV_DepthGreaterEqual and SV_DepthLessEqual.
by Conor McCarthy (＠cmccarthy) April 12, 2024

April 12, 2024

Includes !782 to prevent the 32-bit Windows CI crashing. -- v8: vkd3d-shader/dxil: Support SV_Depth, SV_DepthGreaterEqual and SV_DepthLessEqual. tests/hlsl: Add an SV_Depth test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/777

2 3

[PATCH v7 0/3] MR777: vkd3d-shader/dxil: Support SV_Depth, SV_DepthGreaterEqual and SV_DepthLessEqual.
by Conor McCarthy (＠cmccarthy) April 12, 2024

April 12, 2024

Includes !782 to prevent the 32-bit Windows CI crashing. -- v7: vkd3d-shader/dxil: Support SV_Depth, SV_DepthGreaterEqual and SV_DepthLessEqual. tests/hlsl: Add an SV_Depth test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/777

2 3

[PATCH v10 0/1] MR364: kernel32/tests: Test module refcounting with forwarded exports.
by Jinoh Kang (＠iamahuman) April 12, 2024

April 12, 2024

Test module references created by resolving forwarded exports. The following diagram (best viewed in light mode due to fixed colors) explains what happens in bug #52094 under the hood: ```mermaid graph TB subgraph state_00["Initial"] direction LR s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll] end state_00 -. "1. <code>LoadLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_01 subgraph state_01["python311.dll loaded"] direction LR s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll] s01_ida -- "dynamic ref" --> s01_py311 end state_01 -. "2. <code>LoadLibrary("</code>idapython64.dll<code>")</code>" .-> state_02 subgraph state_02["idapython64.dll loaded"] direction LR s02_ida[ida64.dll] -- "dynamic ref" --> s02_idapy[idapython64.dll] -- "static ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll] s02_ida -- "dynamic ref" --> s02_py311 s02_idapy -- "static forwarded ref" --> s02_py311 end state_02 -. "3. <code>FreeLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_03 subgraph state_03["python311.dll reference removed"] direction LR style s03_py311 color:#f00,stroke:#f00 s03_ida[ida64.dll] -- "dynamic ref" --> s03_idapy[idapython64.dll] -- "static ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll] s03_ida -. "<del>dynamic ref (deleted)</del>" .-> s03_py311 s03_idapy -- "static forwarded ref" --> s03_py311 end ``` On Windows, the static forwarded ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition. -- v10: kernel32/tests: Test module refcounting with forwarded exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/364

2 1

[PATCH v9 0/1] MR364: kernel32/tests: Test module refcounting with forwarded exports.
by Jinoh Kang (＠iamahuman) April 12, 2024

April 12, 2024

Test module references created by resolving forwarded exports. The following diagram (best viewed in light mode due to fixed colors) explains what happens in bug #52094 under the hood: ```mermaid graph TB subgraph state_00["Initial"] direction LR s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll] end state_00 -. "1. <code>LoadLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_01 subgraph state_01["python311.dll loaded"] direction LR s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll] s01_ida -- "dynamic ref" --> s01_py311 end state_01 -. "2. <code>LoadLibrary("</code>idapython64.dll<code>")</code>" .-> state_02 subgraph state_02["idapython64.dll loaded"] direction LR s02_ida[ida64.dll] -- "dynamic ref" --> s02_idapy[idapython64.dll] -- "static ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll] s02_ida -- "dynamic ref" --> s02_py311 s02_idapy -- "static forwarded ref" --> s02_py311 end state_02 -. "3. <code>FreeLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_03 subgraph state_03["python311.dll reference removed"] direction LR style s03_py311 color:#f00,stroke:#f00 s03_ida[ida64.dll] -- "dynamic ref" --> s03_idapy[idapython64.dll] -- "static ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll] s03_ida -. "<del>dynamic ref (deleted)</del>" .-> s03_py311 s03_idapy -- "static forwarded ref" --> s03_py311 end ``` On Windows, the static forwarded ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition. -- v9: kernel32/tests: Test module refcounting with forwarded exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/364

2 1

[PATCH v7 0/1] MR364: kernel32/tests: Test module refcounting with forwarded exports.
by Jinoh Kang (＠iamahuman) April 12, 2024

April 12, 2024

Test module references created by resolving forwarded exports. The following diagram (best viewed in light mode due to fixed colors) explains what happens in bug #52094 under the hood: ```mermaid graph TB subgraph state_00["Initial"] direction LR s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll] end state_00 -. "1. <code>LoadLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_01 subgraph state_01["python311.dll loaded"] direction LR s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll] s01_ida -- "dynamic ref" --> s01_py311 end state_01 -. "2. <code>LoadLibrary("</code>idapython64.dll<code>")</code>" .-> state_02 subgraph state_02["idapython64.dll loaded"] direction LR s02_ida[ida64.dll] -- "dynamic ref" --> s02_idapy[idapython64.dll] -- "static ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll] s02_ida -- "dynamic ref" --> s02_py311 s02_idapy -- "static forwarded ref" --> s02_py311 end state_02 -. "3. <code>FreeLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_03 subgraph state_03["python311.dll reference removed"] direction LR style s03_py311 color:#f00,stroke:#f00 s03_ida[ida64.dll] -- "dynamic ref" --> s03_idapy[idapython64.dll] -- "static ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll] s03_ida -. "<del>dynamic ref (deleted)</del>" .-> s03_py311 s03_idapy -- "static forwarded ref" --> s03_py311 end ``` On Windows, the static forwarded ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition. -- v7: kernel32/tests: Test module refcounting with forwarded exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/364

2 1

[PATCH v6 0/3] MR777: vkd3d-shader/dxil: Support SV_Depth, SV_DepthGreaterEqual and SV_DepthLessEqual.
by Conor McCarthy (＠cmccarthy) April 12, 2024

April 12, 2024

-- v6: vkd3d-shader/dxil: Support SV_Depth, SV_DepthGreaterEqual and SV_DepthLessEqual. tests/hlsl: Add an SV_Depth test. tests/hlsl: Supply data for all mip levels in calculate-lod.shader_test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/777

3 8

[PATCH 0/6] MR785: Draft: vkd3d-shader/ir: Only emit trampolines and launchers when needed.
by Giovanni Mascellani (＠giomasce) April 12, 2024

April 12, 2024

This goes atop !773. The last three commits belong to this MR. Trampolines and launchers allow us to handle code doing multilevel jumps, but they partially virtualize the control flow, which potentially makes the jobs of downstream compilers harder. So we avoid them every time we can. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/785

2 7

[PATCH v3 0/7] MR778: vkd3d-shader/ir: Prepare the CFG structurizer for handling Hull Shaders.
by Giovanni Mascellani (＠giomasce) April 12, 2024

April 12, 2024

Hull Shaders contain two functions instead of just one, so all the algorithms that require computing a CFG need to be run twice. Here we refactor the code so that this can be done more easily. This MR is relatively long, but it is essentially just moving code around, so hopefully it is not too difficult to review anyway. -- v3: vkd3d-shader/ir: Split handling jumps when emitting a structured program. vkd3d-shader/ir: Split handling selections when emitting a structured program. vkd3d-shader/ir: Split handling loops when emitting a structured program. vkd3d-shader/ir: Split handling blocks when emitting a structured program. vkd3d-shader/ir: Refactor declaration emission outside of the CFG structure. vkd3d-shader/ir: Split undominated SSA materialization. vkd3d-shader/ir: Split program structurization. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/778

3 9

Re: [PATCH v2 0/7] MR778: vkd3d-shader/ir: Prepare the CFG structurizer for handling Hull Shaders.
by Giovanni Mascellani (＠giomasce) April 12, 2024

April 12, 2024

On Fri Apr 12 07:05:03 2024 +0000, Conor McCarthy wrote: > The `Split handling * when emitting a structured program` commits do no > more than move code to helper functions, right? Maybe the commit > messages should state that instead. Yes, that's what they do, and that's what "splitting" means in my mind. I'm not terribly attached to that formulation, though, so if you have another suggestion I can use yours. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/778#note_67687

1 0

[PATCH 0/7] MR778: vkd3d-shader/ir: Prepare the CFG structurizer per handling Hull Shaders.
by Giovanni Mascellani (＠giomasce) April 12, 2024

April 12, 2024

Hull Shaders contain two functions instead of just one, so all the algorithms that require computing a CFG need to be run twice. Here we refactor the code so that this can be done more easily. This MR is relatively long, but it is essentially just moving code around, so hopefully it is not too difficult to review anyway. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/778

3 11