From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M9EH1-0005KP-KG for garchives@archives.gentoo.org; Wed, 27 May 2009 08:14:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7ECE7E041A; Wed, 27 May 2009 08:14:06 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id 3F362E0438 for ; Wed, 27 May 2009 08:14:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.41,256,1241391600"; d="scan'208";a="97065885" Received: from unknown (HELO compaq.stroller.uk.eu.org) ([213.152.39.90]) by smtpout.karoo.kcom.com with ESMTP; 27 May 2009 09:14:05 +0100 Received: from [192.168.1.71] (unknown [192.168.1.71]) by compaq.stroller.uk.eu.org (Postfix) with ESMTP id 3E63A137BE3 for ; Wed, 27 May 2009 09:14:03 +0100 (BST) Message-Id: <208DD9E9-EDD3-4E85-A8DE-6B08B08EDCEA@stellar.eclipse.co.uk> From: Stroller To: gentoo-user@lists.gentoo.org In-Reply-To: <20090527034704.49154a6f@ilievnet.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [gentoo-user] USE="mmx mmxext sse sse2 ssse3 3dnow 3dnowext" Date: Wed, 27 May 2009 09:14:03 +0100 References: <4E38BD16-0410-4A31-839C-290364A8D735@stellar.eclipse.co.uk> <200905260637.49384.volkerarmin@googlemail.com> <195F8064-21ED-4FBB-8C2D-78F45FBAF59A@stellar.eclipse.co.uk> <20090526173123.6af2881a@ilievnet.com> <51F59246-9E2D-42D1-9AC6-BB5E41BDAAF3@stellar.eclipse.co.uk> <20090527034704.49154a6f@ilievnet.com> X-Mailer: Apple Mail (2.935.3) X-Archives-Salt: f0d6d1b9-39cf-4a13-8970-cca2c82a7e1a X-Archives-Hash: c0937f930b5130980a84db247263e8d3 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.