Re: [gentoo-user] USE="mmx mmxext sse sse2 ssse3 3dnow 3dnowext"

[Stroller]

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.