August 2023 - Wine-gitlab - list.winehq.org

[PATCH 0/2] MR3695: wldp: add WldpGetLockdownPolicy stub
by Louis Lenders (＠xe) 31 Aug '23

31 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55501 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3695

3 4

[PATCH 0/7] MR320: vkd3d-shader/dxil: Implement DX instruction LoadInput.
by Conor McCarthy (＠cmccarthy) 31 Aug '23

31 Aug '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/320

3 13

Re: [PATCH v17 0/2] MR3504: ntdll: An implementation of SRWLOCK that closer matches Windows'.
by Yuxuan Shui (＠yshui) 31 Aug '23

31 Aug '23

On Thu Aug 31 12:35:40 2023 +0000, Yuxuan Shui wrote: > Another observation is current SRWLOCK is pretty unfair (again, in this > one test). So is the native SRWLOCK. I can make a small change to this MR which makes it less fair, but brings the performance on par with native (for this one test that I have). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43966

1 0

[PATCH 0/5] MR317: vkd3d-shader: Begin validating the generated IR.
by Giovanni Mascellani (＠giomasce) 31 Aug '23

31 Aug '23

The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR. Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317

3 9

Re: [PATCH v17 0/2] MR3504: ntdll: An implementation of SRWLOCK that closer matches Windows'.
by Yuxuan Shui (＠yshui) 31 Aug '23

31 Aug '23

On Thu Aug 31 12:26:04 2023 +0000, Yuxuan Shui wrote: > I see, in current version all threads Waits on the same Address, so the > address' futex queue is contended. Threads are spinning on > `queue->lock`, so there is a chance for the lock to be released and the > threads never actually call `futex` (in this synthetic test anyway). > Whereas with this MR threads are generally waiting on different > addresses, so they always enter futex. Another observation is current SRWLOCK is pretty unfair (again, in this one test). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43962

1 0

Re: [PATCH v17 0/2] MR3504: ntdll: An implementation of SRWLOCK that closer matches Windows'.
by Yuxuan Shui (＠yshui) 31 Aug '23

31 Aug '23

On Thu Aug 31 12:25:16 2023 +0000, Yuxuan Shui wrote: > oh my, native SRWLOCK is really really fast. Even when compared to the > current, no wait list version. > I noticed with exclusive locks, current SRWLOCK would show >100% CPU > usage. I think this means there are some spinning going on? I see, in current version all threads Waits on the same Address, so the address' futex queue is contended. Threads are spinning on `queue->lock`, so there is a chance for the lock to be released and the threads never actually call `futex` (in this synthetic test anyway). Whereas with this MR threads are generally waiting on different addresses, so they always enter futex. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43958

1 0

[PATCH v9 0/3] MR318: ci: Execute the tests, also on AMD.
by Giovanni Mascellani (＠giomasce) 31 Aug '23

31 Aug '23

Running the tests on AMD requires rebuilding the Docker image, unfortunately, so the pipelines for this MR won't work until the MR itself is accepted (and the image is regenerated). -- v9: ci: Briefly document the CI setup. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/318

3 4

Re: [PATCH v17 0/2] MR3504: ntdll: An implementation of SRWLOCK that closer matches Windows'.
by Yuxuan Shui (＠yshui) 31 Aug '23

31 Aug '23

oh my, native SRWLOCK is really really fast. Even when compared to the current, no wait list version. I noticed with exclusive locks, current SRWLOCK would show >100% CPU usage. I think this means there are some spinning going on? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43949

1 0

[PATCH v8 0/3] MR318: ci: Execute the tests, also on AMD.
by Giovanni Mascellani (＠giomasce) 31 Aug '23

31 Aug '23

Running the tests on AMD requires rebuilding the Docker image, unfortunately, so the pipelines for this MR won't work until the MR itself is accepted (and the image is regenerated). -- v8: ci: Briefly document the CI setup. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/318

2 3

[PATCH v5 0/10] MR3645: mshtml: Implement Cycle Collection for all mshtml objects (dispex), part 7.
by Gabriel Ivăncescu 31 Aug '23

31 Aug '23

-- v5: mshtml: Implement Cycle Collection for XMLHttpRequest. mshtml: Implement Cycle Collection for HTMLPerformanceTiming. mshtml: Move PerformanceTiming related fields to the window. mshtml: Move HTMLPerformanceNavigation related fields to the window. mshtml: Implement Cycle Collection for inner windows. mshtml: Get rid of NULL checks for the dispex vtbl. mshtml: Implement Cycle Collection for outer windows. mshtml: Implement Cycle Collection for HTMLLocation. mshtml: Separate the HTMLLocation from the outer window. mshtml: Actually traverse the object-specific edges. https://gitlab.winehq.org/wine/wine/-/merge_requests/3645

2 12