- wine-gitlab - winehq.org

[PATCH v2 0/3] MR5535: advapi32: CryptSetKeyParam() should accept NULL pbData.

by Dmitry Timoshkov (＠dmitry)

At least CryptSetKeyParam(KP_X) should accept NULL pbData. -- v2: advapi32: CryptSetKeyParam() should accept NULL pbData. rsaenh: Validate pbData in CPSetKeyParam(). dssenh: Add CPSetKeyParam() stub implementation. https://gitlab.winehq.org/wine/wine/-/merge_requests/5535

3 hours, 7 minutes

3
4
0 0

[PATCH 0/1] MR5537: win32u: Destroy thread windows before calling driver ThreadDetach.

by Rémi Bernon (＠rbernon)

As discussed in https://gitlab.winehq.org/wine/wine/-/merge_requests/5491#note_67760 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5537

3 hours, 10 minutes

1
0
0 0

[PATCH v3 0/6] MR5491: win32u: Move most vulkan surface code out of the drivers.

by Rémi Bernon (＠rbernon)

-- v3: win32u: Move host surface destruction out of the drivers. win32u: Pass HWND directly to vulkan surface creation driver callback. win32u: Rename vulkan surface creation/destroy driver callbacks. winevulkan: Pass win32u surface wrappers for each vkQueuePresent swapchain. win32u: Introduce a new VkSurfaceKHR wrapping structure. win32u: Introduce a distinct vulkan interface between win32u and the user drivers. https://gitlab.winehq.org/wine/wine/-/merge_requests/5491

3 hours, 16 minutes

2
6
0 0

[PATCH 0/6] MR5536: mf/tests: Add more video processor tests with aperture changes.

by Rémi Bernon (＠rbernon)

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

3 hours, 27 minutes

2
6
0 0

[PATCH 0/2] MR5535: advapi32: CryptSetKeyParam() should accept NULL pbData.

by Dmitry Timoshkov (＠dmitry)

At least CryptSetKeyParam(KP_X) should accept NULL pbData. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5535

4 hours, 3 minutes

2
2
0 0

[PATCH v5 0/1] MR5490: setupapi: Don't set RequiredSize when SetupDiGetClassDescription* fails.

by Alex Henrie (＠alexhenrie)

Discovered while investigating Bug 56551. -- v5: setupapi: Don't set RequiredSize when SetupDiGetClassDescription* fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/5490

7 hours, 26 minutes

2
1
0 0

[PATCH v4 0/1] MR5490: setupapi: Don't set RequiredSize when SetupDiGetClassDescription* fails.

by Alex Henrie (＠alexhenrie)

Discovered while investigating Bug 56551. -- v4: setupapi: Don't set RequiredSize when SetupDiGetClassDescription* fails. https://gitlab.winehq.org/wine/wine/-/merge_requests/5490

8 hours, 16 minutes

2
1
0 0

[PATCH 0/2] MR5534: cryptnet, crypt32: OCSP revocation check improvements.

by Paul Gofman (＠gofman)

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

10 hours

2
2
0 0

[PATCH v4 0/1] MR5437: kernelbase: Do not start the debugger if SEM_NOGPFAULTERRORBOX is set.

by Zebediah Figura (＠zfigura)

-- v4: kernelbase: Do not start the debugger if SEM_NOGPFAULTERRORBOX is set. https://gitlab.winehq.org/wine/wine/-/merge_requests/5437

12 hours, 5 minutes

2
1
0 0

[PATCH v3 0/2] MR2724: wined3d: Submit command buffers that are built for longer than 2 ms.

by Zebediah Figura (＠zfigura)

This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT, with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option enabled, which also improves performance with the game by itself. From my testing, it's possible to raise the threshold from 2 ms up to 5 ms or so, before the driver or GPU seems to reclock back to the lower power level. However, this measurement is questionable for several reasons. It seems to vary depending on the scene being rendered, and of course this will be specific to the game and driver and GPU in question anyway. The game also has a weird approach to vsync that seems to involve it presenting stale frames (and hence artificially inflating the FPS), which I'm not fully sure I accounted for while measuring. And of course, it's hard to be sure that 5 ms is actually the threshold for how long the driver will go before powering down the GPU. In any case, it seems better to err on the side of submitting more often, to make sure the fix affects more drivers. While submission isn't cheap, it seems to me that submitting every 2 ms is unlikely to cause a bottleneck [consider that this is at most 8 (more) submissions per frame]. The maximum of 4 concurrent periodically submitted buffers was chosen arbitrarily. Removing the maximum altogether does not measurably affect performance for this game either way. Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that periodic submission might make a difference. -- v3: wined3d: Submit command buffers after 512 draw or dispatch commands. wined3d: Retrieve the VkCommandBuffer from wined3d_context_vk after executing RTV barriers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2724

12 hours, 19 minutes

2
2
0 0

2024

2023

2022

wine-gitlab