[gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[David Seifert]

Dear friends,
while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
list could be expanded a bit:

avx512 - introduced with Skylake and Knights Landing

I also propose creating a CPU_FLAGS_PPC variable containing (at least):

altivec - PowerPC's SSE
vsx - PowerPC's AVX

Finally, I also propose creating CPU_FLAGS_ARM variable containing:

neon

Any ideas? Currently cpu-feature flags for non-x86 are package local,
whereas making them globally available makes masking easier for non-
applicable archs etc. and makes enabling them easier for users.

David

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Mike Gilbert]

On Mon, Aug 1, 2016 at 5:08 PM, David Seifert <soap@gentoo.org> wrote:
> Dear friends,
> while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> list could be expanded a bit:
>
> avx512 - introduced with Skylake and Knights Landing

According to Wikipedia, "AVX-512 consists of multiple extensions not
all meant to be supported by all processors implementing them."

https://en.wikipedia.org/wiki/AVX-512

https://en.wikipedia.org/wiki/CPUID#EAX.3D7.2C_ECX.3D0:_Extended_Features

> I also propose creating a CPU_FLAGS_PPC variable containing (at least):
>
> altivec - PowerPC's SSE

I see this one exists in use.desc.

> vsx - PowerPC's AVX

I don't see any ebuids using this.

> Finally, I also propose creating CPU_FLAGS_ARM variable containing:
>
> neon
>
> Any ideas? Currently cpu-feature flags for non-x86 are package local,
> whereas making them globally available makes masking easier for non-
> applicable archs etc. and makes enabling them easier for users.

It seems strange to create a USE_EXPAND variable with exactly one value.

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Matt Turner]

On Mon, Aug 1, 2016 at 2:08 PM, David Seifert <soap@gentoo.org> wrote:
> Dear friends,
> while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> list could be expanded a bit:
>
> avx512 - introduced with Skylake and Knights Landing
>
> I also propose creating a CPU_FLAGS_PPC variable containing (at least):
>
> altivec - PowerPC's SSE
> vsx - PowerPC's AVX
>
> Finally, I also propose creating CPU_FLAGS_ARM variable containing:
>
> neon

There is also "iwmmxt" (used by x11-libs/pixman) and ffmpeg has
armv5te, armv6, armv6t2, and armvfp.

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Guilherme Amadio]

On Mon, Aug 01, 2016 at 11:08:47PM +0200, David Seifert wrote:
> Dear friends,
> while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> list could be expanded a bit:

I like the idea of expanding the list of CPU_FLAGS_X86, and having flags
for other arches too, but I would be in favor of dropping the _X86
suffix and using CPU_FLAGS for all arches. Your machine most likely will
only have one kind anyway. Not sure what others think about it, though.

> avx512 - introduced with Skylake and Knights Landing

Only Skylake Xeons (yet to be launched) will support AVX512, and
as mentioned in another email, the subsets supported by Skylake and
KNL are a bit different. So, adding each subset should be better
(e.g. avx512f, avx512cd, avx512er, etc).

> I also propose creating a CPU_FLAGS_PPC variable containing (at least):
> 
> altivec - PowerPC's SSE
> vsx - PowerPC's AVX
> 
> Finally, I also propose creating CPU_FLAGS_ARM variable containing:
> 
> neon
> 
> Any ideas? Currently cpu-feature flags for non-x86 are package local,
> whereas making them globally available makes masking easier for non-
> applicable archs etc. and makes enabling them easier for users.

Masking flags is not needed if they are determined from /proc/cpuinfo.

Cheers,
—Guilherme

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Mon, 1 Aug 2016 17:15:41 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Mon, Aug 1, 2016 at 5:08 PM, David Seifert <soap@gentoo.org> wrote:
> > Dear friends,
> > while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> > list could be expanded a bit:
> >
> > avx512 - introduced with Skylake and Knights Landing
> 
> According to Wikipedia, "AVX-512 consists of multiple extensions not
> all meant to be supported by all processors implementing them."
> 
> https://en.wikipedia.org/wiki/AVX-512
> 
> https://en.wikipedia.org/wiki/CPUID#EAX.3D7.2C_ECX.3D0:_Extended_Features

Also https://bugs.gentoo.org/show_bug.cgi?id=588628.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Tue, 2 Aug 2016 10:04:46 -0300
Guilherme Amadio <amadio@gentoo.org> wrote:

> On Mon, Aug 01, 2016 at 11:08:47PM +0200, David Seifert wrote:
> > Dear friends,
> > while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> > list could be expanded a bit:
> 
> I like the idea of expanding the list of CPU_FLAGS_X86, and having flags
> for other arches too, but I would be in favor of dropping the _X86
> suffix and using CPU_FLAGS for all arches. Your machine most likely will
> only have one kind anyway. Not sure what others think about it, though.

One kind is the reason why they are split -- so we can hide
CPU_FLAGS_X86 on non-x86 CPUs etc.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Vadim A. Misbakh-Soloviov]

By the way, I know that this is not a bugzilla's mirror, but it seems you did 
something wrong wile bumping. For now it refuses to build on Broadwell telling
> fftw-3.3.5/simd-support/simd-avx2.h:43:2: error: #error "compiling simd-
avx2.h without avx2 support"

Although avx2 do exist in cpuinfo (and in cpuflags_x86 too, although there is 
no such flag for fftw itself).

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Mart Raudsepp]

Ühel kenal päeval, T, 02.08.2016 kell 15:25, kirjutas Michał Górny:
> On Mon, 1 Aug 2016 17:15:41 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
> 
> > On Mon, Aug 1, 2016 at 5:08 PM, David Seifert <soap@gentoo.org>
> > wrote:
> > > Dear friends,
> > > while version bumping sci-libs/fftw, I've noticed our
> > > CPU_FLAGS_X86
> > > list could be expanded a bit:
> > > 
> > > avx512 - introduced with Skylake and Knights Landing
> > 
> > According to Wikipedia, "AVX-512 consists of multiple extensions
> > not
> > all meant to be supported by all processors implementing them."
> > 
> > https://en.wikipedia.org/wiki/AVX-512
> > 
> > https://en.wikipedia.org/wiki/CPUID#EAX.3D7.2C_ECX.3D0:_Extended_Fe
> > atures
> 
> Also https://bugs.gentoo.org/show_bug.cgi?id=588628.

Do we actually want to be fast in adding these things, or do we want to
wait for any actual consumers to be possible to start consuming it
right away? Like with all these different variants, will consumers
actually group the variants in the same way and will we be able to map
things cleanly in ebuilds in the future?
Though I guess there are already potential consumers out there that
people have already looked at and I've just not kept up with IRC or
something :)

Also, how are they exposed in cpuinfo, do we have first patches
for cpuid2cpuflags? Since what kernel version are they exposed in
cpuinfo, is it a flag for each CPUID capability? What variants do each
CPU implementing any expose, maybe all CPUs doing e.g avx512f all also
do avx512dq - perhaps all consumers would make such assumptions and
assume things based on real world CPUs? Or maybe all consumers of some
of the variants will always do runtime detection themselves and we
won't even use that flag in an IUSE ever?

tl;dr: Concerned about prematurely adding things without knowing of
consumer examples


Mart

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Mike Gilbert]

On Tue, Aug 2, 2016 at 8:08 PM, Mart Raudsepp <leio@gentoo.org> wrote:
> Also, how are they exposed in cpuinfo, do we have first patches
> for cpuid2cpuflags?

cpuid2cpuflags does not use /proc/cpuinfo since version 2.

A patch adding detection for the various avx512 extensions has been
merged upstream.

https://github.com/mgorny/cpuid2cpuflags/commit/8b020e51773c912cca3d6983bd883a6ff08ad637

> tl;dr: Concerned about prematurely adding things without knowing of consumer examples

I agree that there is no point in adding the values to
cpu_flags_x86.desc until there are some ebuild ready to utilize them.