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

[PATCH v30 0/9] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon 28 May '24

28 May '24

First part of Proton shared memory series. The full branch can be seen at https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories. -- v30: win32u: Use the desktop shared data for GetCursorPos. server: Move the last cursor time to the desktop session object. server: Move the cursor position to the desktop session object. win32u: Open desktop shared objects from session mapping. server: Return the desktop object info in get_thread_desktop. server: Allocate shared session object for desktops. win32u: Open the global session shared mapping. include: Add ReadNoFence64 inline helpers. server: Create a global session shared mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

3 24

[PATCH v4 0/3] MR5462: Ucrtbase's stderr is now always unbuffered.
by eric pouech (＠epo) 28 May '24

28 May '24

Starting with late Windows 10 version, in ucrtbase, stderr is now unbuffered whatever the type of the underlying fd (previously, native only set it to unbuffered when attached to character fd (console, NUL...)). This serie adds also tests for msvcrt & ucrtbase to show the discrepancies. Note: ucrtbase's tests also include a reversed engineered structure layout for FILE. _get_stream_buffer_pointers already gives base, ptr and cnt, and toying with setvbuf gave easily the rest of the fields. Didn't spend time in guessing the flags meaning: which look different from msvcrt's. Related to https://bugs.winehq.org/show_bug.cgi?id=56459 @piotr: I can share the details (the access to the test result in the bug report is limited). -- v4: ucrtbase: Let stderr be always be unbuffered. ucrtbase/tests: Add tests for checking buffering state of standard streams. msvcrt/tests: Add tests for check buffering state of standard streams. https://gitlab.winehq.org/wine/wine/-/merge_requests/5462

3 4

[PATCH 0/4] MR5471: wined3d: Dynamic pipeline state, part 3: EXT_extended_dynamic_state3.
by Zebediah Figura (＠zfigura) 28 May '24

28 May '24

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

5 10

[PATCH 0/3] MR5246: cmd/tests: Add tests for calling special excuteable files.
by Haidong Yu (＠yhd986) 28 May '24

28 May '24

Signed-off-by: Haidong Yu <yuhaidong(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5246

4 5

[PATCH v3 0/3] MR5462: Ucrtbase's stderr is now always unbuffered.
by eric pouech (＠epo) 28 May '24

28 May '24

Starting with late Windows 10 version, in ucrtbase, stderr is now unbuffered whatever the type of the underlying fd (previously, native only set it to unbuffered when attached to character fd (console, NUL...)). This serie adds also tests for msvcrt & ucrtbase to show the discrepancies. Note: ucrtbase's tests also include a reversed engineered structure layout for FILE. _get_stream_buffer_pointers already gives base, ptr and cnt, and toying with setvbuf gave easily the rest of the fields. Didn't spend time in guessing the flags meaning: which look different from msvcrt's. Related to https://bugs.winehq.org/show_bug.cgi?id=56459 @piotr: I can share the details (the access to the test result in the bug report is limited). -- v3: ucrtbase: Let stderr be always be unbuffered. ucrtbase/tests: Add tests for checking buffering state of standard streams. msvcrt/tests: Add tests for check buffering state of standard streams. https://gitlab.winehq.org/wine/wine/-/merge_requests/5462

3 9

[PATCH v6 0/5] MR5464: mf/tests: Check that D3D aware attribute has no effect on the topology.
by Rémi Bernon 28 May '24

28 May '24

Wine incorrectly inserts a sample copier. D3D awareness is handled per node, and each node will have their own sample allocator created from the D3D device manager provided by the session. -- v6: mf/tests: Test device manager handling in the topology loader. mf/tests: Test D3D awareness handling in the topology loader. mf/tests: Split topology loader tests to a new file. mf/tests: Fix printf format warning. include: Add MFTOPOLOGY_DXVA_MODE enum definition. https://gitlab.winehq.org/wine/wine/-/merge_requests/5464

3 10

[PATCH v2 0/5] MR5463: mfreadwrite: Test and fix some reference leaks.
by Rémi Bernon 28 May '24

28 May '24

These were probably the cause of crashes of https://gitlab.winehq.org/wine/wine/-/merge_requests/5459 runs on 32bit Linux VMs. Also included some test fixes that were in https://gitlab.winehq.org/wine/wine/-/merge_requests/5459. -- v2: mfreadwrite/reader: Avoid leaking the stream transform service MFT. mfreadwrite/tests: Shutdown the test stream event queues on source shutdown. mfreadwrite/tests: Avoid using MFCreateMediaBufferFromMediaType. mfreadwrite/tests: Do not accept MFVideoFormat_RGB32 in the test transform. mf/tests: Fix printf format warning. https://gitlab.winehq.org/wine/wine/-/merge_requests/5463

1 8

[PATCH v5 0/3] MR5464: mf/tests: Check that D3D aware attribute has no effect on the topology.
by Rémi Bernon 28 May '24

28 May '24

Wine incorrectly inserts a sample copier. D3D awareness is handled per node, and each node will have their own sample allocator created from the D3D device manager provided by the session. -- v5: mf/tests: Test device manager handling in the topology loader. mf/tests: Test D3D awareness handling in the topology loader. include: Add MFTOPOLOGY_DXVA_MODE enum definition. https://gitlab.winehq.org/wine/wine/-/merge_requests/5464

2 8

[PATCH 0/3] MR5474: winhttp: Receive response timeout and connection caching.
by Paul Gofman (＠gofman) 28 May '24

28 May '24

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

3 5

[PATCH v2 0/2] MR2724: wined3d: Submit command buffers that are built for longer than 2 ms.
by Zebediah Figura (＠zfigura) 28 May '24

28 May '24

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. -- v2: wined3d: Submit command buffers that are built for longer than 2 ms. wined3d: Retrieve the VkCommandBuffer from wined3d_context_vk after executing RTV barriers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2724

7 15