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

Re: [PATCH v5 0/1] MR2413: comctl32: Fix the problem that listview cannot display all files.
by Nikolay Sivov (＠nsivov) April 22, 2023

April 22, 2023

On Fri Mar 24 02:49:18 2023 +0000, Zhao Yi wrote: > I have just updated my commit message and you can review it again. Again, MR description is what it should look like. What you have for commit message duplicates code changes. New paragraph in commit message mixes together unrelated things - it's talking about shellview case it seems, which is not something Listview is directly related to. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2413#note_30948

1 0

[PATCH v5 0/2] MR2618: ntdll: Increment offset by len in build_clr_surrogate_section.
by Alex Henrie (＠alexhenrie) April 22, 2023

April 22, 2023

Instead of multiplying it by 2. I don't know how this ever worked. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54808 -- v5: ntdll: Increment offset by len in build_clr_surrogate_section. kernel32/tests: Check that lpSectionBase != NULL before dereferencing. https://gitlab.winehq.org/wine/wine/-/merge_requests/2618

4 5

[PATCH v9 0/1] MR135: vkd3d-shader/hlsl: Add support for sample index argument in Load().
by Nikolay Sivov (＠nsivov) April 22, 2023

April 22, 2023

-- v9: vkd3d-shader/hlsl: Add support for sample index argument in Load(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/135

2 1

[PATCH v6 0/10] MR2669: wine{alsa,coreaudio,oss,pulse}: Move AudioSessionControl into mmdevapi.
by Davide Beatrici (＠davidebeatrici) April 22, 2023

April 22, 2023

-- v6: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Use mmdevapi's AudioSessionControl. winepulse: Implement function to (un)lock sessions. wineoss: Implement function to (un)lock sessions. winecoreaudio: Implement function to (un)lock sessions. winealsa: Implement function to (un)lock sessions. mmdevapi: Implement AudioSessionControl. mmdevapi: Implement AudioClient stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 22

[PATCH 0/4] MR2695: wine{alsa,coreaudio,oss,pulse}: Use dedicated macros to call interface functions.
by Davide Beatrici (＠davidebeatrici) April 22, 2023

April 22, 2023

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

3 5

[PATCH 0/4] MR2694: wine{alsa,coreaudio,oss,pulse}: Implement functions to lock and unlock sessions.
by Davide Beatrici (＠davidebeatrici) April 22, 2023

April 22, 2023

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

3 5

[PATCH 0/7] MR2693: gdi32: EMF palette recording improvements.
by Piotr Caban (＠piotr) April 22, 2023

April 22, 2023

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

4 9

[PATCH v2 0/10] MR159: vkd3d-shader/hlsl: Broaden resources support v2, part 2.
by Francisco Casas (＠fcasas) April 21, 2023

April 21, 2023

Mainly comprises support for allocating arrays of resources, and loading from them, for both SM1 and SM4. -- v2: vkd3d-shader/hlsl: Support resource arrays when writting SM4. vkd3d-shader/hlsl: Write resource loads in SM1. vkd3d-shader/hlsl: Write sampler declarations in SM1. vkd3d-shader/hlsl: Track objects sampling dimension. vkd3d-shader/hlsl: Track object components usage and allocate registers accordingly. tests: Test objects as parameters. vkd3d-shader/hlsl: Skip object components when creating input/output copies. vkd3d-shader/hlsl: Add fixme for uniform copies for objects within structs. vkd3d-shader/hlsl: Support multiple-register variables in object regsets. tests: Add additional texture array register reservation tests. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/159

4 29

[PATCH v4 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) April 21, 2023

April 21, 2023

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 -- v4: tests: Add tests for sign() intrinsic. vkd3d-shader/hlsl: Add support for sign() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178

2 3

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

April 21, 2023

> 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. Right, I don't disagree; I'm generally in favour of thinking things through. What I'm saying is that right now we haven't committed to a particular approach yet, largely because there doesn't appear to be a clear winner; it mostly just seems like different sets of trade-offs at this point. If you have a preference, and want to have a go at moving things in that direction, by all means go ahead. :) -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_30909

1 0

[PATCH v3 0/2] MR178: vkd3d-shader/hlsl: Add support for sign() intrinsic.
by Ethan Lee (＠flibitijibibo) April 21, 2023

April 21, 2023

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 -- v3: tests: Add tests for sign() intrinsic. vkd3d-shader/hlsl: Add support for sign() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/178

2 2

[PATCH v8 0/1] MR135: vkd3d-shader/hlsl: Add support for sample index argument in Load().
by Nikolay Sivov (＠nsivov) April 21, 2023

April 21, 2023

-- v8: vkd3d-shader/hlsl: Add support for sample index argument in Load(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/135

2 1

[PATCH 0/4] MR2682: uiautomationcore: Focused element retrieval, and a deadlock fix.
by Connor McAdams (＠cmcadams) April 21, 2023

April 21, 2023

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

3 8

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

April 21, 2023

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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

-- 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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

> 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) April 21, 2023

April 21, 2023

> > > 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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

> > 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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

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

[PATCH 0/11] MR2691: mshtml: More ref leak fixes.
by Gabriel Ivăncescu April 21, 2023

April 21, 2023

This should finally fix the ref leaks that keep all gecko nsDocuments alive even on the most basic docs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2691

2 14

[PATCH v26 0/4] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) April 21, 2023

April 21, 2023

Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v26: ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match. ntdll: Only infer hidden attribute from file name if xattr is not present. ntdll: Handle hidden file names inside get_file_info instead of after it. ntdll/tests: Add test for file attributes of files with names beginning with a dot. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

2 6

[PATCH 0/1] MR175: vkd3d-shader/tpf: Return unsigned int from hlsl_sm4_register_from_semantic().
by Zebediah Figura (＠zfigura) April 21, 2023

April 21, 2023

Fix a compile warning: ../vkd3d/libs/vkd3d-shader/hlsl_codegen.c: In function 'allocate_semantic_register': ../vkd3d/libs/vkd3d-shader/hlsl_codegen.c:2947:85: error: passing argument 4 of 'hlsl_sm4_register_from_semantic' from incompatible pointer type [-Werror=incompatible-pointer-types] 2947 | if ((builtin = hlsl_sm4_register_from_semantic(ctx, &var->semantic, output, &type, NULL, &has_idx))) | ^~~~~ | | | unsigned int * In file included from ../vkd3d/libs/vkd3d-shader/hlsl_codegen.c:21: ../vkd3d/libs/vkd3d-shader/hlsl.h:1171:52: note: expected 'enum vkd3d_sm4_register_type *' but argument is of type 'unsigned int *' 1171 | bool output, enum vkd3d_sm4_register_type *type, enum vkd3d_sm4_swizzle_type *swizzle_type, bool *has_idx); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/175

4 3

[PATCH v10 0/1] MR150: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops.
by Nikolay Sivov (＠nsivov) April 21, 2023

April 21, 2023

-- v10: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/150

3 3

[PATCH v4 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias().
by Nikolay Sivov (＠nsivov) April 21, 2023

April 21, 2023

-- v4: vkd3d-shader/hlsl: Implement SampleBias() method. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/172

2 2

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

April 21, 2023

-- 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) April 21, 2023

April 21, 2023

> 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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

> 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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

-- 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) April 21, 2023

April 21, 2023

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) April 21, 2023

April 21, 2023

-- 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) April 21, 2023

April 21, 2023

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) April 20, 2023

April 20, 2023

-- 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) April 20, 2023

April 20, 2023

-- 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) April 20, 2023

April 20, 2023

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) April 20, 2023

April 20, 2023

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

[PATCH 0/4] MR168: hlsl: ps_1_* outputs.
by Zebediah Figura (＠zfigura) April 20, 2023

April 20, 2023

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

3 9

Re: [PATCH v2 0/1] MR2683: vkd3d: Update the version information for release 1.7. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v2 0/5] MR2680: wineps: Support more spool file records (palettes, DIBs) - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v2 0/1] MR2681: kernel32/tests: Fix the ScrollConsoleScreenBuffer() tests on Windows 10 1909. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v3 0/2] MR2649: wininet/tests: Add constants for DetectAutoProxyUrl() and more proxy tests. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v2 0/1] MR173: tests/shader_runner: Remove a redundant vkd3d_test_pop_context(). - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v3 0/5] MR169: hlsl: Return hlsl_ir_node pointers from instruction constructors, part 2. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

Re: [PATCH v4 0/2] MR167: vkd3d: Do not skip all viewports if one is invalid. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

[PATCH v5 0/10] MR2669: wine{alsa,coreaudio,oss,pulse}: Move AudioSessionControl into mmdevapi.
by Davide Beatrici (＠davidebeatrici) April 20, 2023

April 20, 2023

-- v5: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Use mmdevapi's AudioSessionControl. mmdevapi: Implement AudioSessionControl. mmdevapi: Implement AudioClient stub. winepulse: Implement function to (un)lock sessions. wineoss: Implement function to (un)lock sessions. winecoreaudio: Implement function to (un)lock sessions. winealsa: Implement function to (un)lock sessions. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

2 10

[PATCH v4 0/10] MR2669: wine{alsa,coreaudio,oss,pulse}: Move AudioSessionControl into mmdevapi.
by Davide Beatrici (＠davidebeatrici) April 20, 2023

April 20, 2023

-- v4: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Use mmdevapi's AudioSessionControl. winepulse: Implement function to (un)lock sessions. wineoss: Implement function to (un)lock sessions. winecoreaudio: Implement function to (un)lock sessions. winealsa: Implement function to (un)lock sessions. mmdevapi: Implement AudioSessionControl. mmdevapi: Implement AudioClient stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

2 11

[PATCH v3 0/10] MR2669: wine{alsa,coreaudio,oss,pulse}: Move AudioSessionControl into mmdevapi.
by Davide Beatrici (＠davidebeatrici) April 20, 2023

April 20, 2023

-- v3: winepulse: Use mmdevapi's AudioSessionControl. wineoss: Use mmdevapi's AudioSessionControl. winecoreaudio: Use mmdevapi's AudioSessionControl. winealsa: Use mmdevapi's AudioSessionControl. winepulse: Implement function to (un)lock sessions. wineoss: Implement function to (un)lock sessions. winecoreaudio: Implement function to (un)lock sessions. winealsa: Implement function to (un)lock sessions. mmdevapi: Implement AudioSessionControl. mmdevapi: Implement AudioClient stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2669

3 13

[PATCH 0/1] MR2683: vkd3d: Update the version information for release 1.7.
by Henri Verbeet (＠hverbeet) April 20, 2023

April 20, 2023

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

2 1

[PATCH v3 0/4] MR156: vkd3d: Use atomic exchange for descriptor writes.
by Conor McCarthy (＠cmccarthy) April 20, 2023

April 20, 2023

-- v3: vkd3d: Buffer descriptor writes. vkd3d: Use atomic exchange for descriptor writes. vkd3d: Delay writing Vulkan descriptors until submitted to a queue. vkd3d: Ensure descriptors are pointer aligned. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/156

3 5

[PATCH 0/1] MR173: tests/shader_runner: Remove a redundant vkd3d_test_pop_context().
by Zebediah Figura (＠zfigura) April 20, 2023

April 20, 2023

We already popped the context here. Move the break inside the previous if to make control flow a little clearer. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/173

4 3

[PATCH 0/5] MR2680: wineps: Support more spool file records (palettes, DIBs)
by Piotr Caban (＠piotr) April 20, 2023

April 20, 2023

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

3 6

[PATCH 0/1] MR2681: kernel32/tests: Fix the ScrollConsoleScreenBuffer() tests on Windows 10 1909.
by Francois Gouget (＠fgouget) April 20, 2023

April 20, 2023

On Windows 10 1909 ScrollConsoleScreenBufferA() returns an error if the destination is not within the clip rectangle but still modifies the console buffer as expected! So mark this behavior as very_broken(). Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54871 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2681

2 1

[PATCH v4 0/2] MR2618: ntdll: Increment offset by len in build_clr_surrogate_section.
by Alex Henrie (＠alexhenrie) April 20, 2023

April 20, 2023

Instead of multiplying it by 2. I don't know how this ever worked. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54808 -- v4: ntdll: Increment offset by len in build_clr_surrogate_section. kernel32/tests: Test internal consistency of activation context headers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2618

4 6

[PATCH v10 0/5] MR2476: winewayland.drv: part 2: Display configuration enhancements
by Alexandros Frantzis (＠afrantzis) April 20, 2023

April 20, 2023

This second MR in the Wayland series adds display configuration related enhancements, including providing more display information (like a proper/consistent name and position). To get additional information from the Wayland compositor we need to use a protocol from the wayland-protocols collection, so we introduce support in the build system for protocol .xml files and also include the protocol file in our winewayland.drv sources. Since Wayland provides output coordinates only in the compositor logical space, we need to infer the monitor coordinates in the physical pixel space (so that apps can take advantage of the full/native monitor resolution), based on logical coordinates and the current mode. The last commit in the series introduces a best-effort algorithm for this. For people that are curious about this algorithm, or want to experiment a bit: I have created an independent ad-hoc test suite for this algorithm at: https://gitlab.collabora.com/alf/wine-wayland-outputs The core idea of the algorithm is to start with a placement that uses the logical positions, and iteratively move outputs away from others in particular directions until any non-inherent (i.e., not present in the logical space) overlaps have been resolved. Thanks! -- v10: winewayland.drv: Infer and report Windows monitor positions. winewayland.drv: Basic support for Windows monitor positioning. winewayland.drv: Use the output name reported by the compositor. tools: Support building Wayland protocol source files. https://gitlab.winehq.org/wine/wine/-/merge_requests/2476

3 7

[PATCH 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Henri Verbeet (＠hverbeet) April 20, 2023

April 20, 2023

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

3 6

[PATCH v2 0/1] MR2679: msvcrt110: Add stub _Cancellation_beacon::_Cancellation_beacon()
by Vijay Kiran Kamuju (＠infyquest) April 20, 2023

April 20, 2023

Required for Forza Horizon 4 and other games https://bugs.winehq.org/show_bug.cgi?id=54756 -- v2: Add stub _Cancellation_beacon::_Cancellation_beacon() https://gitlab.winehq.org/wine/wine/-/merge_requests/2679

3 2

[PATCH 0/1] MR2679: msvcrt110: Add stub _Cancellation_beacon::_Cancellation_beacon()
by Vijay Kiran Kamuju (＠infyquest) April 20, 2023

April 20, 2023

Required for Forza Horizon 4 and other games https://bugs.winehq.org/show_bug.cgi?id=54756 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2679

3 2

Re: [PATCH v3 0/82] MR2585: Release 8.0.1. - approved
by Alexandre Julliard (＠julliard) April 20, 2023

April 20, 2023

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

1 0

[PATCH v9 0/5] MR2476: winewayland.drv: part 2: Display configuration enhancements
by Alexandros Frantzis (＠afrantzis) April 20, 2023

April 20, 2023

This second MR in the Wayland series adds display configuration related enhancements, including providing more display information (like a proper/consistent name and position). To get additional information from the Wayland compositor we need to use a protocol from the wayland-protocols collection, so we introduce support in the build system for protocol .xml files and also include the protocol file in our winewayland.drv sources. Since Wayland provides output coordinates only in the compositor logical space, we need to infer the monitor coordinates in the physical pixel space (so that apps can take advantage of the full/native monitor resolution), based on logical coordinates and the current mode. The last commit in the series introduces a best-effort algorithm for this. For people that are curious about this algorithm, or want to experiment a bit: I have created an independent ad-hoc test suite for this algorithm at: https://gitlab.collabora.com/alf/wine-wayland-outputs The core idea of the algorithm is to start with a placement that uses the logical positions, and iteratively move outputs away from others in particular directions until any non-inherent (i.e., not present in the logical space) overlaps have been resolved. Thanks! -- v9: winewayland.drv: Infer and report Windows monitor positions. winewayland.drv: Basic support for Windows monitor positioning. winewayland.drv: Use the output name reported by the compositor. tools: Support building Wayland protocol source files. https://gitlab.winehq.org/wine/wine/-/merge_requests/2476

2 8

[PATCH v2 0/5] MR169: hlsl: Return hlsl_ir_node pointers from instruction constructors, part 2.
by Zebediah Figura (＠zfigura) April 20, 2023

April 20, 2023

-- v2: vkd3d-shader/hlsl: Remove an unused local variable from create_loop(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_load_component(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from add_load_component(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_jump(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_int_constant(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/169

3 6

[PATCH v3 0/2] MR167: vkd3d: Do not skip all viewports if one is invalid.
by Conor McCarthy (＠cmccarthy) April 20, 2023

April 20, 2023

-- v3: vkd3d: Treat negative viewport widths as invalid. vkd3d: Do not skip all viewports if one is invalid. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/167

3 3

[PATCH 0/4] MR2677: wine{alsa,coreaudio,oss,pulse}: Symlink mmdevapi headers.
by Davide Beatrici (＠davidebeatrici) April 20, 2023

April 20, 2023

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

3 6

[PATCH v3 0/2] MR2618: ntdll: Increment offset by len in build_clr_surrogate_section.
by Alex Henrie (＠alexhenrie) April 20, 2023

April 20, 2023

Instead of multiplying it by 2. I don't know how this ever worked. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54808 -- v3: ntdll: Increment offset by len in build_clr_surrogate_section. kernel32/tests: Test internal consistency of activation context headers. https://gitlab.winehq.org/wine/wine/-/merge_requests/2618

3 4

[PATCH 0/1] MR2667: ntdll: Reuse old async fileio structures if possible.
by Zebediah Figura (＠zfigura) April 20, 2023

April 20, 2023

This reportedly alleviates stutter when joining a match in Forza Horizon 5. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2667

2 3

Re: [PATCH v4 0/4] MR2670: uiautomationcore: Implement root element retrieval and add support for cache request normalization. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v2 0/1] MR2673: dxgi: Update TRACE in dxgi_device_create_resource(). - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v5 0/6] MR2435: Fix activation context switching from SwitchToFiber(). - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v2 0/1] MR2663: dnsapi/tests: Make DnsQuery()'s CNAME tests more compatible with CDNs. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v2 0/7] MR2671: wineps: Handle EMR_EXTTEXTOUTW record in spool files. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v3 0/1] MR2630: wined3d: Implement shader_extract_from_dxbc() on top of vkd3d_shader_parse_dxbc(). - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

[PATCH v2 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias().
by Nikolay Sivov (＠nsivov) April 19, 2023

April 19, 2023

-- v2: 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

2 2

Re: [PATCH v4 0/3] MR2455: wined3d: Avoid VK_IMAGE_LAYOUT_GENERAL. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

[PATCH 0/8] MR159: vkd3d-shader/hlsl: Broaden resources support v2, part 2.
by Francisco Casas (＠fcasas) April 19, 2023

April 19, 2023

Mainly comprises support for allocating arrays of resources, and loading from them, for both SM1 and SM4. The `vkd3d-shader/hlsl: Skip object components when creating input/output copies.` patch can be dropped if !148 is accepted first. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/159

4 47

Re: [PATCH v7 0/2] MR157: vkd3d-shader/hlsl: Add support for any() intrinsic. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v2 0/1] MR166: vkd3d-shader/hlsl: Fix missing extern resource names. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v3 0/1] MR165: tests: Pop the shader runner context after processing the current section. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v3 0/5] MR163: vkd3d: Handle null GPU addresses. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v3 0/2] MR162: vkd3d-shader/hlsl: Handle regset names in register() and packoffset() as case-insensitive. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v2 0/1] MR160: vkd3d-shader/spirv: Do not declare resources as multisampled if the sample count is 1. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

Re: [PATCH v5 0/1] MR158: vkd3d-shader: Consistently pass location structure by pointer. - approved
by Alexandre Julliard (＠julliard) April 19, 2023

April 19, 2023

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

1 0

[PATCH v2 0/2] MR2618: ntdll: Increment offset by len in build_clr_surrogate_section.
by Alex Henrie (＠alexhenrie) April 19, 2023

April 19, 2023

Instead of multiplying it by 2. I don't know how this ever worked. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54808 -- v2: ntdll: Increment offset by len in build_clr_surrogate_section. kernel32/tests: Check that lpSectionBase != NULL before dereferencing. https://gitlab.winehq.org/wine/wine/-/merge_requests/2618

4 9

[PATCH v3 0/4] MR2670: uiautomationcore: Implement root element retrieval and add support for cache request normalization.
by Connor McAdams (＠cmcadams) April 19, 2023

April 19, 2023

-- v3: uiautomationcore: Add normalization navigation to UiaGetUpdatedCache. https://gitlab.winehq.org/wine/wine/-/merge_requests/2670

3 7

[PATCH v3 0/3] MR2455: wined3d: Avoid VK_IMAGE_LAYOUT_GENERAL.
by Stefan Dösinger April 19, 2023

April 19, 2023

This series aims to improve GPU-side performance by avoiding VK_IMAGE_LAYOUT_GENERAL for textures that are used as render target and shader resource view. To do so, we have to transition them between VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL and VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL depending on use (and likewise for depth stencils). It improves performance of Rocket League from 80 fps to 100 fps in a GPU limited configuration on my Radeon Polaris GPU. This MR is marked as draft for now because I am not convinced by patch 3 yet. For actual submission I think I'll create separate MRs for patches 1-3 and 4-8. Patch 2 introduces a validation layer error in the d3d11 tests that gets fixed in patch 3. No new test failures are introduced, although none of the existing ones are fixed either. -- v3: wined3d: Fall back to general layout if necessary. wined3d: Avoid VK_IMAGE_LAYOUT_GENERAL. wined3d: Sync depth stencils to both early and late depth test. https://gitlab.winehq.org/wine/wine/-/merge_requests/2455

3 9

[PATCH v2 0/2] MR2649: wininet/tests: Add constants for DetectAutoProxyUrl() and more proxy tests.
by Francois Gouget (＠fgouget) April 19, 2023

April 19, 2023

--- See also https://bugs.winehq.org/show_bug.cgi?id=54818 -- v2: wininet/tests: Add more proxy tests. wininet: Add constants for DetectAutoProxyUrl(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2649

3 5

[PATCH 0/2] MR172: vkd3d-shader/hlsl: Implement SampleBias().
by Nikolay Sivov (＠nsivov) April 19, 2023

April 19, 2023

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

2 2

[PATCH v5 0/10] MR2637: winex11: Use messages instead of user callbacks and handle them in the default IME UI window procedure.
by Rémi Bernon April 19, 2023

April 19, 2023

-- v5: winex11: Use EM_REPLACESEL to set IME composition strings. winex11: Always zero terminate XIM composition string. winex11: Compute preedit text buffer sizes in WCHAR units. winex11: Use an IME UI message to set composition status. imm32: Only send GCS_CURSORPOS when cursor position changes. winex11: Use an IME UI message to set cursor pos. winex11: Use an IME UI message to get cursor pos. winex11: Use an IME UI message to set open status. win32u: Keep the builtin IME UI window in win32u struct imc. imm32: Add a struct ime field to track whether IME is builtin. https://gitlab.winehq.org/wine/wine/-/merge_requests/2637

2 15

[PATCH v6 0/2] MR157: vkd3d-shader/hlsl: Add support for any() intrinsic.
by Ethan Lee (＠flibitijibibo) April 19, 2023

April 19, 2023

For now, this is limited to float and bool, scalar and vector. All other types are unsupported. Fixes https://bugs.winehq.org/show_bug.cgi?id=54777 -- v6: tests: Add tests for any() intrinsic. vkd3d-shader/hlsl: Add support for any() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/157

3 4

Re: [PATCH v2 0/1] MR171: Initialize a pointer for MSVC.
by Henri Verbeet (＠hverbeet) April 19, 2023

April 19, 2023

As an aside, I should note that MSVC is not officially a supported compiler for vkd3d. I'll happily take patches to make it work provided they're not too unreasonable, but if it breaks, it breaks. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/171#note_30537

1 0

Re: [PATCH v2 0/1] MR171: Initialize a pointer for MSVC.
by Henri Verbeet (＠hverbeet) April 19, 2023

April 19, 2023

> The patch subject is also missing a component prefix ("vkd3d-shader/hlsl:"). And on that note, the subject line could be a fair bit more specific; "Initialize a pointer" doesn't tell someone reading the commit log a whole lot. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/171#note_30536

1 0

[PATCH v9 0/1] MR150: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops.
by Nikolay Sivov (＠nsivov) April 19, 2023

April 19, 2023

-- v9: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/150

5 5