- wine-gitlab - winehq.org

[PATCH v2 0/2] MR2108: wined3d: Destroy objects belonging to the current completed command buffer/fence.
by Zebediah Figura (＠zfigura) 04 Feb '23

04 Feb '23

-- v2: wined3d: Destroy objects belonging to wined3d_device_gl.completed_fence_id. https://gitlab.winehq.org/wine/wine/-/merge_requests/2108

3 3

[PATCH 0/2] MR2108: wined3d: Destroy objects belonging to the current completed command buffer/fence.
by Zebediah Figura (＠zfigura) 03 Feb '23

03 Feb '23

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

2 2

[PATCH 0/3] MR2107: dxgi: Implement IDXGIResource::GetUsage().
by Zebediah Figura (＠zfigura) 03 Feb '23

03 Feb '23

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

2 3

[PATCH 0/3] MR81: vkd3d-shader/hlsl: Fixes for SM1 writemasks and swizzles.
by Francisco Casas (＠fcasas) 03 Feb '23

03 Feb '23

Because of the change introduced in f21693b2, SM1 scalars and vectors were not longer getting the correct writemask when they are allocated, so this is fixed. Also, the mapping of sm1 src register swizzles is moved outside `write_sm1_instruction()` since there are some instructions that don't do this, remarkably dp2add. This is fixed. Before the last patch we are writing the operation as: ``` dp2add r0.x, r1.x, r0.x, r2.x ``` and now it is: ``` dp2add r0.x, r1.xyxx, r0.xyxx, r2.x ``` dp2add now has its own function, write_sm1_dp2add(), since it seems to be the only instruction with this structure. Ideally we would be using the default swizzles for the first two src arguments: ``` dp2add r0.x, r1, r0, r2.x ``` since, according to native's documentation, these are supported for all sm < 4. But using default swizzles whenever is possible -- along with following the conversion of repeating the last component of the swizzle when fewer than 4 components are to be specified -- has a higher scope. Probably would involve modifying `hlsl_swizzle_from_writemask()` and `hlsl_map_swizzle()`. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/81

3 4

[PATCH 0/2] MR2099: tests: Actually test the return value of some function calls
by Michael Stefaniuc (＠mstefani) 03 Feb '23

03 Feb '23

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

5 6

[PATCH v4 0/1] MR2105: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
by Steve Schnepp (＠steveschnepp) 03 Feb '23

03 Feb '23

Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices. Note, it *increase* the number of vertices, but bandwith is much less costly than multiple calls. Note, only a very precise subset of the calls get buffered in order to ensure that the disruption is minimal. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814 -- v4: ddraw: Add local buffer in d3d_device7_DrawPrimitive() https://gitlab.winehq.org/wine/wine/-/merge_requests/2105

2 1

[PATCH v3 0/1] MR2105: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
by Steve Schnepp (＠steveschnepp) 03 Feb '23

03 Feb '23

Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices. Note, it *increase* the number of vertices, but bandwith is much less costly than multiple calls. Note, only a very precise subset of the calls get buffered in order to ensure that the disruption is minimal. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814 -- v3: ddraw: Add local buffer in d3d_device7_DrawPrimitive() https://gitlab.winehq.org/wine/wine/-/merge_requests/2105

2 1

[PATCH v2 0/1] MR2105: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
by Steve Schnepp (＠steveschnepp) 03 Feb '23

03 Feb '23

Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices. Note, it *increase* the number of vertices, but bandwith is much less costly than multiple calls. Note, only a very precise subset of the calls get buffered in order to ensure that the disruption is minimal. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814 -- v2: ddraw: Add local buffer in d3d_device7_DrawPrimitive() https://gitlab.winehq.org/wine/wine/-/merge_requests/2105

2 1

[PATCH 0/1] MR2105: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
by Steve Schnepp (＠steveschnepp) 03 Feb '23

03 Feb '23

Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices. Note, it *increase* the number of vertices, but bandwith is much less costly than multiple calls. Note, only a very precise subset of the calls get buffered in order to ensure that the disruption is minimal. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2105

2 1

[PATCH 0/3] MR2101: ntdll: Load apiset targets from system directory
by Paul Gofman (＠gofman) 03 Feb '23

03 Feb '23

Starting from Win10, when an apiset target dll (most notably in practice, ucrtbase and msvcrt) is loaded through import resolution or LoadLibrary, the dll from system32 directory is loaded regardless of presence of the same dll in a higher priority search path (e. g., at .exe directory). The other version of apiset target dll is still loaded if LoadLibrary() has a path (even if relative). The practical issue I am trying to solve is the following scenario (encountered with a game using certain Uplay plugin) which has regressed since apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have the other ucrtbase loaded this results in NULL module handle. That issue is reproduced in my test in line 1661 (```ok( hapiset == hsystem || broken( old_behaviour && !hapiset )...```), current Wine behaviour corresponds to old Windows before Win10. The third patch (which removes the last todo in the added test) is not something I hit with any real application so far, just stomped on that in tests and the fix looks trivial. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2101

2 5

2025

2024

2023

2022

wine-gitlab