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

[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

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

April 29, 2023

On Tue Apr 18 19:25:54 2023 +0000, Zebediah Figura wrote: > > I don't think so. `async_terminate()` is currently no-op if the async > has already been terminated with a status other than `STATUS_ALERTED`, > and the patch maintains this invariant. > Right, that's the bit I failed to think through. > > It is possible to introduce a new boolean flag, but the flag cannot > replace `terminate_status`. `terminate_status` can be any arbitrary > value passed to the third parameter of `async_set_timeout`. > Ah, and I missed that that was a possibility, although, in my defense, > it's not stated in the patch subject either. I.e. this patch doesn't > just fix the race where an alerted async is canceled, it also fixes the > similar race where it times out. > So yes, I think the patch makes sense as is. Maybe a comment to yet > again overdocument asyncs wouldn't hurt? I easily see myself looking at > code like this and having to ask myself, "when exactly is > terminate_status set?" and the answer is "if (and only if?) the async is > canceled or times out while it's alerted", which is nice to have > documented and not have to puzzle through later. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/499#note_31579

1 0

[PATCH 0/1] MR2330: xmllite/writer: implement prefix autogeneration
by David Kahurani (＠kahurani) April 29, 2023

April 29, 2023

Looks good to me but would love some opinion(s) Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2330

3 7

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

April 29, 2023

Davide Beatrici (@davidebeatrici) commented about dlls/mmdevapi/session.c: > +#include <winternl.h> > + > +#include <wine/debug.h> > +#include <wine/unixlib.h> > + > +#include "mmdevdrv.h" > +#include "unixlib.h" > + > +#define NULL_PTR_ERR MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, RPC_X_NULL_REF_POINTER) > + > +WINE_DEFAULT_DEBUG_CHANNEL(mmdevapi); > + > +extern void sessions_lock(void) DECLSPEC_HIDDEN; > +extern void sessions_unlock(void) DECLSPEC_HIDDEN; > + > +extern const IAudioClient3Vtbl AudioClient3_Vtbl; Unused. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2669#note_31574

1 0

[PATCH 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 -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/189

2 1

Re: [PATCH v4 0/2] MR188: vkd3d-shader/tpf: Add support for emitting sample_l instructions
by Francisco Casas (＠fcasas) April 28, 2023

April 28, 2023

I just realized one more thing. I think we are not properly following the specification for both sample_l and sample_b. In the **Restrictions** section of the documentation for sample_b it is mentioned that the last src register must use a single component selector if it is not a scalar immediate. This "select_component" is also ilustrated in the sample_l format: ``` sample_l[_aoffimmi(u,v,w)] dest[.mask], srcAddress[.swizzle], srcResource[.swizzle], srcSampler, srcLOD.select_component ``` Currently, we are not respecting that since sm4_src_from_node() sets ``` src->swizzle_type = VKD3D_SM4_SWIZZLE_VEC4; ``` by default. It should be VKD3D_SM4_SWIZZLE_SCALAR in this case. If I am not mistaken, a simple: ``` instr.srcs[3].swizzle_type = VKD3D_SM4_SWIZZLE_SCALAR; ``` after calling sm4_src_from_node() should do. The disassembly should show a single component in the swizzle of the last src register. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188#note_31568

1 0

Re: [PATCH v4 0/2] MR188: vkd3d-shader/tpf: Add support for emitting sample_l instructions
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

On Fri Apr 28 21:50:24 2023 +0000, Francisco Casas wrote: > Currently, there doesn't exist a `[test todo]` Section for the > shader_runner. > This only seems to work (in this incomplete stage) because the > shader_runner is handling the section the same as the previous one, > `[pixel shader todo]`. > The proper way to write this part is: > ``` > [test] > todo draw quad > todo probe all rgba (0.25, 0, 0.25, 0) > ``` > and remove the `todo`s in the next commit. Done! -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188#note_31566

1 0

[PATCH v3 0/2] MR188: vkd3d-shader/tpf: Add support for emitting sample_l instructions
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 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. -- v3: vkd3d-shader/tpf: Add support for emitting sample_l instructions tests: Add a test for SampleLevel() function. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188

3 4

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

April 28, 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. -- v2: vkd3d-shader/tpf: Add support for emitting sample_l instructions https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188

2 2

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

April 28, 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. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188

2 1

[PATCH v6 0/2] MR184: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v6: tests: Add a basic compilation test for SampleGrad() method. vkd3d-shader/hlsl: Add support for SampleGrad() method https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

2 2

[PATCH v11 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

This replicates what seems to be happening when using sign() with shader model 3, which is roughly... ``` int pos = (int) (x > 0); int neg = -((int) (x < 0)); int result = pos + neg; ``` Fixes https://bugs.winehq.org/show_bug.cgi?id=54826 -- v11: tests: Add tests for sign() intrinsic. vkd3d-shader/hlsl: Add support for sign() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178

2 2

Re: [PATCH v7 0/2] MR179: vkd3d-shader/hlsl: Add support for ddx(), ddy() intrinsics.
by Zebediah Figura (＠zfigura) April 28, 2023

April 28, 2023

On Fri Apr 28 14:26:01 2023 +0000, Ethan Lee wrote: > Understood, test has been pushed! 40 isn't that bad, no. Our trigonometry tests do far worse. I'm not particularly surprised that derivatives aren't very accurate anyway. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/179#note_31550

1 0

Re: [PATCH v4 0/4] MR2682: uiautomationcore: Focused element retrieval, and a deadlock fix. - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

Re: [PATCH v2 0/1] MR2720: wined3d: Add a comment about mismatched samplers. - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

Re: [PATCH v2 0/4] MR2721: gdi/wineps: Add support for implicitly calling StartPage and for EMRI_DEVMODE spool file record - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

Re: [PATCH v14 0/4] MR2669: wine{alsa,coreaudio,oss,pulse}: Move AudioSessionControl into mmdevapi. - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

Re: [PATCH v7 0/2] MR161: vkd3d-shader/hlsl: Implement D3DCOLORtoUBYTE4(). - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

Re: [PATCH v2 0/2] MR185: vkd3d: Fix descriptor write issues. - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

Re: [PATCH v7 0/2] MR179: vkd3d-shader/hlsl: Add support for ddx(), ddy() intrinsics. - approved
by Alexandre Julliard (＠julliard) April 28, 2023

April 28, 2023

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

1 0

[PATCH v3 0/4] MR2682: uiautomationcore: Focused element retrieval, and a deadlock fix.
by Connor McAdams (＠cmcadams) April 28, 2023

April 28, 2023

-- v3: uiautomationcore: Retrieve runtime ID on UiaReturnRawElementProvider thread to prevent a deadlock. uiautomationcore: Implement IUIAutomation::GetFocusedElement{BuildCacheRequest}. uiautomationcore: Implement UiaNodeFromFocus. https://gitlab.winehq.org/wine/wine/-/merge_requests/2682

3 5

[PATCH v2 0/4] MR2682: uiautomationcore: Focused element retrieval, and a deadlock fix.
by Connor McAdams (＠cmcadams) April 28, 2023

April 28, 2023

-- v2: uiautomationcore: Retrieve runtime ID on UiaReturnRawElementProvider thread to prevent a deadlock. uiautomationcore: Implement IUIAutomation::GetFocusedElement{BuildCacheRequest}. uiautomationcore: Implement UiaNodeFromFocus. uiautomationcore: Add UiaNodeFromFocus stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2682

3 8

[PATCH 0/1] MR2720: wined3d: Add a comment about mismatched samplers.
by Paul Gofman (＠gofman) April 28, 2023

April 28, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2720

4 3

[PATCH 0/7] MR2712: winewayland.drv: part 3: Handle dynamic wl_output events
by Alexandros Frantzis (＠afrantzis) April 28, 2023

April 28, 2023

This MR introduces the driver mechanisms to handle dynamic events from the Wayland compositor, using wl_output events as the guiding use case (i.e., we want to update the win32u display settings when the host settings change). In this design we create a dedicated thread to read and dispatch Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works. We use the aforementioned mechanisms to queue win32u display device updates to the desktop window thread. Since there are many pieces that need to fall into place, this MR gradually reaches the final design: 1. We first introduce the dedicated read/dispatch thread and handle events (and also display device updates if in the desktop process) in that thread. 2. We ensure access to Wayland output information is thread-safe and consistent (since in step 3 we will need to access it from a different thread). 3. We finally introduce per-thread internal event queues and, if we are in the desktop process, queue the display device update to the desktop window thread internal event queue. Note that the main portion of the wl_output event code is still handled in the dedicated read/dispatch thread. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

3 12

[PATCH v4 0/7] MR181: vkd3d-shader: Normalise signatures and input/output registers to the Shader Model 6 pattern.
by Conor McCarthy (＠cmccarthy) April 28, 2023

April 28, 2023

-- v4: vkd3d-shader: Add source information to normaliser errors and warnings. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/181

2 8

[PATCH v3 0/6] MR181: vkd3d-shader: Normalise signatures and input/output registers to the Shader Model 6 pattern.
by Conor McCarthy (＠cmccarthy) April 28, 2023

April 28, 2023

-- v3: vkd3d-shader/ir: Normalise signatures and input/output registers to the Shader Model 6 pattern. vkd3d-shader/tpf: Fail parsing if an input/output parameter order is > 2. tests/d3d12: Test register relative addressing in vertex and pixel shaders. vkd3d-shader: Introduce an internal sm6 signature structure. vkd3d-shader/tpf: Return an error from vkd3d_shader_sm4_parser_create() if the parser failed. vkd3d-shader/d3dbc: Return an error from vkd3d_shader_sm1_parser_create() if the parser failed. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/181

2 6

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

April 28, 2023

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

4 3

[PATCH v2 0/4] MR181: vkd3d-shader: Normalise signatures and input/output registers to the Shader Model 6 pattern.
by Conor McCarthy (＠cmccarthy) April 28, 2023

April 28, 2023

-- v2: vkd3d-shader/ir: Normalise signatures and input/output registers to the Shader Model 6 pattern. vkd3d-shader/tpf: Fail parsing if an input/output parameter order is > 2. tests/d3d12: Test register relative addressing in vertex and pixel shaders. vkd3d-shader: Introduce an internal sm6 signature structure. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/181

2 4

[PATCH v5 0/2] MR184: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v5: tests: Add a basic compilation test for SampleGrad() method. vkd3d-shader/hlsl: Add support for SampleGrad() method https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

2 4

[PATCH v6 0/2] MR179: vkd3d-shader/hlsl: Add support for ddx(), ddy() intrinsics.
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

SPIR-V already handled DSX/DSY, so only D3DBC/TPF needed new case blocks. You'll notice that there's no test for this one - in addition to being a pretty straightforward translation for all possible formats, this feature uses the render target width/height and I wasn't sure if there was a good way to ensure that the test would always make sense. Instead, I did the test manually, and it's what you'd expect (EDIT: Previously the test used a uniform which always optimized to 0, new test uses VPOS instead): HLSL: ``` float4 main(float4 pos : sv_position) : sv_target { float4 x = ddx(pos.x); float4 y = ddy(pos.y); return x + y; } ``` D3DBC: ``` ps_3_0 dcl_position0 vPos mov r0.xyzw, vPos.xyzw mov r1.x, r0.x dsx r1.x, r1.x mov r0.x, r0.yxxx dsy r0.x, r0.x mov r1.xyzw, r1.x mov r0.xyzw, r0.x add r0.xyzw, r1.xyzw, r0.xyzw mov oC0.xyzw, r0.xyzw ``` DXBC-TPF: ``` ps_4_0 dcl_input_ps_siv linear v0.xyzw, position dcl_output o0.xyzw dcl_temps 2 mov r0.xyzw, v0.xyzw mov r1.x, r0.x dsx r1.x, r1.x mov r0.x, r0.yxxx dsy r0.x, r0.x mov r1.xyzw, r1.x mov r0.xyzw, r0.x add r0.xyzw, r1.xyzw, r0.xyzw mov o0.xyzw, r0.xyzw ret ``` Fixes https://bugs.winehq.org/show_bug.cgi?id=54827 -- v6: tests: Add tests for ddx(), ddy() intrinsics. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/179

2 3

[PATCH v4 0/2] MR184: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v4: tests: Add a basic compilation test for SampleGrad() method. vkd3d-shader/hlsl: Add support for SampleGrad() method https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

3 4

[PATCH v5 0/2] MR179: vkd3d-shader/hlsl: Add support for ddx(), ddy() intrinsics.
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

SPIR-V already handled DSX/DSY, so only D3DBC/TPF needed new case blocks. You'll notice that there's no test for this one - in addition to being a pretty straightforward translation for all possible formats, this feature uses the render target width/height and I wasn't sure if there was a good way to ensure that the test would always make sense. Instead, I did the test manually, and it's what you'd expect (EDIT: Previously the test used a uniform which always optimized to 0, new test uses VPOS instead): HLSL: ``` float4 main(float4 pos : sv_position) : sv_target { float4 x = ddx(pos.x); float4 y = ddy(pos.y); return x + y; } ``` D3DBC: ``` ps_3_0 dcl_position0 vPos mov r0.xyzw, vPos.xyzw mov r1.x, r0.x dsx r1.x, r1.x mov r0.x, r0.yxxx dsy r0.x, r0.x mov r1.xyzw, r1.x mov r0.xyzw, r0.x add r0.xyzw, r1.xyzw, r0.xyzw mov oC0.xyzw, r0.xyzw ``` DXBC-TPF: ``` ps_4_0 dcl_input_ps_siv linear v0.xyzw, position dcl_output o0.xyzw dcl_temps 2 mov r0.xyzw, v0.xyzw mov r1.x, r0.x dsx r1.x, r1.x mov r0.x, r0.yxxx dsy r0.x, r0.x mov r1.xyzw, r1.x mov r0.xyzw, r0.x add r0.xyzw, r1.xyzw, r0.xyzw mov o0.xyzw, r0.xyzw ret ``` Fixes https://bugs.winehq.org/show_bug.cgi?id=54827 -- v5: tests: Add test for ddx(), ddy() intrinsics vkd3d-shader/hlsl: Add support for ddx(), ddy() intrinsics. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/179

4 10

[PATCH v3 0/2] MR184: Draft: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v3: tests: Add a basic compilation test for SampleGrad() method. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

4 11

[PATCH 0/1] MR2699: evr: Don't flip image vertically.
by eric pouech (＠epo) April 28, 2023

April 28, 2023

This is actually fixing two issues: - if we get a negative stride, then the video transform should have already flipped vertically the image, so we don't need to flip it again. (This is another side effect for handling negative strides in wg_transform). - it also fixes a crash in AoEII, as the image source line offsets were incorrectly computed with unsigned arithmetic (while signed arithmetic was expected), resulting in incorrect sign propagation from 32bit to 64bit integers. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2699

3 4

[PATCH v3 0/5] MR176: hlsl: Return hlsl_ir_node pointers from instruction constructors, part 3.
by Zebediah Figura (＠zfigura) April 28, 2023

April 28, 2023

-- v3: vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_resource_store(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_resource_load(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_loop(). vkd3d-shader/hlsl: Pass an hlsl_block pointer to hlsl_new_loop(). vkd3d-shader/hlsl: Reuse the "init" instruction list if possible in create_loop(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/176

3 6

[PATCH v10 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) April 28, 2023

April 28, 2023

This replicates what seems to be happening when using sign() with shader model 3, which is roughly... ``` int pos = (int) (x > 0); int neg = -((int) (x < 0)); int result = pos + neg; ``` Fixes https://bugs.winehq.org/show_bug.cgi?id=54826 -- v10: tests: Add tests for sign() intrinsic. vkd3d-shader/hlsl: Add support for sign() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178

3 5

[PATCH 0/4] MR2721: gdi/wineps: Add support for implicitly calling StartPage and for EMRI_DEVMODE spool file record
by Piotr Caban (＠piotr) April 28, 2023

April 28, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2721

3 5

[PATCH v2 0/1] MR2678: win32u: Partially implement NtUserDisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_PREFERRED_MODE).
by Paul Gofman (＠gofman) April 28, 2023

April 28, 2023

win32u: Partially implement NtUserDisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_PREFERRED_MODE). Required for Ghost Recon Breakpoint. -- v2: win32u: Partially implement NtUserDisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_PREFERRED_MODE). https://gitlab.winehq.org/wine/wine/-/merge_requests/2678

3 8

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

April 28, 2023

-- v13: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Move AudioSessionControl into mmdevapi. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 10

[PATCH v8 0/1] MR2609: shlwapi: Implement StrFormatByteSizeEx
by David Kahurani (＠kahurani) April 28, 2023

April 28, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54733 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v8: shlwapi: Implement StrFormatByteSizeEx https://gitlab.winehq.org/wine/wine/-/merge_requests/2609

3 2

Re: [PATCH v2 0/1] MR2549: winevulkan: Update to VK spec version 1.3.246.
by Georg Lehmann (＠DadSchoorse) April 28, 2023

April 28, 2023

On Fri Apr 28 05:16:50 2023 +0000, Georg Lehmann wrote: > We are not supporting video extension at the moment because > `make_vulkan` wasn't updated to support more than one xml file. VK_NV_displacement_micromap isn't final yet, we don't enable provisional extensions in winevulkan. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2549#note_31470

1 0

Re: [PATCH v2 0/1] MR2549: winevulkan: Update to VK spec version 1.3.246.
by Georg Lehmann (＠DadSchoorse) April 28, 2023

April 28, 2023

On Fri Apr 28 05:16:50 2023 +0000, Oscar Barenys wrote: > sorry for asking here if not appropiate, but just asking: > just compiled a bunch of NV VK samples on Windows and was going to test > on Linux via Wine.. > and noticed the KHR video decode sample: > https://github.com/nvpro-samples/vk_video_samples/tree/main/vk_video_decoder > and also the new DMM sample (VK_NV_displacement_micromap): > https://github.com/nvpro-samples/vk_mini_samples/tree/main/samples/mm_displ… > fail to run under wine.. > any reason for not supporting the "released" KHR video (decoding) exts:? > ``` > VK_KHR_video_decode_queue > VK_KHR_video_queue > VK_KHR_video_decode_h264 > VK_KHR_video_decode_h265 > ``` > and also the new VK_NV_displacement_micromap released with 1.3.245 spec? We are not supporting video extension at the moment because `make_vulkan` wasn't updated to support more than one xml file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2549#note_31469

1 0

[PATCH v7 0/1] MR2609: shlwapi: Implement StrFormatByteSizeEx
by David Kahurani (＠kahurani) April 28, 2023

April 28, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54733 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v7: shlwapi: Implement StrFormatByteSizeEx https://gitlab.winehq.org/wine/wine/-/merge_requests/2609

2 1

Re: [PATCH v2 0/1] MR2549: winevulkan: Update to VK spec version 1.3.246.
by Oscar Barenys (＠oscarbg) April 27, 2023

April 27, 2023

sorry for asking here if not appropiate, but just asking: just compiled a bunch of NV VK samples on Windows and was going to test on Linux via Wine.. and noticed the KHR video decode sample: https://github.com/nvpro-samples/vk_video_samples/tree/main/vk_video_decoder and also the new DMM sample (VK_NV_displacement_micromap): https://github.com/nvpro-samples/vk_mini_samples/tree/main/samples/mm_displ… fail to run under wine.. any reason for not supporting the "released" KHR video (decoding) exts:? ``` VK_KHR_video_decode_queue VK_KHR_video_queue VK_KHR_video_decode_h264 VK_KHR_video_decode_h265 ``` and also the new VK_NV_displacement_micromap released with 1.3.245 spec? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2549#note_31463

1 0

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

April 27, 2023

-- v12: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Move AudioSessionControl into mmdevapi. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 5

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

April 27, 2023

-- v11: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Move AudioSessionControl into mmdevapi. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 11

Re: [PATCH v2 0/2] MR2717: d3d9/tests: AMD GPUs sample the border color of cube textures. - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v2 0/5] MR2704: imm32: More tests and fixes for IMMGWL_IMC and ImmGenerateMessages. - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v4 0/3] MR2705: d3dcompiler: D3DAssemble is a private export. - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v4 0/9] MR2718: gdi: Partial support for creating EMF spool files. - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v2 0/5] MR2715: dsound: Doppler shift (part 1) - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v2 0/1] MR2706: ntdll: Print RPC_S_SERVER_UNAVAILABLE exceptions - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v5 0/1] MR2602: mfplat: Fix returned buffer length in dxgi_surface_buffer_lock(). - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v2 0/1] MR2716: po: Update Lithuanian translation. - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

Re: [PATCH v3 0/2] MR2692: msi:custom: ok_() takes printf-style arguments. - approved
by Alexandre Julliard (＠julliard) April 27, 2023

April 27, 2023

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

1 0

[PATCH 0/2] MR2717: d3d9/tests: AMD GPUs sample the border color of cube textures.
by Stefan Dösinger April 27, 2023

April 27, 2023

--- This must be the longest ignored d3d test failure. I think my r200 GPU does not show this behavior, but my r500 one does. I'll be able to check next week if anyone cares. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2717

2 3

[PATCH v2 0/2] MR2578: Fixing module paths in LdrPath (corner case).
by eric pouech (＠epo) April 27, 2023

April 27, 2023

The serie intent is to fix unexpected paths in module's list: This happens: - when running under old / (new) wow64 - when main module is located under the syswow64 directory - the 32 bit modules are stored in LdrData (and then exposed through a couple of ways) under syswow64 (they are normally stored under system32, letting the redirection come into play when needed) This triggers a couple of errors in winetest (as we're using c:\windows\syswow64\msinfo32.exe in many tests to trigger a wow64 process from a winetest program). This is the fix awaited in MR!2497. @julliard: I'm not 100% happy with the fix itself by reintroducting ref to the redirected DLLs in ntdll/PE but couldn't find a better idea. -- v2: ntdll: Store system DLL in LdrData under system32 for a wow64 process. kernel32: Harden some wow64 module tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/2578

3 6

[PATCH v4 0/1] MR2710: ntdll: Implement efficiency class reporting for intel hybrid CPUs.
by Torge Matthies (＠tmatthies) April 27, 2023

April 27, 2023

Signed-off-by: Torge Matthies <tmatthies(a)codeweavers.com> -- v4: ntdll: Implement efficiency class reporting for intel hybrid CPUs. https://gitlab.winehq.org/wine/wine/-/merge_requests/2710

2 3

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

April 27, 2023

This is required by https://bugs.winehq.org/show_bug.cgi?id=54660 . -- v9: 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. vkd3d-shader/hlsl: Don't create semantic vars more than once. vkd3d-shader/hlsl: Move get_array_size() and get_array_type() to hlsl.c. tests: Test duplicated semantics. tests: Test array types with semantics. vkd3d-shader/hlsl: Avoid invalid input/output copies for non-numeric types. tests: Map unindentified hrs on compilation. tests: Allow invalid vertex shader tests. tests: Expect S_OK result on [vertex shader]. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/148

4 20

[PATCH 0/5] MR2704: imm32: More tests and fixes for IMMGWL_IMC and ImmGenerateMessages.
by Rémi Bernon April 27, 2023

April 27, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2704

1 6

[PATCH v3 0/3] MR2705: d3dcompiler: D3DAssemble is a private export.
by Stefan Dösinger April 27, 2023

April 27, 2023

This series allows linking of our d3dx9.dll against d3dcompiler.lib from the Windows SDK. It presumably also fixes the d3dcompiler tests, although I didn't bother building them with Visual Studio so far. And yes, I did check, that stringification macro works on MSVC. -- v3: d3dcompiler: Make D3DAssemble a private export. d3dcompiler/tests: Load D3DAssemble via GetProcAddress. d3dx9: Load D3DAssemble via GetProcAddress. https://gitlab.winehq.org/wine/wine/-/merge_requests/2705

2 4

Re: [PATCH v9 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) April 27, 2023

April 27, 2023

On Thu Apr 27 13:22:42 2023 +0000, Giovanni Mascellani wrote: > This means that expressions of type other than `float` are casted to > `float`. In principle that should be correct in the end, because AFAIU > the sign should always be mapped correctly, but it makes me a bit > nervous. Could the type of zero be set to coincide with the type of the argument? Pushed an update to do this, since it seems like if anything it'd be an optimization - as part of the update I've also added int versions of all the tests, to make sure it's doing the right thing for float and non-float types. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178#note_31399

1 0

[PATCH v3 0/9] MR2718: gdi: Partial support for creating EMF spool files.
by Piotr Caban (＠piotr) April 27, 2023

April 27, 2023

Printing using EMF spool files is still missing some features and has some bugs: - ResetDC should generally work on gdi side but is ignored on playback - because of that it wasn't really tested - no support for ExtEscape / Escape yet - DC bounds are incorrect In order to enable printing using EMF spool files it's needed to change printer print processor to wineps. -- v3: gdi32: Add GdiIsMetaPrintDC implementation. https://gitlab.winehq.org/wine/wine/-/merge_requests/2718

3 10

[PATCH v2 0/10] MR2718: gdi: Partial support for creating EMF spool files.
by Piotr Caban (＠piotr) April 27, 2023

April 27, 2023

Printing using EMF spool files is still missing some features and has some bugs: - ResetDC should generally work on gdi side but is ignored on playback - because of that it wasn't really tested - no support for ExtEscape / Escape yet - DC bounds are incorrect In order to enable printing using EMF spool files it's needed to change printer print processor to wineps. -- v2: gdi32: Add GdiIsMetaPrintDC implementation. gdi32: Implicitly call StartPage while creating spool file. gdi32: Add support for creating EMF spool files. gdi32: Factor out emf_create helper. gdi32: Factor out emf_eof helper. gdi32: Improve EMF DC cleanup when CloseEnhMetafile is not called. gdi32: Store the printer info in a structure. wineps: Reset current position on every page. localspl: Validate datatype in StartDocPrinter. localspl: Add support for PRINTER_ATTRIBUTE_RAW_ONLY printer attribute. https://gitlab.winehq.org/wine/wine/-/merge_requests/2718

3 13

[PATCH v8 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) April 27, 2023

April 27, 2023

This replicates what seems to be happening when using sign() with shader model 3, which is roughly... ``` int pos = (int) (x > 0); int neg = -((int) (x < 0)); int result = pos + neg; ``` Fixes https://bugs.winehq.org/show_bug.cgi?id=54826 -- v8: tests: Add tests for sign() intrinsic. vkd3d-shader/hlsl: Add support for sign() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178

4 4

[PATCH 0/5] MR2715: dsound: Doppler shift (part 1)
by Anton Baskanov (＠baskanov) April 27, 2023

April 27, 2023

Development branch: https://gitlab.winehq.org/baskanov/wine/-/commits/dsound-doppler/ -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2715

3 6

[PATCH 0/2] MR185: vkd3d: Fix descriptor write issues.
by Conor McCarthy (＠cmccarthy) April 27, 2023

April 27, 2023

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

3 3

[PATCH v6 0/2] MR161: vkd3d-shader/hlsl: Implement D3DCOLORtoUBYTE4().
by Nikolay Sivov (＠nsivov) April 27, 2023

April 27, 2023

-- v6: vkd3d-shader/hlsl: Implement D3DCOLORtoUBYTE4() function. vkd3d-shader/hlsl: Partially implement trunc(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/161

3 3

[PATCH 0/10] MR2718: gdi: Partial support for creating EMF spool files.
by Piotr Caban (＠piotr) April 27, 2023

April 27, 2023

Printing using EMF spool files is still missing some features and has some bugs: - ResetDC should generally work on gdi side but is ignored on playback - because of that it wasn't really tested - no support for ExtEscape / Escape yet - DC bounds are incorrect In order to enable printing using EMF spool files it's needed to change printer print processor to wineps. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2718

4 12

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Giovanni Mascellani (＠giomasce) April 27, 2023

April 27, 2023

On Thu Apr 27 01:58:24 2023 +0000, Zebediah Figura wrote: > > Among other things, this means that it's still not completely clear to > me what you mean by "maximally CISC" or "minimally CISC" (and while I > think I sort of get the general idea for the terms, that's not nearly > enough to understand options (3) and (4)). > Ah, I'm sorry. To put it into more concrete terms: HLSL is intentionally > a quite simple IR. I would describe it as erring on the side of RISC in > design. Everything operates on SSA values except for extern and resource > loads; single instructions do pretty much maximally modular things; we > avoid adding new expression types or instruction types if we can instead > just lower them to simpler expressions immediately. > By contrast, both sm1 and sm4 are more CISC. One instruction can do > multiple arithmetic operations (abs, neg, sat) in addition to whatever > else it's doing; instructions load directly from multiple types of > registers (instead of always going through an SSA value, or even just > always going through a temporary register). > Part of being able to make statements like "HLSL IR is RISC" is the > knowledge that it used to be less so (e.g. we used to have > HLSL_IR_CONSTRUCTOR, which I assume you can guess the idea of) and also > that we've considered making it less so. On the basis that one HLSL > instruction corresponds to one smX instruction we've considered adding > some of those features to HLSL IR (for example, making hlsl_src hold a > union that includes not just SSA values but also immediate constants or > something similar to hlsl_deref). We eventually decided against those on > the grounds that it would make the IR more complex, and harder to reason > about when doing optimization passes. > > * In general, I think that code processing should be done in the form > of IR passes as much as possible, rather than be embedded in the > frontends or backends. This helps modularity and code sharing. I think > Conor's patches go into this direction, which makes sense to me. > Frontends and backends already care about serialization and > deserialization and should not be loaded with excessive other duties. > Yeah. Well, in a sense the question can be rephrased as: should v-s IR > exist just as a common, "neutral" format, and then we'd have basically > frontend- and/or backend-specific IR that we'd do passes over? E.g. in > this case the backend IR would probably be adapted from struct > sm4_instruction, which currently exists just to be a slightly more > structured version of the byte code, but could grow to be more than > that. It seems we probably won't be moving this way, but that's kind of > what I was envisioning with that proposal. In that case struct > vkd3d_shader_instruction wouldn't have any optimization passes done over > it, the only raison d'être would be to help allow mixing any frontend > with any backend. > > * Currently my understanding is that `vkd3d_shader_instrucion` is > basically modeled after SM4. When converting SM4 -> SPIR-V, the SM4 code > is basically deserialized to `vkd3d_shader_instruction` and then > rewritten to SPIR-V in a rather naive way. The deserialization step is > very syntactical, to the point that the original SM4 code can be > faithfully disassembled from the IR. > I believe that vkd3d_shader_instruction is modeled after (or even > "adapted directly from") struct wined3d_shader_instruction, which was > designed to handle both sm1 and sm4. Fundamentally the formats are > relatively similar, enough that it's possible to write a single > disassembly routine, and a single GLSL shader backend, that mostly > handles both, although there did need to be a lot of version-specific > code in the latter case. > > If we want `vkd3d_shader_instruction` to be flexible enough to support > different frontends and backends, I think it must somehow be unchained > from SM4. In particular, SM4 disassembling has to go through a different path. > Right, and there's part of the rub. If we want it to be usable for > things like disassembly (and assembly), we need v_s_i to be able to > express everything that *any* frontend or backend can. This ends up kind > of bloating the structure, which is one of the reasons I'm not sure we > want that "maximally CISC" kind of IR. > Like I mentioned, the less complicated an IR is, the easier it is to > work with. On the other hand, the kind of passes we'd be potentially > doing over a maximally CISC v_s_ir aren't the same as the work we do > with HLSL IR. HLSL has to bridge the gap from text all the way down to > byte code, but v_s_ir would potentially just be a bunch of peepholes. > The fact that it doesn't have to deal with *types*, or well, doesn't > have to deal with data structures, is already quite a benefit. So I'm > not sure anymore that that per se is a concern. > And of course when trading off one complex IR against multiple (ideally > less complex) IRs, it takes some judgement to decide which is the best option. Thanks for the explanation. Keeping in mind my remark about salt and cargo ships from yesterday, here are my thoughts. > If we want it to be usable for things like disassembly (and assembly), we need v_s_i to be able to express everything that *any* frontend or backend can. And I don't think we want it, it would be unmanageable. > should v-s IR exist just as a common, "neutral" format, and then we'd have basically frontend- and/or backend-specific IR that we'd do passes over? Ideally this would feel a good design to me. Though I would say that it is not a hard requirement for frontends and backends to have their specific IR, even if it is conceivable that past a certain complexity threshold it is difficult to do without. Also, my idea is that you can do passes over {front,back}end specific IRs, but also over the common IR. At least, I'd design the common IR in such a way that they can be done. In practice I see a number of difficulties: * Shaders are not just code; they also embed interface information (input and output signatures, uniforms, buffers, object bindings, ...) and other random metadata (for example for the hull shaders). Should this be representable in the common IR? * How essential (or "RISC") should the IR be? Should it be scalar or vector? Making it more essential means that frontends have to do more work and common IR passes are easier to write; make it less means that backends have to do more work, though it also has the advantage that passes that make sense for different frontends and backends can be deduplicated. Maybe I am just rehashing the same elements around and around. It's quite hard to design this thing... -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31369

1 0

[PATCH v2 0/3] MR2705: d3dcompiler: D3DAssemble is a private export.
by Stefan Dösinger April 27, 2023

April 27, 2023

This series allows linking of our d3dx9.dll against d3dcompiler.lib from the Windows SDK. It presumably also fixes the d3dcompiler tests, although I didn't bother building them with Visual Studio so far. And yes, I did check, that stringification macro works on MSVC. -- v2: d3dcompiler: Make D3DAssemble a private export. d3dcompiler/tests: Load D3DAssemble via GetProcAddress. d3dx9: Load D3DAssemble via GetProcAddress. https://gitlab.winehq.org/wine/wine/-/merge_requests/2705

3 9

[PATCH v10 0/1] MR135: vkd3d-shader/hlsl: Add support for sample index argument in Load().
by Nikolay Sivov (＠nsivov) April 27, 2023

April 27, 2023

-- v10: vkd3d-shader/hlsl: Add support for sample index argument in Load(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/135

2 1

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

April 27, 2023

-- v10: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Move AudioSessionControl into mmdevapi. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 8

Re: [PATCH v2 0/9] MR895: msxml3/tests: Filter attributes tests by version.
by Daniel Lehman (＠dlehman25) April 27, 2023

April 27, 2023

On Thu Apr 27 06:51:02 2023 +0000, Nikolay Sivov wrote: > How bad would it be to duplicate tests in msxml3/4/6, removing version > checks completely? could try that. don't think it'd be too bad would it be just for the tests that are different? would msxml3 remain the main place for tests with common results and msxml4/6-specific tests under dlls/msxml[46]? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/895#note_31345

1 0

Re: [PATCH v2 0/9] MR895: msxml3/tests: Filter attributes tests by version.
by Daniel Lehman (＠dlehman25) April 27, 2023

April 27, 2023

On Wed Apr 26 11:22:29 2023 +0000, Nikolay Sivov wrote: > I don't see "versions" field set anywhere? it's set but only for the 'default namespace' test, on lines 13744 and 13785 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/895#note_31344

1 0

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

April 27, 2023

-- v9: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Move AudioSessionControl into mmdevapi. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 7

[PATCH v2 0/2] MR2692: Draft: msi:custom: ok_() takes printf-style arguments.
by Francois Gouget (＠fgouget) April 27, 2023

April 27, 2023

custom.c does not use the test.h and debug.h definitions and presumably has a good reason not to. But this resulted in the printf-format compiler attribute getting lost. So copy it from debug.h to allow proper checks of the ok_() format string. Also fix said format strings. -- v2: msi/tests: ok_() takes printf-style arguments. msi/tests: Fix the ok() formats so they match the size of their arguments. https://gitlab.winehq.org/wine/wine/-/merge_requests/2692

3 4

[PATCH 0/1] MR2716: po: Update Lithuanian translation.
by Aurimas Fišeras April 27, 2023

April 27, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2716

1 1

[PATCH 0/4] MR181: vkd3d-shader: Normalise signatures and input/output registers to the Shader Model 6 pattern.
by Conor McCarthy (＠cmccarthy) April 27, 2023

April 27, 2023

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

4 8

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

April 27, 2023

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

3 6

[PATCH 0/1] MR182: vkd3d-shader/hlsl: Introduce hlsl_ir_index, part 2/2 (optional).
by Francisco Casas (＠fcasas) April 27, 2023

April 27, 2023

This patch makes index expressions on resources hlsl_ir_index nodes instead of hlsl_ir_resource_load nodes, because it is not known if they will be used later as the lhs of an hlsl_ir_resource_store. For now, the only benefit is consistency. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/182

3 2

[PATCH v5 0/2] MR161: vkd3d-shader/hlsl: Implement D3DCOLORtoUBYTE4().
by Nikolay Sivov (＠nsivov) April 27, 2023

April 27, 2023

-- v5: vkd3d-shader/hlsl: Implement D3DCOLORtoUBYTE4() function. vkd3d-shader/hlsl: Partially implement trunc(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/161

3 3

[PATCH v4 0/1] MR2713: kernelbase: Add GetPackagesByPackageFamily stub.
by Etaash Mathamsetty (＠etaash.mathamsetty) April 27, 2023

April 27, 2023

webview2 uses this function to locate media foundation. I also saw the UWP version of FH5 calling this function as well, interestingly. -- v4: kernelbase: Add GetPackagesByPackageFamily stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2713

3 2

[PATCH v2 0/2] MR184: Draft: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) April 27, 2023

April 27, 2023

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v2: tests: Add tests for SampleGrad() method. vkd3d-shader/hlsl: Add support for SampleGrad() method https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

2 4

[PATCH 0/2] MR184: Draft: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) April 27, 2023

April 27, 2023

This one's marked as a draft, as there seems to be a blocker with the method parameters. The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it: ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` Seems like it's surprised when we try to load from the constant buffer maybe? -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

3 5

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Zebediah Figura (＠zfigura) April 27, 2023

April 27, 2023

> Among other things, this means that it's still not completely clear to me what you mean by "maximally CISC" or "minimally CISC" (and while I think I sort of get the general idea for the terms, that's not nearly enough to understand options (3) and (4)). Ah, I'm sorry. To put it into more concrete terms: HLSL is intentionally a quite simple IR. I would describe it as erring on the side of RISC in design. Everything operates on SSA values except for extern and resource loads; single instructions do pretty much maximally modular things; we avoid adding new expression types or instruction types if we can instead just lower them to simpler expressions immediately. By contrast, both sm1 and sm4 are more CISC. One instruction can do multiple arithmetic operations (abs, neg, sat) in addition to whatever else it's doing; instructions load directly from multiple types of registers (instead of always going through an SSA value, or even just always going through a temporary register). Part of being able to make statements like "HLSL IR is RISC" is the knowledge that it used to be less so (e.g. we used to have HLSL_IR_CONSTRUCTOR, which I assume you can guess the idea of) and also that we've considered making it less so. On the basis that one HLSL instruction corresponds to one smX instruction we've considered adding some of those features to HLSL IR (for example, making hlsl_src hold a union that includes not just SSA values but also immediate constants or something similar to hlsl_deref). We eventually decided against those on the grounds that it would make the IR more complex, and harder to reason about when doing optimization passes. > * In general, I think that code processing should be done in the form of IR passes as much as possible, rather than be embedded in the frontends or backends. This helps modularity and code sharing. I think Conor's patches go into this direction, which makes sense to me. Frontends and backends already care about serialization and deserialization and should not be loaded with excessive other duties. Yeah. Well, in a sense the question can be rephrased as: should v-s IR exist just as a common, "neutral" format, and then we'd have basically frontend- and/or backend-specific IR that we'd do passes over? E.g. in this case the backend IR would probably be adapted from struct sm4_instruction, which currently exists just to be a slightly more structured version of the byte code, but could grow to be more than that. It seems we probably won't be moving this way, but that's kind of what I was envisioning with that proposal. In that case struct vkd3d_shader_instruction wouldn't have any optimization passes done over it, the only raison d'être would be to help allow mixing any frontend with any backend. > * Currently my understanding is that `vkd3d_shader_instrucion` is basically modeled after SM4. When converting SM4 -> SPIR-V, the SM4 code is basically deserialized to `vkd3d_shader_instruction` and then rewritten to SPIR-V in a rather naive way. The deserialization step is very syntactical, to the point that the original SM4 code can be faithfully disassembled from the IR. I believe that vkd3d_shader_instruction is modeled after (or even "adapted directly from") struct wined3d_shader_instruction, which was designed to handle both sm1 and sm4. Fundamentally the formats are relatively similar, enough that it's possible to write a single disassembly routine, and a single GLSL shader backend, that mostly handles both, although there did need to be a lot of version-specific code in the latter case. > If we want `vkd3d_shader_instruction` to be flexible enough to support different frontends and backends, I think it must somehow be unchained from SM4. In particular, SM4 disassembling has to go through a different path. Right, and there's part of the rub. If we want it to be usable for things like disassembly (and assembly), we need v_s_i to be able to express everything that *any* frontend or backend can. This ends up kind of bloating the structure, which is one of the reasons I'm not sure we want that "maximally CISC" kind of IR. Like I mentioned, the less complicated an IR is, the easier it is to work with. On the other hand, the kind of passes we'd be potentially doing over a maximally CISC v_s_ir aren't the same as the work we do with HLSL IR. HLSL has to bridge the gap from text all the way down to byte code, but v_s_ir would potentially just be a bunch of peepholes. The fact that it doesn't have to deal with *types*, or well, doesn't have to deal with data structures, is already quite a benefit. So I'm not sure anymore that that per se is a concern. And of course when trading off one complex IR against multiple (ideally less complex) IRs, it takes some judgement to decide which is the best option. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31316

1 0

[PATCH v3 0/1] MR2710: ntdll: Implement efficiency class reporting for intel hybrid CPUs.
by Torge Matthies (＠tmatthies) April 27, 2023

April 27, 2023

Signed-off-by: Torge Matthies <tmatthies(a)codeweavers.com> -- v3: ntdll: Implement efficiency class reporting for intel hybrid CPUs. https://gitlab.winehq.org/wine/wine/-/merge_requests/2710

3 12

[PATCH v4 0/1] MR2602: mfplat: Fix returned buffer length in dxgi_surface_buffer_lock().
by Paul Gofman (＠gofman) April 26, 2023

April 26, 2023

-- v4: mfplat: Fix returned buffer length in dxgi_surface_buffer_lock(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2602

3 3

Re: [PATCH v3 0/2] MR2571: Some improvements for appwiz.cpl. - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v3 0/2] MR2709: include: Add ISpTTSEngineSite and ISpTTSEngine interfaces. - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v4 0/5] MR2676: dxgi, d3d9: Create swapchain textures from wined3d_swapchain_get_back_buffer() instead of using a callback. - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v2 0/11] MR2662: mfplat: Optimize DXGI buffer locking - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v2 0/2] MR2708: Two misc janitorings - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v2 0/1] MR2707: threadpoolwinrt: Forward a Release() to a Release() method. - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v13 0/4] MR566: shell32: Implement SHBindToFolderIDListParent. - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v6 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias(). - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

Re: [PATCH v6 0/5] MR136: vkd3d-shader/hlsl: Handle discard statement. - approved
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

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

1 0

[PATCH v3 0/1] MR2713: kernelbase: Add GetPackagesByPackageFamily stub.
by Etaash Mathamsetty (＠etaash.mathamsetty) April 26, 2023

April 26, 2023

webview2 uses this function to locate media foundation. I also saw the UWP version of FH5 calling this function as well, interestingly. -- v3: kernelbase: Add GetPackagesByPackageFamily stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2713

2 1