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

[PATCH 0/5] MR177: vkd3d-shader/hlsl: Normalize bools when loading from uniforms or vertex input.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/177

5 13

[PATCH v10 0/13] MR148: vkd3d-shader/hlsl: Support semantics for array types.
by Francisco Casas (＠fcasas) May 1, 2023

May 1, 2023

This is required by https://bugs.winehq.org/show_bug.cgi?id=54660 . -- v10: vkd3d-shader/hlsl: Consider duplicated input semantic types equivalent in SM1. vkd3d-shader/hlsl: Handle possibly different types in input semantic var load. vkd3d-shader/hlsl: Error out when a semantic is used with incompatible types. vkd3d-shader/hlsl: Error out when an output semantic is used more than once. vkd3d-shader/hlsl: Support semantics for array types. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/148

5 17

[PATCH v5 0/3] MR188: vkd3d-shader/tpf: Add support for emitting sample_l instructions
by Ethan Lee (＠flibitijibibo) May 1, 2023

May 1, 2023

>From what I can tell, the recent work on SampleBias/SampleLevel did all of the work for us, we just need to take the same framework and include the case for the `sample_l` instruction. Tested with some shaders from the native Linux version of Little Racers STREET. -- v5: vkd3d-shader/tpf: For sample_l/sample_b, set lod swizzle to SCALAR. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188

4 7

[PATCH v2 0/4] MR2726: wine{alsa,coreaudio,oss,pulse}: Move SimpleAudioVolume into mmdevapi.
by Davide Beatrici (＠davidebeatrici) May 1, 2023

May 1, 2023

Please note that with this MR the following `TRACE()` calls are removed: - `"ALSA does not support volume control\n"` - `"OSS doesn't support setting volume\n"` - `"PulseAudio does not support session volume control\n"` Should I perhaps move them to the specific drivers' unixlib instead? -- v2: winepulse: Use mmdevapi's SimpleAudioVolume. wineoss: Use mmdevapi's SimpleAudioVolume. https://gitlab.winehq.org/wine/wine/-/merge_requests/2726

3 5

[PATCH 0/9] MR2719: winegstreamer: Cleanup media source streams and add synchronization.
by Rémi Bernon May 1, 2023

May 1, 2023

Mostly a refresh of https://gitlab.winehq.org/wine/wine/-/merge_requests/1278, with a bit of cleanup. More to come. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2719

3 11

[PATCH v8 0/4] MR2387: winegstreamer: Use stream format in stream_props_GetMediaType.
by Ziqing Hui (＠zhui) May 1, 2023

May 1, 2023

According to the tests in 23b72ad, when we are reading a compressed stream, the type returned by `stream_props_GetMediaType()` should reflect compressed format even if we finnally output uncomressed data. For example, if we use wmvcore reader to read a WMV3 stream and output RGB24, the format information returned by `stream_props_GetMediaType()` should be WMV3, not RGB24. -- v8: winegstreamer: Use codec format in stream_props_GetMediaType. https://gitlab.winehq.org/wine/wine/-/merge_requests/2387

3 6

[PATCH v4 0/1] MR180: vkd3d-shader/hlsl: Partially implement static expressions evaluation.
by Nikolay Sivov (＠nsivov) April 30, 2023

April 30, 2023

-- v4: vkd3d-shader/hlsl: Partially implement static expressions evaluation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/180

3 3

[PATCH 0/4] MR2726: wine{alsa,coreaudio,oss,pulse}: Move SimpleAudioVolume into mmdevapi.
by Davide Beatrici (＠davidebeatrici) April 29, 2023

April 29, 2023

Please note that with this MR the following `TRACE()` calls are removed: - `"ALSA does not support volume control\n"` - `"OSS doesn't support setting volume\n"` - `"PulseAudio does not support session volume control\n"` Should I perhaps move them to the specific drivers' unixlib instead? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2726

3 6

[PATCH v2 0/1] MR189: tests: Add a test for arrays with an expression as the index.
by Ethan Lee (＠flibitijibibo) April 29, 2023

April 29, 2023

See https://bugs.winehq.org/show_bug.cgi?id=54832 I'm starting to see this particular FIXME in quite a few games (Escape Goat 2, Murder Miners, and Little Racers STREET to name a few), and since I'm not sure how to fix this I figured I could at least provide a test for someone that knows more SM4 than me :P -- v2: tests: Add a test for arrays with an expression as the index. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/189

2 1

Re: [PATCH v3 0/1] MR499: server: Allow cancelling alerted asyncs.
by Jinoh Kang (＠iamahuman) April 29, 2023

April 29, 2023

On Sat Apr 29 14:54:15 2023 +0000, Jinoh Kang wrote: > To reduce complexity, I've tried refactoring the state management. > Currently, the async has the following two state flags that deal with > the state of the client that originally requested the async: > - `signaled`: indicates whether the async object is signaled; the client > may wait on the async handle before returning from the corresponding > wine system call. > - Valid transition: 0 -> 1. > - This flag is set if only if any of the following conditions are true: > - Given that `!async->blocking`, > - `async_wake_obj(async)` has been called when > `async->unknown_status = 0`, or > - `async_handoff(async, ...)` has been called with `get_error() != > STATUS_ALERTED && (async->pending || !NT_ERROR(get_error()) && > (get_error() != STATUS_PENDING || async->iosb->status != STATUS_PENDING)`. > - (Regardless of `async->blocking`) `async_set_result(async, status, > ...)` has been called with `async->terminated && (!async->alerted || > status != STATUS_PENDING)`. > - Note that this flag exhibits slightly different behavior depending > on `async->blocking`. > - If `async->blocking`, it tries to block the requestor until the > async operation has completed. > - If `!async->blocking`, it tries to signal as soon as the initial > status is known, _unless_ the wait handle is being closed, in which case > it doesn't bother to touch the flag at all. > - If signaled and a wait on the async object is satisfied, the > requestor function should have performed the synchronous completion > sequence (either directly or via APC\_ASYNC\_IO) before the wait is > satisfied, unless `async->pending`. > - `direct_result`: from Wine codebase, `a flag if we're passing result > directly from request instead of APC`. > - Valid transition: 1 -> 0 (after set to 1 from `create_request_async`). > - Whenever async state is settled, the flag is set if all of the > following conditions are true: > - The async was created via create_request_async(), and > - async_set_unknown_status() has not been called, and > - The async handle has never been waited on (wait consumes the > flag), and > - Any of: > - async_handoff() has not been called, or > - From async_handoff(), the async is terminated or alerted synchronously. > - The flag has the following effect: > - For each async_terminate() call, it will send APC_ASYNC_IO if and > only if !direct_result. > - For each async handle wait satisfaction, it will call > async_set_result() if and only if direct_result. > We can observe the following from above: > - The flags are defined in terms of what the flags *do* rather than what > the value of the flags *mean*. It doesn't help that the transitions for > each flag are quite scattered and sparse. > - Their behaviors are dependent on the client-side async implementation, > so reasoning about them requires verifying how the requestor side behaves. > - Depending on other part of the async object state, one or more flags > may be left unobserved and thus ignored, effectivly becoming a "don't > care" bit. > This increases complexity and hinders maintenance in my opinion. In > particular, it's difficult to determine precisely *when* the flag is or > should be set or unset. > I'd propose that the constituent conditions of each flag be refactored > into separate state variables first. Paradoxically, it may even help > combine two or more binary flags into an enum as the semantics become > more simpler. Independent of above, I'm thinking about introducing a new `completed` flag and replacing `terminated` with `completed || alerted`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/499#note_31580

1 0