On Mon, 30 Mar 2026, Amin Abdulrahman via ffmpeg-devel wrote:
- What is the optimization-target for the handwritten assembly on AArch64? Do you target any specific microarchitecture? Are there specific constraints on the assembly code?
The optimization target is generally a compromise across all aarch64 cores. If a specific scheduling is very beneficial for some cores, while regressing other cores only slightly, that is preferred. But if a change comes with large regressions for other cores, it might be skipped.
A lot of our assembly has been written when the most available aarch64 devices all had Cortex-A53 cores, so there may be some tuning/scheduling bias towards that one - but if revising scheduling it may be good to consider all common cores.
Do your tools correctly simulate the specifics around e.g. the dedicated MAC accumulator forwarding paths in A53/A55/A520? See e.g. https://code.ffmpeg.org/mstorsjo/FFmpeg/commit/f569e790017989f3cacf592a08bc06ec92b3a753 and discussion at https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21148#issuecomment-22320. I tested whether GCC and Clang correctly tune this if targeting specifically Cortex-A53/A55, by writing a function with intrinsics and trying different -mtune parameters, but they didn't seem to prefer the optimization.
Unfortunately, even though A53/A55/A520 has this very beneficial forwarding path, it seems like A510 lacks it, so in the recent patch above, we decided not to do this. Some amount of our existing assembly may have been written relying on this though.
As for constraints on the assembly code; our assembly needs to be portable across OSes. We achieve this by using a set of macros that abstract away platform specific details (i.e. most raw assembly directives).
- Do you have any recommendations on relevant routines to consider as initial targets? I went through the source tree and found many assembly files but I'm lacking the knowledge to judge which one would be an "impactful" starting point.
I guess it depends on what use case you're considering. Functions for h264/hevc might give the biggest real-world impact. You may also want to look at libdav1d, https://code.videolan.org/videolan/dav1d.
- Is there any dedicated infrastructure for such "fine-grained" performance evaluation/profiling? Like, anything else than re-compiling ffmpeg and running one of the real-world tasks that leverages the optimization target.
For evaluating the performance of assembly implementations, we primarily rely on the checkasm tool, I suggest you familiarize yourself with it. In short, build the checkasm tool, pick a specific set of functions you want to benchmark, and run e.g. './tests/checkasm/checkasm --test=h264qpel --bench="put_h264_qpel_16*"'.
Benchmarking on aarch64 is tricky, as there are various different timers with different availability and quirks. You get the best timing quality if you build with --disable-linux-perf, but that requires you to enable user-mode access to performance counter registers, using a kernel module like https://code.videolan.org/janne/arm64-cycle-cnt.
There's a new implementation of checkasm under discussion/integration, see https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22546. With that version, checkasm will automatically pick the best available timer without you needing to decide on it at configure time.
With the checkasm tool you can benchmark the behaviour of your suggested changes. To evaluate whether the change is beneficial overall, one would want to have benchmark numbers from a couple different systems. There's no service for this; some people working on aarch64 assembly have got their own collection of diverse test devices that they can use for benchmarking.
- Is there any interest from the development community's side in optimized assembly routines? I would like to try regardless but if the optimizations can be helpful in a broader sense, that would be nice.
If you can provide rescheduled versions of functions - that looks like handwritten assembly and fits into our coding style, I think we would appreciate the contributions!
I'm less convinced that we're interested in integrating the framework as such into our build system. But if it can be shown how users easily can run the tool on the existing code, I guess that someone could want to look at it!
// Martin _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
