On Fri, 7 Jun 2024, Rémi Denis-Courmont wrote:
Le 7 juin 2024 12:12:45 GMT+03:00, "Martin Storsjö" <mar...@martin.st> a écrit :
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
It feels a little newbie-hostile choice to pick something that's broken
by default but only on non-Android Linux.
Actually, on aarch64 Windows (both native Windows, and Linux binaries in
WSL), pmccntr_el0 is accessible in user mode (and this is a documented
feature, not an accident). Hence the "usually" in the comments.
But yes, the default is a bit hostile in that sense, as it's usually not
usable as such on Linux.
This patch is at least a small baby step in a different direction; more
configurability probably would be good, but I didn't want to take on
fixing that here. But for those actually working on assembly, pmccntr_el0
still is the best and usually worth the hassle - so we want to get rid of
it entirely.
Is there at least a runtime warning?
Since ac40c3bb07781e72f3eb1e30ea450019cc1f6302 we do have a runtime test
in checkasm, if --bench is passed, giving the user a somewhat generic
message, rather than crashing. (For other code using START/STOP_TIMER,
there's no runtime check/warning though.)
// 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".
