On Fri, 14 Jun 2024, Zhao Zhili wrote:
On Jun 13, 2024, at 20:54, Martin Storsjö <mar...@martin.st> wrote:
On Fri, 7 Jun 2024, Martin Storsjö wrote:
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the unscaled nanosecond output of
clock_gettime is much higher resolution).
In one tested case, the cntvct_el0 timer has a frequency of 25 MHz
(readable via the register cntfrq_el0).
---
libavutil/aarch64/timer.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index fadc9568f8..966f17081a 100644
--- a/libavutil/aarch64/timer.h
+++ b/libavutil/aarch64/timer.h
@@ -33,7 +33,16 @@ static inline uint64_t read_time(void)
uint64_t cycle_counter;
__asm__ volatile(
"isb \t\n"
+#if defined(__ANDROID__)
+ // cntvct_el0 has lower resolution than pmccntr_el0, but is usually
+ // accessible from user space by default.
+ "mrs %0, cntvct_el0 "
+#else
+ // pmccntr_el0 has higher resolution, but is usually not accessible
+ // from user space by default (but access can be enabled with a custom
+ // kernel module).
"mrs %0, pmccntr_el0 "
+#endif
: "=r"(cycle_counter) :: "memory" );
Zhao, does this implementation seem useful to you? Does it give you better
(more accurate, less noisy?) benchmarking numbers on Android, than the fallback
based on clock_gettime?
Hi Martin, this works on Android and macOS both, so maybe you can enable it for
macOS too.
I have compared the result of this implementation and
mach_absolute_time, this looks like the implementation has smaller
variable Deviation than mach_absolute_time. I guess the result is the
same when compared to clock_gettime.
Right, it does seem to use the same scale as mach_absolute_time - but it
probably has less overhead when we can fetch it by just reading a
register, instead of calling out to a system function.
So then I guess I could extend this patch to enable it for
defined(__APPLE__) too.
We have linux perf on Android, and kperf on macOS. Linux perf has the
benefit to reduce interference from other processes on statistical
results, if I understand correctly.
Yes, possibly, but on the other hand, it also has a bit more noise and
overhead over just using pmccntr_el0; if e.g. tuning and comparing small
differences in functions, pmccntr_el0 usually gives the best result.
But anyway, as those are configurable, users building with linux perf will
get that, and users disabling it will get the more accurate register
instead.
I’m not sure about the benefit of macOS kperf.
macOS kperf gives the best and most accurate numbers you can get, on that
HW, but unfortunately, it's undocumented and unofficial (and requires
running with sudo). It does give numbers comparable to linux perf, I
think, i.e. proper clock cycle level numbers.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
