- wine-gitlab - winehq.org

[PATCH 0/5] MR2715: dsound: Doppler shift (part 1)
by Anton Baskanov (＠baskanov) 27 Apr '23

27 Apr '23

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) 27 Apr '23

27 Apr '23

-- 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) 27 Apr '23

27 Apr '23

-- 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) 27 Apr '23

27 Apr '23

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) 27 Apr '23

27 Apr '23

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 (＠stefan) 27 Apr '23

27 Apr '23

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

4 9

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

27 Apr '23

-- 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) 27 Apr '23

27 Apr '23

-- 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) 27 Apr '23

27 Apr '23

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) 27 Apr '23

27 Apr '23

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

2025

2024

2023

2022

wine-gitlab