https://bugs.winehq.org/show_bug.cgi?id=43519
--- Comment #3 from Robert Xiao nneonneo@gmail.com --- Created attachment 58914 --> https://bugs.winehq.org/attachment.cgi?id=58914 wined3d_fence_wait patch that seems to fix the issue
OK, I built from source (tag wine-2.14) and reproduced the bug. Then I patched wined3d_fence_wait by setting the timeout to something much less than ~(uint64_t)0xffff (but still very large, ~146 years) and the problem appears to be fixed.
I believe what's happening is that the timeout value is internally being adjusted by macOS somewhere, and that adjustment is not entirely predictable. The previous comment to avoid 0xfffffffffffffbff suggests that the adjustment is at least 1000 nanoseconds (1us), but my testing suggests that the adjustment could be as high as 65536 nanoseconds under certain circumstances.
To avoid any future issues, this patch uses a timeout of 2^62 nanoseconds. Why not 2^63? Because I'm paranoid that a "negative" value (one which could be interpreted as a negative signed 64-bit int) might cause other issues down the line. 2^62 is a long enough wait time to be safe, while being far enough from 2^63 or 2^64 that we shouldn't see any further issues.