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

Re: [PATCH v4 0/1] MR2675: mfreadwrite: Fix an address of operator typo. - approved
by Alexandre Julliard (＠julliard) 21 Apr '23

21 Apr '23

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

1 0

Re: [PATCH v2 0/1] MR2685: msvcrt: Fix crash when rethrowing after a non-C++ exception on x86_64. - approved
by Alexandre Julliard (＠julliard) 21 Apr '23

21 Apr '23

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

1 0

Re: [PATCH v11 0/5] MR2476: winewayland.drv: part 2: Display configuration enhancements - approved
by Alexandre Julliard (＠julliard) 21 Apr '23

21 Apr '23

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

1 0

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