- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR1623: rpcrt4/tests: Don't use an array of pointers in test_conf_complex_struct. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1653: msvcrt: Use operator_delete to free _Condition_variable queue nodes. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1640: mshtml: Fix realloc size vs element count mixup. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1647: mshtml: Annotate nsalloc with __WINE_(DEALLOC|MALLOC). - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1644: include: Annotate SnmpUtilMem(Re)Alloc with __WINE_(DEALLOC|MALLOC). - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v3 0/1] MR1645: include: Annotate ber_(alloc_t|bvdup|init) with __WINE_(DEALLOC|MALLOC). - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/11] MR1649: configure,winemac: Various macOS cleanups - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v3 0/1] MR1651: ntdll: Trace the name of critical sections which are released while not acquired. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v3 0/8] MR1629: ntdll: Finish heap refactoring in preparation for LFH support. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1655: inetcomm: Allocate PROPVARIANT memory with CoTaskMemAlloc. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1656: user32: Avoid freeing invalid pointers in WIN_CreateWindowEx. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1657: kernel32/tests: Avoid releasing invalid path pointer. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1658: advapi32/tests: Only free GetSecurityInfo pointer on success. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1648: d3d9/tests: Do not test the alpha channel in test_multisample_get_front_buffer_data(). - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/3] MR1650: wined3d: Misc patches. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1652: winspool: Define copy_file() only if CUPS is available. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/5] MR1617: Some more preparation before enabling long types in wined3d. - approved
by Alexandre Julliard (＠julliard) 02 Dec '22

02 Dec '22

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

1 0

Re: [PATCH v2 0/1] MR1552: winevulkan: Use direct calls for vkGetDescriptorEXT.
by Jinoh Kang (＠iamahuman) 02 Dec '22

02 Dec '22

> Would it help to return to the return address already on the PE stack? Are we sure it's never clobbered? > I guess that moving the ret address to rcx and push rcx / ret might be the same performance-wise as pushq 0x70(%rcx), ret. Yes, skipping rcx save will break existing tests. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18485

1 0

Re: [PATCH v2 0/1] MR1552: winevulkan: Use direct calls for vkGetDescriptorEXT.
by Zebediah Figura (＠zfigura) 02 Dec '22

02 Dec '22

On Fri Dec 2 20:30:47 2022 +0000, **** wrote: > Paul Gofman replied on the mailing list: > ``` > On 12/2/22 14:25, Gabriel Ivăncescu (@insn) wrote: > > On Fri Dec 2 18:57:30 2022 +0000, Jacek Caban wrote: > >>> This should help a bit more, does it make a difference for you? > >> My previous test wasn't really good for measuring it. > >> I hacked a micro-benchmark, which confirms that the patch improves > >> performance a lot. It was visible when doing "real" Vulkan > >> vkGetPhysicalDeviceProperties calls in a loop, but even cleaner when I > >> changed it further to make Unix side to be no-op. It closes most of the > >> gap between direct call and __wine_unix_call_dispatcher. Times recorded > >> for no-op calls: > >> - direct call: 5761 > >> - unpatched Wine: 13933 > >> - ret.diff: 6823 (55% time spent in __wine_unix_call_dispatcher, 29% in > >> PE vkGetPhysicalDeviceProperties) > >> Looks impressive! > > @gofman This isn't about setting it in rcx or not, it's about > mispairing `call`s and `ret`s, which basically means 100% mispredicted > because CPUs are optimized for it, so it couldn't do any speculative > execution past the return before. > > > Yes, I figured that much. Yet the attached diff removes the return > address from rcx in wine_syscall_dispatcher(), so I thought it makes > sense to note that it will break things. > ``` Would it help to return to the return address already on the PE stack? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18480

3 2

Re: [PATCH v2 0/1] MR1552: winevulkan: Use direct calls for vkGetDescriptorEXT.
by Gabriel Ivăncescu (＠insn) 02 Dec '22

02 Dec '22

On Fri Dec 2 18:57:30 2022 +0000, Jacek Caban wrote: > > This should help a bit more, does it make a difference for you? > My previous test wasn't really good for measuring it. > I hacked a micro-benchmark, which confirms that the patch improves > performance a lot. It was visible when doing "real" Vulkan > vkGetPhysicalDeviceProperties calls in a loop, but even cleaner when I > changed it further to make Unix side to be no-op. It closes most of the > gap between direct call and __wine_unix_call_dispatcher. Times recorded > for no-op calls: > - direct call: 5761 > - unpatched Wine: 13933 > - ret.diff: 6823 (55% time spent in __wine_unix_call_dispatcher, 29% in > PE vkGetPhysicalDeviceProperties) > Looks impressive! @gofman This isn't about setting it in rcx or not, it's about mispairing `call`s and `ret`s, which basically means 100% mispredicted because CPUs are optimized for it, so it couldn't do any speculative execution past the return before. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18478

2 1

Re: [PATCH v2 0/1] MR1552: winevulkan: Use direct calls for vkGetDescriptorEXT.
by Jacek Caban (＠jacek) 02 Dec '22

02 Dec '22

> This should help a bit more, does it make a difference for you? My previous test wasn't really good for measuring it. I hacked a micro-benchmark, which confirms that the patch improves performance a lot. It was visible when doing "real" Vulkan vkGetPhysicalDeviceProperties calls in a loop, but even cleaner when I changed it further to make Unix side to be no-op. It closes most of the gap between direct call and __wine_unix_call_dispatcher. Times recorded for no-op calls: - direct call: 5761 - unpatched Wine: 13933 - ret.diff: 6823 (55% time spent in __wine_unix_call_dispatcher, 29% in PE vkGetPhysicalDeviceProperties) Looks impressive! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18474

1 0

[PATCH v2 0/5] MR1622: d3d10/effect: Add support for more instructions.
by Nikolay Sivov (＠nsivov) 02 Dec '22

02 Dec '22

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: d3d10/effect: Add 'frc' instruction support for expressions. d3d10/effect: Add 'rcp' instruction support for expressions. d3d10/effect: Add 'div' instruction support for expressions. d3d10/effect: Add 'ftob' instruction support for expressions. d3d10/effect: Partially implement updates through value expressions. https://gitlab.winehq.org/wine/wine/-/merge_requests/1622

3 7

Re: [PATCH v2 0/1] MR1552: winevulkan: Use direct calls for vkGetDescriptorEXT.
by mbriar (＠mbriar) 02 Dec '22

02 Dec '22

> ret.diff > >This should help a bit more, does it make a difference for you? This does seem to help significantly, from 48000 up to 62000 ops/s. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18467

1 0

[PATCH v6 0/2] MR1618: gdiplus: improve performance of GdipScaleMatrix
by Bartosz Kosiorek (＠gang65) 02 Dec '22

02 Dec '22

-- v6: gdiplus: improve performance of matrix multiplication by unrolling loop. https://gitlab.winehq.org/wine/wine/-/merge_requests/1618

3 4

[PATCH v2 0/4] MR1635: jscript: Implement a Garbage Collector to deal with circular references.
by Gabriel Ivăncescu (＠insn) 02 Dec '22

02 Dec '22

Implement a basic GC based on the mark-and-sweep algorithm, without requiring manually specifying "roots", which vastly simplifies the management. For now, it is triggered every 30 seconds since it last finished, on a new object initialization. Better heuristics could be used in the future. The comments in the code should hopefully understand the high level logic of this approach without boilerplate details. I've tested it on FFXIV launcher (along with other patches from Proton to have it work) and it stops the massive memory leak successfully by itself, so at least it does its job properly. The second patch in the MR is just an optimization for a *very* common case. For artificial testing, one could use something like: ```javascript function leak() { var a = {}, b = {}; a.b = b; b.a = a; } ``` which creates a circular ref and will leak when the function returns. It also introduces and makes use of a "heap_stack", which prevents stack overflows on long chains. -- v2: jscript: Create the source function's 'prototype' prop object on demand. jscript: Run the garbage collector every 30 seconds on a new object jscript: Implement CollectGarbage(). jscript: Implement a Garbage Collector to deal with circular references. https://gitlab.winehq.org/wine/wine/-/merge_requests/1635

2 4

2025

2024

2023

2022

wine-gitlab