[FFmpeg-devel] [RFC] New swscale internal design prototype

[Niklas Haas]

On Sun, 09 Mar 2025 18:11:54 +0200 Martin Storsjö <martin at martin.st> wrote:
> On Sat, 8 Mar 2025, Niklas Haas wrote:
> 
> > What are the thoughts on the float-first approach?
> 
> In general, for modern architectures, relying on floats probably is 
> reasonable. (On architectures that aren't of quite as widespread interest, 
> it might not be so clear cut though.)
> 
> However with the benchmark example you provided a couple of weeks ago, we 
> concluded that even on x86 on modern HW, floats were faster than int16 
> only in one case: When using Clang, not GCC, and when compiling with 
> -mavx2, not without it. In all the other cases, int16 was faster than 
> float.

Hi Martin,

I should preface that this particular benchmark was a very specific test for
floating point *filtering*, which is considerably more punishing than the
conversion pipeline I have implemented here, and I think it's partly the
fault of compilers generating very unoptimal filtering code.

I think it would be better to re-assess using the current prototype on actual
hardware. I threw up a quick NEON test branch: (untested, should hopefully work)
https://github.com/haasn/FFmpeg/commits/swscale3-neon

# adjust the benchmark iters count as needed based on the HW perf
make libswscale/tests/swscale && libswscale/tests/swscale -unscaled 1 -bench 50

If this differs significantly from the ~1.8x speedup I measure on x86, I
will be far more concerned about the new approach.

> After doing those benchmarks, my understanding was that you concluded that 
> we probably need to keep int16 based codepaths still, then.

This may have been a misunderstanding. While I think we should keep the option
of using fixed point precision *open*, the main take-away for me was that we
will definitely need to transition to custom SIMD; since we cannot rely on the
compiler to generate good code for us.

> Did something fundamental come up since we did these benchmarks that 
> changed your conclusion?
> 
> // Martin
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".