- Wine-gitlab - list.winehq.org

[PATCH v2 0/4] MR9510: Draft: win32u: Implement timeline semaphore rewinding.
by Rémi Bernon 14 Jan '26

14 Jan '26

Pretty much the same kind of thing Proton does, this is only for non-shared semaphores for now. This creates timeline events backed by host timeline semaphores, for every wait and signal operation on a client timeline semaphore. Events are host timeline semaphores with monotonically increasing values. One event is a `(host semaphore, value)` unique tuple, and their value is incremented every time they get signaled. They can be reused right away as a different event, with the new value. Signaled events are queued to a per-device event list for reuse, as we cannot safely destroy them [^1] and as creating them might be costly. A thread is spawned for every device that uses timeline semaphores, monitoring the events and semaphore value changes. The semaphore wrapper keeps the current client semaphore value, which is read directly by `vkGetSemaphoreCounterValue`. CPU and GPU waits on the client semaphore are swapped with a wait on a timeline event, and GPU signals with a signal on a timeline event. CPU signals simply update the client semaphore value on the wrapper, signaling the timeline thread to check and notify any waiter. The timeline thread waits on signal events, coming from the GPU, and on a per-device semaphore for CPU notifications (wait/signal list updates, CPU-side signal). It will then signal any pending wait for a client semaphore value that has been reached, and removes timed out waits. --- For shared semaphores my idea is to use the client timeline semaphore host handle itself as a signal to notify other device threads of semaphore value changes, as the host semaphore is what is exported and imported in other devices. The timeline threads would wait on that semaphore too in addition to the signal events and thread notification semaphore. The main issue with shared semaphores actually comes from sharing the client semaphore values, so that they can be read from each device timeline threads as well as from other processes. There's two scenarios to support, one that is for in-process sharing which could perhaps keep the information locally, but we also need to support cross-process sharing so I think there's no other way than to involve wineserver. My idea then is to move shared semaphore client value to wineserver, which will cost a request on every signal and wait (and reading the value for waits could later be moved to a shared memory object). This will also allow us to implement `D3DKMTWaitForSynchronizationObjectFromCpu` which might be useful for D3D12 fence implementation as it'll allow us to translate a timeline semaphore wait to an asynchronous NT event signal. [^1]: Vulkan spec indicates that semaphores may only be destroyed *after* every operation that uses them has fully executed, and it's unclear whether signaling or waiting a semaphore is enough as an indicator for full execution or whether we would need to wait on a submit fence. -- v2: win32u: Implement timeline semaphore rewinding support. win32u: Make a copy of the timeline semaphore value arrays. win32u: Spawn a device thread for timeline semaphores. win32u: Hook more vulkan timeline semaphore functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9510

3 9

[PATCH v5 0/5] MR9690: win32u: Implement OpenGL shared resources import.
by Rémi Bernon (＠rbernon) 14 Jan '26

14 Jan '26

Supersedes !9616 and !9572 -- v5: win32u: Implement glImportSemaphoreWin32(Handle/Name)EXT for opaque handle types. win32u: Implement glImportMemoryWin32(Handle/Name)EXT for opaque handle types. win32u: Expose device LUID / nodes mask to opengl32. win32u: Enumerate system GPU devices from EGL devices. win32u: Make sysparam GPU devices less Vulkan specific. https://gitlab.winehq.org/wine/wine/-/merge_requests/9690

3 6

Re: [PATCH 0/1] MR9882: kernelbase: Trim whitespaces from the quoted 'cmdline'
by Yeshun Ye (＠yeyeshun) 14 Jan '26

14 Jan '26

On Wed Jan 14 08:31:55 2026 +0000, eric pouech wrote: > thanks to add a test case for this and don't use c++ comment in the code I apologize for the oversight, the "//" comments are meant to be deleted. Regarding the test cases, do I need to test the "CreateProcessInternalW" function? As for "get_file_name" and "find_exe_file", they are static and cannot be accessed in the test cases. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9882#note_126904

1 0

Re: [PATCH 0/1] MR9882: kernelbase: Trim whitespaces from the quoted 'cmdline'
by eric pouech (＠epo) 14 Jan '26

14 Jan '26

thanks to add a test case for this and don't use c++ comment in the code -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9882#note_126901

1 0

Re: [PATCH v11 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Etaash Mathamsetty (＠etaash.mathamsetty) 14 Jan '26

14 Jan '26

Looks good to me other than those 2 minor things. Not sure if that would be enough to get it merged tho -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9868#note_126889

1 0

Re: [PATCH v11 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Etaash Mathamsetty (＠etaash.mathamsetty) 14 Jan '26

14 Jan '26

```suggestion:-6+0 if (force_square) { shm_buffer = wayland_shm_buffer_create(square_length, square_length, WL_SHM_FORMAT_ARGB8888); } else { shm_buffer = wayland_shm_buffer_create(bm.bmWidth, bm.bmHeight, WL_SHM_FORMAT_ARGB8888); } ``` Minor formatting nitpick -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9868#note_126887

1 0

Re: [PATCH v11 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Etaash Mathamsetty (＠etaash.mathamsetty) 14 Jan '26

14 Jan '26

You can avoid variable s by modifying src directly -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9868#note_126888

1 0

[PATCH 0/1] MR9880: cmd: Replace '/' to '\' for path in 'WCMD_pushd'
by Yeshun Ye (＠yeyeshun) 14 Jan '26

14 Jan '26

The parameter of the 'pushd' command may contain the character ‘/’, which is compatible with Windows. Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9880

2 2

[PATCH 0/5] MR9879: wined3d: Various.
by Elizabeth Figura (＠zfigura) 14 Jan '26

14 Jan '26

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

2 5

[PATCH v10 0/4] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) 14 Jan '26

14 Jan '26

There are several motivations to enable ctor/dtor support: 1. ASan. This is not just about my wine-asan work, this is important for @bernhardu's PE asan work as well. The compiler generates ctors that poisons memory around global variables so misuses of them can be caught. This is the same both of our implementations of ASan. 2. Building third-party codebases against wine's CRT. This is not necessary for mingw-gcc or llvm-mingw, but the MSVC frontend of clang is another option for cross-compiling to Windows. However right now that requires Windows SDK. Bringing wine CRT to the point of being functional enough will give us another option. Could be useful for things like Proton. 3. (Controversial) Many dlls perform init/deinit tasks in `DllMain`. Some of them might benefit from a conversion to ctor/dtor. Since nothing in wine uses ctor/dtor right now, this change shouldn't have any impact by itself. -- v10: crt: Run MSVC constructors and destructors. winecrtend: New staticlib hosting fallbacks of initterm and initterm_e. winegcc: Merge .CRT sections for windows targets. winebuild: Generate start and end symbols for .CRT sections. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

3 11