July 2023 - wine-gitlab

[PATCH 0/2] MR3319: Draft: Leave critical section before waiting for streaming thread.
by Santino Mazza (＠tati1454) 12 Jul '23

12 Jul '23

This is just a draft to receive feedback, I'm not sure how could I test this behavior, right now the test I wrote works but there are times where it doesn't enter into the deadlock. Also I'm not sure if leaving the critical section before waiting for the streaming thread is the correct way to solve the problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3319

3 3

[PATCH v5 0/8] MR3050: msvcrt: Switch to using snames for create_locinfo.
by Victor Hermann Chiletto (＠vitorhnn) 12 Jul '23

12 Jul '23

This MR attempts to bring Wine's handling of `setlocale` and `_create_locale` more in line with the behavior of native >= `msvcr110`. It does this by replacing the usage of the LCID based `GetLocaleInfo` with the sname based `GetLocaleInfoEx`. `GetLocaleInfo` doesn't support neutral locales, even on native, which causes problems with neutral Chinese locales like `zh-Hans` and `zh-Hant`. It also improves the accuracy of the internal `__lc_locale_name_func`, as tests indicate that it returns `LOCALE_SNAME`s instead of ISO 639 language names. Potential future improvements: * Modifying the generation of the `pclmap` and `pcumap` fields of `threadlocaleinfostruct` to work on WCHARs. * I've done some changes to `__thread_data` which make it not fully match native, I'll submit a follow up which fixes this. -- v5: msvcrt: Use GetLocaleInfoEx to compare locale info. msvcrt: Remap synonyms to snames. msvcrt: Simplify set_lc_locale_name. msvcrt: Skip exhaustive locale search with valid snames. msvcrt: Convert locale_to_LCID to snames. msvcrt: Use snames instead of LCIDs in create_locinfo. msvcr120/tests: Check ___lc_locale_name_func with neutral Chinese locales. msvcr110/tests: Add tests for new setlocale behaviors. https://gitlab.winehq.org/wine/wine/-/merge_requests/3050

4 12

[PATCH v42 0/7] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) 12 Jul '23

12 Jul '23

Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver. Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options: * Pass the Windows path to wineserver and do the conversion there. * This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons. * Obtain the current working directory of the requesting process and temporarily change directories to there. * This only handles relative paths and fails for absolute paths, UNC paths, etc. * Conditionally change directories based on whether the path is relative or not. * This is error-prone and wineserver does not have the requisite functions to do this cleanly. I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded. Abstract sockets are supported by this patch. -- v42: ws2_32/tests: Add test for AF_UNIX sockets fix. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/2786

2 7

Re: [PATCH v41 0/7] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) 12 Jul '23

12 Jul '23

On Wed Jul 12 18:13:28 2023 +0000, Zebediah Figura wrote: > I'm not particularly sure about patch 4/7 (opening and deleting Unix > sockets as files), but the socket parts of this look good to me now. I do agree that the file deletion code is a bit hacky, but a lot of the file handling code in wineserver depends on having a valid file descriptor, and we can't `open()` the socket file. This was the simplest way I could find to make socket file deletion work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_38815

1 0

[PATCH v2 0/1] MR253: vkd3d-shader/hlsl: Skip unallocated variables when looking for reservation conflicts.
by Zebediah Figura (＠zfigura) 12 Jul '23

12 Jul '23

-- v2: vkd3d-shader/hlsl: Skip unallocated variables when looking for reservation conflicts. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/253

3 2

[PATCH v3 0/5] MR273: vkd3d-shader: sm1 constants.
by Zebediah Figura (＠zfigura) 12 Jul '23

12 Jul '23

Most of the interesting part is the API (first patch); the rest is implementation. The basic idea is that we have predefined fixed numbers for the float, integer, and boolean constant arrays, and treat each of the three like a constant buffer. Implementation-wise, we lower sm1-style constant registers to sm4-style constant buffers and immediate constants, which are capable of expressing a strict superset of the same functionality. Note that use of immediate constants is *not* the way that wined3d currently handles DEF instructions, but rather those are uploaded via uniforms. Is there a reason for this? Relative addressing is not yet implemented. In theory it should be simple enough to either translate it directly, for external constants, or use sm4-style immediate constant buffers, for internal constants. There may be a snag if an application depends on relative addressing to cover a range of both internal and external constants; this surely would require manual assembly or an application bug, but we could implement it by copying to a temporary array using a private TEMP-like register type. -- Because API is easiest to review when there's a concrete user, I have functional patches hooking this up to wined3d, in the following branches: https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5 https://gitlab.winehq.org/zfigura/wine/-/commits/himavant_cb The vkd3d branch contains some extra commits necessary to compile basic shaders; I intend to submit these as soon as possible after the important API parts have been reviewed. I tested this patch series by building a mingw vkd3d tree with that branch, and running the shader runner through Wine, with a test that uses both internal and external constants: make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/writemask-assignop-0.shader_test I actually originally wrote the API without a user in mind, and later hooked up the implementation in Wine, and was surprised to find how straightforward it ended up being, so I think that speaks quite strongly in favour of this API. Granted, I had already written "wined3d: Store push constants in wined3d_buffers in struct wined3d_state." by that point, but that was something I anticipated needing for Wine anyway, without thinking of vkd3d. -- I actually originally did the implementation all in spirv.c, mostly because this was before we had infrastructure in place to do passes on the middle IR. I much prefer this version, it's quite centralized in one place and I think ends up being simpler than the spirv.c version anyway, but I can retrieve the spirv.c version if anyone wants to see it. That said, we may not want to lower to VKD3DSPR_CONSTBUFFER for GLSL without UBOs (but then again, we could also just emit VKD3DSPR_CONSTBUFFER registers as plain GLSL arrays). The actual declaration of flat constants is kept in spirv. I suppose the alternative here is to instead declare buffers from the reflection information and simply ignore dcl_constantbuffer. I submitted the patch as-is since it seemed simple enough and I didn't want to block this work further on rewriting that part, but we may want to rewrite it in the future regardless. ``` After the torchlight red on sweaty faces After the frosty silence in the gardens After the agony in stony places The shouting and the crying Prison and palace and reverberation Of thunder of spring over distant mountains ``` -- v3: vkd3d-shader/spirv: Emit variables for flat constant buffers. vkd3d-shader/ir: Normalise sm1-style constants. vkd3d-shader/ir: Move normalization code from spirv.c to ir.c. vkd3d-shader/d3dbc: Scan descriptors for constant register sets. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/273

2 6

[PATCH v2 0/5] MR273: vkd3d-shader: sm1 constants.
by Zebediah Figura (＠zfigura) 12 Jul '23

12 Jul '23

Most of the interesting part is the API (first patch); the rest is implementation. The basic idea is that we have predefined fixed numbers for the float, integer, and boolean constant arrays, and treat each of the three like a constant buffer. Implementation-wise, we lower sm1-style constant registers to sm4-style constant buffers and immediate constants, which are capable of expressing a strict superset of the same functionality. Note that use of immediate constants is *not* the way that wined3d currently handles DEF instructions, but rather those are uploaded via uniforms. Is there a reason for this? Relative addressing is not yet implemented. In theory it should be simple enough to either translate it directly, for external constants, or use sm4-style immediate constant buffers, for internal constants. There may be a snag if an application depends on relative addressing to cover a range of both internal and external constants; this surely would require manual assembly or an application bug, but we could implement it by copying to a temporary array using a private TEMP-like register type. -- Because API is easiest to review when there's a concrete user, I have functional patches hooking this up to wined3d, in the following branches: https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5 https://gitlab.winehq.org/zfigura/wine/-/commits/himavant_cb The vkd3d branch contains some extra commits necessary to compile basic shaders; I intend to submit these as soon as possible after the important API parts have been reviewed. I tested this patch series by building a mingw vkd3d tree with that branch, and running the shader runner through Wine, with a test that uses both internal and external constants: make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/writemask-assignop-0.shader_test I actually originally wrote the API without a user in mind, and later hooked up the implementation in Wine, and was surprised to find how straightforward it ended up being, so I think that speaks quite strongly in favour of this API. Granted, I had already written "wined3d: Store push constants in wined3d_buffers in struct wined3d_state." by that point, but that was something I anticipated needing for Wine anyway, without thinking of vkd3d. -- I actually originally did the implementation all in spirv.c, mostly because this was before we had infrastructure in place to do passes on the middle IR. I much prefer this version, it's quite centralized in one place and I think ends up being simpler than the spirv.c version anyway, but I can retrieve the spirv.c version if anyone wants to see it. That said, we may not want to lower to VKD3DSPR_CONSTBUFFER for GLSL without UBOs (but then again, we could also just emit VKD3DSPR_CONSTBUFFER registers as plain GLSL arrays). The actual declaration of flat constants is kept in spirv. I suppose the alternative here is to instead declare buffers from the reflection information and simply ignore dcl_constantbuffer. I submitted the patch as-is since it seemed simple enough and I didn't want to block this work further on rewriting that part, but we may want to rewrite it in the future regardless. ``` After the torchlight red on sweaty faces After the frosty silence in the gardens After the agony in stony places The shouting and the crying Prison and palace and reverberation Of thunder of spring over distant mountains ``` -- v2: vkd3d-shader/spirv: Emit variables for flat constant buffers. vkd3d-shader/ir: Normalise sm1-style constants. vkd3d-shader/ir: Move normalization code from spirv.c to ir.c. vkd3d-shader/d3dbc: Scan descriptors for constant register sets. include: Define an API for d3dbc constants. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/273

3 7

[PATCH v3 0/3] MR271: Draft: Introduce a GitLab pipeline for vkd3d
by Giovanni Mascellani (＠giomasce) 12 Jul '23

12 Jul '23

With this pipeline vkd3d automatically gets built on Linux (in an image based on Debian unstable), both in 32 and 64 bit mode. Both builds are tested with radv and llvmpipe. A number of caveats apply, though: * A number of tests currently fail in llvmpipe, so the llvmpipe jobs are marked as allowed to fail. Ideally we'll eventually fix our bugs and mark the llvmpipe ones in the tests, so that the CI tests completely pass and possible problems in the Vulkan driver are recorded at a better granularity (this is the reason why GitLab says that the pipeline is passed with warnings: the warnings are that there are jobs that failed, even if they were allowed to fail). * The runners provided by the GitLab instance don't have a GPU available, so I configured my own computer (equipped with an AMD Radeon RX 5700 RX) to provide a runner with access to the GPU. This setup is not currently satisfying: for me, because I use that computer for other things and I don't like having random code submitted to it (it is theoretically sandboxed, but sandboxes are not always bullet-proof, especially if they have access to a GPU); for the users, because my computer might be unavailable at any time. I'll work on a better solution. For the time being I intend the runner to only accept jobs from the master branch; once a better solution is implemented I'd like to run the pipeline for MRs too. * While the `Dockerfile` and related assets do not necessarily need to be available in this repository, given that the CI accesses the binary image from the Docker hub anyway, I think it's still valuable to have them, so others can improve them (and for sure improvement opportunities are nowhere near missing). However, other ways to make them available can be found, if for some reason it is not liked to have them in this repository (they are not pretty!). * One of the reason they are not pretty is that I have a custom hack to compile `widl` from the Wine sources without compiling (or installing from the distribution) the whole of Wine, in the interest of keeping the Docker image small (well, small-ish: Vulkan drivers, compilers and X libraries are not small anyway). * Again on the subject of the Docker image, I am currently putting the binary image in my own namespace on the Docker hub. Using the GitLab container registry in the namespace of the Wine project would probably be better, so that I am not a bottleneck in the future. * Even if we discount all the points above, this MR cannot be merged yet, because my runner is currently configured for my namespace only. I guess I need the intervention of a GitLab admin to fix that. However, I think there's already material enough for valuable feedback. -- v3: ci: Introduce a CI pipeline for GitLab. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271

4 6

[PATCH 0/3] MR3318: include: Update Kerberos related headers
by Maxim Karasev (＠mxkrsv) 12 Jul '23

12 Jul '23

Required to build KList example authorization program from Windows SDK examples. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3318

2 3

[PATCH 0/1] MR3288: gdiplus: Clip polygons before drawing them
by David Kahurani (＠kahurani) 12 Jul '23

12 Jul '23

Validate user data before passing it to PolyDraw. The program in the bug requests to draw figures outrageously outside the DC's region after presumably some uninitialized values happen as a result of a missing font. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41617 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3288

3 7

2025

2024

2023

2022

wine-gitlab July 2023