On Thu, 31 Mar 2022, Ben Avison wrote:
On 30/03/2022 14:49, Martin Storsjö wrote:
Looks generally reasonable. Is it possible to factorize out the individual
transforms (so that you'd e.g. invoke the same macro twice in the 8x8 and
4x4 functions) without too much loss?
There is a close analogy here with the vertical/horizontal deblocking
filters, because while there are similarities between the two matrix
multiplications within a transform, one of them follows a series of loads and
the other follows a matrix transposition.
If you look for example at ff_vc1_inv_trans_8x8_neon, you'll see I was able
to do a fair amount of overlap between sections of the function -
particularly between the transpose and the second matrix multiplication, but
to a lesser extent between the loads and the first matrix multiplication and
between the second multiplication and the stores. This sort of overlapping is
tricky to maintain when using macros. Also, it means the the order of
operations within each matrix multiply ended up quite different.
At first sight, you might think that the multiplies from the 8x8 function
(which you might also view as kind of 8-tap filter) would be re-usable for
the size-8 multiplies in the 8x4 or 4x8 function. Yes, the instructions are
similar, save for using .4h elements rather than .8h elements, but that has
significant impacts on scheduling. For example, the Cortex-A72, which is my
primary target, can only do NEON bit-shifts in one pipeline at once,
irrespective of whether the vectors are 64-bit or 128-bit long, while other
instructions don't have such restrictions.
So while in theory you could factor some of this code out more, I suspect any
attempt to do so would have a detrimental effect on performance.
Ok, fair enough. Yes, it's always a trade off between code simplicity and
getting the optimal interleaving. As you've spent the effort on making it
efficient with respect to that, let's go with that then!
(FWIW, for future endeavours, having the checkasm tests in place while
developing/tuning the implementation does allow getting good empirical
data on how much you gain from different alternative scheduling choices. I
usually don't follow the optimization guides for any specific core, but
track the benchmark numbers for a couple different cores and try to pick a
scheduling that is a decent compromise for all of them.)
Also, for future work - if you have checkasm tests in place while working
on the assembly, I usually amend the test with debug printouts that
visualize the output of the reference and the tested function, and a map
showing which elements differ - which makes tracking down issues a whole
lot easier. I don't think any of the checkasm tests in ffmpeg have such
printouts though, but within e.g. the dav1d project, the checkasm tool is
extended with helpers for comparing and printing such debug aids.
// 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".
