April 2024 - Wine-GitLab - list.winehq.org

[PATCH v5 0/10] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) April 9, 2024

April 9, 2024

I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally. As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata. A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with. Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators. -- v5: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs. vkd3d-shader/hlsl: Store state block on pass variables. vkd3d-shader/hlsl: Parse list of state blocks. vkd3d-shader/hlsl: Introduce hlsl_ir_stateblock_constant. vkd3d-shader/hlsl: Parse and store state blocks on variables. tests: Add tests for "compile" and CompileShader() syntax. tests: Add tests for fxgroup syntax. tests: Test function call syntax for state blocks. tests: Add more state block syntax tests. vkd3d-shader/hlsl: Also call dce before lowering deref paths. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739

5 14

[PATCH 0/3] MR5469: d2d1/effect: Zero value buffer on size or type mismatch.
by Nikolay Sivov (＠nsivov) April 9, 2024

April 9, 2024

Found this after seeing test crashes caused by writing to adjacent stack memory, corrupting it. Happened with "size + 1" tests. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5469

3 4

[PATCH v14 0/3] MR734: vkd3d-shader/dxil: SamplePosition and SampleCount.
by Conor McCarthy (＠cmccarthy) April 9, 2024

April 9, 2024

-- v14: vkd3d-shader/dxil: Implement DX intrinsic RenderTargetGetSampleCount. vkd3d-shader/dxil: Implement DX intrinsics Texture2DMSGetSamplePosition and RenderTargetGetSamplePosition. tests/hlsl: Add tests for GetSamplePosition() and GetSampleCount(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/734

2 3

[PATCH v13 0/3] MR734: vkd3d-shader/dxil: SamplePosition and SampleCount.
by Conor McCarthy (＠cmccarthy) April 9, 2024

April 9, 2024

-- v13: vkd3d-shader/dxil: Implement DX intrinsic RenderTargetGetSampleCount. vkd3d-shader/dxil: Implement DX intrinsics Texture2DMSGetSamplePosition and RenderTargetGetSamplePosition. tests/hlsl: Add tests for GetSamplePosition() and GetSampleCount(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/734

2 3

[PATCH v12 0/3] MR734: vkd3d-shader/dxil: SamplePosition and SampleCount.
by Conor McCarthy (＠cmccarthy) April 9, 2024

April 9, 2024

-- v12: vkd3d-shader/dxil: Implement DX intrinsic RenderTargetGetSampleCount. vkd3d-shader/dxil: Implement DX intrinsics Texture2DMSGetSamplePosition and RenderTargetGetSamplePosition. tests/hlsl: Add tests for GetSamplePosition() and GetSampleCount(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/734

2 3

[PATCH v4 0/1] MR3908: wineserver: Report non-zero exit code for abnormal process termination
by Adam Rehn (＠adamrehn) April 9, 2024

April 9, 2024

**Overview:** Wine currently reports an exit code of zero for processes that terminate due to either of the following conditions: - The Linux process that represents the Windows process receives a signal such as `SIGKILL` (e.g. due to a user manually killing the process, or the Linux OOM killer targeting the process due to memory pressure) - The process fails to start because the image is a 32-bit executable and Wine has only been built with 64-bit support Both of these scenarios represent failures, and so a non-zero exit code is appropriate. This patch ensures that an exit code of 1 is reported for these abnormal process termination edge cases. **Underlying cause:** The following logic flow occurs in the Wine server for typical process termination: 1. When a `process` object is created by the Wine server, its `exit_code` field is [set to an initial value](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.… of `STILL_ACTIVE`, and the `exit_code` field in each of its corresponding `thread` objects is [set to a default value of zero](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/thread.c?…. 2. When a client process terminates, it sends a `terminate_process` protocol request to the server, and the handler [passes the specified exit code](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c… to the `terminate_process()` function. This function sets the `is_terminating` field of the process object [to a value of 1](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c?re…, and if the exit code is non-zero then it also [copies its value to each of the thread objects](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/proces… for the process. 3. The client process closes the pipe that it had been using to communicate with the server. 4. The server [detects the pipe close event](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.… and calls the `kill_process()` function, specifying a value of zero for the `violent_death` parameter. 5. The logic in the `kill_process()` function identifies this as a [normal termination on pipe close](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.…, and then subsequently calls the `kill_thread()` function to [kill each of the threads for the process](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/proces…. 6. The `kill_thread()` function [then calls](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/thread.c… `remove_process_thread()`, which [copies the exit code from the last thread object](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process… to the `exit_code` field of the process object. 7. The final value of the `exit_code` field is [reported when responding](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/pro… to `get_process_info` protocol requests, [as sent by](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/dlls/ntdll/unix/pr… `NtQueryInformationProcess()`. The abnormal process termination scenarios listed earlier will skip the `terminate_process` protocol request and immediately close the pipe. As a result, the `is_terminating` field of the process object will retain its default value of zero, and the `exit_code` field of each thread for the process will also remain at the default value of zero. Since the logic in `process_poll_event()` always treats a pipe close event as a non-violent termination, `remove_process_thread()` will simply copy the exit code value of zero from the last thread into the process object, and this will then be reported when querying the process exit code. **Fix details:** The fix modifies `process_poll_event()` to check the value of the `is_terminating` field of the process object, and to treat a pipe close event as a violent termination if the value of the field is zero. This triggers the alternative code path in `kill_process()` that calls `terminate_process()` and [specifies an exit code value of 1](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c?re…, which is copied to the thread objects and subsequently to the process object. In my testing, only the abnormal process termination scenarios listed above result in the value of the `is_terminating` field being zero when the pipe is closed. In all other scenarios, I have observed the value to be 1 when the pipe close event is detected. Non-abnormal scenarios tested include ordinary process completion with both zero and non-zero exit codes, crashes in Windows processes due to unhandled exceptions, and ending processes via the Wine implementation of Task Manager. -- v4: wineserver: Report non-zero exit code for abnormal process termination https://gitlab.winehq.org/wine/wine/-/merge_requests/3908

3 2

[PATCH v22 0/5] MR564: vkd3d-shader/ir: Transform clip/cull signature elements into an array.
by Conor McCarthy (＠cmccarthy) April 9, 2024

April 9, 2024

-- v22: tests/d3d12: Test multiple clip distance inputs in test_clip_distance(). tests/d3d12: Use five clip distances for the multiple test in test_clip_distance(). vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays. vkd3d-shader/ir: Transform clip/cull inputs into an array. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564

2 6

Re: [PATCH v3 0/1] MR761: tests/shader_runner: Report compilation errors on the block's starting line.
by Francisco Casas (＠fcasas) April 8, 2024

April 8, 2024

> This seems a little fragile. I don't think it is that fragile, currently we handle directives in 3 points in run_shader_tests(): 1. The first switch, where we detect that we stopped reading the block because a new block starts or the file ended. 2. The reading of the tags at the beginning of new blocks. 3. The reading of individual lines using a second switch. We don't need to call update_line_number_context() in 1, and we always have to call it in 2 so we don't have to worry about forgetting to do so we add new functionalities. It is only in 3 that we have to remember to call update_line_number_context() for the switch cases when we want to update the line number context for each line instead of presenting it at the beginning of the block, but even if we forget, the error will be reported at the beginning of the block because of 2. > Could we just track the starting line for things touching "shader_source" and then setup/restore the test context in e.g. compile_shader()? Here is a patch for that proposal (how I see it), but I find it more complex. [0001-tests-shader-runner-Report-compilation-errors-on-the.patch](/uploads/02a5639e5c17c001d23e1d89105c949b/0001-tests-shader-runner-Report-compilation-errors-on-the.patch) -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/761#note_67306

1 0

[PATCH 0/2] MR5473: wow64: Mind generic xstate in a couple of missed places.
by Paul Gofman (＠gofman) April 8, 2024

April 8, 2024

Fixes some wow64 mode regressions introduced by commit 29c73ee17335b30f3f49c8b3562742c6a35b482c ("ntdll: Support more xstate features."). That is actually covered by existing ntdll/tests/exception but there are a couple of tests (related to gs override) which crash those tests. Just in case, attaching an ad-hoc patch which comments out those and let the rest run (and succeed here in wow64 mode with these patches). Properly skipping those probably require Wine check I am afraid. [test.patch](/uploads/9db61a514f4242add75e96cb9493e8c0/test.patch) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5473

2 2

[PATCH 0/1] MR5472: winecoreaudio: Correctly handle devices whose UID contains non-ASCII characters.
by Brendan Shanks (＠bshanks) April 8, 2024

April 8, 2024

This should fix audio issues for users with certain USB audio devices (possibly including the Creative Pebble V3 and RØDECaster Pro II). The Core Audio UID can contain non-ASCII characters and is converted to UTF-8 by `unix_get_endpoint_ids`. But we were using `CFStringGetLength` to calculate the resulting size, which returns the length in UTF-16 code pairs. This resulted in any UIDs containing non-ASCII characters being truncated, `dev_id_from_device` later failing, and audio not working. Instead use `CFStringGetBytes` to calculate the resulting UTF-8 size, and to do the conversion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5472

2 1