June 2024 - wine-gitlab

[PATCH 0/6] MR5815: wined3d: Feed FFP shader constants through push constant buffers, part 1.
by Elizabeth Figura (＠zfigura) 27 Jun '24

27 Jun '24

This is another step towards getting render states out of wined3d_state. The idea here is similar to the "push constant buffers" used for d3d8/9 flat constants, and reuses the same infrastructure. That is, we pack all of the constants directly into a wined3d_buffer which is bound directly to the wined3d_state as a normal constant buffer. For SPIR-V this buffer is placed in the GPU, and the shader can simply access it directly, with no renderer-specific changes needed other than to determine the buffer's location. Currently this buffer is still stored on the CPU for GLSL, and the contents are pulled back from the sysmem resource pointer, instead of being pulled from state->render_states. Eventually, at least for Vulkan, the idea will be to write a FFP replacement shader which takes structured data (which, given the constraints of SPIR-V, is broadly necessary; we cannot simply upload individual named uniforms as we can with GLSL). In fact this will take the form of an HLSL shader compiled to Shader Model 2 bytecode. This allows us to, once again, reuse pretty much all of the existing infrastructure and avoid writing more backend-specific code, and has the effect that this FFP replacement works not only with SPIR-V but also with GLSL, allowing us to eventually remove the existing GLSL FFP pipeline, and enabling me to develop the HLSL FFP pipeline mainly using the GL renderer [which is useful since the Vulkan renderer is still missing a few other features]. The full branch is available at [1], and passes all tests when using the GL renderer. [1] https://gitlab.winehq.org/zfigura/wine/-/tree/himavant8 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5815

3 7

[PATCH 0/1] MR5367: gitlab: Add gdb to the docker images.
by Rémi Bernon (＠rbernon) 27 Jun '24

27 Jun '24

I'm currently, very unsuccessfully, tracking down a crash on the unix side that only happens on Gitlab, and although I'm still unable to reproduce it, it then would be useful to have gdb to attach on segfault when I will. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5367

3 4

[PATCH v3 0/1] MR5351: wined3d: Compile the clear compute shaders with D3DCompile().
by Giovanni Mascellani (＠giomasce) 27 Jun '24

27 Jun '24

-- v3: wined3d: Compile the clear compute shaders at runtime. https://gitlab.winehq.org/wine/wine/-/merge_requests/5351

4 3

[PATCH v6 0/3] MR5923: winegstreamer: Use affinity to determine 'max-threads' value.
by Brendan McGrath (＠redmcg) 27 Jun '24

27 Jun '24

GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the Steam Deck, this is configured to be 16 (which is double its number of logical cores). _SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it can create more threads than is useful, which ultimately wastes memory resources. Using affinity to set 'max-threads' addresses both these problems. -- v6: winegstreamer: Set MAX_THREADS to 4 for i386. winegstreamer: Use thread_count to determine 'max-threads' value. winegstreamer: Use process affinity to calculate thread_count. https://gitlab.winehq.org/wine/wine/-/merge_requests/5923

3 5

[PATCH 0/1] MR5941: xcopy: Handle switch options concatenated with path.
by Piotr Caban (＠piotr) 27 Jun '24

27 Jun '24

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

2 1

[PATCH 0/7] MR5930: win32u: Factor surface rect computation out of the drivers.
by Rémi Bernon (＠rbernon) 27 Jun '24

27 Jun '24

This clips surface rects which are larger than the virtual screen, keeping full window surfaces for one which are smaller. This makes sure that off-screen windows have valid pixels on overviews like macOS Exposé, or similarly, GNOME shell activities view. Supersedes both https://gitlab.winehq.org/wine/wine/-/merge_requests/5865 and https://gitlab.winehq.org/wine/wine/-/merge_requests/5878. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5930

3 8

Re: [PATCH v5 0/3] MR5923: winegstreamer: Use affinity to determine 'max-threads' value.
by Rémi Bernon (＠rbernon) 27 Jun '24

27 Jun '24

Rémi Bernon (@rbernon) commented about dlls/winegstreamer/unixlib.c: > return STATUS_UNSUCCESSFUL; > } > > + if (SUCCEEDED(NtQueryInformationProcess( GetCurrentProcess(), > + ProcessAffinityMask, &process_mask, sizeof(process_mask), NULL ))) > + thread_count = popcount(process_mask); > + else > + thread_count = 0; ```suggestion:-4+0 if (!NtQueryInformationProcess(GetCurrentProcess(), ProcessAffinityMask, &process_mask, sizeof(process_mask), NULL))) thread_count = popcount(process_mask); else thread_count = 0; ``` SUCCEEDED is for HRESULT, Nt API returns NTSTATUS and we often just check that it's 0. Also note the style fixes (no space in paren here, continuation indent is 8 spaces). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5923#note_74517

1 0

Re: [PATCH v5 0/3] MR5923: winegstreamer: Use affinity to determine 'max-threads' value.
by Rémi Bernon (＠rbernon) 27 Jun '24

27 Jun '24

Rémi Bernon (@rbernon) commented about dlls/winegstreamer/unixlib.c: > return true; > } > > +static ULONG popcount( ULONG val ) > +{ > +#if defined(__MINGW32__) > + return __builtin_popcount( val ); > +#else > + val -= val >> 1 & 0x55555555; > + val = (val & 0x33333333) + (val >> 2 & 0x33333333); > + return ((val + (val >> 4)) & 0x0f0f0f0f) * 0x01010101 >> 24; > +#endif > +} > + Well, now the __builtin_popcount path is never taken, because on the unix side it's not built with MinGW. There's a compiler check available already though. (Also mind the style change to match winegstreamer) ```suggestion:-10+0 static ULONG popcount(ULONG val) { #if HAVE___BUILTIN_POPCOUNT return __builtin_popcount(val); #else val -= val >> 1 & 0x55555555; val = (val & 0x33333333) + (val >> 2 & 0x33333333); return ((val + (val >> 4)) & 0x0f0f0f0f) * 0x01010101 >> 24; #endif } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5923#note_74516

1 0

[PATCH 0/1] MR5939: po: Update Lithuanian translation.
by Aurimas Fišeras (＠AurimasF) 27 Jun '24

27 Jun '24

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

2 1

Re: [PATCH v5 0/6] MR5870: mmdevapi: Implement loopback capture with winepulse backend.
by Davide Beatrici (＠davidebeatrici) 27 Jun '24

27 Jun '24

On Thu Jun 27 01:41:40 2024 +0000, Davide Beatrici wrote: > Agreed. We may eventually want to make use of something like [clang-format](https://clang.llvm.org/docs/ClangFormat.html). https://gitlab.winehq.org/wine/wine/-/merge_requests/5938 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5870#note_74514

1 0

2025

2024

2023

2022

wine-gitlab June 2024