August 2023 - wine-gitlab

[PATCH 0/1] MR321: vkd3d-shader/hlsl: Implement intrinsic tan.
by Petrichor Park (＠petrathekat) 31 Aug '23

31 Aug '23

Now that we can write HLSL intrinsics in HLSL, cleaning up missing functions becomes much easier. This commit also extends the trigonometry tests a little bit to make sure that tan works right. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/321

3 2

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

31 Aug '23

On Thu Aug 31 13:00:04 2023 +0000, Yuxuan Shui wrote: > 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). That's kind of surprising; win32 futexes are fair and we're using them internally. Why aren't our SRW locks fair? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_43978

1 0

[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

2025

2024

2023

2022

wine-gitlab August 2023