On Mon Jan 12 17:10:32 2026 +0000, Paul Gofman wrote:
I am afraid this is not a reliable way to compute the unbiased time. Random factors may influence this and it looks challenging (even if possible) to implement a reliable bias. IMO if we have to implement that we'd be better off detecting suspend in some way and use our own current bias always, which, even if not 100% correct, would at least be consistent over time and would not introduce random time jumps. Also note that, as Rémi noted in the linked MR, that an ability to use RtlQueryUnbiasedInterruptTime() doesn't help winevulkan: it has to convert between CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW and QPC time, it is not free to choose unibiased QPC time instead, that is not what apps may expect. Unless we are known to have something depending on CLOCK_BOOTTIME now, I'd also suggest to revert MR 8916 for now and help both this aspect with now wrong unbiased time and winevulkan. 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 counts for quite a while so the winevulkan issue this is currently causing has been present there for quite a while (and it would be nice if it could be fixed as well). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9875#note_126637