On Sun, 09 Mar 2025 18:11:54 +0200 Martin Storsjö <mar...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".