[gentoo-dev] Re: Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, 11 Dec 2010 19:01:16 + Matt Turner wrote: > On Sat, Dec 11, 2010 at 5:57 PM, Jeroen Roovers 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.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, 11 Dec 2010 18:57:58 +0100 Jeroen Roovers 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.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: 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 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
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, 11 Dec 2010 18:57:58 +0100 Jeroen Roovers 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, Dec 11, 2010 at 20:01, Matt Turner 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
Re: [gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, Dec 11, 2010 at 5:57 PM, Jeroen Roovers 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
Re: [gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, 11 Dec 2010 19:19:05 +0100 Patrick Lauer 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On 12/11/10 18:57, Jeroen Roovers wrote: > Hi all, > > > bugs like [1] makes clear to me that the increasing number of CPU > extensions USE flags is getting more and more confusing. > [snip] > > 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. > 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. Patrick
[gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
Hi all, bugs like [1] makes clear to me that the increasing number of CPU extensions USE flags is getting more and more confusing. ffmpeg-0.6_p25767.ebuild : IUSE="+3dnow +3dnowext alsa altivec amr bindist +bzip2 cpudetection custom-cflags debug dirac doc +encode faac frei0r gsm +hardcoded-tables ieee1394 jack jpeg2k +mmx +mmxext mp3 network oss pic qt-faststart rtmp schroedinger sdl speex +ssse3 static-libs test theora threads v4l v4l2 vaapi vdpau vorbis vpx X x264 xvid +zlib video_cards_nvidia" (I am not going to argue here that USE defaults shouldn't be used for CPU extensions.) 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. I think it would look a lot less confusing if, using the example above, the output of emerge would not look like this: [ebuild N] media-video/ffmpeg-0.6_p25767 USE="3dnow 3dnowext bzip2 encode hardcoded-tables mmx mmxext ssse3 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" 0 kB 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 jer [1] https://bugs.gentoo.org/show_bug.cgi?id=340539 "media-video/ffmpeg-0.6_p25423 - libswscale/swscale.c:1269: error: implicit declaration of function 'sws_init_swScale_*'"
Re: [gentoo-dev] install media and USB debugging
On 2010.12.11 09:26, Andrea Conti wrote: > Hi, > > (First of all: I'm not sure this list is the right place to ask. If > it > > is not, feel free to point me in the right direction) > > Is there a specific reason why the kernel on the install media is > built > with CONFIG_USB_STORAGE_DEBUG=y ? This has the nasty side-effect of > completely overwriting the kernel log buffer with junk when booting > from > a USB cdrom drive. [snip] > > Andrea > Andrea, Please file a bug at bugs.gentoo.org That will get into the right developers work queue -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgp79A9y5OpPV.pgp Description: PGP signature
[gentoo-dev] install media and USB debugging
Hi, (First of all: I'm not sure this list is the right place to ask. If it is not, feel free to point me in the right direction) Is there a specific reason why the kernel on the install media is built with CONFIG_USB_STORAGE_DEBUG=y ? This has the nasty side-effect of completely overwriting the kernel log buffer with junk when booting from a USB cdrom drive. I don't think debugging usb-storage is something you would usually carry out with install media. On the other hand, this pretty much requires attaching an ATA cdrom drive to the machine if you need to take a look at any part of the boot log while installing (try that with a netbook, or a rack-mounted server!) Andrea
