If system is suspended / resumed right between these two calls the bias gets completely off.
Indeed, this could happen and is fixed now with v3, where after a jump in bias over the threshold the new bias is recalculated in a calibration loop run to get an accurate reading.
Note as well that this here doesn't prevent other processes from executing and reading stale bias values from USD after system is resumed
The InterruptTimeBias in USD here is meant to be paired with the InterruptTime also in USD (I also sandwiched it between the high and low values to always be in sync with it in v3). This value is as stale as all other tick counts and time data in USD after resume and this did not seem to have caused any problem yet, so I don't think we need any extra measures to make wineserver executes first and/or suspend/resume hooks. As you said though there is a theoretical possible race after suspend if mixed with QPC (which is technically not using this value where it should be used). If the first converted vulkan timestamp after suspend being off in rare cases is a critical issue there, winevulkan could do something like: - get QPC (latest timestamp independent of USD) - get InterruptTimeBias - query InterruptTime (from USD) If the QPC and InterruptTime values are not close (which both include suspend time), then we know that the bias is stale and can just get it again. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9875#note_126899