7 Nov
2022
7 Nov
'22
7:04 p.m.
On Sun Nov 6 15:22:54 2022 +0000, **** wrote:
Paul Gofman replied on the mailing list:
> On 6 Nov 2022, at 03:15, Anton Baskanov (@baskanov) <wine@gitlab.winehq.org> wrote: > > On Sat Nov 5 17:01:44 2022 +0000, **** wrote: >> Paul Gofman replied on the mailing list: >> \`\`\` >> 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? >> \`\`\` > I don't think we can just replace the spin locks with condition variable as it would add a significant overhead to the map/unmap calls. > No, it won’t add significant overhead. On Linux I don’t see how it can end up in any overhead, as SRW/condition variables end up in futex which spins itself when thinks it makes sense (on kernel side). Unfortunately on other platforms cond vars are less efficient, yet I personally guess that removing the spinlock would do more good than harm generally. > I tried replacing YieldProcessor() calls with SwitchToThread() You need a normal sync object there to try the effect, not tweaking the spin. Adding a hack to avoid cs thread is a dead end, I am afraid.
I don't know whether this patch makes sense or not, but we should probably at least try getting rid of the spinning first. I know Matteo was working on this; @Mystral, how's the progress on that work going?