Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-10 Thread Adrian Bunk
On Wed, Aug 09, 2017 at 11:56:32PM +0200, Adam Borowski wrote: >... > Thus, it'd be nice to have a way to automatically detect such cases, but I > don't know of a anything better than testing manually. Which is extra unfun > as any pre-sse2 (or pre-sse3) machine is crummy to the extreme, making >

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-09 Thread Adam Borowski
On Wed, Aug 09, 2017 at 05:31:08PM -0400, A. Maitland Bottoms wrote: > Let me just mention in this thread the volk package. Vector Optimized > Library of Kernels implements a high level set of DSP operations, with > fast implementations chosen at runtime depending on available CPU SIMD > instructi

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-09 Thread A. Maitland Bottoms
Let me just mention in this thread the volk package. Vector Optimized Library of Kernels implements a high level set of DSP operations, with fast implementations chosen at runtime depending on available CPU SIMD instructions. There is always a generic fallback implementation that runs on any CPU

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-08 Thread Bastien ROUCARIES
On Tue, Aug 8, 2017 at 4:47 AM, Adam Borowski wrote: > On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote: >> It's easy to quite reliably detect the presence of such instructions >> (probably no one JITs such code). There's no real way to check if it's >> executed unconditionally, thou

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-08 Thread Adrian Bunk
On Tue, Aug 08, 2017 at 04:47:26AM +0200, Adam Borowski wrote: > On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote: > > It's easy to quite reliably detect the presence of such instructions > > (probably no one JITs such code). There's no real way to check if it's > > executed unconditi

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-07 Thread Adam Borowski
On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote: > It's easy to quite reliably detect the presence of such instructions > (probably no one JITs such code). There's no real way to check if it's > executed unconditionally, though -- a lot of software has optimized code > paths that are

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-07 Thread Philipp Kern
On 08/07/2017 12:15 PM, Adrian Bunk wrote: > Packages that genuinely cannot work on the architecture baseline are > very rare, these are a tiny part of the packages that are not binary-any. In general I agree with you that we should not allow too much fragmentation. I suppose at the point where we

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-07 Thread Adrian Bunk
On Sat, Aug 05, 2017 at 07:53:02PM +0200, Adam Borowski wrote: >... > Dropping baseline support is giving up, but let's at least surrender nicely. > > Thus, here's a proposed solution: in unstable, there's now a bunch of > packages that do such checking in preinst, and thus refuse (overridably) to

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-06 Thread Ian Campbell
On Sun, 2017-08-06 at 17:27 +0200, Adam Borowski wrote: > On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote: > > What is the expected interaction with the hwcaps based library > > installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}). > > Presumably > > libraries would still be exp

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-06 Thread Adam Borowski
On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote: > What is the expected interaction with the hwcaps based library > installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}). Presumably > libraries would still be expected to use those as appropriate? hwcaps implies runtime detection

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-06 Thread Ian Campbell
On Sun, 2017-08-06 at 01:13 +0200, Adam Borowski wrote: > > As for a foreign machine: > * ISA_IGNORE=y apt install »package« How about: ASSUME_ISAS=sse2 apt install »package« i.e. with the ability to specify the set you expect/know that the target machine will have. It could support "all" as

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-05 Thread Adam Borowski
On Sat, Aug 05, 2017 at 11:50:42PM +0200, Guus Sliepen wrote: > On Sat, Aug 05, 2017 at 07:53:02PM +0200, Adam Borowski wrote: > > > Thus, here's a proposed solution: in unstable, there's now a bunch of > > packages that do such checking in preinst, and thus refuse (overridably) to > > even instal

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-05 Thread Guus Sliepen
On Sat, Aug 05, 2017 at 07:53:02PM +0200, Adam Borowski wrote: > Thus, here's a proposed solution: in unstable, there's now a bunch of > packages that do such checking in preinst, and thus refuse (overridably) to > even install such software. [...] A big issue here is that install-time is differe

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-05 Thread Christian Seiler
On 08/05/2017 10:04 PM, Philipp Kern wrote: > On 08/05/2017 07:53 PM, Adam Borowski wrote: >> Thus, here's a proposed solution: in unstable, there's now a bunch of >> packages that do such checking in preinst, and thus refuse (overridably) to >> even install such software. >> >> Currently this incl

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-05 Thread Adam Borowski
On Sat, Aug 05, 2017 at 10:04:28PM +0200, Philipp Kern wrote: > On 08/05/2017 07:53 PM, Adam Borowski wrote: > > Thus, here's a proposed solution: in unstable, there's now a bunch of > > packages that do such checking in preinst, and thus refuse (overridably) to > > even install such software. > >

Re: sse{2,3,4.2}, altivec, neon, ...

2017-08-05 Thread Philipp Kern
On 08/05/2017 07:53 PM, Adam Borowski wrote: > Thus, here's a proposed solution: in unstable, there's now a bunch of > packages that do such checking in preinst, and thus refuse (overridably) to > even install such software. > > Currently this includes: > * sse2: i386 (inc. hurd-i386, kfreebsd-i38