schizobeyondpills wrote: ↑25 Oct 2020, 15:12
QPC is independent of and
isn't synchronized to any external time reference. To retrieve time stamps that can be synchronized to an external time reference, such as, Coordinated Universal Time (UTC) for use in high-resolution time-of-day measurements, use GetSystemTimePreciseAsFileTime.
For the purposes of short-term temporals like framepacing, pollpacing, dejittering, and whatnots, we don't need reference clocks. We only need overkill precision relativity in a monotically incrementing clock with relatively small timedrift (practically zero at the required timescales we need), and that's sufficient for fixing a lot of Vicious Cycle Effect for a long time to come.
There are Right Tool for Right Job, and we definitely need precision TOD measurements. But this is not one of these situations. It isn't critical for time-relative stuff like the time differentials of frames that can be compared to adjacent framepairs (Aka framepacing statistics). TOD accuracy is generally irrelevant for that kind of statistic. And so it is also, for gametime stuff currently in the majority of current workflows. We just merely need good-enough relativity accuracy (Event timestamps, gametime timestamps, etc) down to the sub-microsecond precision. In the theoretical ultralongterm, we can also jitter-compensate polls by using continuous poll mode (a special mode so we always know it's ticktocking at 8000 polls a second, with missed-poll detection logic) and manually dejittering the polls systemside by gridlocking them to exact 0.125us separation regardless of how polls jittered from the mouse sensor to the software application. Or even future mouse input APIs that adds sensorside timestamps to the polls.
You only need microsecond counters for that (like RTDSC or QPC) and the counter can drift a bit to PC over days because both the PC and the mouse sensor microcontroller are independent clocks. But it'd be meaningless error margin over the timescales of one second. There are multiple long-term solutions to resisting internal system jitter from the perspective of gametime accuracy. Clock drift is ultra tiny in the time interval of adjacent frame pairs, to the point where it's meaningless error. Sure, some counters monotically increments inaccurately (bugs) and had tickbackwards issues (bugs), but most modern counters are sub-microsecond accurate (both in relative accuracy & drift accuracy) over the required tiny timescales of our mudane use cases of mouse poll accuracy vs gametime accuracy etc.
I am not dismissing the need for microsecond-accurate TOD for many situations. But many use cases don't need microsecond-accurate TOD -- simply that we only need microsecond-accurate time relativity over short timescales for the vast majority of fighting the Blur Busters Vicious Cycle Effect (the term I now call ever tinier things becoming problems, mudane things like higher resolutions amplifying refresh rate limitations, to things like mouse pollrate limitations showing at higher display refresh rates, etc).
In an overabundance of caution, I even now recommend game developers to cast (int) rawinput mouse positions as (double) as an intermediate math precision preserving step before the (float) of GPU APIs. It's common sense precision-preservation much like the 10-bit LUT processing step between an 8-bit GPU output and an 8-bit monitor panel. Less rounding errors build up during math processing of color processing (contrast, color, gamma mapping, etc).
Also, I got a USB3 PCI-X card. Big difference when I put my 8000Hz mouse as the only device on it, its own solid tree trunk straight to the CPU on a dedicated PCI Express lane! No bus contention, no USB contention, no second fiddle branch off a USB hub! Even CPU%-per-poll goes down slightly as it's not doing any demultiplexing sheningians anymore (whatever it is; USB sharing, interrupt sharing, or other sharing unbeknownst to our knowledge). Any weak link is now Windows/software's fault, not the USB chipset / processing / hub fault.
You are right there are many weak links but we only need to whac-a-mole sufficiently enough weak links to get sufficient worthiness out of certain hardware. We can whac the rest of the moles later, once we've whac'd enough moles for our current tick-tock of the current Vicious Cycle Effect situation.
.