April 2023 - wine-gitlab

[PATCH v3 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias().
by Nikolay Sivov (＠nsivov) 21 Apr '23

21 Apr '23

-- v3: vkd3d-shader/hlsl: Implement SampleBias() method. vkd3d-shader/hlsl: Add separate helpers to generate object methods. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/172

3 5

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

21 Apr '23

> 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...) I suppose it depends a lot on one's own thought processes and habits, so I don't claim that what's better for me is intrinsecally better for everybody. Also, as you say, Wine's standards are much worse than what we're discussing here, so, while I don't think they are good standards, I had to come to terms with them. I agree with Zeb that having smaller files helps segregation of code, and if code is segregated properly with reasonable interfaces between the segregated parts it is easier (for me at least) to understand and change, because I can study each of the segregated parts somewhat independently. In theory it is not the number of lines or functions that counts, but in practice, with some exceptions, once a file has grown past a few thousands lines of code it's hard for me not to think that it would make good use of some splitting. For example, I would find ideal to have `hlsl_codegen.c` splitted in a few pieces. The prepend/append copies and copy propagation sections could be easily moved to an independent file each one, keeping basically everything `static` except a handful of functions that are called by `hlsl_emit_bytecode()`. You have a small interface, but everything else you have to do in copy propagation doesn't need to interact with all the rest of `hlsl_codegen.c`, and splitting the file ensures that. If somebody wants to learn how copy propagation works, they can read `hlsl_copy_propagation.c` instead of having to potentially have to go through the whole of `hlsl_codegen.c`. This luckily already happened for `hlsl_constant_ops.c`. I wouldn't move each other pass in its own file because that would be too small, though. There is some sweet spot, which of course can change from person to person. As for `tpf.c`, the parser and writer parts are basically completely independent. They don't even share the internal representation. When I am working on the parser it's unlikely that I care about the writer at all. So having them in the same place is just confusing for me. Since they need to share some code (mostly the definitions) it makes sense to move that in a shader header, as it was before. If, say, I want to refactor how an hypothetical field `type` is used, then I'm likely to search through the file for that identifier. And if unrelated code sits in the same file, I'll have a lot more false positives. As I said above, that's probably a very personal thing, and having bigger files is not a blocker for me. Just wanted to share my point of view. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30845

1 0

[PATCH v2 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. -- v2: tasklist: Partially support '\fi' option. tasklist: Support '\fo' option. tasklist: Support '\nh' option. tasklist: Add basic functionality. https://gitlab.winehq.org/wine/wine/-/merge_requests/2688

2 5

[PATCH v2 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 -- v2: findstr: Add basic functionality. https://gitlab.winehq.org/wine/wine/-/merge_requests/2689

2 2

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

2025

2024

2023

2022

wine-gitlab April 2023