Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture

[Josh Triplett]

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

[Geert Stappers]

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

[Paul Wise]

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

[Simon McVittie]

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

[Adam Borowski]

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

[Christian Seiler]

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

[Geert Stappers]

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

[Geert Stappers]

> * 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