- Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR2709: include: Add ISpTTSEngineSite and ISpTTSEngine interfaces.
by Shaun Ren (＠shaunren) April 26, 2023

April 26, 2023

-- v2: include: Add ISpTTSEngineSite and ISpTTSEngine interfaces. https://gitlab.winehq.org/wine/wine/-/merge_requests/2709

3 3

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

April 26, 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 -- v3: tests: Add test for ddx(), ddy() intrinsics https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/179

4 6

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

April 26, 2023

-- v5: vkd3d-shader/hlsl: Implement SampleBias() method. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/172

6 10

[PATCH v5 0/5] MR136: vkd3d-shader/hlsl: Handle discard statement.
by Nikolay Sivov (＠nsivov) April 26, 2023

April 26, 2023

-- v5: tests: Add a simple test for "discard". tests: Remove rtv clears in Vulkan runner. tests: Remove rtv clears in d3d12 runner. vkd3d-shader/hlsl: Handle discard statement. vkd3d-shader/trace: Add separate id for discard. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/136

6 9

[PATCH 0/2] MR2711: include: Add ISpTTSEngineSite and ISpTTSEngine interfaces.
by Shaun Ren (＠shaunren) April 26, 2023

April 26, 2023

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

3 4

[PATCH 0/2] MR2709: include: Add ISpTTSEngineSite and ISpTTSEngine interfaces.
by Shaun Ren (＠shaunren) April 26, 2023

April 26, 2023

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

3 4

[PATCH 0/1] MR2707: threadpoolwinrt: Forward a Release() to a Release() method.
by Michael Stefaniuc (＠mstefani) April 26, 2023

April 26, 2023

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

3 2

[PATCH 0/11] MR2662: mfplat: Optimize DXGI buffer locking
by Giovanni Mascellani (＠giomasce) April 26, 2023

April 26, 2023

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

3 14

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

April 26, 2023

> Yeah, that makes sense. It's just that there are several vkd3d developers rather experienced in design—and also often opinionated—and I was hoping to get at least some thoughts on the matter :-/ I don't consider myself experienced, at least not into IR design. Until little time ago I knew basically nothing about `vkd3d_shader_instruction`, and still now I don't know that much. 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)). Therefore I don't feel I have a definite opinion about the subject. There are just a couple of rather vague points that come to my mind. * 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. * 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. 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. An option is to have an IR specific for SM1/SM4 (which are probably close enough to have the same IR) and another more general IR, that is meant to achieve interoperability for many different shader languages. The SM4-IR would be rather similar to the current `vkd3d_shader_instruction` (so syntactically close to SM4), and the "general" IR could be more like an actual compiler IR (SSA, possibly mor e RISC, if I understand Zeb's terminology). If eventually we want to do some SPIR-V-specific optimizations, there could be the need to a SPIR-V-IR too. The HLSL compiler could emit general-IR (which would be somewhat similar to what's already emitting), which would then be optimized, converted to SM4-IR (that's possibly similar to a direction that was already considered), optimized again (for passes that go not make sense for general-IR) and then emitted (which would be basically serializing). It's quite a lot of work, anyway. As I said, take all of this with a grain of salt. Maybe two grains. Ok, it probably wouldn't hurt to add a cargo ship's worth of salt. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31222

1 0

Re: [PATCH v2 0/2] MR2700: msxml3: Rename msxml3 to winexml and point msxml* to it.
by Alexandre Julliard (＠julliard) April 26, 2023

April 26, 2023

I'm not convinced that this justifies a Wine-specific module. The usual solution for problems with native dlls is "don't do that", i.e. fix the builtin so that native is not required. It's hard to tell without more details, but in this case an app-specific dll override may also be enough. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2700#note_31218

1 0