August 2023 - wine-gitlab

Re: [PATCH v10 0/3] MR318: ci: Execute the tests, also on AMD. - approved
by Alexandre Julliard (＠julliard) 31 Aug '23

31 Aug '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/318

1 0

[PATCH 0/6] MR3697: kernelbase: Fix FindFirstFile for masks only matching files with no extension.
by Paul Gofman (＠gofman) 31 Aug '23

31 Aug '23

Welcome to Princeland depends on that. Added tests show that NtQueryDirectoryFile mask handling is different from FindFirstFile (even though it doesn't quite match Windows too, the details are different, e. g., on Windows mask "*." will select file "ea" with FindFirstFile but not with NtQueryDirectoryFile). So the correct way is probably do the wildcards matching in kernelbase directly without relying on NtQueryDirectoryFile. Having files not apprearing in the output of FindFirstFile is not obvious on Windows as well as the mask matches generated short names and that might provide an unexpected output. However, the part with not returning the files with extension when mask requires so looks rather straightforward and depending on that is not probably supposed to semi-randomly break on Windows. While checking the tests before after the changes I was checking that besides not introducing new TODOs no test files are appearing in the missing part in todo tests (as starting to incorrectly missing some files in the output has an obvious regression potential). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3697

2 6

[PATCH 0/1] MR3694: d3dcompiler/tests: Avoid interpolation filters in test_samplers().
by Matteo Bruni (＠Mystral) 31 Aug '23

31 Aug '23

To avoid accuracy issues, specifically with the QXL driver. In preparation of the next vkd3d merge when these tests will start to work in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3694

3 6

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

31 Aug '23

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

2 3

[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

2025

2024

2023

2022

wine-gitlab August 2023