Here's the setup of my secondary machine.. It's a Dell Inspiron
Desktop 530, with 2 gigs of ram, assembled and shipped August 2007. It
has an Intel Core2 (*NOT* a "Core2 Duo") cpu. From /proc/cpuinfo...

vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Genuine Intel(R) CPU 2140 @ 1.60GHz
stepping : 2
cpu MHz : 1595.660
cache size : 1024 KB

Here are the cpu flags...

waltdnes@d530 ~ $ grep flags /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl
est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts

Then I ran "gcc -march=native -Q --help=target" and got a major shock.
It's a long output listing of what -march=native thinks about my cpu.
Here are some relevant items...

-march= core2
-mmmx [disabled]
-msse [disabled]
-msse2 [disabled]
-msse3 [disabled]
-mssse3 [disabled]

It properly identified the cpu as "core2". But mmx, sse, sse2, sse3
(aka pni), and ssse3 are disabled!!!

The reason I dug into this was that I was trying to 1920x1080i
streaming video from my HDHomerun TV tuner box. I originally used

CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe"

when setting up the system. It could not handle 1920x1080i streaming TV
video.

After findinding out about "-native", I changed CFLAGS to...

CFLAGS="-O2 -march=native -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=sse -fomit-frame-pointer -pipe"

...and emerged system and world and rebuilt the kernel. Now the onboard
Intel GPU handles 1920x1080i flawlessly. As a matter of fact, it
handles 1080p flawlessly.

--
Walter Dnes <waltdnes@waltdnes.org>

Walter Dnes wrote:

gcc -march=native -Q --help=target


If that shows something disabled that cat /proc/cpuinfo shows as
available, is it safe to turn it on? So far all I have found that is
disabled that cpuinfo shows is mmx. I'm still looking tho.


Also, I think the native setting is a setting that is known to be 100%
safe. It is likely one of those things that if you use anything not
safe and have problems, you get to keep the pieces. I think if the CPU
supports it should be fine to turn but wanted to ask and make sure. I
paid almost $200 for my CPU and I would like to get $200 out of it and
use it all. I bought the whole thing so may as well use the whole
thing. ;-)


Thoughts?

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On 12/17/2011 11:07 PM, Walter Dnes wrote:


Then I ran "gcc -march=native -Q --help=target" and got a major shock.
It's a long output listing of what -march=native thinks about my cpu.
Here are some relevant items...

-march= core2
-mmmx [disabled]
-msse [disabled]
-msse2 [disabled]
-msse3 [disabled]
-mssse3 [disabled]

It properly identified the cpu as "core2". But mmx, sse, sse2, sse3
(aka pni), and ssse3 are disabled!!!


The output lies. It's a known issue. Use this instead:

echo | gcc -dM -E - -march=native

You should see stuff like:

#define __MMX__ 1
#define __SSE3__ 1

On Sat, Dec 17, 2011 at 11:58:36PM +0200, Nikos Chantziaras wrote

> The output lies. It's a known issue. Use this instead:
>
> echo | gcc -dM -E - -march=native
>
> You should see stuff like:
>
> #define __MMX__ 1
> #define __SSE3__ 1

The onboard GPU was initially incapable of handling 1080i video without
stuttering badly and dropping frames. After explicitly changing the
flags and rebuilding system+world+kernel, it displays 1080p videos
flawlessly. That's one big "co-incidence".

--
Walter Dnes <waltdnes@waltdnes.org>

On Sat, Dec 17, 2011 at 3:07 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> -march= * * * * * * * * * * * * * * * core2
> -mmmx * * * * * * * * * * * * * * * * [disabled]
> -msse * * * * * * * * * * * * * * * * [disabled]
> -msse2 * * * * * * * * * * * * * * * *[disabled]
> -msse3 * * * * * * * * * * * * * * * *[disabled]
> -mssse3 * * * * * * * * * * * * * * * [disabled]
>
> *It properly identified the cpu as "core2". *But mmx, sse, sse2, sse3
> (aka pni), and ssse3 are disabled!!!

I think you may be misinterpreting that output. It's not telling you
that MMX etc. are disabled, it's telling you that the /commandline
options/ are disabled. Why?

From the GCC docs:
"core2: Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
and SSSE3 instruction set support."

That means those features are implied by -march=core2, adding those
commandline switches would be redundant.

On Sat, Dec 17, 2011 at 08:10:54PM -0500, Walter Dnes wrote

> The onboard GPU was initially incapable of handling 1080i video without
> stuttering badly and dropping frames. After explicitly changing the
> flags and rebuilding system+world+kernel, it displays 1080p videos
> flawlessly. That's one big "co-incidence".

This was only recently installed. Is it possible that the generic x86
code from the initial install was the problem? And that emerging
system+world got me full optimization?

--
Walter Dnes <waltdnes@waltdnes.org>

On 12/18/2011 12:34 PM, Walter Dnes wrote:

On Sat, Dec 17, 2011 at 08:10:54PM -0500, Walter Dnes wrote


The onboard GPU was initially incapable of handling 1080i video without
stuttering badly and dropping frames. After explicitly changing the
flags and rebuilding system+world+kernel, it displays 1080p videos
flawlessly. That's one big "co-incidence".


This was only recently installed. Is it possible that the generic x86
code from the initial install was the problem? And that emerging
system+world got me full optimization?


Could be. It could also be it's because of "-mfpmath=sse". That's only
used by default on 64-bit. On 32-bit, the FPU is used for floating
point operations by default, which gives better precision (80 bit vs 64
bit) but slower speed.


But then again, that sounds too much of a performance difference. So if
I had to guess, I'd say it's because of the world rebuild that made sure
everything was built with proper optimizations.

> Could be. It could also be it's because of "-mfpmath=sse".

AFAIK most video decoders (outside of reference implementations) are
written using integer math only... -O3 is a much more likely candidate.

andrea