[FFmpeg-devel] [PATCH] swscale/aarch64/hscale.S Refactor hscale_16_to_15__fs_4
Martin Storsjö
martin at martin.st
Sun Mar 2 01:21:09 EET 2025
On Sun, 2 Mar 2025, Martin Storsjö wrote:
> On Sat, 1 Mar 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:
>
>> Before/after:
>>
>> A78
>> hscale_16_to_15__fs_4_dstW_8_neon: 86.8 ( 1.72x)
>> hscale_16_to_15__fs_4_dstW_24_neon: 147.5 ( 2.73x)
>> hscale_16_to_15__fs_4_dstW_128_neon: 614.0 ( 3.14x)
>> hscale_16_to_15__fs_4_dstW_144_neon: 680.5 ( 3.18x)
>> hscale_16_to_15__fs_4_dstW_256_neon: 1193.2 ( 3.19x)
>> hscale_16_to_15__fs_4_dstW_512_neon: 2305.0 ( 3.27x)
>>
>> hscale_16_to_15__fs_4_dstW_8_neon: 86.0 ( 1.74x)
>> hscale_16_to_15__fs_4_dstW_24_neon: 106.8 ( 3.78x)
>> hscale_16_to_15__fs_4_dstW_128_neon: 404.0 ( 4.81x)
>> hscale_16_to_15__fs_4_dstW_144_neon: 451.8 ( 4.80x)
>> hscale_16_to_15__fs_4_dstW_256_neon: 760.5 ( 5.06x)
>> hscale_16_to_15__fs_4_dstW_512_neon: 1520.0 ( 5.01x)
>>
>> A72
>> hscale_16_to_15__fs_4_dstW_8_neon: 156.8 ( 1.52x)
>> hscale_16_to_15__fs_4_dstW_24_neon: 217.8 ( 2.52x)
>> hscale_16_to_15__fs_4_dstW_128_neon: 906.8 ( 2.90x)
>> hscale_16_to_15__fs_4_dstW_144_neon: 1014.5 ( 2.91x)
>> hscale_16_to_15__fs_4_dstW_256_neon: 1751.5 ( 2.96x)
>> hscale_16_to_15__fs_4_dstW_512_neon: 3469.3 ( 2.97x)
>>
>> hscale_16_to_15__fs_4_dstW_8_neon: 151.2 ( 1.54x)
>> hscale_16_to_15__fs_4_dstW_24_neon: 173.4 ( 3.15x)
>> hscale_16_to_15__fs_4_dstW_128_neon: 660.0 ( 3.98x)
>> hscale_16_to_15__fs_4_dstW_144_neon: 735.7 ( 4.00x)
>> hscale_16_to_15__fs_4_dstW_256_neon: 1273.5 ( 4.09x)
>> hscale_16_to_15__fs_4_dstW_512_neon: 2488.2 ( 4.16x)
>> ---
>>
>> This patch removes the use of stack for temporary state and replaces
>> interleaved ld4 loads with ld1.
>> I'm aware the component is being deprecated, however in my use case
>> (screen recording) the total time spent in this function is roughly 15%,
>> the improvement is significant and worth sharing.
>
> The patch looks good. I didn't follow it in exact detail, but it overall
> looks reasonable, and looks much better than the previous form. This
> description of what the patch does and why also is worth keeping in the final
> commit message, but as there's no need to repost the patch, I could just
> adjust the message myself before pushing it.
I pushed this one, and the second ac3dsp patch now, with the commit
messages readjusted a little bit. The first ac3dsp patch should be good
too if someone verifies that it's ok to handle 16 elements at a time.
// Martin
More information about the ffmpeg-devel
mailing list