FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-11-2010, 05:29 PM
Michał Górny
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, 11 Dec 2010 19:19:05 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> How many packages are affected by those?
> I like the idea, but I think changing it around for 2 packages might
> be a bit silly. If there's a reasonable amount of packages involved
> I'm all for it.

How many packages use VIDEO_CARDS? How many packages use LIRC_DEVICES?
I think the number doesn't matter that much here.

--
Best regards,
Michał Górny
 
Old 12-11-2010, 06:01 PM
Matt Turner
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, Dec 11, 2010 at 5:57 PM, Jeroen Roovers <jer@gentoo.org> wrote:
[snip]

I agree that this could be better. To me, most of the problems with
this are due to users not knowing which of these should be set for
their particular CPU.

Instead of having defaults set by a profile, I'd like to figure out a
way we can have these flags set by default dependent on the user's
CPU. This might require some additional logic in portage; I don't
know.

Matt
 
Old 12-11-2010, 06:03 PM
Dirkjan Ochtman
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, Dec 11, 2010 at 20:01, Matt Turner <mattst88@gentoo.org> wrote:
> I agree that this could be better. To me, most of the problems with
> this are due to users not knowing which of these should be set for
> their particular CPU.
>
> Instead of having defaults set by a profile, I'd like to figure out a
> way we can have these flags set by default dependent on the user's
> CPU. This might require some additional logic in portage; I don't
> know.

Yeah, I think setting the best possible default is important here.

Cheers,

Dirkjan
 
Old 12-11-2010, 06:06 PM
Ciaran McCreesh
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, 11 Dec 2010 18:57:58 +0100
Jeroen Roovers <jer@gentoo.org> wrote:
> bugs like [1] makes clear to me that the increasing number of CPU
> extensions USE flags is getting more and more confusing.

Another big confusion is that x86 and amd64 use the same names for many
extensions, but often the archs require different handling. Why not have
X86_CPU_EXTS, AMD64_CPU_EXTS etc?

--
Ciaran McCreesh
 
Old 12-12-2010, 03:03 AM
Mike Frysinger
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Saturday, December 11, 2010 12:57:58 Jeroen Roovers wrote:
> but more like this:
>
> [ebuild N ] media-video/ffmpeg-0.6_p25767 USE="bzip2 encode
> hardcoded-tables zlib -X -alsa (-altivec) -amr -bindist -cpudetection
> -custom-cflags -debug -dirac -doc -faac -frei0r -gsm -ieee1394 -jack
> -jpeg2k -mp3 -network -oss -pic -qt-faststart -rtmp -schroedinger -sdl
> -speex -static-libs -test -theora -threads -v4l -v4l2 -vaapi -vdpau
> -vorbis -vpx -x264 -xvid" VIDEO_CARDS="-nvidia" CPU_EXTS="3dnow
> 3dnowext mmx mmxext ssse3" 0 kB

nice idea. now put together some patches :P.
-mike
 
Old 12-12-2010, 04:22 AM
Duncan
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

Dirkjan Ochtman posted on Sat, 11 Dec 2010 20:03:39 +0100 as excerpted:

> On Sat, Dec 11, 2010 at 20:01, Matt Turner <mattst88@gentoo.org> wrote:
>> I agree that this could be better. To me, most of the problems with
>> this are due to users not knowing which of these should be set for
>> their particular CPU.
>>
>> Instead of having defaults set by a profile, I'd like to figure out a
>> way we can have these flags set by default dependent on the user's CPU.
>> This might require some additional logic in portage; I don't know.
>
> Yeah, I think setting the best possible default is important here.

FWIW, I don't think that's a good idea -- at least if you're suggesting
real-time build-machine detection (see below for the alternative). Not
only will implementing it be a lot of work, but then you'll have people
filing bugs because they intended to compile for several different
machines and set generic CFLAGS accordingly, but still ended up with
broken packages because the default CPU extensions logic looked at the
build machine only, and they thought they were done when they set the
profile, CFLAGS and CHOST to the level of generic they intended.

Unless the logic is based on the -march set in C(XX)FLAGS. That could
work, as people should already be setting that as specific or generic as
they want.

I do like the USE_EXPAND idea, tho.

Meanwhile, would it be possible to have altivec in the same USE_EXPAND?
It's the same CPU extensions type of thing on PPC, if I'm not mistaken.
Does profile-mask work for USE_EXPAND? Because it just seems strange to
me to see all those CPU extensions in their own USE_EXPAND and see altivec
still in USE.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 12-12-2010, 05:34 AM
Ryan Hill
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, 11 Dec 2010 18:57:58 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> Among all CPU extensions USE flags you'll find:
>
> 3dnow
> 3dnowext
> mmx
> mmxext
> sse
> sse2
> sse3
> sse4
> sse4a
> sse5
> ssse3
>
> I probably missed a few, there.

sse4.1, sse4.2, avx

sse5 was a draft, it was never implemented.

--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 12-12-2010, 05:46 AM
Ryan Hill
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, 11 Dec 2010 19:01:16 +0000
Matt Turner <mattst88@gentoo.org> wrote:

> On Sat, Dec 11, 2010 at 5:57 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> [snip]
>
> I agree that this could be better. To me, most of the problems with
> this are due to users not knowing which of these should be set for
> their particular CPU.
>
> Instead of having defaults set by a profile, I'd like to figure out a
> way we can have these flags set by default dependent on the user's
> CPU. This might require some additional logic in portage; I don't
> know.

I think the fewer sources of magic USE flags the better. Maybe we could
document how to figure out what instruction sets a processor supports in the
handbook instead.


--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 12-12-2010, 03:54 PM
Matt Turner
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sun, Dec 12, 2010 at 6:34 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Sat, 11 Dec 2010 18:57:58 +0100
> sse5 was a draft, it was never implemented.

I don't think it's quite as simple as that. According to Wikipedia,
AMD has significantly scaled back SSE5 so that it won't interfere with
AVX, but it will be implemented in Bulldozer and will consist of the
new XOP, FMA4, and CVT16 instruction sets.

Strangely enough, media-libs/spandsp already has an SSE5 USE flag.

Matt
 
Old 12-12-2010, 05:09 PM
ross smith
 
Default Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable

On Sat, Dec 11, 2010 at 14:03, Dirkjan Ochtman <djc@gentoo.org> wrote:


On Sat, Dec 11, 2010 at 20:01, Matt Turner <mattst88@gentoo.org> wrote:

> I agree that this could be better. To me, most of the problems with

> this are due to users not knowing which of these should be set for

> their particular CPU.

>

> Instead of having defaults set by a profile, I'd like to figure out a

> way we can have these flags set by default dependent on the user's

> CPU. This might require some additional logic in portage; I don't

> know.



Yeah, I think setting the best possible default is important here.
*+1 to good defaults.
Perhaps *something along the lines of: If CPU_FLAGS is empty or not defined, set flags based on the -march and -mtune variables. *If CPU_FLAGS is set, respect what has been set there and ignore the other logic for defaults.


This would allow the average user, and the users building for multiple machines to continue like nothing changed, and users that want to selectively want to enable processor flags can in an easy way.


Best,
Ross


Cheers,



Dirkjan


*
 

Thread Tools




All times are GMT. The time now is 10:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org