April 2023 - wine-gitlab

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Henri Verbeet (＠hverbeet) 21 Apr '23

21 Apr '23

> I suppose it depends on your standard for how long a file can be. I feel like more than a few thousand lines can start to feel like an awful lot, and at that point the compilation time does start to show. > > Personally I think modularity is the most important thing, and I find it somehow easier to mentally work with files that segregate their components. In this case I think segregating the reader and writer would not have been a bad idea, and keeping the sm4 definitions in a separate file might also have been nice even if not. > > Obviously by that principle, any sufficiently modular piece of code can be split into its own file, however small. If it's only a few hundred lines, or a couple of functions (honestly, the number of \[well-formed?\] functions may matter less to me than the line count) I'd be inclined against it, but I think I have a lower threshold for what seems reasonable to split up. Take HLSL copy propagation, for instance, which is only about 500 lines, but on the other hand spans a whole 20 functions; that feels to me like a large enough self-contained chunk of code that it's worth at least considering segregation. I don't want to be insensitive to the concern, particularly since both Giovanni and you raised it, but I just don't get it? Navigating within a file seems at least as easy as navigating between files, and files on the order of ~2k lines in case of d3dbc.c and ~5k lines in case of tpf.c don't seem particularly unusual in either vkd3d or Wine. (I had been thinking we might as well merge hlsl.c, hlsl_codegen.c and hlsl_constant_ops.c, but I guess not then...) > > In any case, while it's perhaps not quite true at the moment, parsing and serialising the different bytecode formats should be closely related and use the same constants, structures, and so on. There's currently some HLSL-specific code intermixed that would more properly belong in hlsl.c/hlsl_codegen.c, but we can deal with that once we get to it. > > ...Possibly. I would have appreciated a bit more discussion on this first. I had been vaguely thinking of moving more code *to* the backend files, so now I need to stop and re-plan. > > And while I think we'd always been talking about using the same structures in hlsl_smX, I kind of thought that we would perform that conversion before moving things around. That would have let things be done more gradually, and avoided some unpleasant rebases. > > Anyway, generally this ties into the question I brought up in \[1\]. I brought up a relatively complete summary of our options with the IR there, but it doesn't seem to have garnered any discussion. At best we seem to have committed to a "maximally CISC" instruction set with Conor's normalization patches, so that rules out option (2). Well, yeah, the impression I came away with from that conversation was that there were no particularly strong preferences, and not much of a general consensus either; few people seem to care. I don't think we've ruled out any of the options presented there at this point. As noted there, (1) is essentially the current state, but we could certainly move away from that towards one of the other options. And ultimately I think the distinction between the options is a bit artificial to begin with; it ends up largely being a matter of doing particular transformation passes on either the frontend IR, the intermediate IR, or the backend IR. That's not a decision we need to make upfront for every conceivable transformation, and we can change our minds if a particular choice doesn't quite work out. In the case of Conor's tessellation shader work, the consideration is simply that these transformations are more practical to do on the vkd3d_shader_instruction level than on the SPIR-V level, and while doing them on the TPF level would also be plausible, that would require doing a bunch of disassembler work first. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30827

1 0

[PATCH 0/1] MR2689: findstr: Add basic functionality.
by Zhiyi Zhang (＠zhiyi) 21 Apr '23

21 Apr '23

Company of Heroes: Battle of Crete needs a functioning findstr.exe to exit properly. Freemake Video Converter 4.1 installer also needs this. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=35254 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2689

3 3

[PATCH v2 0/3] MR2675: mfreadwrite: Fix an address of operator typo.
by Ziqing Hui (＠zhui) 21 Apr '23

21 Apr '23

-- v2: mfreadwrite: Introduce create_sink_writer_from_factory. mfreadwrite: Fix an address of operator typo. mfreadwrite/tests: Add more tests for MFCreateSinkWriterFromURL. https://gitlab.winehq.org/wine/wine/-/merge_requests/2675

4 9

[PATCH 0/4] MR2688: tasklist: Add basic functionality.
by Zhiyi Zhang (＠zhiyi) 21 Apr '23

21 Apr '23

Company of Heroes: Battle of Crete needs a functioning tasklist.exe to exit properly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2688

3 6

[PATCH v4 0/4] MR136: vkd3d-shader/hlsl: Handle discard statement.
by Nikolay Sivov (＠nsivov) 21 Apr '23

21 Apr '23

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

6 17

[PATCH 0/1] MR2678: win32u: Partially implement NtUserDisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_PREFERRED_MODE).
by Paul Gofman (＠gofman) 21 Apr '23

21 Apr '23

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

3 6

[PATCH 0/2] MR2674: d3d10: Use the vkd3d-shader DXBC API.
by Henri Verbeet (＠hverbeet) 20 Apr '23

20 Apr '23

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

3 3

[PATCH 0/5] MR176: hlsl: Return hlsl_ir_node pointers from instruction constructors, part 3.
by Zebediah Figura (＠zfigura) 20 Apr '23

20 Apr '23

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

2 5

[PATCH v3 0/1] MR1853: mf: Request more samples for MFT when needed.
by Shaun Ren (＠shaunren) 20 Apr '23

20 Apr '23

When an upstream node has not given enough samples to the transform, we need to request more samples from it to avoid stalling the pipeline. This fixes an issue where the intro audio of the game Airborne Kingdom stops playing after a few seconds. -- v3: mf: Request more samples for transforms when needed. https://gitlab.winehq.org/wine/wine/-/merge_requests/1853

2 3

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Zebediah Figura (＠zfigura) 20 Apr '23

20 Apr '23

Oof, I would have asked that we not do this quite yet :-/ > I wouldn't call either d3dbc.c or tpf.c very long, but I suppose that's a matter of opinion. I imagine it doesn't help that I find the practice of spreading source code over a million tiny files to be one of the most irritating things a codebase can do... I suppose it depends on your standard for how long a file can be. I feel like more than a few thousand lines can start to feel like an awful lot, and at that point the compilation time does start to show. Personally I think modularity is the most important thing, and I find it somehow easier to mentally work with files that segregate their components. In this case I think segregating the reader and writer would not have been a bad idea, and keeping the sm4 definitions in a separate file might also have been nice even if not. Obviously by that principle, any sufficiently modular piece of code can be split into its own file, however small. If it's only a few hundred lines, or a couple of functions (honestly, the number of [well-formed?] functions may matter less to me than the line count) I'd be inclined against it, but I think I have a lower threshold for what seems reasonable to split up. Take HLSL copy propagation, for instance, which is only about 500 lines, but on the other hand spans a whole 20 functions; that feels to me like a large enough self-contained chunk of code that it's worth at least considering segregation. > In any case, while it's perhaps not quite true at the moment, parsing and serialising the different bytecode formats should be closely related and use the same constants, structures, and so on. There's currently some HLSL-specific code intermixed that would more properly belong in hlsl.c/hlsl_codegen.c, but we can deal with that once we get to it. ...Possibly. I would have appreciated a bit more discussion on this first. I had been vaguely thinking of moving more code *to* the backend files, so now I need to stop and re-plan. And while I think we'd always been talking about using the same structures in hlsl_smX, I kind of thought that we would perform that conversion before moving things around. That would have let things be done more gradually, and avoided some unpleasant rebases. Anyway, generally this ties into the question I brought up in [1]. I brought up a relatively complete summary of our options with the IR there, but it doesn't seem to have garnered any discussion. At best we seem to have committed to a "maximally CISC" instruction set with Conor's normalization patches, so that rules out option (2). I'd obviously like to keep HLSL details out of the sm1/sm4 code, but I'd also really like to keep sm1/sm4 details out of hlsl_codegen.c as much as we can. We are still going to need specific hlsl -> smX glue for some things like register allocation and semantic validation, and that may be unavoidable (though on the other hand, a lot of that may end up being shareable... certainly in the case of register allocation it currently is; I'm just not sure if it should remain that way.) Past that, it's still an open question what kind of instructions the HLSL compiler should actually emit. I don't really know the answer to this one. My natural inclination is that we want the HLSL compiler to care about its target as little as possible [so I'm inclined against option (1)]. Going further, even if the IR is going to be maximal anyway, I'd say that HLSL should probably still emit a more minimal subset [basically option (3)], and then we would have backend-specific optimization passes that "raise" simple IR into more complex IR. We don't want to complexify the HLSL IR to match the CISC capabilities of vkd3d_shader_instruction, and if we're going to have to perform "raising" passes on vkd3d_shader_instruction anyway, probably better to raise them per backend. Of course, there are upsides and downsides to each approach, and I'm not fully sure which is best. [1] https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/37#note_13059 -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30793

1 0

2025

2024

2023

2022

wine-gitlab April 2023