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

[PATCH v3 0/7] MR5907: ntdll: Optimize NtQueryVirtualMemory(MemoryWorkingSetExInformation).
by Paul Gofman (＠gofman) 24 Jun '24

24 Jun '24

-- v3: ntdll: Buffer pagemap reads in fill_working_set_info(). ntdll: Fill range of output in fill_working_set_info(). https://gitlab.winehq.org/wine/wine/-/merge_requests/5907

3 8

[PATCH v10 0/1] MR5904: Improve color mode and paper source detection
by Ilia Docin (＠IDocin) 24 Jun '24

24 Jun '24

-- v10: sane.ds: Improve color mode and paper source detection https://gitlab.winehq.org/wine/wine/-/merge_requests/5904

3 3

[PATCH v9 0/3] MR5904: Improve color mode and paper source detection
by Ilia Docin (＠IDocin) 24 Jun '24

24 Jun '24

-- v9: Fix stringop-overread compiler error https://gitlab.winehq.org/wine/wine/-/merge_requests/5904

3 4

[PATCH v2 0/7] MR5907: ntdll: Optimize NtQueryVirtualMemory(MemoryWorkingSetExInformation).
by Paul Gofman (＠gofman) 24 Jun '24

24 Jun '24

-- v2: ntdll: Buffer pagemap reads in fill_working_set_info(). ntdll: Fill range of output in fill_working_set_info(). ntdll: Limit vprot scan range to the needed interval in get_working_set_ex(). ntdll: Iterate views instead of requested addresses in get_working_set_ex(). https://gitlab.winehq.org/wine/wine/-/merge_requests/5907

3 9

[PATCH 0/1] MR5910: sane.ds: Add SANE option settable flag support
by Ilia Docin (＠IDocin) 24 Jun '24

24 Jun '24

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

4 3

[PATCH v3 0/3] MR5685: Implement MarkupServices_ParseString
by Santino Mazza (＠tati1454) 24 Jun '24

24 Jun '24

-- v3: mshtml: Implement MarkupServices_ParseString. mshtml: Implement MarkupServices_CreateMarkupContainer. mshtml/tests: Test for IMarkupServices. https://gitlab.winehq.org/wine/wine/-/merge_requests/5685

3 4

[PATCH v4 0/1] MR5658: winevulkan: Make device memory wrapper available in callbacks.
by Arek Hiler (＠ivyl) 24 Jun '24

24 Jun '24

With [`VK_EXT_device_address_binding_report`](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_device_address_binding_report.html) we can get [debug_util](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/ht… callbacks used to track memory bindings. Since it's the host's implementation that starts the callback we have to be sure that we have a way of converting it to the client side's variant before it's added to the handle map - i.e. we don't know the host handle at that time yet. This is [used by vkd3d-proton](https://github.com/HansKristian-Work/vkd3d-proton/pull/1962). Requires Mesa with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28649. before (note the missing BIND for VkDevice which actually means `VkDeviceMemory`): ``` vkd3d-proton % VKD3D_TEST_FILTER=create_placed_resource_size VKD3D_CONFIG=fault VKD3D_DEBUG=trace ~/src/wine/build/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800100200000 || size 000000000019a000. trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800100200000 || size 000000000019a000. trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. :trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232285.553:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. ``` after: ``` % VKD3D_TEST_FILTER=create_placed_resource_size VKD3D_CONFIG=fault VKD3D_DEBUG=trace ~/src/wine/build/wine ./tests/d3d12.exe 2>&1 | grep vkd3d_address_binding_callback 232338.036:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.036:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkImage || VA ffff800100200000 || size 000000000019a000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkImage || VA ffff800100200000 || size 000000000019a000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkDevice || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: BIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkBuffer || VA ffff800100200000 || size 0000000001000000. 232338.037:0020:0024:trace:vkd3d-proton:vkd3d_address_binding_callback: UNBIND || VkDevice || VA ffff800100200000 || size 0000000001000000. ``` [The spec guarantees](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/v… the following: > An application can receive multiple callbacks if multiple VkDebugUtilsMessengerEXT objects are created. A callback will always be executed in the same thread as the originating Vulkan call. As of TLS I went with a suggestion from IRC: ``` <ivyl_> There's an issue with how we handle callbacks related to VK_EXT_debug_utils and VK_EXT_debug_report. In wine_vkAllocateMemory() we call device->funcs.p_vkAllocateMemory() which may execute callback. <ivyl_> At this point we still don't have handle mapping added because we don't know what host_memory handle will be. <ivyl_> AFAIU there's a spec guarantee that callback will be executed in the same thread as the call causing it, so I was thinking about maybe keeping `memory` in a tls (if enable_wrapper_list) and using that? <ivyl_> but that's I don't see any precedent of using thread local storage on the unix side <ivyl_> tls value would be short-lived in such case - only for the duration of the call to `device->funcs.p_vkAllocateMemory()` <jacekc_> we usually use teb on unix side, see ntuser_thread_info ``` -- v4: winevulkan: Make device memory wrapper available in callbacks. https://gitlab.winehq.org/wine/wine/-/merge_requests/5658

5 7

[PATCH v2 0/2] MR5918: Basic implementation of recorset functions.
by Alistair Leslie-Hughes (＠alesliehughes) 24 Jun '24

24 Jun '24

-- v2: msado15: Implement _Recordset get/put MaxRecords msado15: Implement _Recordset get/put CacheSize https://gitlab.winehq.org/wine/wine/-/merge_requests/5918

2 2

[PATCH 0/2] MR5918: Basic implementation of recorset functions.
by Alistair Leslie-Hughes (＠alesliehughes) 24 Jun '24

24 Jun '24

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

3 3

[PATCH 0/7] MR5912: win32u: Create a shared memory object for message queue and read active hooks bitmap from it.
by Rémi Bernon 24 Jun '24

24 Jun '24

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

2 9