[FFmpeg-devel] [PATCH] ac3dsp: remove 3dnow version of float_to_fixed24
daniel at drv.nu
Tue Nov 17 08:55:10 CET 2015
On Tue, Nov 17, 2015 at 12:00 AM, Daniel Verkamp <daniel at drv.nu> wrote:
> This implementation is only used in a very narrow set of circumstances:
> it is not bitexact, and there is an SSE implementation, so the 3DNow
> version would only get used on K6-II/K6-III/early (pre-XP) Athlon CPUs.
> It is completely dead code in x86-64 builds.
This patch is more or less to "test the waters" for more 3DNow removal patches.
The arguments in favor of removal:
- Any CPU with 3DNow support but no SSE2 support is 10+ years old
(Athlon 64 and the corresponding Opteron introduced SSE2 in 2003), and
any with 3DNow but no SSE is going on 15 years old (Athlon XP added
SSE in 2001).
- Because of the above, nobody is testing this code, so it can easily
bit-rot; I have been running a FATE client on an Athlon 64 machine
(from 2005!) to help guard against this, but I'd like to toss it,
since it's not doing anything else useful aside from heating up the
room. (Additionally, this machine is actually *too new* and is being
forced via CPUFLAGS to run 3DNow functions, rather than the supported
SSE2, so its continued existence is not a proof of users of these
- 64-bit builds are carrying this extra code that will never get used.
This could be solved by compile-time checks for ARCH_X86_32, but I
think that would be a waste of effort compared to just removing the
- More code means higher maintenance burden when modifying the
- Keeping the existing optimizations has very low cost (but see
maintenance and FATE arguments).
- The few affected machines will presumably get slightly worse
performance from the C/MMX fallbacks.
If you do in fact use an affected machine to run FFmpeg, now is the
time to speak up: if you post benchmarks proving these optimizations
are in fact useful and used, they are less likely to be removed.
-- Daniel Verkamp
More information about the ffmpeg-devel