- wine-gitlab - winehq.org

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

2025

2024

2023

2022

wine-gitlab