|
On 12/7/2017 6:18 AM, Robert Bragg
wrote:
Hi Robert, Testing on SKL shows timestamps drift only about 10us for sampling done in kernel for about 30min time. Verified with changes from https://github.com/sakamble/i915-timestamp-support/commits/drm-tip Note that since we are sampling counter in debugfs, there is likely overhead of read that is adding to drift so adjustment might be needed. But with OA reports we just have to worry about initial timecounter setup where we need accurate pair of system time and GPU timestamp clock counts. I think timestamp clock is highly stable and we don't need logic to determine frequency at runtime. Will try to get confirmation from HW team as well. If we need to determine the frequency, Sourab's approach needs to refined as 1. It can be implemented entirely in i915 because what we need is pair of system time and gpu clocks over different durations. 2. crosstimestamp framework usage in that approach is incorrect as ideally we should be sending ART counter and GPU counter. Instead we were hacking to send the TSC clock. Quoting Thomas from https://patchwork.freedesktop.org/patch/144298/ get_device_system_crosststamp() is for timestamps taken via a clock which is directly correlated with the timekeeper clocksource. ART and TSC are correlated via: TSC = (ART * scale) + offset get_device_system_crosststamp() invokes the device function which reads ART, which is converted to CLOCK_MONOTONIC_RAW by the conversion above, and then uses interpolation to map the CLOCK_MONOTONIC_RAW value to CLOCK_MONOTONIC. The device function does not know anything about TSC. All it knows about is ART. I am not aware if GPU timestamp clock is correlated with TSC like ART for ethernet drivers and if i915 can read ART like ethernet drivers. 3. I have seen precision issues in the calculations in i915_perf_clock_sync_work and usage of MONO_RAW which might jump time. Adjusting timecounter time can be another option if we confirm that GPU timestamp frequency is stable. On SKL I have seen very small drift of less than 10us over a period of 30 minutes. Verified with changes from https://github.com/sakamble/i915-timestamp-support/commits/drm-tip 36bit counter will overflow in about 95min at 12mhz and timecounter framework considers counter value with delta from timecounter init of more than half of total time covered by counter as time in the past so current approach works for less than 45min. Will need to add overflow watchdog support like other drivers which just reinitializes timecounter prior to 45min. If we rely on timecounter alone without correlation to know frequency, setting init time as MONOTONIC system time should take care of monotonicity of correlated times. Regards, Sagar
|
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
