[MPlayer-dev-eng] [PATCH] two independent patches for configure

[Xidorn Quan]

On Thu, Oct 11, 2012 at 12:09 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Wed, 10 Oct 2012 23:14:22 +0800
> Xidorn Quan <quanxunzhen at gmail.com> wrote:
>
> > > Then why not -march=native -mtune=native ?
> > >
> >
> > Some compilers like clang don't support cpu autodetection at present.
>
> Maybe because it's not that useful of a feature anyway, and mostly leads
> to binaries that run on only one CPU.


To let binaries run on more cpu can be easily achieved by just
enabling runtime cpu detection when configuring, which prevents all
these compile time detections form performing.


> Even in mplayer, most of the "heavily lifting" happens in ffmpeg or in

inline assembler.


AFAIK, cflags is shared between mplayer and ffmpeg when compiling
mplayer since ffmpeg/config.mak just includes config.mak generated by
mplayer's configure.


> In other words, it's pointless and dangerous.
>

If it is pointless and dangerous, why not just use generic or i686
instead of so many cpu detections already there?

Or do you have any hard numbers how this additional detection (or any
> detection) improves performance?
>

Well, I admit that I don't have any hard numbers. But anyway, I think
it should improve performance, or compilers will not provide these
flags.

(This might also be one of the reasons why distros supposedly often ship
> "broken" mplayer binaries.)
>