On 27 May 2009, at 01:47, Daniel Iliev wrote:
Yes, just add "cpudetection" to those or put it in in make.conf.
Apparently not!
I rebuilt using that flag & received this message:
* You've enabled the cpudetection flag. This feature is
* included mainly for people who want to use the same
* binary on another system with a different CPU architecture.
* MPlayer will already detect your CPU settings by default at
* buildtime; this flag is used for runtime detection.
* You won't need this turned on if you are only building
* mplayer for this system. Also, if your compile fails, try
* disabling this use flag.
I think this speaks for itself.
I can't see any problems here?
The idea is to enable the "cpudetection" flag and all USE flags which
correspond to one or another extended instruction set (EIS) and build
mplayer with support for all EIS plus extra code for "*run-time* cpu
detection". This way mplayer *could* use all EIS that are implemented
in its code, but *will* detect which EIS are supported by your CPU and
use only them. In other words the same binary will use different EIS
on
different CPUs.
There could be problems if you had enabled all the EIS flags globally
(in make.conf) instead only for mplayer, because other programs don't
have the "run-time cpu detection" feature and will fail in their
attempts to use for example 3dnow! on an Intel CPU.
I hope I was clear enough, apologies for my Englush.
Hi there,
The thing is that run-time CPU detection is unnecessary, if you're
always going to be using this mplayer binary you've just built on the
same system. mplayer will be built correctly without this cpudetection
flag (just put all the USE flags corresponding to EIS instructions in
package.use as previously discussed, but without cpudetection).
If you upgrade your motherboard in the future, then the cpudetection
flag will ensure that mplayer immediately takes advantage of the new
CPU's full abilities, but that's not an everyday problem and it's no
problem to rebuild mplayer in this case.
Building with cpudetection will make a bigger mplayer binary, I think.
I don't think that will slow your system down significantly, but I
think it might take 1/2 a second longer to play your movie because
each run-time it needs to work out which extra code to use. Also extra
clutter in the terminal output, I think, if you're looking at that to
see why a movie stutters or fails to decode.
I'm not saying cpudetection is absolutely wrong, just it's
unnecessary. I personally find it a little inelegant.
I guess that "philosophically" I want my mplayer *built* so that it
runs optimally on my system every time. I don't want it to have to
work out for itself, every time it runs, which is the best way for it
to run. I'm not sure if that makes senes?
Your English is excellent.
Stroller.
