This will unlikely do it for a generic case. Affinity can be change after CS thread is created (both ways). Besides, cs thread serves other purposes besides optimization (e. g., shader compilation used to break on nv drivers sometimes when non-default FPU setup is used). I guess a better thing to do would be maybe to get rid of spinlocking in cs thread which should also be helping in favour of SRW lock / condition variable?
On 5 Nov 2022, at 10:39, Anton Baskanov wine@gitlab.winehq.org wrote:
From: Anton Baskanov baskanov@gmail.com
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45893 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47767 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44546
dlls/wined3d/cs.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/dlls/wined3d/cs.c b/dlls/wined3d/cs.c index 8ee7e7fccc9..b2f682e9837 100644 --- a/dlls/wined3d/cs.c +++ b/dlls/wined3d/cs.c @@ -3431,6 +3431,19 @@ struct wined3d_cs *wined3d_cs_create(struct wined3d_device *device, } }
- if (wined3d_settings.cs_multithreaded & WINED3D_CSMT_ENABLE)
- {
DWORD_PTR affinity_mask;if (GetProcessAffinityMask(GetCurrentProcess(), &affinity_mask, NULL)){if (!(affinity_mask & (affinity_mask - 1))){WARN("Disabling CSMT, process is running on a single processor.\n");wined3d_settings.cs_multithreaded &= ~WINED3D_CSMT_ENABLE;}}- }
- if (wined3d_settings.cs_multithreaded & WINED3D_CSMT_ENABLE && !RtlIsCriticalSectionLockedByThread(NtCurrentTeb()->Peb->LoaderLock)) {
-- GitLab