public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Stroller <stroller@stellar.eclipse.co.uk>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] USE="mmx mmxext sse sse2 ssse3 3dnow 3dnowext"
Date: Wed, 27 May 2009 09:14:03 +0100	[thread overview]
Message-ID: <208DD9E9-EDD3-4E85-A8DE-6B08B08EDCEA@stellar.eclipse.co.uk> (raw)
In-Reply-To: <20090527034704.49154a6f@ilievnet.com>


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.




  reply	other threads:[~2009-05-27  8:14 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26  4:27 [gentoo-user] USE="mmx mmxext sse sse2 ssse3 3dnow 3dnowext" Stroller
2009-05-26  4:37 ` Adam Carter
2009-05-26  4:59   ` Volker Armin Hemmann
2009-05-26  4:37 ` Volker Armin Hemmann
2009-05-26  5:00   ` Stroller
2009-05-26  5:10     ` Volker Armin Hemmann
2009-05-26  6:15       ` Stroller
2009-05-26  6:27         ` Volker Armin Hemmann
2009-05-26  8:34           ` Stroller
2009-05-26 14:31     ` Daniel Iliev
2009-05-26 21:07       ` Stroller
2009-05-27  0:47         ` Daniel Iliev
2009-05-27  8:14           ` Stroller [this message]
2009-05-27 10:00             ` Daniel Iliev
2009-05-27 12:14               ` Stroller
2009-05-27 19:57                 ` Wyatt Epp
2009-05-27 20:04                   ` Volker Armin Hemmann
2009-05-27 20:09                     ` Alan McKinnon
2009-05-27 20:40                       ` Wyatt Epp
2009-05-27 20:47                         ` Volker Armin Hemmann
2009-05-27 21:04                         ` Mike Edenfield
2009-05-27 21:12                           ` Alan McKinnon
2009-05-27 23:00                       ` Adam Carter
2009-05-27 20:08                   ` Ward Poelmans
2009-05-27 21:04                     ` Mike Edenfield
2009-05-27 21:23                   ` Arttu V.
2009-05-28 10:17                     ` Daniel Iliev
2009-05-28 19:13                       ` Stroller
2009-05-28 20:08                         ` Ward Poelmans
2009-05-28 20:19                           ` Stroller
2009-05-28 20:27                             ` Ward Poelmans
2009-05-28 20:38                               ` Stroller
2009-05-29  5:30                             ` Graham Murray
2009-05-29  6:36                               ` Volker Armin Hemmann
2009-05-29  6:55                               ` Volker Armin Hemmann
2009-05-29 15:25                                 ` Mike Edenfield
2009-05-29  7:51                             ` Neil Bothwick
2009-05-26 22:20       ` KH
2009-05-26 22:26         ` KH
2009-05-26 22:32         ` Alan McKinnon
2009-05-26 13:26 ` [gentoo-user] " James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=208DD9E9-EDD3-4E85-A8DE-6B08B08EDCEA@stellar.eclipse.co.uk \
    --to=stroller@stellar.eclipse.co.uk \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox