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
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
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
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
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/himavant5https://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
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/himavant5https://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
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
When handling an exception, NtContinue can be called from within the signal handler, in which case the raise(SIGUSR2) call ends up getting eaten and integer register context gets restored. Switch to the method used on X86 to avoid these issues.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3315
lParam being NULL is handled in win32u/defwnd.c so make sure to pass the NULL through rather than relying on the pointer always being valid since it may not be in this case.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3314
Some tests in gdiplus output hex-formatted data chunks, but it is very hard to read
EXAMPLE BEFORE FIX:
```
image.c:4831: Test marked todo: 16: data should match
image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 80i
mage.c:4837: 80image.c:4837: 80image.c:4837: 80image.c:4837: 80image.c:4837: 80image.c:4837: 40image.c:4837: 40im
age.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40ima
ge.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4838:
```
EXAMPLE AFTER FIX:
```
image.c:4802: Test marked todo: 16: data should match
image.c:4804: 40 40 40 40 40 40 80 80 80 80 80 80 40 40 40 40 40 40 40 40 40 40 40 40
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3313
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/himavant5https://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
```
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/273
This fixes SetWindowLongPtr on WoW64. On 32-bit, we have
```
#define SetWindowLongPtrA SetWindowLongA
#define SetWindowLongPtrW SetWindowLongW
```
meaning that on WoW64, all pointers passed would be padded with `0xffffffff` (because they are treated as LONG), and this is the cause of many of the failing WoW64 tests. This fixes that behavior. I'm not sure if this is the right place to fix it though.
--
v5: wow64win: Always use NtUserSetWindowLongPtr() for GWLP_HINSTANCE and GWLP_WNDPROC.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3294
This fixes SetWindowLongPtr on WoW64. On 32-bit, we have
```
#define SetWindowLongPtrA SetWindowLongA
#define SetWindowLongPtrW SetWindowLongW
```
meaning that on WoW64, all pointers passed would be padded with `0xffffffff` (because they are treated as LONG), and this is the cause of many of the failing WoW64 tests. This fixes that behavior. I'm not sure if this is the right place to fix it though.
--
v4: wow64win: Always use NtUserSetWindowLongPtr() for GWLP_HINSTANCE and GWLP_WNDPROC.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3294
In HttpSendRequestW and HttpSendRequestExW, if the header pointer is not
null but the length parameter is 0, the header length should be derived
from the string length instead.
In HttpSendRequestA and HttpSendRequestExA, on the same scenario, the
function should fail instead.
--
v3: wininet: Handle http headers correctly when length is 0
wininet/tests: Edge cases for header lengths in http requests
https://gitlab.winehq.org/wine/wine/-/merge_requests/3269
This fixes SetWindowLongPtr on WoW64. On 32-bit, we have
```
#define SetWindowLongPtrA SetWindowLongA
#define SetWindowLongPtrW SetWindowLongW
```
meaning that on WoW64, all pointers passed would be padded with `0xffffffff` (because they are treated as LONG), and this is the cause of many of the failing WoW64 tests. This fixes that behavior. I'm not sure if this is the right place to fix it though.
--
v3: wow64win: Always use NtUserSetWindowLongPtr() for GWLP_WNDPROC.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3294
Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type.
Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later.
--
v4: vkd3d-shader/spirv: Use enum vkd3d_data_type instead of vkd3d_shader_component_type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263
Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type.
Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later.
--
v3: vkd3d-shader/spirv: Use a helper function to check if a data type is floating point.
vkd3d-shader/spirv: Use vkd3d_spirv_get_op_constant() for 64-bit types.
vkd3d-shader/spirv: Use enum vkd3d_data_type instead of vkd3d_shader_component_type.
vkd3d-shader: Encode type info in enum vkd3d_data_type values.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263
Fix the issue of incorrect linkid calculation due to a lack of judgment on the current type.
Signed-off-by: Zhaoyi <zhaoyi(a)uniontech.com>
--
v12: comctl32/tests: Add a test case to get syslinkid.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3114
It can be unnecessary at best and unsupported at worst (e.g. no ARB_texture_multisample).
--
v2: wined3d: Don't force going through a texture when downloading from renderbuffers.
wined3d: Handle depth textures in texture2d_read_from_framebuffer().
wined3d: Rename wined3d_context_gl_apply_fbo_state_blit() function.
wined3d: Factor out a wined3d_context_gl_apply_blit_state_fb() function.
wined3d: Don't call wined3d_texture_load() from wined3d_context_gl_apply_blit_state().
wined3d: Don't bind the FBO to GL_READ_FRAMEBUFFER in wined3d_context_gl_apply_blit_state().
wined3d: Don't call wined3d_context_gl_apply_blit_state() from texture2d_read_from_framebuffer().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3211
IIRC you also mentioned that specifying a conflicting majority through modifiers results an a compile error (much like with pragmas). Can we have tests for that too, please?
Also, is there any reason not to add these tests to vkd3d?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3263#note_38726
Mainly promoting single object components to variables for SM 5.0's RDEF block and lowering combined samplers to separate sampler+texture objects for SM 4.
Following patches (including prepending uniform copies resource components within struct parameters) in:
https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6c
--
v4: vkd3d-shader/hlsl: Don't allocate all texture registers for synthetic separated samplers.
vkd3d-shader/hlsl: Lower combined samplers to separate sampler and texture objects for SM4.
vkd3d-shader/hlsl: Separate tracking of sampler_dim and usage for object components.
vkd3d-shader/hlsl: Introduce hlsl_new_synthetic_var_named().
vkd3d-shader/hlsl: Check is_uniform instead of HLSL_STORAGE_UNIFORM when validating object refs.
tests: Add lowering combined samplers tests.
vkd3d-shader/hlsl: Handle resource components individually for SM 5.0.
vkd3d-shader/tpf: Introduce struct extern_resource.
vkd3d-shader/hlsl: Allow derefs to provide the data_type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/209
This fixes SetWindowLongPtr on WoW64. On 32-bit, we have
```
#define SetWindowLongPtrA SetWindowLongA
#define SetWindowLongPtrW SetWindowLongW
```
meaning that on WoW64, all pointers passed would be padded with `0xffffffff` (because they are treated as LONG), and this is the cause of many of the failing WoW64 tests. This fixes that behavior. I'm not sure if this is the right place to fix it though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3294
--
v5: vkd3d-shader/dxil: Read function bodies.
vkd3d-shader/dxil: Read numeric constants.
vkd3d-shader/dxil: Read global function declarations.
vkd3d-shader/dxil: Validate the module format version.
vkd3d-shader/dxil: Read the value symbol table.
vkd3d-shader/dxil: Read the type table.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/259
Today, CreateTextServices() returns an Rich Edit object without row
start and end marks, which are expected to exist by many Rich Edit
operations as well as EM_* message handlers.
This leads to a crash when certain messages (e.g., EM_SCROLLCARET) are
sent to the Rich Edit object via ITextServices::TxSendMessage(), unless
ME_WrapMarkedParagraphs() has been called beforehand.
Fix this by calling wrap_marked_paras_dc() early in the initialization
process.
This is not a problem for windowed Rich Edit controls, which already
calls ME_WrapMarkedParagraphs() before the user or application starts
interacting with it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3208
Fix the issue of incorrect linkid calculation due to a lack of judgment on the current type.
Signed-off-by: Zhaoyi <zhaoyi(a)uniontech.com>
--
v11: comctl32/syslink: Check item type before increasing link ID in SYSLINK_LinkAtPt().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3114
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.
--
v2: ci: Introduce a CI pipeline for GitLab.
configure: Require widl >= 3.21.
vkd3d: Filter devices according to VKD3D_VULKAN_DEVICE_FILTER.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271
Inter-process invalidation is left unimplemented, but this covers the majority of cases that a JIT needs to be aware of in order to flush any caches on code changes.
Unsure if this is fine to merge without any user-code upstream, please do let me know if that's the case.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3287
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.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271
Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type.
Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later.
--
v2: vkd3d-shader/spirv: Use a helper function to check if a data type is floating point.
vkd3d-shader/spirv: Use vkd3d_spirv_get_op_constant() for 64-bit types.
vkd3d-shader/spirv: Use enum vkd3d_data_type instead of vkd3d_shader_component_type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263
This is needed for Direct Storage part of newer MS d3d12 SDK (which is shipped with the games) to work (in particular, fixes New World crash on start after recent game update).
QueryIoRingCapabilities() is present starting from Windows 11 only, and SDK still works on Win10, but Win10 doesn't provide api-ms-win-core-ioring-l1-1-0 apiset dll (while Wine does since commit 7d81575c680212f7bef7a7d7d11d2615ffde4c9a). SDK is fine if api-ms-win-core-ioring-l1-1-0 is absent but once it is present it expects at least QueryIoRingCapabilities to be present (and then gracefully handles error return from it).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3291
> It is indeed Wine-specific, but on Windows it isn't as much of a problem because AllocConsole gives you the same cmd you would use normally, while wineconsole is inferior to a normal terminal.
I think that what you're looking for is `AttachConsole`. Depending details of process hierarchy, something `if (!AttachConsole(ATTACH_PARENT_PROCESS)) AllocConsole()` instead of plain `AllocConsole` should do what you want both on Windows and Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3145#note_38575
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.
--
v39: 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.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
This also converts the opaque pointers passed across the PE->Unix interface to opaque types
represented as UINT64 which store the unix side pointer. This makes the thunking simpler and should
avoid anyone accidently dereferencing the unix pointer in the PE code.
This was tested with warcraft 3 (1.26, the last non-reforged release), and is consistent with the standard 32bit build. ~~But since movies on warcraft 3 are broken in standard 32bit builds I could only test that that the gstreamer graph gets built up similarly and not verify the video playback. Id appreciate if someone knew of a working exercise of the gstreamer code.~~ it works great, the issue with cinematics ended up being related to modesetting under xwayland, running with a virtual desktop in winecfg confirms playback working perfectly.
--
v10: winegstreamer: Implement Wow64 entrypoints in the Unix library.
winegstreamer: Replace ambiguously sized/aligned elements
winegstreamer: Replace pointers with handles in PE->Unix transition
https://gitlab.winehq.org/wine/wine/-/merge_requests/3075