Hi, Le 8 mars 2025 14:53:42 GMT-08:00, Niklas Haas <ffm...@haasn.xyz> a écrit : >https://github.com/haasn/FFmpeg/blob/swscale3/doc/swscale-v2.txt
>I have spent the past week or so ironing >I wanted to post it here to gather some feedback on the approach. Where does >it fall on the "madness" scale? Is the new operations and optimizer design >comprehensible? Am I trying too hard to reinvent compilers? Are there any >platforms where the high number of function calls per frame would be >probitively expensive? What are the thoughts on the float-first approach? See >also the list of limitations and improvement ideas at the bottom of my design >document. Using floats internally may be fine if there's (almost) never any spillage, but that necessarily implies custom calling conventions. And won't work with as many as 32 pixels. On RVV 128-bit, you'd have only 4 vectors. On Arm NEON, it would be even worse as scalars/constants need to be stored in vectors as well. Otherwise transferring two or even four times as much data to/from memory at every step is probably going to more than absorb any performance gains from using floats (notably not needing to scale values). _______________________________________________ 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".
