September 2022 - wine-gitlab

[PATCH v6 0/4] MR852: ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional pread.
by Witold Baryluk (＠baryluk) 15 Sep '22

15 Sep '22

Apex Legends game periodically (every 30 seconds) calls this function with up to 22k virtual addresses. All but 1 of them is valid. Due to amount of queries addresses, and cost of seek+read, this causes this function to take up to about 50ms. So framerate drops from ~150 FPS to 20FPS for about a second. As far as I can see, returning 0 entries from this function, still makes Apex Legend work. But keep code correct, and optimise it by: 1. Opening pagemap file once, and never closing it. This eliminates repeated fopen/fseek/fread/fclose sequences, which helps even in queries with small amount of virtual addresses. 2. Using pread, instead of seek+read. 3. Only performing pagemap read when the address is valid. Future work might recognize continues pages in the query, and perform a batch read of multiple pagemap entries, instead one page at a time, but for now it is not necassary. This change get_working_set_ex peek wall clock runtime from 57ms to 0.29ms. Tested on Linux, but similar change done for the BSD part. `Signed-off-by: Witold Baryluk <witold.baryluk(a)gmail.com>` -- v6: ntdll: Keep pagemap file open after first use of NtQueryVirtualMemory(MemoryWorkingSetExInformation) ntdll: Use pread in NtQueryVirtualMemory(MemoryWorkingSetExInformation) https://gitlab.winehq.org/wine/wine/-/merge_requests/852

2 6

[PATCH v5 0/4] MR852: ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional pread.
by Witold Baryluk (＠baryluk) 15 Sep '22

15 Sep '22

Apex Legends game periodically (every 30 seconds) calls this function with up to 22k virtual addresses. All but 1 of them is valid. Due to amount of queries addresses, and cost of seek+read, this causes this function to take up to about 50ms. So framerate drops from ~150 FPS to 20FPS for about a second. As far as I can see, returning 0 entries from this function, still makes Apex Legend work. But keep code correct, and optimise it by: 1. Opening pagemap file once, and never closing it. This eliminates repeated fopen/fseek/fread/fclose sequences, which helps even in queries with small amount of virtual addresses. 2. Using pread, instead of seek+read. 3. Only performing pagemap read when the address is valid. Future work might recognize continues pages in the query, and perform a batch read of multiple pagemap entries, instead one page at a time, but for now it is not necassary. This change get_working_set_ex peek wall clock runtime from 57ms to 0.29ms. Tested on Linux, but similar change done for the BSD part. `Signed-off-by: Witold Baryluk <witold.baryluk(a)gmail.com>` -- v5: ntdll: Keep pagemap file open after first use of NtQueryVirtualMemory(MemoryWorkingSetExInformation) https://gitlab.winehq.org/wine/wine/-/merge_requests/852

3 5

[PATCH v4 0/4] MR852: ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional pread.
by Witold Baryluk (＠baryluk) 15 Sep '22

15 Sep '22

Apex Legends game periodically (every 30 seconds) calls this function with up to 22k virtual addresses. All but 1 of them is valid. Due to amount of queries addresses, and cost of seek+read, this causes this function to take up to about 50ms. So framerate drops from ~150 FPS to 20FPS for about a second. As far as I can see, returning 0 entries from this function, still makes Apex Legend work. But keep code correct, and optimise it by: 1. Opening pagemap file once, and never closing it. This eliminates repeated fopen/fseek/fread/fclose sequences, which helps even in queries with small amount of virtual addresses. 2. Using pread, instead of seek+read. 3. Only performing pagemap read when the address is valid. Future work might recognize continues pages in the query, and perform a batch read of multiple pagemap entries, instead one page at a time, but for now it is not necassary. This change get_working_set_ex peek wall clock runtime from 57ms to 0.29ms. Tested on Linux, but similar change done for the BSD part. `Signed-off-by: Witold Baryluk <witold.baryluk(a)gmail.com>` -- v4: ntdll: Keep pagemap file open after first use of NtQueryVirtualMemory(MemoryWorkingSetExInformation) ntdll: Use pread in NtQueryVirtualMemory(MemoryWorkingSetExInformation) ntdll: Do not use hardcoded page shift in NtQueryVirtualMemory(MemoryWorkingSetExInformation) ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional page check https://gitlab.winehq.org/wine/wine/-/merge_requests/852

3 5

[PATCH v3 0/1] MR852: ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional pread.
by Witold Baryluk (＠baryluk) 15 Sep '22

15 Sep '22

Apex Legends game periodically (every 30 seconds) calls this function with up to 22k virtual addresses. All but 1 of them is valid. Due to amount of queries addresses, and cost of seek+read, this causes this function to take up to about 50ms. So framerate drops from ~150 FPS to 20FPS for about a second. As far as I can see, returning 0 entries from this function, still makes Apex Legend work. But keep code correct, and optimise it by: 1. Opening pagemap file once, and never closing it. This eliminates repeated fopen/fseek/fread/fclose sequences, which helps even in queries with small amount of virtual addresses. 2. Using pread, instead of seek+read. 3. Only performing pagemap read when the address is valid. Future work might recognize continues pages in the query, and perform a batch read of multiple pagemap entries, instead one page at a time, but for now it is not necassary. This change get_working_set_ex peek wall clock runtime from 57ms to 0.29ms. Tested on Linux, but similar change done for the BSD part. Signed-off-by: Witold Baryluk's avatarWitold Baryluk <witold.baryluk(a)gmail.com> -- v3: ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional pread. https://gitlab.winehq.org/wine/wine/-/merge_requests/852

2 1

[PATCH 0/1] MR863: wininet/tests: Don't send two HTTP responses for a single request in server_thread.
by Jacek Caban (＠jacek) 15 Sep '22

15 Sep '22

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

2 1

[PATCH v2 0/6] MR846: uiautomationcore: Implement basic HWND based HUIANODE behavior. (v2)
by Connor McAdams (＠cmcadams) 15 Sep '22

15 Sep '22

Changes since prior MR: - Check if HWND is valid after sending `WM_GETOBJECT` and getting a 0 return value. - Block on thread calling `UiaNodeFromHandle()` rather than the marshaling thread. - Squash `IWineUiaNode::get_prop_val` commit into commit where it is actually used. -- v2: uiautomationcore: Add tests for UiaNodeFromHandle. uiautomationcore: Create UI Automation client thread. uiautomationcore: Implement UiaNodeFromHandle. uiautomationcore: Shutdown provider thread when all returned nodes are released. uiautomationcore: Increment module reference count when starting provider thread. uiautomationcore: Implement UiaReturnRawElementProvider. https://gitlab.winehq.org/wine/wine/-/merge_requests/846

2 7

[PATCH 0/6] MR846: uiautomationcore: Implement basic HWND based HUIANODE behavior. (v2)
by Connor McAdams (＠cmcadams) 15 Sep '22

15 Sep '22

Changes since prior MR: - Check if HWND is valid after sending `WM_GETOBJECT` and getting a 0 return value. - Block on thread calling `UiaNodeFromHandle()` rather than the marshaling thread. - Squash `IWineUiaNode::get_prop_val` commit into commit where it is actually used. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/846

3 15

Re: [PATCH v2 0/2] MR827: winusb: Add WinUsb_Free stub. - approved
by Huw Davies (＠huw) 15 Sep '22

15 Sep '22

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/827

1 0

Re: [PATCH v2 0/2] MR827: winusb: Add WinUsb_Free stub.
by Huw Davies (＠huw) 15 Sep '22

15 Sep '22

Looks like the app calls `WinUsb_Free(NULL)` on startup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/827#note_8508

1 0

[PATCH 0/1] MR854: winevulkan: Update to VK spec version 1.3.228.
by Georg Lehmann (＠DadSchoorse) 15 Sep '22

15 Sep '22

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

2 1

2025

2024

2023

2022

wine-gitlab September 2022