[FFmpeg-devel] [PATCH] fix --enable-runtime-cpudetect --disable-amd3dnow compilation

Michael Niedermayer michaelni
Sun Sep 5 00:59:11 CEST 2010

On Fri, Sep 03, 2010 at 07:15:50PM -0300, Ramiro Polla wrote:
> On Fri, Sep 3, 2010 at 7:06 PM, Alexander Strange <astrange at ithinksw.com> wrote:
> > CC ? ? ?libswscale/swscale.o
> > ...
> > libswscale/swscale.c: In function ?ff_getSwsFunc?:
> > libswscale/swscale.c:1268: warning: implicit declaration of function ?sws_init_swScale_3DNow?
> > libswscale/swscale.c:1269: error: ?swScale_3DNow? undeclared (first use in this function)
> > libswscale/swscale.c:1269: error: (Each undeclared identifier is reported only once
> > libswscale/swscale.c:1269: error: for each function it appears in.)
> >
> > Alternatively, it could declare prototypes for sws_init_swScale_3DNow / swScale_3DNow even if they aren't being compiled.
> > That would let us use "if (COMPILE_TEMPLATE_AMD3DNOW && flags & SWS_CPU_CAPS_3DNOW)" instead of #ifdefs. But it might make some of the other templating more complex.
> Since we're on the subject, do we really need this complexity in
> swscale? dsputils always builds c and optimized code, then selects in
> the init function. swscale has one extra layer of complexity in which
> you can disable runtime cpu detection and it would only compile for
> the fastest optimization available.
> Could we drop this and always enable runtime cpu detection like dsputil does?

and thus make the code 3 times bigger for anyone who used
non runtime cpudetect?
i dont think this is a good idea
id rather see dsputil gain support to have things disabled at compiletime
that arent relevant for some target cpu. it would make ffmpeg quite a bit
smaller id guess. also if we could get rid of the calls and inline the
optimized code from dsputil for the non runtime cpudetect case we would
gain a bit speed for many codecs

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100905/c7309af2/attachment.pgp>

More information about the ffmpeg-devel mailing list