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.
next prev parent 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