Cpu_flags_x86

Xywa · Posted: Thu Jan 29, 2015 8:51 pm Post subject: Cpu_flags_x86

Hi,

I have just read a news about new: CPU_FLAGS_X86

Martux · Veteran Joined: 04 Feb 2005 Posts: 1917

Use the flags from the script, if something changes in a packages use flags, you will see it like this:

229566 · Tux's lil' helper Joined: 16 Aug 2010 Posts: 127

ffmpeg loses cpu-specific flags because they're removed from USE, but doesn't appear to have CPU_FLAGS_X86. Is this a bug? Or not all ebuilds are compliant at this stage?

khayyam · Posted: Fri Jan 30, 2015 1:41 am Post subject:

ct85711 · Veteran Joined: 27 Sep 2005 Posts: 1791

Oh fun, another shift that most likely is going to be half pushed out, breaking stuff because it's not pushed fully out to everything, and properly supported...

229566 · Tux's lil' helper Joined: 16 Aug 2010 Posts: 127

Maitreya · Guru Joined: 11 Jan 2006 Posts: 445

I just moved them from USE to CPU_FLAGS_X86 and then add ${CPU_FLAGS_X86} to USE

limn · l33t Joined: 13 May 2005 Posts: 997

Theirs not to reason why

lost+found · Posted: Fri Jan 30, 2015 10:40 pm Post subject:

The script doesn't mention the `sse4' flag on a Core i3, although there are packages offering it...

iamben · Apprentice Joined: 10 May 2004 Posts: 278

Once all packages have been converted, you will no longer need CPU_FLAGS_X86 in USE. ffmpeg was converted 6 hrs ago, I believe all packages in portage have been converted, but all bets are off with overlays

eccerr0r · Posted: Sat Jan 31, 2015 12:08 am Post subject:

Is it possible to now do a per-package CPU_FLAGS_X86?

Like if I want a generic install but allow some apps to be runnable only on those machines that have the capability? (namely want a generic install that will run on all CPUs but allow adobe-flash to run only on those capable of SSE2)?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

khayyam · Posted: Sat Jan 31, 2015 12:35 am Post subject:

hello ... I honestly don't see what benefit this change brings, I mean, does it matter if its in USE or some other var if they are all essentially useflags. I can see negatives in the forum of package rebuilds due to --changed-use || --newuse but what exactly is the problem its intended to solve? Is the USE namespace cluttered, and if so how does adding a sub-set improve this?

With the addition of PYTHON_TARGETS we saw no end of rebuilds (for users here) because one or other target had changed, and because they were using --newuse rather than --changed-use ... the former is practically unusable because useflags change constantly as python versions are bumped, or made obsolete, and/or packages incur a use change. While its not likely that this will be the case with CPU_FLAGS_X86 I question the wisdom of causing further rebuilds for no apparent reason ... other than having a new subset of useflags what has been achieved?

best ... khay

khayyam · Posted: Sat Jan 31, 2015 12:40 am Post subject:

iamben · Apprentice Joined: 10 May 2004 Posts: 278

limn · l33t Joined: 13 May 2005 Posts: 997

Thank you for the link iamben.

The change then is to have a separate use variable that will have all the optimization flags for a given CPU that are or are ever likely to be included in an ebuild.

In this context running the script is preferred, rather than simply copying the currently existing USE flags.

khayyam · Posted: Sat Jan 31, 2015 3:05 am Post subject:

The_Great_Sephiroth · Posted: Sat Jan 31, 2015 3:50 am Post subject:

I just saw this on my laptop (and an Acer I am building) and set them. I did not realize I had sse3 (I had set ssse3 because I saw it) until running the script. I did the same as the other fellow. I appended CPU_FLAGS_X86 to USE and removed my CPU stuff from USE. This way once the shift is done, I simply stop appending the one variable to the other. I did have to rebuild ffmpeg to gain sse3 support. I do not mind this change and actually like it due to havign my CPU-specific stuff in one var and my system-wide flags in USE for my programs to build with.
_________________
Ever picture systemd as what runs "The Borg"?

iamben · Apprentice Joined: 10 May 2004 Posts: 278

mv · Watchman Joined: 20 Apr 2005 Posts: 6780

krinn · Watchman Joined: 02 May 2003 Posts: 7470

Before:
To disable sse in a package: <CFLAGS="-nosse" USE="-sse" emerge package>

Now: <CFLAGS="-nosse" CPU_FLAGS_X86="" emerge package>
I don't see any benefits there, just that i should remember to watch out CPU_FLAGS_X86 now instead of USE

It would had been an improvement if CPU_FLAGS_X86 was autobuild by parsing current CFLAGS: to disable sse, a simple <CFLAGS="-nosse" emerge package">

It looks like what i'm calling a "wanking feature", because renaming a feature to endup doing the same as before is not some shiny new feature, just some mental masturbation.

limn · l33t Joined: 13 May 2005 Posts: 997

I would have expected the news item to have the reason for the change.
Reading the item alone, it seemed just shuffling deck chairs.

khayyam · Posted: Sat Jan 31, 2015 1:54 pm Post subject:

iamben · Apprentice Joined: 10 May 2004 Posts: 278

You seem to be convinced that gentoo devs are out to ruin your life. I think they're doing a great job and I'm willing to give them the benefit of the doubt on changes like this.

The trick with package rebuilds is to let your CPU do most of the work... you don't have to interpret every package rebuild like a slap in the face from the maintainer. On my desktop install with 1400 packages, around 15 (fifteen!) needed a rebuild for some CPU flag change... not a big deal.

229566 · Tux's lil' helper Joined: 16 Aug 2010 Posts: 127

iamben · Apprentice Joined: 10 May 2004 Posts: 278

CFLAGS to USE flag mapping isn't nearly as straightforward as cpuinfo to USE flag mapping