April 2023 - wine-gitlab

Re: [PATCH v2 0/1] MR175: vkd3d-shader/tpf: Return unsigned int from hlsl_sm4_register_from_semantic(). - approved
by Alexandre Julliard (＠julliard) 21 Apr '23

21 Apr '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/175

1 0

Re: [PATCH v11 0/1] MR150: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops. - approved
by Alexandre Julliard (＠julliard) 21 Apr '23

21 Apr '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/150

1 0

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

21 Apr '23

-- v3: mfreadwrite: Fix an address of operator typo. https://gitlab.winehq.org/wine/wine/-/merge_requests/2675

3 3

[PATCH 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) 21 Apr '23

21 Apr '23

This replicates what seems to be happening when using sign() with shader model 3, which is roughly... ``` int pos = (int) (x > 0); int neg = -((int) (x < 0)); int result = pos + neg; ``` Fixes https://bugs.winehq.org/show_bug.cgi?id=54826 -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178

2 2

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

21 Apr '23

> 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. Mesa does this, and I suspect this is exactly the kind of thing that Henri finds distasteful. Personally it seems excessive to me as well, actually. There is a cost to having a lot of files, mostly in terms of slowing navigation a bit, and having to have more tabs open in one's editor. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30882

1 0

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

21 Apr '23

> > > 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. 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 :-/ > 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. I think it's less artificial than it looks, largely because we only have the one target (SPIRV) that would involve lowering transformations. Which is to say, there are a lot of lowering transformations that we could be doing, rather than (as I suspect we will initially) independently lowering things in GLSL and SPIRV. Similarly there are a lot of raising transformations we could be doing in HLSL -> smX that we currently aren't. I think there's also a lot to be said for being consistent about where we do a given transformation, but maybe I'm cargo-culting consistency a bit too hard. The effect of all this is that while it's not hard to adjust, it could eventually involve rewriting a *lot* of transformations, and so it seems like the kind of thing to think about now before we commit to one approach. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30881

1 0

[PATCH v2 0/5] MR2672: apisetschema: Add api-ms-win-core-psm-appnotify-l1-1-0.
by Mohamad Al-Jaf (＠maljaf) 21 Apr '23

21 Apr '23

Needed for Minecraft Legends. -- v2: apisetschema: Add api-ms-win-core-psm-appnotify-l1-1-0. twinapi.appcore: Add UnregisterAppStateChangeNotification stub. twinapi.appcore: Add RegisterAppStateChangeNotification stub. twinapi.appcore: Add stub DLL. include: Add appnotify.h file. https://gitlab.winehq.org/wine/wine/-/merge_requests/2672

6 13

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Zebediah Figura (＠zfigura) 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. Something like this. I find it hard to give an objective rationalization of *why* I want to split things up, but I think to a degree it comes down to the same reasons that large functions should be split up. It communicates to the reader that a piece of code is self-contained and should make sense by itself. On the other hand, when I see a large file, much like a large function, I can't help but think "can this be split up into a coherent set of pieces?" To a degree I guess it also is an intuitive judgement, and that can be poor. The cost of compiling large files shouldn't be discarded either, I don't think. E.g. our d3d12.c test file (or d3d11.c, and so on) doesn't really need to be split from an architectural standpoint—yes, the tests *can* stand alone, but there's no common thread segregating any one group of tests from another, and splitting *every* test into its own file seems excessive. No, if something makes me want to split up that file, it's that it takes multiple seconds to compile (depending on machine). I don't think there's any concern regarding navigation, at least on my part. That said, it's also something that feels like a waste of time to argue a lot about. I didn't feel like hlsl_constant_ops.c was particularly necessary, and would probably have just kept it in hlsl_codegen.c if it was just me, but it also doesn't feel like it's worth bikeshedding at all. Nor do I really intend to argue about splitting up the backend readers and writers here, just make a vague comment about code organization and move on. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30876

1 0

[PATCH 0/1] MR2685: msvcrt: Fix crash when rethrowing after a non-C++ exception on x86_64.
by Brendan Shanks (＠bshanks) 21 Apr '23

21 Apr '23

This fixes a crash seen with the .NET Framework 3.5 SP1 installer in a 64-bit prefix where `ServiceModelReg.exe` throws a C++ exception, it's rethrown again, then a CLR exception (`0xe0434f4d`) exception is thrown, and finally there's another C++ rethrow. At the last rethrow, `cxx_frame_handler()` detects the rethrow and sets `*rec` to the previous exception record, which is the CLR exception, not the C++ exception. If `+seh` is enabled, it then assumes `*rec` is a C++ exception and tries to TRACE info about it, which crashes. Move the rethrow detection before the exception type check, so the TRACEs are not done. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2685

3 2

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

4 9

2025

2024

2023

2022

wine-gitlab April 2023