[issue2570] configure incorrectly enables #define HAVE_AMD3DNOW 1 in config.h
Justin Ruggles justin.rugg...@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 iss...@roundup.libav.org https://roundup.libav.org/issue2570 __
[issue2570] configure incorrectly enables #define HAVE_AMD3DNOW 1 in config.h
Justin Ruggles justin.rugg...@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 iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2570
[issue2570] configure incorrectly enables #define HAVE_AMD3DNOW 1 in config.h
Ronald S. Bultje rsbul...@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 iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2570
[issue2570] configure incorrectly enables #define HAVE_AMD3DNOW 1 in config.h
John Van Sickle john.vansic...@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 iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2570
[issue2570] configure incorrectly enables #define HAVE_AMD3DNOW 1 in config.h
New submission from John Van Sickle john.vansic...@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=0xbfebfbffFPU,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=0xe3bdSSE3,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 iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2570
