Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
Wookey wrote: > +++ Christian Seiler [2016-05-07 16:14 +0200]: > > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > > I now have a better idea _why_ a sse-suport package. > > I do think that this sort of ISA-level checking would be best done via > dpkg and package metadata, although this sse-support mechanism will > obviously work. i.e the cpontrol file says what ISA features are > wanted and dpkg can not install it if those HWCAPS are not available > (or indeed install alternate versions that will work if they are > available). > > We worked up a prototype spec for this a couple of years ago (at the > bootstrap sprint), but it needs the namespace and granularity fleshing > out: what is the set of HWCAPS listed in each package, what is > presumed to be 'base' that we don't list individually, and so on. I'd love to see this integrated with dpkg multiarch support. That way, for instance, specific packages could provide optimized versions for specific target CPU features. I think we'd need three things to make that happen: 1) Support in dpkg multiarch to understand "compatible" architectures that can satisfy each others' dependencies (e.g. a dependency on libfoo1:amd64 is satisfied by libfoo1:amd64+avx2, and vice versa). 2) Support for synthesizing such architectures in a canonical way from a set of CPU features, so that every combination of CPU features doesn't need its own unique architecture name (we don't want architecture names like "amd64+sse4+avx2+rdrand", even though a package might need that set of features). 3) Support for detecting available CPU features, as you mentioned above, to not even attempt to install a package that requires unavailable CPU features. Optionally, we could also detect if the set of CPU features has changed incompatibly. For instance, if you move your Debian filesystem to a system without some features that you have installed packages depending on, it'd be nice to handle that as gracefully as possible. - Josh Triplett
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
To: bug report 823672 So the BTS has the message below - Forwarded message from Wookey - Date: Tue, 10 May 2016 04:15:23 +0100 From: Wookey To: debian-de...@lists.debian.org Subject: Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture User-Agent: Mutt/1.5.23 (2014-03-12) +++ Christian Seiler [2016-05-07 16:14 +0200]: > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > I now have a better idea _why_ a sse-suport package. I do think that this sort of ISA-level checking would be best done via dpkg and package metadata, although this sse-support mechanism will obviously work. i.e the cpontrol file says what ISA features are wanted and dpkg can not install it if those HWCAPS are not available (or indeed install alternate versions that will work if they are available). We worked up a prototype spec for this a couple of years ago (at the bootstrap sprint), but it needs the namespace and granularity fleshing out: what is the set of HWCAPS listed in each package, what is presumed to be 'base' that we don't list individually, and so on. Hopefully one day someone will care enough about this to implement it :-) It's handy for a range of purposes, like i386/486/586/686 moves, SSE/altivec/NEON usage, and particularly MIPS which has a lot of variation in available ISA. It would have let us deal neatly with the Raspi ARM v6 vs v7 baseline issue too. > @Adam: One suggestion though: since this might also come in handy > in other places, I'd recommend you name the source package something > more generic (such as cpu-support or so, assuming that's not taken > already, I didn't check) Seems to me that isa-support or isa-check or hwcaps-support are better names (it's about the ISA user or the hwcaps available, not the cpu in general). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ - End forwarded message - -- Groeten Geert Stappers -- Leven en laten leven
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sun, May 8, 2016 at 1:51 AM, Simon McVittie wrote: > Altivec detection on 32-bit powerpc would also be useful Probably also NEON on ARM? -- bye, pabs https://wiki.debian.org/PaulWise
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, 07 May 2016 at 17:15:51 +0200, Adam Borowski wrote: > Good idea! The test harness is already templated, so there's no reason to > make this x86 specific. Altivec detection on 32-bit powerpc would also be useful, assuming 32-bit powerpc has a future in Debian at all. ioquake3:powerpc would depend on it. (If anyone reading this has a non-Altivec PowerPC capable of running a 1999 game engine and thinks ioquake3 needs to support it, there's a request for testing on #701561.) S
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 04:14:05PM +0200, Christian Seiler wrote: > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: > >> My gut feeling says that the package 'sse-support' is sabotage on > >> architecture "any". Obviously, it's arch specific. > > This is from #823465 http://bugs.debian.org/823465 Sadly, nope. We'd need to somehow add a (possibly indirect) dependency on 686-support to every single gcc-compiled package on i386. > > I now have a better idea _why_ a sse-suport package. > > > > My concern is how should look a Debian control file at source level ( arch > > all ). > > At arch Intel makes a 'Depends: sse-support' sense > > Having at arch ARM 'Depens: sse-support' also, will prevent install, but > > not `build`. > > I really don't get what you are saying here. Of course one would NOT > have an arch: any package in Debian that depends on sse-support on > non-i386, you'd put in Depends: sse-support [i386] in debian/control > and the package build would then add the dependency on i386, but not > and anything on other platforms. (If the package in question even > supports other platforms than x86 in the first place.) I'd guess a package that has generic code paths is unlikely to have such a strict dependency (although sse2 is so old that a number-crunching package probably won't bother with runtime detection). > Why so critical? The current situation is that if there's a package > in the archive that now only works with SSE extensions, and is not > easily portable to non-SSE (for example, if it contains hand-written > assembly code), then the only recourse that's available _now_ is to > drop i386 from that package's architecture (because it will segfault > without a good error message) - or to add detection in preinst... Detection in preinst is exactly what sse-detect is for, yeah. > @Adam: One suggestion though: since this might also come in handy > in other places, I'd recommend you name the source package something > more generic (such as cpu-support or so, assuming that's not taken > already, I didn't check), and have it generate a binary package with > the name sse-support. I'm pretty sure that other cases could come up > with a similar requirement in the future, and that way they'd easily > find a home. Good idea! The test harness is already templated, so there's no reason to make this x86 specific. I think I'll put the master list as an 822-formatted file like: .-- Name: sse2 Architecture: any-i386 Instruction: addpd %xmm0, %xmm1 Name: sse3 Architecture: any-i386 any-amd64 x32 Instruction: haddpd %xmm0, %xmm1 Name: fp11 Architecture: pdp11 Instruction: ldbt ` which on pdp11 will generate fp11-support which will do the right thing (assuming I read the docs correctly, I don't know PDP-11 assembly :þ). Meow! -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On 05/07/2016 03:59 PM, Geert Stappers wrote: > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: >> >> My gut feeling says that the package 'sse-support' is sabotage on >> architecture "any". >> > > This is from #823465 http://bugs.debian.org/823465 > > | I'm afraid there's not enough people who care about 586 enough to maintain > | it. And the bad decision of i386 to stick to a single arch during its whole > | life makes it hard to do so on debian-ports. Compare with ARM: there's arm > | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to > | make use of new CPU features, which also makes it easy to keep old compat > | without forcing new processors to stay with the lowest common denominator. > > > I now have a better idea _why_ a sse-suport package. > > My concern is how should look a Debian control file at source level ( arch > all ). > At arch Intel makes a 'Depends: sse-support' sense > Having at arch ARM 'Depens: sse-support' also, will prevent install, but not > `build`. I really don't get what you are saying here. Of course one would NOT have an arch: any package in Debian that depends on sse-support on non-i386, you'd put in Depends: sse-support [i386] in debian/control and the package build would then add the dependency on i386, but not and anything on other platforms. (If the package in question even supports other platforms than x86 in the first place.) Why so critical? The current situation is that if there's a package in the archive that now only works with SSE extensions, and is not easily portable to non-SSE (for example, if it contains hand-written assembly code), then the only recourse that's available _now_ is to drop i386 from that package's architecture (because it will segfault without a good error message) - or to add detection in preinst... (Because porting is not always an option, especially if it's lots of code.) This does not, however, excuse packages to force SSE support if a package CAN support other hardware, and it wasn't meant to. It is meant to cover the cases where a package is either not available on i386 at all or available to at least some users. I fail to see why you would think this is a bad thing? @Adam: One suggestion though: since this might also come in handy in other places, I'd recommend you name the source package something more generic (such as cpu-support or so, assuming that's not taken already, I didn't check), and have it generate a binary package with the name sse-support. I'm pretty sure that other cases could come up with a similar requirement in the future, and that way they'd easily find a home. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: > > My gut feeling says that the package 'sse-support' is sabotage on > architecture "any". > This is from #823465 http://bugs.debian.org/823465 | I'm afraid there's not enough people who care about 586 enough to maintain | it. And the bad decision of i386 to stick to a single arch during its whole | life makes it hard to do so on debian-ports. Compare with ARM: there's arm | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to | make use of new CPU features, which also makes it easy to keep old compat | without forcing new processors to stay with the lowest common denominator. I now have a better idea _why_ a sse-suport package. My concern is how should look a Debian control file at source level ( arch all ). At arch Intel makes a 'Depends: sse-support' sense Having at arch ARM 'Depens: sse-support' also, will prevent install, but not `build`. Gee, what a can of worms is thirty years so called binary compatible. Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
> * Package name: sse-support > Upstream Author : me > Binaries: sse2-support, sse3-support, more? > Description : prevent installation on processors without required > support > This is a mostly dummy package, whose only purpose is to detect the presence > of ${binary%%-support}. It refuses to install on inadequate processors, thus > allowing specifying such a requirement as a dependency. > This e-mail is written with the awareness of PowerPC, ARM, MIPS and ARM64 architectures. My gut feeling says that the package 'sse-support' is sabotage on architecture "any". After reading https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions I'm even more sure that "sse-support" is about 'there is only one true processor architecture' I think that is wrong. Groeten Geert Stappers -- Leven en laten leven