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
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
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.
--
v3: 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
On Wed Jun 26 07:26:50 2024 +0000, Zhiyi Zhang wrote:
> This looks correct at first glance. Do you have an application affected
> by this? It seems to me changing this only reduces some time and -1 will
> be returned if it's the last item.
Yes, I have. It fails on asserting return value of sending LVM_GETNEXTITEM message. I agree about aftereffect of this fix. Anyway, for me it doesn't make sense to handle ahead of time incorrect item (== infoPtr->nItemCount).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5909#note_74482
Previously it was assumed that synchronous I/O fills the 64-bit IOSB, and
asynchronous I/O fills the 32-bit IOSB.
As the ntdll:wow64 tests show, this is incorrect. I/O on an overlapped handle,
whether it is synchronous or not, fills the 32-bit IOSB, and I/O on a
non-overlapped handle always fills the 64-bit IOSB.
The first half is important, since completion can be signaled before we even
return from the initial I/O call [NtReadFile() etc.] Filling the IOSB after
signaling completion is the cause of bug 56389. This patch series fixes that.
The second discrepancy does not cause any bugs, as far as I can see, and is
a bit harder to fix anyway. It is therefore not addressed by this patch series.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56389
--
v2: ntdll: Always fill the 32-bit iosb for overlapped handles, for regular read/write.
ntdll: Always fill the 32-bit iosb for overlapped handles, in set_async_direct_result().
ntdll: Always fill the 32-bit iosb for overlapped handles, in file_complete_async().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5926
--
v4: mmdevapi/tests: Add test for capturing render loopback.
winepulse.drv: Implement pulse_get_loopback_capture_device().
winepulse.drv: Factor out wait_pa_operation_complete().
mmdevapi: Stub AUDCLNT_STREAMFLAGS_LOOPBACK support.
mmdevapi: Adjust timing after main loop start in client_Initialize().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5870