- wine-gitlab - winehq.org

[PATCH 0/7] MR1752: Draft: RFC: Make syscall functions sysv_abi on x64
by Torge Matthies (＠tmatthies) 08 Dec '22

08 Dec '22

This removes 20 `movaps` instructions from every syscall that calls a sysv_abi function, plus an `and` for stack alignment and some other instructions depending on the function. In `NtAllocateLocallyUniqueId` for example this reduces the number of instructions from 63 to 36. I don't entirely understand the llvm-mca output but here are the before and after stats that it outputs for that function: Before Iterations: 100 Instructions: 6300 Total Cycles: 3335 Total uOps: 6300 Dispatch Width: 6 uOps Per Cycle: 1.89 IPC: 1.89 Block RThroughput: 15.0 After Iterations: 100 Instructions: 3600 Total Cycles: 1514 Total uOps: 3600 Dispatch Width: 6 uOps Per Cycle: 2.38 IPC: 2.38 Block RThroughput: 6.0 This currently depends on the stack being aligned by the syscall dispatcher, which afaict is the case if `sizeof(struct syscall_frame) % 16 == 0`. If that is not good enough I can add an `andq $~15,%rsp` somewhere. One question I have is whether we want to continue supporting CDECL syscalls (only `wine_server_call`, `wine_server_fd_to_handle` and `wine_server_handle_to_fd`)? If we do, this adds a bit of complexity to the syscall dispatcher, see the commit "FIXUP ntdll: Support CDECL syscalls." If we don't, and make those syscalls WINAPI instead, then for every call to those functions on x86 it seems to either change nothing or add one `add` instruction. However we of course lose the ability to make CDECL syscalls. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1752

3 9

[PATCH 0/1] MR1751: gdiplus: improve performance of GdipTranslateMatrix
by Bartosz Kosiorek (＠gang65) 08 Dec '22

08 Dec '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1751

2 1

[PATCH v2 0/4] MR1727: Enable long types in wined3d/texture.c
by eric pouech (＠epo) 08 Dec '22

08 Dec '22

-- v2: wined3d: Enable long types in texture.c. wined3d: Reduce usage of long integral types in texture.c. wined3d: Change stencil parameter type in blitter_clear() method. wined3d: Get/set texture's level_count and lod as unsigned int. https://gitlab.winehq.org/wine/wine/-/merge_requests/1727

3 6

[PATCH 0/2] MR1739: Enable long types in wined3d/nvidia_texture_shader.c
by eric pouech (＠epo) 08 Dec '22

08 Dec '22

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

3 3

[PATCH 0/2] MR1738: Enable long types in wined3d/shader.c.
by eric pouech (＠epo) 08 Dec '22

08 Dec '22

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

3 3

[PATCH 0/2] MR1737: Enable long types in wined3d/utils.c
by eric pouech (＠epo) 08 Dec '22

08 Dec '22

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

3 3

[PATCH v4 0/5] MR54: vkd3d-shader/hlsl: Initialize static variables to 0 by default.
by Francisco Casas (＠fcasas) 08 Dec '22

08 Dec '22

We are currently not initializing static values to zero by default. Consider the following shader: ```hlsl static float4 va; float4 main() : sv_target { return va; } ``` we get the following output: ``` ps_5_0 dcl_output o0.xyzw dcl_temps 2 mov r0.xyzw, r1.xyzw mov o0.xyzw, r0.xyzw ret ``` where r1.xyzw is not initialized. This patch solves this by assigning the static variable the value of an uint 0, and thus, relying on complex broadcasts. This seems to be the behaviour of the the native compiler, since it retrieves the following error on a shader that lacks an initializer on a data type with object components: ``` error X3017: cannot convert from 'uint' to 'struct <unnamed>' ``` -- v4: vkd3d-shader/hlsl: Allow uninitialized static objects. vkd3d-shader/hlsl: Validate that non-uniform objects are not referenced. tests: Add additional object references tests. tests: Test proper initialization of static structs to zero. vkd3d-shader/hlsl: Initialize static variables to 0 by default. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/54

4 7

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

08 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 last 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. -- v6: 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. jscript: Use a jsdisp to hold refs for scopes. https://gitlab.winehq.org/wine/wine/-/merge_requests/1635

3 7

Re: [PATCH v2 0/1] MR1552: winevulkan: Use direct calls for vkGetDescriptorEXT. - closed
by Georg Lehmann (＠DadSchoorse) 08 Dec '22

08 Dec '22

This merge request was closed by Georg Lehmann. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1552

1 0

[PATCH 0/1] MR1748: winevulkan: Update to VK spec version 1.3.237.
by Georg Lehmann (＠DadSchoorse) 08 Dec '22

08 Dec '22

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

2 1

2025

2024

2023

2022

wine-gitlab