Jan. 12, 2026
5:34 p.m.
On Mon Jan 12 17:11:37 2026 +0000, Marc-Aurel Zent wrote: > I was having an issue with a proprietary modern dotnet application that > mixed tick count and system time calculation and hung up if the two > diverged too much... > If this is indeed an unsolvable problem for winevulkan at the moment, > then maybe this is worth reverting, although unless I am > misunderstanding something `InterruptTimeBias` is now exactly what is > needed to convert between CLOCK_MONOTONIC and QPC time; and I don't > believe there is a much more accurate way to implement this otherwise > (and in practice this also does not fluctuate at all really after a few > iterations of taking the maximum of CLOCK_BOOTTIME - CLOCK_MONOTONIC > without suspending the system). > Of note is also that on macOS tick counts have included suspend ticks > for quite a while so the winevulkan issue this is currently causing has > been present there for years (and it would be nice if it could be fixed > as well). Perhaps winevulkan could use InterruptTimeBias. But computing that discretely (not synced with actual current time reported), and doing it this way is probably not an option, that is too inaccurate and subject to random jumps and that is going to affect not only vulkan but also system time queries and user shared data info. Maybe a more robust way would be something like: - use CLOCK_MONOTONIC for Qpc as a source and add InterruptTimeBias there; - try to detect time jumps in wineserver based on the difference between the CLOCK_MONOTONIC and CLOCK_BOOTTIME, if that jumped (compared to current bias) over some threshold and that is consistent over a few consequent time update then update the time bias. This is also not ideal of course as the bias will be wrong at first time queries right after reboot. Also, there are audio backends which could potentially also got the time mismatch now, and might need the same adjustment too. IMO the bottom line of that is that is not so simple change in any case, and to fix the regressions introduced by the change (even while the change itself might be correct) reverting is probably best for code freeze at least. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9875#note_126638