mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-19 13:38:19 +02:00
e278a89fdd
On Mali, GPU timestamp cycle counts are mapped to the arch counter, and so advance at the same rate as CNTVCT (with a fixed offset). The kernel applies gradual NTP adjustments to CLOCK_BOOTTIME by modifying the rate of the cycle->ns conversion slightly from the nominal frequency of the clock, which causes it to drift from the GPU clock's ns values (which just use the nominal frequency). On a rock5b, I measured this drift in the 25-30µs/s range. Perfetto's clock synchronization applies a fixed offset between each clock snapshot, and so does not handle clocks with significantly different rates and infrequent snapshots well. For panvk, we emit snapshots once per second, and so the drift results in an error of ~25µs right before the next snapshot. This is significant for measuring the latency of CPU<->GPU operations, and shows up as a sawtooth pattern on the measured latency distribution over time. CLOCK_MONOTONIC_RAW does not have the NTP adjustment, and so the only source of drift is error in the shift/mult approximation that the kernel uses for cycle->ns. This error is very small, and so by emitting CPU trace events against CLOCK_MONOTONIC_RAW instead of CLOCK_BOOTTIME, we can get much more accurate synchronization. Signed-off-by: Olivia Lee <olivia.lee@collabora.com> Reviewed-by: Eric R. Smith <eric.smith@collabora.com> Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34390> |
||
|---|---|---|
| .. | ||
| ci | ||
| clc | ||
| compiler | ||
| drm-shim | ||
| ds | ||
| genxml | ||
| lib | ||
| libpan | ||
| midgard | ||
| perf | ||
| shared | ||
| tools | ||
| util | ||
| vulkan | ||
| .clang-format | ||
| meson.build | ||