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

[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

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

April 26, 2023

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

3 3

Re: [PATCH v2 0/9] MR895: msxml3/tests: Filter attributes tests by version.
by Nikolay Sivov (＠nsivov) April 26, 2023

April 26, 2023

How bad would it be to duplicate tests in msxml3/4/6, removing version checks completely? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/895#note_31211

1 0

Re: [PATCH v2 0/9] MR895: msxml3/tests: Filter attributes tests by version.
by Nikolay Sivov (＠nsivov) April 26, 2023

April 26, 2023

Nikolay Sivov (@nsivov) commented about dlls/msxml3/tests/domdoc.c: > } > > test = tests; > - while (test->xml) { > + while (test->xml) > + { > + if (test->versions && !(entry->ver & test->versions)) > + { > + test++; > + continue; > + } I don't see "versions" field set anywhere? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/895#note_31210

1 0