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

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

[Stroller]

Hi there,

I'm always rather reluctant to enable any of these, being unsure  
whether my ageing PentiumPro or Pentium 4 CPUs support such features  
as 3DNow! (originally an AMD technology) or the advanced SSSSSSSSSE3.

According to this page <http://en.gentoo-wiki.com/wiki/MPlayer>,  
however:

    You can greatly improve MPlayer's performances (in my experience, by
    up to +40%!) by recompiling it with appropriate CPU-related USE  
flags.

Moreover:

    Note: The mplayer build system will automatically detect your CPU
    settings if you allow it. Therefore, the safest thing to do is  
enable
    all of the optimization USE flags and let the script detect them. If
    you disable the use flags, then it will forcibly disable support for
    that optimization, and possibly break your build. In other words,  
add
    mmx mmxext sse sse2 ssse3 3dnow 3dnowext to your USE flags for this
    ebuild, and if your box supports it, it will work automatically.

w00t!

Should I enable all these USE flags globally? Will other packages also  
fallback safely as mplayer does?

Or should I add all these flags only to /etc/portage/package.use,  
allowing mplayer to make full use of the hardware USEs it supports,  
but limiting other apps to only those I'm really really confident  
about (i.e. "mmx" & that's about it).

Thanks in advance for all suggestions,

Stroller.

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

[Adam Carter]

'grep flags /proc/cpuinfo' to see what features the CPU supports, and add those to USE. You'll recognise most but apparently "pni" = sse3 (but then my core2 also shows ssse3 as well....odd)

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

[Volker Armin Hemmann]

On Dienstag 26 Mai 2009, Adam Carter wrote:
> 'grep flags /proc/cpuinfo' to see what features the CPU supports, and add
> those to USE. You'll recognise most but apparently "pni" = sse3 (but then
> my core2 also shows ssse3 as well....odd)

ssse3 is not sse3

different stuff.

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

[Volker Armin Hemmann]

On Dienstag 26 Mai 2009, Stroller wrote:
> Hi there,
>
> I'm always rather reluctant to enable any of these, being unsure
> whether my ageing PentiumPro or Pentium 4 CPUs support such features
> as 3DNow! (originally an AMD technology) or the advanced SSSSSSSSSE3.
>
> According to this page <http://en.gentoo-wiki.com/wiki/MPlayer>,
> however:
>
>     You can greatly improve MPlayer's performances (in my experience, by
>     up to +40%!) by recompiling it with appropriate CPU-related USE
> flags.
>
> Moreover:
>
>     Note: The mplayer build system will automatically detect your CPU
>     settings if you allow it. Therefore, the safest thing to do is
> enable
>     all of the optimization USE flags and let the script detect them. If
>     you disable the use flags, then it will forcibly disable support for
>     that optimization, and possibly break your build. In other words,
> add
>     mmx mmxext sse sse2 ssse3 3dnow 3dnowext to your USE flags for this
>     ebuild, and if your box supports it, it will work automatically.
>
> w00t!
>
> Should I enable all these USE flags globally? Will other packages also
> fallback safely as mplayer does?
>
> Or should I add all these flags only to /etc/portage/package.use,
> allowing mplayer to make full use of the hardware USEs it supports,
> but limiting other apps to only those I'm really really confident
> about (i.e. "mmx" & that's about it).
>
> Thanks in advance for all suggestions,
>
> Stroller.

you can enable them globaly.

If a package would build using say 3dnow without the cpu supporting it it will 
crash with an instruction error. So either it works always or never.

Just look at /proc/cpuinfo you find everything you need to know there. It 
isn't hard. In fact, it is really ,really simple.

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

[Stroller]

On 26 May 2009, at 05:37, Volker Armin Hemmann wrote:
> ...
> If a package would build using say 3dnow without the cpu supporting  
> it it will
> crash with an instruction error. So either it works always or never.

Hmmmn.... so if I use it my applications might crash, but it's safe to  
use?

The mplayer ebuild is stated to be "intelligent" about ignoring these  
flags if necessary, so I'm not sure that "if mplayer works, so will  
everything else" is a safe conclusion. My question was exactly if it  
was so - are other ebuilds also as "intelligent" as mplayer?

> Just look at /proc/cpuinfo you find everything you need to know  
> there. It
> isn't hard. In fact, it is really ,really simple.

I'd disagree. If it were really simple, Portage would take care of it  
automagically for me. It (apparently?) doesn't.

It's kinda a pain to have to look up what's supported on each system,  
and then edit make.conf accordingly. Especially as some translation is  
required: Adam Carter states, 'apparently "pni" = sse3'. What else  
might be this or that or something else? The suggested `grep flags / 
proc/cpuinfo` shows "apic sep mtrr" amongst others, but there appears  
no USE flags corresponding to those. Or are there?

To keep my life simple, I'm going to use the absolute minimum of  
flashypants hardware USE flags unless I know its safe.

Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow  
3dnowext >> /etc/portage/package.use` unless someone else is able to  
be more informative.

Stroller.
  

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

[Volker Armin Hemmann]

On Dienstag 26 Mai 2009, Stroller wrote:
> On 26 May 2009, at 05:37, Volker Armin Hemmann wrote:
> > ...
> > If a package would build using say 3dnow without the cpu supporting
> > it it will
> > crash with an instruction error. So either it works always or never.
>
> Hmmmn.... so if I use it my applications might crash, but it's safe to
> use?
>
> The mplayer ebuild is stated to be "intelligent" about ignoring these
> flags if necessary, so I'm not sure that "if mplayer works, so will
> everything else" is a safe conclusion. My question was exactly if it
> was so - are other ebuilds also as "intelligent" as mplayer?
>
> > Just look at /proc/cpuinfo you find everything you need to know
> > there. It
> > isn't hard. In fact, it is really ,really simple.
>
> I'd disagree. If it were really simple, Portage would take care of it
> automagically for me. It (apparently?) doesn't.

portage does not take care. mplayers build has a cpu feature autodection.

Different stuff. Really.

>
> It's kinda a pain to have to look up what's supported on each system,
> and then edit make.conf accordingly. Especially as some translation is
> required: Adam Carter states, 'apparently "pni" = sse3'. What else
> might be this or that or something else? The suggested `grep flags /
> proc/cpuinfo` shows "apic sep mtrr" amongst others, but there appears
> no USE flags corresponding to those. Or are there?

apic is interrupt controller. mtrr is about ram access - and supported since 
pentium ... 1? mmx? 2? very early. There are no flags, because that stuff 
really is nothing apps care about (with the exception of X and mtrr - luckily 
for you, that is nothing YOU have to care about).


> Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow
> 3dnowext >> /etc/portage/package.use` unless someone else is able to
> be more informative.

yeah, except that is bullshit

no pentium can do 3dnow. Or was there a 3dnow flag in /proc/mtrr? No? Then 
don't even touch it. Same for ssse3. This has nothing to do with sse3. It is 
something completly different. And p4 never had this. 
Enable mmx, mmxext, sse, sse2 for everything and you are fine. Check for pni 
if you want sse3. Everything else is not for you.

look also here:
http://en.wikipedia.org/wiki/Pentium_4

as you can see:MMX, SSE, SSE2, SSE3 but sse3 only if you have 'pni' among your 
cpu's features.

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

[Stroller]

On 26 May 2009, at 06:10, Volker Armin Hemmann wrote:
>> ...
>> The mplayer ebuild is stated to be "intelligent" about ignoring these
>> flags if necessary, so I'm not sure that "if mplayer works, so will
>> everything else" is a safe conclusion. My question was exactly if it
>> was so - are other ebuilds also as "intelligent" as mplayer?
>>
>> ...
>> I'd disagree. If it were really simple, Portage would take care of it
>> automagically for me. It (apparently?) doesn't.
>
> portage does not take care. mplayers build has a cpu feature  
> autodection.
>
> Different stuff. Really.

Right, that was the question. Thank you for answering it. Sorry if I  
was unclear.

>> Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow
>> 3dnowext >> /etc/portage/package.use` unless someone else is able to
>> be more informative.
>
> yeah, except that is bullshit

So? It doesn't matter. Uh, I mean - that's what you just told me.

> no pentium can do 3dnow.

I did think that. But with other instructions adopted by the other  
manufacturer (eg. Intel adopted the amd64 architecture, I think?) it  
seemed odd that a set of instructions would be ignored so long.

> Or was there a 3dnow flag in /proc/mtrr? No? Then
> don't even touch it. Same for ssse3. This has nothing to do with  
> sse3. It is
> something completly different. And p4 never had this.

That's cool. I'll just keep minimal hardware USE flags in make.conf;  
in /etc/portage/package.use I'll tell mplayer to USE everything  
(including 3dnow) that it can.

Thanks,

Stroller.

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

[Volker Armin Hemmann]

On Dienstag 26 Mai 2009, Stroller wrote:
> On 26 May 2009, at 06:10, Volker Armin Hemmann wrote:
> >> ...
> >> The mplayer ebuild is stated to be "intelligent" about ignoring these
> >> flags if necessary, so I'm not sure that "if mplayer works, so will
> >> everything else" is a safe conclusion. My question was exactly if it
> >> was so - are other ebuilds also as "intelligent" as mplayer?
> >>
> >> ...
> >> I'd disagree. If it were really simple, Portage would take care of it
> >> automagically for me. It (apparently?) doesn't.
> >
> > portage does not take care. mplayers build has a cpu feature
> > autodection.
> >
> > Different stuff. Really.
>
> Right, that was the question. Thank you for answering it. Sorry if I
> was unclear.
>
> >> Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow
> >> 3dnowext >> /etc/portage/package.use` unless someone else is able to
> >> be more informative.
> >
> > yeah, except that is bullshit
>
> So? It doesn't matter. Uh, I mean - that's what you just told me.


see a bit below

>
> > no pentium can do 3dnow.
>
> I did think that. But with other instructions adopted by the other
> manufacturer (eg. Intel adopted the amd64 architecture, I think?) it
> seemed odd that a set of instructions would be ignored so long.

because 3dnow is/was very unimportant for intel- but Intel couldn't compete 
without AMD64. So they had to licence it. 3dnow and SSE have a lot of commands 
in common/similar commands anyway so it doesn't really matter from Intels POV.

The thing is - autodetection is a useflag too - and you are trusting a feature 
that might break any time. Better to know what your cpu can and can't do and 
set it by yourself. Also there are a lot more packages that do benefit from 
mmx, 3dnow, sse...

>
> > Or was there a 3dnow flag in /proc/mtrr? No? Then
> > don't even touch it. Same for ssse3. This has nothing to do with
> > sse3. It is
> > something completly different. And p4 never had this.
>
> That's cool. I'll just keep minimal hardware USE flags in make.conf;
> in /etc/portage/package.use I'll tell mplayer to USE everything
> (including 3dnow) that it can.

sorry that I was harsh. I shouldn't have been awake when I wrote the mail - 
freaking heat... 

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

[Stroller]

On 26 May 2009, at 07:27, Volker Armin Hemmann wrote:
>> ...
>> I did think that. But with other instructions adopted by the other
>> manufacturer (eg. Intel adopted the amd64 architecture, I think?) it
>> seemed odd that a set of instructions would be ignored so long.
>
> because 3dnow is/was very unimportant for intel- but Intel couldn't  
> compete
> without AMD64. So they had to licence it. 3dnow and SSE have a lot  
> of commands
> in common/similar commands anyway so it doesn't really matter from  
> Intels POV.

Completely OT now, but I seem to have a recollection that they have a  
cross-licensing agreement which covers stuff like this without further  
royalties.

Thanks for your help & the interesting discussion,

Stroller.

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

[Daniel Iliev]

On Tue, 26 May 2009 06:00:10 +0100
Stroller <stroller@stellar.eclipse.co.uk> wrote:


> Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow  
> 3dnowext >> /etc/portage/package.use` unless someone else is able to  
> be more informative.
> 
> Stroller.
>   


Yes, just add "cpudetection" to those or put it in in make.conf.

If you want to set the proper flags there's no other way but
to check what features the particular CPU model supports. The only sure
thing is that no Intel CPUs support AMD's 3now and 3dnowext.
Everything else depends on the moment the particular model was
released, because those features were not initially specified but
being added as time passes by.

Some random thoughts...

The packages that could utilize some of those cpu instruction sets are
not so many. Try "euse -i sse" for example and see which programs would
be affected if you change it. Then...trial and error. :)

Last but not least. If you have a (supported model of) NVidia
video card and don't mind using the closed source driver, you could try
VDPAU. It's a technology for Linux for offloading video decoding from
CPU to GPU. For a reference mplayer takes about 30% on my CPU to play
HD clips normally and about 2% when using VDPAU.

HTH

-- 
Best regards,
Daniel

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

[Stroller]

On 26 May 2009, at 15:31, Daniel Iliev wrote:
>
>> Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow
>> 3dnowext >> /etc/portage/package.use` unless someone else is able to
>> be more informative.
>>
>
> 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.

Stroller.

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

[Daniel Iliev]

On Tue, 26 May 2009 22:07:10 +0100
Stroller <stroller@stellar.eclipse.co.uk> wrote:

> 
> On 26 May 2009, at 15:31, Daniel Iliev wrote:
> >
> >> Looks like `echo media-video/mplayer mmx mmxext sse sse2 ssse3
> >> 3dnow 3dnowext >> /etc/portage/package.use` unless someone else is
> >> able to be more informative.
> >>
> >
> > 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.
> 
> Stroller.
> 
>

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.

-- 
Best regards,
Daniel

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.

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

[Daniel Iliev]

On Wed, 27 May 2009 09:14:03 +0100
Stroller <stroller@stellar.eclipse.co.uk> wrote:

> 
> On 27 May 2009, at 01:47, Daniel Iliev wrote:
> >
> > 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).
>

I'm afraid the common sense says disabling the "cpudetection" USE
flag could lead to the problem I described in my previous message.
Please, don't get me wrong - I'm not arguing and I've never tried to
build mplayer with EIS that is unsupported by the CPU. It may work if
the build system detects and corrects such errors when cpudetection is
disabled.

I personally set the correct EIS USE flags for my CPU globally and
disable the cpudetection flag. This has the advantage that all programs
supporting one or another EIS would be built with the EIS code included.
I didn't suggest you this approach because I believe somewhere in this
thread you mentioned you wanted to use the same settings on several
different systems.

-- 
Best regards,
Daniel

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

[Stroller]

On 27 May 2009, at 11:00, Daniel Iliev wrote:
> ...
> I'm afraid the common sense says disabling the "cpudetection" USE
> flag could lead to the problem I described in my previous message.
> Please, don't get me wrong - I'm not arguing and I've never tried to
> build mplayer with EIS that is unsupported by the CPU. It may work if
> the build system detects and corrects such errors when cpudetection is
> disabled.

I think it shouldn't apply to mplayer, as explained by Volker earlier  
in the thread. If a USE for an unsupported EIS is detected, the  
mplayer build process will ignore it, and build without them. This is  
because mplayer specifically is particularly clever about this,  
apparently.

> I personally set the correct EIS USE flags for my CPU globally and
> disable the cpudetection flag.

Clearly this is the ideal way.

> ... I didn't suggest you this approach because I believe somewhere  
> in this
> thread you mentioned you wanted to use the same settings on several
> different systems.

Not necessarily, but I don't want to have to *think* too much about  
hardware. I mean, I can safely set MMX because I know reasonably well  
what it is, I remember when it came out, and I remember reading as the  
next couple of subsequent generations of CPU were released that they  
would continue to support it. I have a pretty good idea that MMX is  
ubiquitous, and I imagine it to be supported even to the very latest  
Intel CPUs (not sure about AMD?).

But I don't know what SSE is or SSSE (??) or any of the others, and I  
don't really have any desire to know. Just so long as my server works  
then I'm happy. I mean, I guess if I used Linux on the desktop then  
performance might be more important to me, and it would behove me to  
optimise each system. Or if my server carried a lot of load. But my  
Linux boxes mostly don't -  they sit in a corner & serve files by  
Samba & email by IMAP and very little more.

mplayer is kinda an exceptional case for me, because I rip DVDs  
to .mp4 format and then stream them across the network from the  
fileserver to my PS3. When I rip them, the process runs circa 12 or 14  
hours, so if I can shave 10% of this then that may be useful - the  
movie may be ready to watch an hour earlier, and on some occasion I  
may be glad of that.

So if I `flagedit media-video/mplayer mmx mmxext sse sse2 ssse3 3dnow  
3dnowext` that gets me the best performance for mplayer without having  
to think about it.

Of course, the amount of time I've spent on this thread, I could  
perhaps have learned *exactly* what all these extended instruction  
sets do, who designed them, whether they're cross-licensed between  
manufacturers and what their prospects are for continued support in  
the future. But I would personally find that very boring, and I am  
much happier to have learned a little about how mplayer's build system  
works and how Gentoo wraps that.

Stroller.

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

[Wyatt Epp]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On Wed, May 27, 2009 at 8:14 AM, Stroller <stroller@stellar.eclipse.co.uk>wrote:

>
> Of course, the amount of time I've spent on this thread, I could perhaps
> have learned *exactly* what all these extended instruction sets do, who
> designed them, whether they're cross-licensed between manufacturers and what
> their prospects are for continued support in the future. But I would
> personally find that very boring, and I am much happier to have learned a
> little about how mplayer's build system works and how Gentoo wraps that.
>

It actually turns out that you can get the bare essentials on all of these
in about four minutes from Wikipedia.  Just sayin'.... :)

Reading this thread, though, it seems like it would be useful to have a
FEATURES=cpudetection for Portage.  I honestly don't understand why the user
should have to be arsed to set those USEs manually if they don't actually
care about moving binary packages around.  Thoughts?

Cheers,
Wyatt

[-- Attachment #2: Type: text/html, Size: 1316 bytes --]

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

[Volker Armin Hemmann]

On Mittwoch 27 Mai 2009, Wyatt Epp wrote:
> On Wed, May 27, 2009 at 8:14 AM, Stroller 
<stroller@stellar.eclipse.co.uk>wrote:
> > Of course, the amount of time I've spent on this thread, I could perhaps
> > have learned *exactly* what all these extended instruction sets do, who
> > designed them, whether they're cross-licensed between manufacturers and
> > what their prospects are for continued support in the future. But I would
> > personally find that very boring, and I am much happier to have learned a
> > little about how mplayer's build system works and how Gentoo wraps that.
>
> It actually turns out that you can get the bare essentials on all of these
> in about four minutes from Wikipedia.  Just sayin'.... :)
>
> Reading this thread, though, it seems like it would be useful to have a
> FEATURES=cpudetection for Portage.  I honestly don't understand why the
> user should have to be arsed to set those USEs manually if they don't
> actually care about moving binary packages around.  Thoughts?

thoughts: there are distros that hold your hand already.

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

[Alan McKinnon]

On Wednesday 27 May 2009 22:04:06 Volker Armin Hemmann wrote:
> On Mittwoch 27 Mai 2009, Wyatt Epp wrote:
> > On Wed, May 27, 2009 at 8:14 AM, Stroller
>
> <stroller@stellar.eclipse.co.uk>wrote:
> > > Of course, the amount of time I've spent on this thread, I could
> > > perhaps have learned *exactly* what all these extended instruction sets
> > > do, who designed them, whether they're cross-licensed between
> > > manufacturers and what their prospects are for continued support in the
> > > future. But I would personally find that very boring, and I am much
> > > happier to have learned a little about how mplayer's build system works
> > > and how Gentoo wraps that.
> >
> > It actually turns out that you can get the bare essentials on all of
> > these in about four minutes from Wikipedia.  Just sayin'.... :)
> >
> > Reading this thread, though, it seems like it would be useful to have a
> > FEATURES=cpudetection for Portage.  I honestly don't understand why the
> > user should have to be arsed to set those USEs manually if they don't
> > actually care about moving binary packages around.  Thoughts?
>
> thoughts: there are distros that hold your hand already.

There's also Windows. For just in case Ubuntu doesn't hold enough of your 
hand.

-- 
alan dot mckinnon at gmail dot com

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

[Wyatt Epp]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Wed, May 27, 2009 at 4:09 PM, Alan McKinnon <alan.mckinnon@gmail.com>wrote:

> On Wednesday 27 May 2009 22:04:06 Volker Armin Hemmann wrote:
> >
> > thoughts: there are distros that hold your hand already.
>
> There's also Windows. For just in case Ubuntu doesn't hold enough of your
> hand.


Oh right, what was I thinking, giving the users an optional tool to make
their lives marginally easier after they've tired of trying to remember for
their thirtieth install just which of these inane x86 SIMD instructions are
supported by cpu x?  I'm rolling my eyes over here, guys; that was uncalled
for and you know it.

Then again, it might be egg on my face for thinking that civilised discourse
was possible on a mailing list. :/

[-- Attachment #2: Type: text/html, Size: 1098 bytes --]

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

[Volker Armin Hemmann]

On Mittwoch 27 Mai 2009, Wyatt Epp wrote:
> On Wed, May 27, 2009 at 4:09 PM, Alan McKinnon 
<alan.mckinnon@gmail.com>wrote:
> > On Wednesday 27 May 2009 22:04:06 Volker Armin Hemmann wrote:
> > > thoughts: there are distros that hold your hand already.
> >
> > There's also Windows. For just in case Ubuntu doesn't hold enough of your
> > hand.
>
> Oh right, what was I thinking, giving the users an optional tool to make
> their lives marginally easier after they've tired of trying to remember for
> their thirtieth install just which of these inane x86 SIMD instructions are
> supported by cpu x?  I'm rolling my eyes over here, guys; that was uncalled
> for and you know it.

remember? a short look into /proc/cpuinfo tells you that. Or just:
if it is amd, it has 3dnow. Everything recent has sse and sse2. SSE3,4,ssse3 - 
check cpuinfo.

>
> Then again, it might be egg on my face for thinking that civilised
> discourse was possible on a mailing list. :/

well, it is civilised. Nobody did a personal attack. But if you think you are 
attacked because people disagree with you or don't think that your idea is a 
good one - well.. then you should not be part of discussions, true.

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

[Mike Edenfield]

On 5/27/2009 4:40 PM, Wyatt Epp wrote:
> On Wed, May 27, 2009 at 4:09 PM, Alan McKinnon <alan.mckinnon@gmail.com
> <mailto:alan.mckinnon@gmail.com>> wrote:
>
>     On Wednesday 27 May 2009 22:04:06 Volker Armin Hemmann wrote:
>      >
>      > thoughts: there are distros that hold your hand already.
>
>     There's also Windows. For just in case Ubuntu doesn't hold enough of
>     your
>     hand.
>
>
> Oh right, what was I thinking, giving the users an optional tool to make
> their lives marginally easier after they've tired of trying to remember
> for their thirtieth install just which of these inane x86 SIMD
> instructions are supported by cpu x?  I'm rolling my eyes over here,
> guys; that was uncalled for and you know it.

Clearly you haven't seen any of the Gentoo Installer threads.

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

[Alan McKinnon]

On Wednesday 27 May 2009 23:04:54 Mike Edenfield wrote:
> On 5/27/2009 4:40 PM, Wyatt Epp wrote:
> > On Wed, May 27, 2009 at 4:09 PM, Alan McKinnon <alan.mckinnon@gmail.com
> > <mailto:alan.mckinnon@gmail.com>> wrote:
> >
> >     On Wednesday 27 May 2009 22:04:06 Volker Armin Hemmann wrote:
> >      > thoughts: there are distros that hold your hand already.
> >
> >     There's also Windows. For just in case Ubuntu doesn't hold enough of
> >     your
> >     hand.
> >
> >
> > Oh right, what was I thinking, giving the users an optional tool to make
> > their lives marginally easier after they've tired of trying to remember
> > for their thirtieth install just which of these inane x86 SIMD
> > instructions are supported by cpu x?  I'm rolling my eyes over here,
> > guys; that was uncalled for and you know it.
>
> Clearly you haven't seen any of the Gentoo Installer threads.

Or me and Uwe (may he rest in peace and may there be infinite pubs in the 
afterlife where he is now) discussing who owed the other how many of Namibia's 
finest brew.

-- 
alan dot mckinnon at gmail dot com

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

[Adam Carter]

 > > > actually care about moving binary packages around.  Thoughts?
> >
> > thoughts: there are distros that hold your hand already.
>
> There's also Windows. For just in case Ubuntu doesn't hold
> enough of your hand.

I'm with Wyatt on this one. Can we appreciate there may be a difference between convenience and hand holding? If we consider the case where the user is not interested in moving binary packages between machines, there is nothing to be gained from customsing these CPU feature flags as you always want all of them.

Personally I wouldn't bother putting a feature request in for this, as I know which flags to use and as I only build about one gentoo box a year so the overhead is low.

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

[Ward Poelmans]

On Wed, May 27, 2009 at 21:57, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> Reading this thread, though, it seems like it would be useful to have a
> FEATURES=cpudetection for Portage.  I honestly don't understand why the user
> should have to be arsed to set those USEs manually if they don't actually
> care about moving binary packages around.  Thoughts?

W're gentoo users, we like being in control and don't like it when a
program thinks for us.

Ward

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

[Mike Edenfield]

On 5/27/2009 4:08 PM, Ward Poelmans wrote:
> On Wed, May 27, 2009 at 21:57, Wyatt Epp<wyatt.epp@gmail.com>  wrote:
>> Reading this thread, though, it seems like it would be useful to have a
>> FEATURES=cpudetection for Portage.  I honestly don't understand why the user
>> should have to be arsed to set those USEs manually if they don't actually
>> care about moving binary packages around.  Thoughts?
>
> W're gentoo users, we like being in control and don't like it when a
> program thinks for us.

Even if this feature were to appear (and it seems to me like a complete 
pain in the ass to implement), no one is gonna force your fingers to 
type "FEATURES=cpudetection" into your make.conf file.

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

[Arttu V.]

On 5/27/09, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> Reading this thread, though, it seems like it would be useful to have a
> FEATURES=cpudetection for Portage.

Congratulations, it's already there! Sort of. -march=native ;)

-- 
Arttu V.

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

[Daniel Iliev]

On Thu, 28 May 2009 00:23:52 +0300
"Arttu V." <arttuv69@gmail.com> wrote:

> On 5/27/09, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> > Reading this thread, though, it seems like it would be useful to
> > have a FEATURES=cpudetection for Portage.
> 
> Congratulations, it's already there! Sort of. -march=native ;)
> 

Not the same thing. "-march=" instructs gcc to produce a binary
designed to run only on the given CPU architecture, while
USE flags instruct the build system to include or not support for a
given feature. Think of the USE flags "this" and "that" as shortcuts to
"./configure --enable-this --disable-that".

So, for example mplayer could be a binary which can take advantage (or
not) of SSSE3 and is designed to run only (or not) on core2.


P.S.

And what's next - feature like:

FEATURES="do_the_best_system_ever"

where "do_the_best_system_ever" is a shorthand for:

detect_best_cflags
detect_best_cxxflags
detect_best_ldflags
detect_best_uselags

Sounds good and it's not against Gentoo philosophy - the end user has
the choice to use this feature or not. Any volunteers for the
implementation? Oh, wait! Somebody define "best", please! :)


-- 
Best regards,
Daniel

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

[Stroller]

On 28 May 2009, at 11:17, Daniel Iliev wrote:
> ...
> Not the same thing. "-march=" instructs gcc to produce a binary
> designed to run only on the given CPU architecture, while
> USE flags instruct the build system to include or not support for a
> given feature ...

Actually, I _think_ in mplayer the difference is that the USE flags  
enable the use of hand-written assembler code which takes advantage of  
the MMX or whatever.

I'm not 100% sure about this at all, but what's the difference in the  
architectures of the Pentium 2 & the Pentium 3, if not for the support  
for SSE? (and / or whatever)

Sure they are designed differently, but surely the instruction sets of  
all 32-bit processors from the earliest Pentiums even to Core Duos  
(not Core2s) are all basically x86. Some have these extended  
instruction sets (EIS, I think you called them earlier in the thread)  
and those are the additions from one generation to the next. So if you  
choose -march=pentium3 it will not run on a Pentium 2 because Pentium  
2s do not have SSSE, and it's the *compiler* that added the code that  
utilises SSE.

I believe that mplayer is one of those exceptional packages which uses  
some assembler optimisations. These don't make any sense for most  
programs, because it takes too much time to write & much maintenance  
is loads of hassle, and assembler will make little difference. Most  
programs are one minute opening a new window, and the next minute are  
waiting for the mail server to reply and are doing lots of different  
tasks which are not worth hand optimising. But once mplayer has  
started decoding a video, then it's doing the same thing time & time  
again, decoding each frame of the picture - it does exactly the same  
thing 25 times per second for an hour or two at a time, so that may be  
worth optimising for if the compiler is found to be less clever than  
someone like John Carmack.

I'm not absolutely sure that the USE flags enable hand-written  
assembler code, but what I do know is that:
1) ASM stands for assembler. See http://en.wikipedia.org/wiki/Asm
2) Google "mplayer asm" returns a bunch of hits.
3) MMX was marketed as "MultiMedia eXtension"
4) mplayer is a multimedia player.
5) MMX doesn't have floating point support, but SSE adds that and has  
dedicated functions for multiplying floating point numbers [1], which  
is just the sort of thing that one are useful in decoding mpegs &  
playing back video.

Stroller.




[1] http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

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

[Ward Poelmans]

On Thu, May 28, 2009 at 21:13, Stroller <stroller@stellar.eclipse.co.uk> wrote:
>
> I'm not absolutely sure that the USE flags enable hand-written assembler
> code, but what I do know is that:

Don't make it more difficult then it is. SSE, etc means the CPU
support a certain set of instructions. When you enable the use flag
for it, mplayer will make use of the instructions. And to do that, it
will use assembly if necessary. If you want to know where and how,
take a look at the mplayer source code. For example the file
libavcodec/x86/h264_idct_sse2.asm does exactly what the name suggests.

Ward

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

[Stroller]

On 28 May 2009, at 21:08, Ward Poelmans wrote:

> On Thu, May 28, 2009 at 21:13, Stroller <stroller@stellar.eclipse.co.uk 
> > wrote:
>>
>> I'm not absolutely sure that the USE flags enable hand-written  
>> assembler
>> code, but what I do know is that:
>
> Don't make it more difficult then it is. SSE, etc means the CPU
> support a certain set of instructions. When you enable the use flag
> for it, mplayer will make use of the instructions.

But, surely "-march=" also instructs gcc to support the additional  
instructions.  Suggest you re-read Daniel's post that I was replying to.

What's the difference between supporting the "certain set of  
instructions" with "-march=" and doing so with USEs?

Or doesn't "-march=" support additional "certain sets of  
instructions". What does it do, then?

Stroller.

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

[Ward Poelmans]

On Thu, May 28, 2009 at 22:19, Stroller <stroller@stellar.eclipse.co.uk> wrote:
> What's the difference between supporting the "certain set of instructions"
> with "-march=" and doing so with USEs?
>
> Or doesn't "-march=" support additional "certain sets of instructions". What
> does it do, then?

The difference is that with the USE flag, you enable the use of
assembly code in the source of mplayer that makes use of the "certain
set of instructions". The -march option enables the use of the
"certain set of instructions" when gcc is optimizing and so gcc will
use the "certain set of instructions" when it converts the source code
into assembly code.

Ward

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

[Stroller]

On 28 May 2009, at 21:27, Ward Poelmans wrote:

> On Thu, May 28, 2009 at 22:19, Stroller <stroller@stellar.eclipse.co.uk 
> > wrote:
>> What's the difference between supporting the "certain set of  
>> instructions"
>> with "-march=" and doing so with USEs?
>>
>> Or doesn't "-march=" support additional "certain sets of  
>> instructions". What
>> does it do, then?
>
> The difference is that with the USE flag, you enable the use of
> assembly code in the source of mplayer that makes use of the "certain
> set of instructions". The -march option enables the use of the
> "certain set of instructions" when gcc is optimizing and so gcc will
> use the "certain set of instructions" when it converts the source code
> into assembly code.



Right. That's what I was surmising in the post (28 May 2009 20:13:57  
BST) you previously replied to.

Stroller.

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

[Graham Murray]

Stroller <stroller@stellar.eclipse.co.uk> writes:

> But, surely "-march=" also instructs gcc to support the additional
> instructions.  Suggest you re-read Daniel's post that I was replying
> to.
>
> What's the difference between supporting the "certain set of
> instructions" with "-march=" and doing so with USEs?
>
> Or doesn't "-march=" support additional "certain sets of
> instructions". What does it do, then?

I am not sure,

$ gcc -Q --help=target -march=core2
The following options are target specific:         
  -m128bit-long-double                  [disabled] 
  -m32                                  [enabled]  
  -m3dnow                               [disabled] 
  -m3dnowa                              [disabled] 
  -m64                                  [disabled] 
  -m80387                               [enabled]  
  -m96bit-long-double                   [enabled]  
  -mabm                                 [disabled] 
  -maccumulate-outgoing-args            [disabled] 
  -maes                                 [disabled] 
  -malign-double                        [disabled] 
  -malign-functions=                               
  -malign-jumps=                                   
  -malign-loops=                                   
  -malign-stringops                     [enabled]  
  -march=                               core2      
  -masm=                                           
  -mavx                                 [disabled]
  -mbranch-cost=
  -mcld                                 [disabled]
  -mcmodel=
  -mcx16                                [disabled]
  -mfancy-math-387                      [enabled]
  -mfma                                 [disabled]
  -mforce-drap                          [disabled]
  -mfp-ret-in-387                       [enabled]
  -mfpmath=
  -mfused-madd                          [enabled]
  -mglibc                               [enabled]
  -mhard-float                          [enabled]
  -mieee-fp                             [enabled]
  -mincoming-stack-boundary=
  -minline-all-stringops                [disabled]
  -minline-stringops-dynamically        [disabled]
  -mintel-syntax                        [disabled]
  -mlarge-data-threshold=
  -mmmx                                 [disabled]
  -mms-bitfields                        [disabled]
  -mno-align-stringops                  [disabled]
  -mno-fancy-math-387                   [disabled]
  -mno-fused-madd                       [disabled]
  -mno-push-args                        [disabled]
  -mno-red-zone                         [disabled]
  -mno-sse4                             [enabled]
  -momit-leaf-frame-pointer             [disabled]
  -mpc
  -mpclmul                              [disabled]
  -mpopcnt                              [disabled]
  -mpreferred-stack-boundary=
  -mpush-args                           [enabled]
  -mrecip                               [disabled]
  -mred-zone                            [enabled]
  -mregparm=
  -mrtd                                 [disabled]
  -msahf                                [disabled]
  -msoft-float                          [disabled]
  -msse                                 [disabled]
  -msse2                                [disabled]
  -msse2avx                             [disabled]
  -msse3                                [disabled]
  -msse4                                [disabled]
  -msse4.1                              [disabled]
  -msse4.2                              [disabled]
  -msse4a                               [disabled]
  -msse5                                [disabled]
  -msseregparm                          [disabled]
  -mssse3                               [disabled]
  -mstack-arg-probe                     [disabled]
  -mstackrealign                        [enabled]
  -mstringop-strategy=
  -mtls-dialect=
  -mtls-direct-seg-refs                 [enabled]
  -mtune=
  -muclibc                              [disabled]
  -mveclibabi=

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

[Volker Armin Hemmann]

On Freitag 29 Mai 2009, Graham Murray wrote:
> Stroller <stroller@stellar.eclipse.co.uk> writes:
> > But, surely "-march=" also instructs gcc to support the additional
> > instructions.  Suggest you re-read Daniel's post that I was replying
> > to.
> >
> > What's the difference between supporting the "certain set of
> > instructions" with "-march=" and doing so with USEs?
> >
> > Or doesn't "-march=" support additional "certain sets of
> > instructions". What does it do, then?
>
> I am not sure,
>
> $ gcc -Q --help=target -march=core2
> The following options are target specific:
>   -m128bit-long-double                  [disabled]
>   -m32                                  [enabled]
>   -m3dnow                               [disabled]
>   -m3dnowa                              [disabled]
>   -m64                                  [disabled]
>   -m80387                               [enabled]
>   -m96bit-long-double                   [enabled]
>   -mabm                                 [disabled]
>   -maccumulate-outgoing-args            [disabled]
>   -maes                                 [disabled]
>   -malign-double                        [disabled]
>   -malign-functions=
>   -malign-jumps=
>   -malign-loops=
>   -malign-stringops                     [enabled]
>   -march=                               core2
>   -masm=
>   -mavx                                 [disabled]
>   -mbranch-cost=
>   -mcld                                 [disabled]
>   -mcmodel=
>   -mcx16                                [disabled]
>   -mfancy-math-387                      [enabled]
>   -mfma                                 [disabled]
>   -mforce-drap                          [disabled]
>   -mfp-ret-in-387                       [enabled]
>   -mfpmath=
>   -mfused-madd                          [enabled]
>   -mglibc                               [enabled]
>   -mhard-float                          [enabled]
>   -mieee-fp                             [enabled]
>   -mincoming-stack-boundary=
>   -minline-all-stringops                [disabled]
>   -minline-stringops-dynamically        [disabled]
>   -mintel-syntax                        [disabled]
>   -mlarge-data-threshold=
>   -mmmx                                 [disabled]
>   -mms-bitfields                        [disabled]
>   -mno-align-stringops                  [disabled]
>   -mno-fancy-math-387                   [disabled]
>   -mno-fused-madd                       [disabled]
>   -mno-push-args                        [disabled]
>   -mno-red-zone                         [disabled]
>   -mno-sse4                             [enabled]
>   -momit-leaf-frame-pointer             [disabled]
>   -mpc
>   -mpclmul                              [disabled]
>   -mpopcnt                              [disabled]
>   -mpreferred-stack-boundary=
>   -mpush-args                           [enabled]
>   -mrecip                               [disabled]
>   -mred-zone                            [enabled]
>   -mregparm=
>   -mrtd                                 [disabled]
>   -msahf                                [disabled]
>   -msoft-float                          [disabled]
>   -msse                                 [disabled]
>   -msse2                                [disabled]
>   -msse2avx                             [disabled]
>   -msse3                                [disabled]
>   -msse4                                [disabled]
>   -msse4.1                              [disabled]
>   -msse4.2                              [disabled]
>   -msse4a                               [disabled]
>   -msse5                                [disabled]
>   -msseregparm                          [disabled]
>   -mssse3                               [disabled]
>   -mstack-arg-probe                     [disabled]
>   -mstackrealign                        [enabled]
>   -mstringop-strategy=
>   -mtls-dialect=
>   -mtls-direct-seg-refs                 [enabled]
>   -mtune=
>   -muclibc                              [disabled]
>   -mveclibabi=

and man gcc says:
 --help={class|[^]qualifier}[,...]
           Print (on the standard output) a description of the command line 
options understood by the compiler that fit into all specified
           classes and qualifiers.  These are the supported classes:

target
    This will display target-specific options.  Unlike the --target-help 
option however, target-specific options of the linker
               and assembler will not be displayed.  This is because those 
tools do not currently support the extended --help= syntax.

Which leads to the conclusion, that it only shows options that can be set. Not 
options how they are really set (besides a few that are enabled by the 
architecture). If you leave -march=core2 out. you will probably get the same 
result.

for example:
 -mfpmath=unit
           Generate floating point arithmetics for selected unit unit.  The 
choices for unit are:

           387 Use the standard 387 floating point coprocessor present 
majority of chips and emulated otherwise.  Code compiled with this
               option will run almost everywhere.  The temporary results are 
computed in 80bit precision instead of precision specified by
               the type resulting in slightly different results compared to 
most of other chips.  See -ffloat-store for more detailed
               description.

               This is the default choice for i386 compiler.

           sse Use scalar floating point instructions present in the SSE 
instruction set.  This instruction set is supported by Pentium3
               and newer chips, in the AMD line by Athlon-4, Athlon-xp and 
Athlon-mp chips.  The earlier version of SSE instruction set
               supports only single precision arithmetics, thus the double and 
extended precision arithmetics is still done using 387.
               Later version, present only in Pentium4 and the future AMD 
x86-64 chips supports double precision arithmetics too.

               For the i386 compiler, you need to use -march=cpu-type, -msse 
or -msse2 switches to enable SSE extensions and make this
               option effective.  For the x86-64 compiler, these extensions 
are enabled by default.

               The resulting code should be considerably faster in the 
majority of cases and avoid the numerical instability problems of
               387 code, but may break some existing code that expects 
temporaries to be 80bit.

               This is the default choice for the x86-64 compiler.

as you can see from the man excerpt, if the help showed enabled options, 
mfpmath=sse should be there. It isn't.

...

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

[Volker Armin Hemmann]

On Freitag 29 Mai 2009, Graham Murray wrote:
> Stroller <stroller@stellar.eclipse.co.uk> writes:
> > But, surely "-march=" also instructs gcc to support the additional
> > instructions.  Suggest you re-read Daniel's post that I was replying
> > to.
> >
> > What's the difference between supporting the "certain set of
> > instructions" with "-march=" and doing so with USEs?
> >
> > Or doesn't "-march=" support additional "certain sets of
> > instructions". What does it do, then?
>
> I am not sure,
>
> $ gcc -Q --help=target -march=core2
> The following options are target specific:
>   -m128bit-long-double                  [disabled]
>   -m32                                  [enabled]
>   -m3dnow                               [disabled]
>   -m3dnowa                              [disabled]
>   -m64                                  [disabled]
>   -m80387                               [enabled]
>   -m96bit-long-double                   [enabled]
>   -mabm                                 [disabled]
>   -maccumulate-outgoing-args            [disabled]
>   -maes                                 [disabled]
>   -malign-double                        [disabled]
>   -malign-functions=
>   -malign-jumps=
>   -malign-loops=
>   -malign-stringops                     [enabled]
>   -march=                               core2
>   -masm=
>   -mavx                                 [disabled]
>   -mbranch-cost=
>   -mcld                                 [disabled]
>   -mcmodel=
>   -mcx16                                [disabled]
>   -mfancy-math-387                      [enabled]
>   -mfma                                 [disabled]
>   -mforce-drap                          [disabled]
>   -mfp-ret-in-387                       [enabled]
>   -mfpmath=
>   -mfused-madd                          [enabled]
>   -mglibc                               [enabled]
>   -mhard-float                          [enabled]
>   -mieee-fp                             [enabled]
>   -mincoming-stack-boundary=
>   -minline-all-stringops                [disabled]
>   -minline-stringops-dynamically        [disabled]
>   -mintel-syntax                        [disabled]
>   -mlarge-data-threshold=
>   -mmmx                                 [disabled]
>   -mms-bitfields                        [disabled]
>   -mno-align-stringops                  [disabled]
>   -mno-fancy-math-387                   [disabled]
>   -mno-fused-madd                       [disabled]
>   -mno-push-args                        [disabled]
>   -mno-red-zone                         [disabled]
>   -mno-sse4                             [enabled]
>   -momit-leaf-frame-pointer             [disabled]
>   -mpc
>   -mpclmul                              [disabled]
>   -mpopcnt                              [disabled]
>   -mpreferred-stack-boundary=
>   -mpush-args                           [enabled]
>   -mrecip                               [disabled]
>   -mred-zone                            [enabled]
>   -mregparm=
>   -mrtd                                 [disabled]
>   -msahf                                [disabled]
>   -msoft-float                          [disabled]
>   -msse                                 [disabled]
>   -msse2                                [disabled]
>   -msse2avx                             [disabled]
>   -msse3                                [disabled]
>   -msse4                                [disabled]
>   -msse4.1                              [disabled]
>   -msse4.2                              [disabled]
>   -msse4a                               [disabled]
>   -msse5                                [disabled]
>   -msseregparm                          [disabled]
>   -mssse3                               [disabled]
>   -mstack-arg-probe                     [disabled]
>   -mstackrealign                        [enabled]
>   -mstringop-strategy=
>   -mtls-dialect=
>   -mtls-direct-seg-refs                 [enabled]
>   -mtune=
>   -muclibc                              [disabled]
>   -mveclibabi=

get this:
dev.gentoo.org/~dirtyepic/bin/analyze-x86

and let it run, for example:
/analyze-x86 /bin/gzip
Checking vendor_id string... AuthenticAMD 64
Disassembling /bin/gzip, please wait...
i486:    0 i586:    0 ppro:   36 mmx:   46 3dnow:    0 ext3dnow:    0 sse:    
0 sse2:    4 sse3:    0
/bin/gzip will run on AMD Athlon64 or higher processor.

or this:
/analyze-x86 /bin/bash
Checking vendor_id string... AuthenticAMD 64
Disassembling /bin/bash, please wait...
i486:    0 i586:    0 ppro:  369 mmx:  876 3dnow:    0 ext3dnow:    0 sse:  
120 sse2:    0 sse3:    0
/bin/bash will run on Pentium III (pentium3) or higher processor.

and march=k8-sse3 -msse3 -O2 -pipe were my flags. Seems that a lot of stuff 
got turned on ;)

mplayer is even more 'interessting':
./analyze-x86 /usr/bin/mplayer
Checking vendor_id string... AuthenticAMD 64
Disassembling /usr/bin/mplayer, please wait...
i486: 3948 i586:   14 ppro: 7573 mmx: 164986 3dnow: 5331 ext3dnow:  768 sse: 
31407 sse2: 27712 sse3:   51

This binary was found to contain the cpuid instruction.
It may be able to conditionally execute instructions if
they are supported on the host (i586+).

/usr/bin/mplayer will run on AMD Athlon64 w/ SSE3 or higher processor.

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

[Mike Edenfield]

Stroller<stroller@stellar.eclipse.co.uk>  writes:
> But, surely "-march=" also instructs gcc to support the additional
> instructions.  Suggest you re-read Daniel's post that I was replying
> to.
>
> What's the difference between supporting the "certain set of
> instructions" with "-march=" and doing so with USEs?

One is for telling gcc how to compile C code, the other is for telling 
packages what inline assembler code is legal.

In the case of mplayer, just setting mmx/sse/etc does absolutely 
nothing.  You also have to enable custom-cpuopts, which then tells 
mplayer to ignore its own build-time detection of CPU features and only 
use the ones you tell it.  Either way, if mplayer does it automatically 
or you pass in USE flags, all they do is enable selected asm files in 
the codecs that use those opcodes.

--K

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

On Thu, 28 May 2009 21:19:37 +0100, Stroller wrote:

> What's the difference between supporting the "certain set of  
> instructions" with "-march=" and doing so with USEs?

-march determines how the code is compiled.
USE determines which code is compiled.


-- 
Neil Bothwick

Runtime Error: Out of funny taglines!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[KH]

Hi,

so I temporarily disable all USE flags in my make.conf by adding the "#"
to the line. Some with package.use.
The I run :

USE="cpudetection" emerge -pv mplayer

See output below.

So what changes for me: oss is added. That's nothing for hardware and I
use alsa, so I don't need it, do I?
-aalib -cddb -cdparanoia -debug -dirac -dvb (not hardware)
-pvr (it's software too, isn't it?)
-samba -schroedinger -xinerama (not hardware)


Is this a valid way of approache?

So My USE flags are set correct (for hardware) aren't they?

Some more output can be found below.


kh


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] media-video/mplayer-1.0_rc2_p28450  USE="X a52 aac alsa
ass cpudetection* dts dv dvd encode esd gif gtk iconv ipv6 jpeg live mad
md5sum mmx mp2 mp3 opengl oss* png quicktime sdl sse sse2 theora
truetype unicode vorbis x264 xscreensaver xv xvid -3dnow -3dnowext
-aalib* (-altivec) -amrnb -amrwb -arts -bidi -bindist -bl -cddb* -cdio
-cdparanoia* -custom-cflags -custom-cpuopts -debug* -dga -dirac*
-directfb -doc -dvb* (-dvdnav) -dxr3 -enca -fbcon -ftp -ggi -jack
-joystick -ladspa -libcaca -lirc -lzo -mmxext -mng -musepack -nas
-nemesi -openal -pnm -pulseaudio -pvr* -radio -rar (-real) -rtc -samba*
-schroedinger* -speex -ssse3 (-svga) -teletext -tga -v4l -v4l2 (-vidix)
(-win32codecs) -xanim -xinerama* -xvmc -zoran" VIDEO_CARDS="vesa* -mga
-s3virge -tdfx" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB



grep flags /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3dnow rep_good nopl pni lahf_lm cmp_legacy

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

[KH]

KH schrieb:
> Hi,
> 
> so I temporarily disable all USE flags in my make.conf by adding the "#"
> to the line. Some with package.use.
> The I run :
> 
> USE="cpudetection" emerge -pv mplayer
> 


> 
> Is this a valid way of approache?
> 

From Stroller:

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.

Stroller.




So to answer my own question: It looks like it isn't the correct approache.

kh

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

[Alan McKinnon]

On Wednesday 27 May 2009 00:20:50 KH wrote:
> Hi,
>
> so I temporarily disable all USE flags in my make.conf by adding the "#"
> to the line. Some with package.use.
> The I run :
>
> USE="cpudetection" emerge -pv mplayer
>
> See output below.
>
> So what changes for me: oss is added. That's nothing for hardware and I
> use alsa, so I don't need it, do I?
> -aalib -cddb -cdparanoia -debug -dirac -dvb (not hardware)
> -pvr (it's software too, isn't it?)
> -samba -schroedinger -xinerama (not hardware)
>
>
> Is this a valid way of approache?
>
> So My USE flags are set correct (for hardware) aren't they?

No, you have it wrong.

The ebuild does not magically change the USE flags based on what you have. It 
will build according to what you tell it, no more, no less.

USE=cpudetection causes special code to be compiled into mplayer. Think of it 
this way (a highly simplistic explanation that gets the point across):

mplayer is built with routines for every possible optimization. At RUNTIME, 
when mplayer starts, it figures out what you have and what you can use, and 
remembers for itself the routines you can't use and does not run them.

cpudetection changes runtime behaviour, not compile time behaviour, and does 
not change your use flags at all. When you hashed out the line in 
/etc/make.conf, all you proved is that with the exception of oss, your 
configured USE flags for mplayer are the same as the default for your profile 
and mplayer.

-- 
alan dot mckinnon at gmail dot com

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

[James]

Stroller <stroller <at> stellar.eclipse.co.uk> writes:


> I'm always rather reluctant to enable any of these, being unsure  
> whether my ageing PentiumPro or Pentium 4 CPUs support such features  
> as 3DNow! (originally an AMD technology) or the advanced SSSSSSSSSE3.


I run this on dozens of amd64 laptops and 3workstations and servers
from make.conf:

USE="mmx mmxext sse sse2 sse3 3dnow 3dnowext \

no problems, great performance!

Here is something nice from that palladies dude I keep in my
.bashrc:

# USE flag settings hack by Ciaran McCreesh:
explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
portdir)/profiles/use.{,local.}desc; }
alias ef="explainuseflag"


ef sse3
Enable optimisations using the sse3 assmbly code
Enable SSE3 support


ef ssse3
faster floating point optimization for SSSE3 capable chips (Intel Core 2 and
later chips)


My wife just loves Palladis exercise class....
;-)


hth,

James