Discussion:
[issue2570] configure incorrectly enables "#define HAVE_AMD3DNOW 1" in config.h
(too old to reply)
John Van Sickle
2011-01-24 21:27:32 UTC
Permalink
Raw Message
New submission from John Van Sickle <***@gmail.com>:

FFmpeg was crashing when using '-vf scale=$W:$H' on my FreeBSD 8 -stable box
which I backtraced in gdb to swsscale trying to use 3DNOW instructions. The
problem is my processor doesn't support 3DNOW:

CPU: Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz
Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>

If I build FFmpeg with '--disable-amd3dnow --disable-amd3dnowext' it doesn't
crash. I brought this issue up in #ffmpeg-devel and mru recommended I file a bug
report.
---------------------------------------------------------------------------

Tested with:

FFmpeg version git-5f3b831, Copyright (c) 2000-2011 the FFmpeg developers
built on Jan 24 2011 02:02:44 with gcc 4.4.6 20110118 (prerelease)

---------------------------------------------------------------------------

Problem:

$ cd ffmpeg

$ gmake clean && gmake distclean

$ ./configure --enable-gpl --cc=/usr/local/bin/gcc44 --as=/usr/local/bin/as

$ grep 3DNOW config.h
#define HAVE_AMD3DNOW 1
#define HAVE_AMD3DNOWEXT 1

---------------------------------------------------------------------------

$ /usr/local/bin/as --version
GNU assembler (GNU Binutils) 2.21

$ /usr/local/bin/gcc44 --version
gcc44 (GCC) 4.4.6 20110118 (prerelease)

---------------------------------------------------------------------------

MPlayer's ./configure correctly sets HAVE_AMD3DNOW and HAVE_AMD3DNOWEXT to 0.

----------
messages: 13546
priority: normal
status: new
substatus: new
title: configure incorrectly enables "#define HAVE_AMD3DNOW 1" in config.h
type: bug

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2570>
________________________________________________
John Van Sickle
2011-01-24 21:58:06 UTC
Permalink
Raw Message
John Van Sickle <***@gmail.com> added the comment:

Set Priority normal -> important

----------
priority: normal -> important

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2570>
________________________________________________
Ronald S. Bultje
2011-01-25 15:52:20 UTC
Permalink
Raw Message
Ronald S. Bultje <***@gmail.com> added the comment:

Hi,

HAVE_AMD3DNOW means it can be assembled, not that the CPU supports it. Use
----enable-runtime-cpudetect configure flag to use runtime cpu detection
which should fix this.

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2570>
________________________________________________
John Van Sickle
2011-01-25 16:47:59 UTC
Permalink
Raw Message
John Van Sickle <***@gmail.com> added the comment:

Hi rbultje,

Thanks for responding. The solution you mention is, IMO, a rather poor one. How
are users supposed to know that they need --enable-runtime-cpudetect? Because
for me it took:

1) Having FFmpeg crash with any '-vf scale'
2) Build ffmpeg_g and backtrace
3) Build and test with --disable-amd3dnow --disable-amd3dnowext
4) File bug report
5) Dev responds

Here's what should have happened.

1) FFmpeg's ./configure tests if my system can use 3dnow. [no]

I'm not cross compiling here, the only thing I pass to ./configure is
--enable-gpl and the $PATH to up-to-date gcc and as.

Is it unreasonable to expect FFmpeg to build a binary that won't crash trying to
using SIMD instructions my system doesn't support?

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2570>
________________________________________________
Justin Ruggles
2011-03-03 17:34:19 UTC
Permalink
Raw Message
Justin Ruggles <***@gmail.com> added the comment:

unlike in libavcodec and libavutil, runtime cpu detection for libswscale
is optional. maybe this should be changed to at least default to 'on'
instead of 'off' to avoid unwanted surprises like this.

----------
status: new -> open
substatus: new -> open
topic: +build system, swscaler

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2570>
________________________________________________
Justin Ruggles
2011-06-14 20:55:52 UTC
Permalink
Raw Message
Justin Ruggles <***@gmail.com> added the comment:

this should be fixed now that libswscale uses the libavutil runtime cpu
flags. if not, please reopen.

----------
status: open -> closed
substatus: open -> fixed
topic: -build system, swscaler

______________________________________________
Libav issue tracker <***@roundup.libav.org>
<https://roundup.libav.org/issue2570>
______________________________________________

Loading...