* Why disable NEON support in recipes if runtime detection works? @ 2020-07-19 9:06 Tanu Kaskinen 2020-07-19 9:30 ` [OE-core] " Adrian Bunk 2020-07-20 22:26 ` Khem Raj 0 siblings, 2 replies; 11+ messages in thread From: Tanu Kaskinen @ 2020-07-19 9:06 UTC (permalink / raw) To: openembedded-core Hi! If a recipe provides NEON optimizations, should those be explicitly disabled when "neon" is not in TUNE_FEATUERS, even if the software is able to detect NEON availability at runtime? I'm currently converting the pulseaudio recipe from Autotools to Meson, and the old Autotools build system supports disabling NEON optimizations but the Meson build system doesn't. So I'm wondering if I should add the missing feature to the Meson build system, or just let the runtime detection do its work. Is there ever need for disabling NEON optimizations if the CPU indicates NEON support? I guess it could be useful for testing the "no NEON" case (I today found out that dropping "neon" from TUNE_FEATURES doesn't remove NEON support from the qemuarm machine), but otherwise it seems unnecessary, unless there are CPUs that advertise NEON support but don't actually support it. PulseAudio doesn't have a similar configure switch for the x86 optimizations, so in the name of consistency I would like to rely only on the runtime CPU detection also for the NEON optimizations. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-19 9:06 Why disable NEON support in recipes if runtime detection works? Tanu Kaskinen @ 2020-07-19 9:30 ` Adrian Bunk 2020-07-19 9:46 ` Tanu Kaskinen 2020-07-20 22:26 ` Khem Raj 1 sibling, 1 reply; 11+ messages in thread From: Adrian Bunk @ 2020-07-19 9:30 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core On Sun, Jul 19, 2020 at 12:06:15PM +0300, Tanu Kaskinen wrote: >... > I'm currently converting the pulseaudio recipe from Autotools to Meson, > and the old Autotools build system supports disabling NEON > optimizations but the Meson build system doesn't. So I'm wondering if I > should add the missing feature to the Meson build system, or just let > the runtime detection do its work. >... Looking at the git history it seems this was added as a workaround at a time when the autodetection was buggy and caused build breakage. Debian also backported commit 0af05213 (build: make ARM NEON check in configure.ac more strict) to PulseAudio 4.0, which was included in PulseAudio 5.0. > Tanu cu Adrian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-19 9:30 ` [OE-core] " Adrian Bunk @ 2020-07-19 9:46 ` Tanu Kaskinen 0 siblings, 0 replies; 11+ messages in thread From: Tanu Kaskinen @ 2020-07-19 9:46 UTC (permalink / raw) To: Adrian Bunk; +Cc: openembedded-core On Sun, 2020-07-19 at 12:30 +0300, Adrian Bunk wrote: > On Sun, Jul 19, 2020 at 12:06:15PM +0300, Tanu Kaskinen wrote: > > ... > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > > and the old Autotools build system supports disabling NEON > > optimizations but the Meson build system doesn't. So I'm wondering if I > > should add the missing feature to the Meson build system, or just let > > the runtime detection do its work. > > ... > > Looking at the git history it seems this was added as a workaround at a > time when the autodetection was buggy and caused build breakage. > > Debian also backported commit 0af05213 (build: make ARM NEON check in > configure.ac more strict) to PulseAudio 4.0, which was included in > PulseAudio 5.0. Thanks for the archeology work! I'll go ahead and drop the TUNE_FEATURES check then. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-19 9:06 Why disable NEON support in recipes if runtime detection works? Tanu Kaskinen 2020-07-19 9:30 ` [OE-core] " Adrian Bunk @ 2020-07-20 22:26 ` Khem Raj 2020-07-26 6:27 ` Tanu Kaskinen [not found] ` <1625397D9F68474B.26462@lists.openembedded.org> 1 sibling, 2 replies; 11+ messages in thread From: Khem Raj @ 2020-07-20 22:26 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > Hi! > > If a recipe provides NEON optimizations, should those be explicitly > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > able to detect NEON availability at runtime? > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > and the old Autotools build system supports disabling NEON > optimizations but the Meson build system doesn't. So I'm wondering if I > should add the missing feature to the Meson build system, or just let > the runtime detection do its work. > > Is there ever need for disabling NEON optimizations if the CPU > indicates NEON support? I guess it could be useful for testing the "no > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > doesn't remove NEON support from the qemuarm machine), but otherwise it > seems unnecessary, unless there are CPUs that advertise NEON support > but don't actually support it. > I think the issue will result in a compiler error perhaps when neon is disabled via compiler command line which would be the case when neon is not in TUNE_FEATURES the compiler might warn or error out when it finds neon instructions being compiled via inline assembly. you just can try passing something like -mfpu=vfpv3d16 or some such and see if compiler/assembler complains during build, if not then perhaps its fine. > PulseAudio doesn't have a similar configure switch for the x86 > optimizations, so in the name of consistency I would like to rely only > on the runtime CPU detection also for the NEON optimizations. > > -- > Tanu > > https://www.patreon.com/tanuk > https://liberapay.com/tanuk > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-20 22:26 ` Khem Raj @ 2020-07-26 6:27 ` Tanu Kaskinen [not found] ` <1625397D9F68474B.26462@lists.openembedded.org> 1 sibling, 0 replies; 11+ messages in thread From: Tanu Kaskinen @ 2020-07-26 6:27 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > Hi! > > > > If a recipe provides NEON optimizations, should those be explicitly > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > > able to detect NEON availability at runtime? > > > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > > and the old Autotools build system supports disabling NEON > > optimizations but the Meson build system doesn't. So I'm wondering if I > > should add the missing feature to the Meson build system, or just let > > the runtime detection do its work. > > > > Is there ever need for disabling NEON optimizations if the CPU > > indicates NEON support? I guess it could be useful for testing the "no > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > > doesn't remove NEON support from the qemuarm machine), but otherwise it > > seems unnecessary, unless there are CPUs that advertise NEON support > > but don't actually support it. > > > > I think the issue will result in a compiler error perhaps when neon is > disabled via > compiler command line which would be the case when neon is not in TUNE_FEATURES > the compiler might warn or error out when it finds neon instructions > being compiled via inline > assembly. you just can try passing something like -mfpu=vfpv3d16 or > some such and see if > compiler/assembler complains during build, if not then perhaps its fine. If the last -mfpu is something else than neon, then including arm_neon.h will succeed but compiling neon code will fail. I did some experiments, and what I found was that when I remove neon from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very early in the compiler command line. PulseAudio adds -mfpu=neon to CFLAGS when building neon code, and the last -mfpu wins, so the neon code gets built without errors. The configure check in PulseAudio only checks that the compiler accepts -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any actual neon code. This means that if the user adds -mfpu=vfp (or other non-neon) to CFLAGS rather than CC, configure will pass but building will fail. Is this something to guard against? A default qemuarm build doesn't do this, so I don't know if this ever happens in OE. I don't know yet how Meson behaves, I'll continue testing... -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1625397D9F68474B.26462@lists.openembedded.org>]
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? [not found] ` <1625397D9F68474B.26462@lists.openembedded.org> @ 2020-07-26 7:59 ` Tanu Kaskinen 2020-07-26 14:01 ` Khem Raj 0 siblings, 1 reply; 11+ messages in thread From: Tanu Kaskinen @ 2020-07-26 7:59 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote: > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > Hi! > > > > > > If a recipe provides NEON optimizations, should those be explicitly > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > > > able to detect NEON availability at runtime? > > > > > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > > > and the old Autotools build system supports disabling NEON > > > optimizations but the Meson build system doesn't. So I'm wondering if I > > > should add the missing feature to the Meson build system, or just let > > > the runtime detection do its work. > > > > > > Is there ever need for disabling NEON optimizations if the CPU > > > indicates NEON support? I guess it could be useful for testing the "no > > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > > > doesn't remove NEON support from the qemuarm machine), but otherwise it > > > seems unnecessary, unless there are CPUs that advertise NEON support > > > but don't actually support it. > > > > > > > I think the issue will result in a compiler error perhaps when neon is > > disabled via > > compiler command line which would be the case when neon is not in TUNE_FEATURES > > the compiler might warn or error out when it finds neon instructions > > being compiled via inline > > assembly. you just can try passing something like -mfpu=vfpv3d16 or > > some such and see if > > compiler/assembler complains during build, if not then perhaps its fine. > > If the last -mfpu is something else than neon, then including > arm_neon.h will succeed but compiling neon code will fail. > > I did some experiments, and what I found was that when I remove neon > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very > early in the compiler command line. PulseAudio adds -mfpu=neon to > CFLAGS when building neon code, and the last -mfpu wins, so the neon > code gets built without errors. > > The configure check in PulseAudio only checks that the compiler accepts > -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any > actual neon code. This means that if the user adds -mfpu=vfp (or other > non-neon) to CFLAGS rather than CC, configure will pass but building > will fail. Is this something to guard against? A default qemuarm build > doesn't do this, so I don't know if this ever happens in OE. > > I don't know yet how Meson behaves, I'll continue testing... I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC. Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is enabled in any case. So, Meson seems pretty safe, although I guess it would be nice not to override the user's -mfpu setting. I think this isn't a big problem is practice, since runtime detection works. I haven't tested with a compiler that truly can't build Neon code, because I don't know how to do that. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-26 7:59 ` Tanu Kaskinen @ 2020-07-26 14:01 ` Khem Raj 2020-07-27 20:45 ` Andre McCurdy 0 siblings, 1 reply; 11+ messages in thread From: Khem Raj @ 2020-07-26 14:01 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 3689 bytes --] On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote: > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > Hi! > > > > > > > > If a recipe provides NEON optimizations, should those be explicitly > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > > > > able to detect NEON availability at runtime? > > > > > > > > I'm currently converting the pulseaudio recipe from Autotools to > Meson, > > > > and the old Autotools build system supports disabling NEON > > > > optimizations but the Meson build system doesn't. So I'm wondering > if I > > > > should add the missing feature to the Meson build system, or just let > > > > the runtime detection do its work. > > > > > > > > Is there ever need for disabling NEON optimizations if the CPU > > > > indicates NEON support? I guess it could be useful for testing the > "no > > > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > > > > doesn't remove NEON support from the qemuarm machine), but otherwise > it > > > > seems unnecessary, unless there are CPUs that advertise NEON support > > > > but don't actually support it. > > > > > > > > > > I think the issue will result in a compiler error perhaps when neon is > > > disabled via > > > compiler command line which would be the case when neon is not in > TUNE_FEATURES > > > the compiler might warn or error out when it finds neon instructions > > > being compiled via inline > > > assembly. you just can try passing something like -mfpu=vfpv3d16 or > > > some such and see if > > > compiler/assembler complains during build, if not then perhaps its > fine. > > > > If the last -mfpu is something else than neon, then including > > arm_neon.h will succeed but compiling neon code will fail. > > > > I did some experiments, and what I found was that when I remove neon > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very > > early in the compiler command line. PulseAudio adds -mfpu=neon to > > CFLAGS when building neon code, and the last -mfpu wins, so the neon > > code gets built without errors. > > > > The configure check in PulseAudio only checks that the compiler accepts > > -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any > > actual neon code. This means that if the user adds -mfpu=vfp (or other > > non-neon) to CFLAGS rather than CC, configure will pass but building > > will fail. Is this something to guard against? A default qemuarm build > > doesn't do this, so I don't know if this ever happens in OE. > > > > I don't know yet how Meson behaves, I'll continue testing... > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC. > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is > enabled in any case. > > So, Meson seems pretty safe, although I guess it would be nice not to > override the user's -mfpu setting. I think this isn't a big problem is > practice, since runtime detection works. > > I haven't tested with a compiler that truly can't build Neon code, > because I don't know how to do that. Right. Cpu implementations without neon do exist But they are perhaps rare enough and may not use the package too so chances are slim that we encounter this issue Qemuarm emulated a cpu with neon so yes it won’t show on qemuarm > > > -- > Tanu > > https://www.patreon.com/tanuk > https://liberapay.com/tanuk > > [-- Attachment #2: Type: text/html, Size: 4909 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-26 14:01 ` Khem Raj @ 2020-07-27 20:45 ` Andre McCurdy 2020-07-29 13:46 ` Tanu Kaskinen 0 siblings, 1 reply; 11+ messages in thread From: Andre McCurdy @ 2020-07-27 20:45 UTC (permalink / raw) To: Khem Raj; +Cc: Tanu Kaskinen, openembedded-core On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <raj.khem@gmail.com> wrote: > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <tanuk@iki.fi> wrote: >> On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote: >> > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: >> > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: >> > > > Hi! >> > > > >> > > > If a recipe provides NEON optimizations, should those be explicitly >> > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is >> > > > able to detect NEON availability at runtime? >> > > > >> > > > I'm currently converting the pulseaudio recipe from Autotools to Meson, >> > > > and the old Autotools build system supports disabling NEON >> > > > optimizations but the Meson build system doesn't. So I'm wondering if I >> > > > should add the missing feature to the Meson build system, or just let >> > > > the runtime detection do its work. >> > > > >> > > > Is there ever need for disabling NEON optimizations if the CPU >> > > > indicates NEON support? I guess it could be useful for testing the "no >> > > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES >> > > > doesn't remove NEON support from the qemuarm machine), but otherwise it >> > > > seems unnecessary, unless there are CPUs that advertise NEON support >> > > > but don't actually support it. >> > > > >> > > >> > > I think the issue will result in a compiler error perhaps when neon is >> > > disabled via >> > > compiler command line which would be the case when neon is not in TUNE_FEATURES >> > > the compiler might warn or error out when it finds neon instructions >> > > being compiled via inline >> > > assembly. you just can try passing something like -mfpu=vfpv3d16 or >> > > some such and see if >> > > compiler/assembler complains during build, if not then perhaps its fine. >> > >> > If the last -mfpu is something else than neon, then including >> > arm_neon.h will succeed but compiling neon code will fail. >> > >> > I did some experiments, and what I found was that when I remove neon >> > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very >> > early in the compiler command line. PulseAudio adds -mfpu=neon to >> > CFLAGS when building neon code, and the last -mfpu wins, so the neon >> > code gets built without errors. >> > >> > The configure check in PulseAudio only checks that the compiler accepts >> > -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any >> > actual neon code. This means that if the user adds -mfpu=vfp (or other >> > non-neon) to CFLAGS rather than CC, configure will pass but building >> > will fail. Is this something to guard against? A default qemuarm build >> > doesn't do this, so I don't know if this ever happens in OE. >> > >> > I don't know yet how Meson behaves, I'll continue testing... >> >> I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC. >> Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I >> tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is >> enabled in any case. >> >> So, Meson seems pretty safe, although I guess it would be nice not to >> override the user's -mfpu setting. I think this isn't a big problem is >> practice, since runtime detection works. >> >> I haven't tested with a compiler that truly can't build Neon code, >> because I don't know how to do that. Presumably set a -mcpu=XXX to something which can never support NEON? > Right. Cpu implementations without neon do exist > But they are perhaps rare enough and may not use the package too so chances are slim that we encounter this issue So what's the conclusion? That CPU's without NEON are so rare that OE doesn't need to care about them? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-27 20:45 ` Andre McCurdy @ 2020-07-29 13:46 ` Tanu Kaskinen 2020-07-29 22:08 ` Andre McCurdy 0 siblings, 1 reply; 11+ messages in thread From: Tanu Kaskinen @ 2020-07-29 13:46 UTC (permalink / raw) To: Andre McCurdy, Khem Raj; +Cc: openembedded-core On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote: > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <raj.khem@gmail.com> wrote: > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote: > > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > > > Hi! > > > > > > > > > > > > If a recipe provides NEON optimizations, should those be explicitly > > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > > > > > > able to detect NEON availability at runtime? > > > > > > > > > > > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > > > > > > and the old Autotools build system supports disabling NEON > > > > > > optimizations but the Meson build system doesn't. So I'm wondering if I > > > > > > should add the missing feature to the Meson build system, or just let > > > > > > the runtime detection do its work. > > > > > > > > > > > > Is there ever need for disabling NEON optimizations if the CPU > > > > > > indicates NEON support? I guess it could be useful for testing the "no > > > > > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > > > > > > doesn't remove NEON support from the qemuarm machine), but otherwise it > > > > > > seems unnecessary, unless there are CPUs that advertise NEON support > > > > > > but don't actually support it. > > > > > > > > > > > > > > > > I think the issue will result in a compiler error perhaps when neon is > > > > > disabled via > > > > > compiler command line which would be the case when neon is not in TUNE_FEATURES > > > > > the compiler might warn or error out when it finds neon instructions > > > > > being compiled via inline > > > > > assembly. you just can try passing something like -mfpu=vfpv3d16 or > > > > > some such and see if > > > > > compiler/assembler complains during build, if not then perhaps its fine. > > > > > > > > If the last -mfpu is something else than neon, then including > > > > arm_neon.h will succeed but compiling neon code will fail. > > > > > > > > I did some experiments, and what I found was that when I remove neon > > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very > > > > early in the compiler command line. PulseAudio adds -mfpu=neon to > > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon > > > > code gets built without errors. > > > > > > > > The configure check in PulseAudio only checks that the compiler accepts > > > > -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any > > > > actual neon code. This means that if the user adds -mfpu=vfp (or other > > > > non-neon) to CFLAGS rather than CC, configure will pass but building > > > > will fail. Is this something to guard against? A default qemuarm build > > > > doesn't do this, so I don't know if this ever happens in OE. > > > > > > > > I don't know yet how Meson behaves, I'll continue testing... > > > > > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC. > > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I > > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is > > > enabled in any case. > > > > > > So, Meson seems pretty safe, although I guess it would be nice not to > > > override the user's -mfpu setting. I think this isn't a big problem is > > > practice, since runtime detection works. > > > > > > I haven't tested with a compiler that truly can't build Neon code, > > > because I don't know how to do that. > > Presumably set a -mcpu=XXX to something which can never support NEON? No success so far... I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio recipe, but Neon got still enabled. GCC warned that -march=armv7ve conflicted with the chosen -mcpu (which makes sense, since "ve" in "armv7ve" means "virtualization extensinons", and Cortex-A9 doesn't have virtualization support, and all cores that have virtualization support have mandatory Neon support). Then I tried adding -march=armv7a to the pulseaudio CFLAGS, but then the build failed, because Meson failed some C++ linker check ("Unable to determine dynamic linker"). Then I tried to remove armv7ve and add cortexa9 to TUNE_FEATURES, but GCC didn't like that at all, nothing built any more. I'm still in the process of trying different combinations. Maybe it would be better to try to use someting older than Cortex-A9, since A9 has optional Neon support. If you're familiar with tweaking the target CPU with qemuarm, suggestions are welcome. (If I sound like I know something about Arm CPUs, that's only because I've looked up things from Wikipedia today.) > > Right. Cpu implementations without neon do exist > > But they are perhaps rare enough and may not use the package too so chances are slim that we encounter this issue > > So what's the conclusion? That CPU's without NEON are so rare that OE > doesn't need to care about them? That seems overkill. PulseAudio detects Neon support at runtime, so even if Neon is enabled at build time, the binaries should work also on hardware without Neon. I think Khem misunderstood some details. I'm currently just trying to figure out how to test that the Neon check in Meson works also in the cases where the compiler can't build Neon code - so far in my tests Meson has always enabled Neon and the compiler has always built it without errors. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-29 13:46 ` Tanu Kaskinen @ 2020-07-29 22:08 ` Andre McCurdy 2020-08-23 8:53 ` Tanu Kaskinen 0 siblings, 1 reply; 11+ messages in thread From: Andre McCurdy @ 2020-07-29 22:08 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: Khem Raj, openembedded-core On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote: > > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <raj.khem@gmail.com> wrote: > > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote: > > > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > > > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > > > > Hi! > > > > > > > > > > > > > > If a recipe provides NEON optimizations, should those be explicitly > > > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > > > > > > > able to detect NEON availability at runtime? > > > > > > > > > > > > > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > > > > > > > and the old Autotools build system supports disabling NEON > > > > > > > optimizations but the Meson build system doesn't. So I'm wondering if I > > > > > > > should add the missing feature to the Meson build system, or just let > > > > > > > the runtime detection do its work. > > > > > > > > > > > > > > Is there ever need for disabling NEON optimizations if the CPU > > > > > > > indicates NEON support? I guess it could be useful for testing the "no > > > > > > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > > > > > > > doesn't remove NEON support from the qemuarm machine), but otherwise it > > > > > > > seems unnecessary, unless there are CPUs that advertise NEON support > > > > > > > but don't actually support it. > > > > > > > > > > > > > > > > > > > I think the issue will result in a compiler error perhaps when neon is > > > > > > disabled via > > > > > > compiler command line which would be the case when neon is not in TUNE_FEATURES > > > > > > the compiler might warn or error out when it finds neon instructions > > > > > > being compiled via inline > > > > > > assembly. you just can try passing something like -mfpu=vfpv3d16 or > > > > > > some such and see if > > > > > > compiler/assembler complains during build, if not then perhaps its fine. > > > > > > > > > > If the last -mfpu is something else than neon, then including > > > > > arm_neon.h will succeed but compiling neon code will fail. > > > > > > > > > > I did some experiments, and what I found was that when I remove neon > > > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very > > > > > early in the compiler command line. PulseAudio adds -mfpu=neon to > > > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon > > > > > code gets built without errors. > > > > > > > > > > The configure check in PulseAudio only checks that the compiler accepts > > > > > -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any > > > > > actual neon code. This means that if the user adds -mfpu=vfp (or other > > > > > non-neon) to CFLAGS rather than CC, configure will pass but building > > > > > will fail. Is this something to guard against? A default qemuarm build > > > > > doesn't do this, so I don't know if this ever happens in OE. > > > > > > > > > > I don't know yet how Meson behaves, I'll continue testing... > > > > > > > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC. > > > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I > > > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is > > > > enabled in any case. > > > > > > > > So, Meson seems pretty safe, although I guess it would be nice not to > > > > override the user's -mfpu setting. I think this isn't a big problem is > > > > practice, since runtime detection works. > > > > > > > > I haven't tested with a compiler that truly can't build Neon code, > > > > because I don't know how to do that. > > > > Presumably set a -mcpu=XXX to something which can never support NEON? > > No success so far... > > I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio > recipe, but Neon got still enabled. GCC warned that -march=armv7ve > conflicted with the chosen -mcpu (which makes sense, since "ve" in > "armv7ve" means "virtualization extensinons", and Cortex-A9 doesn't > have virtualization support, and all cores that have virtualization > support have mandatory Neon support). Is that true? If so then the various armv7ve specific tuning files (tune-cortexa15.inc, etc) could all be simplified by removing the option to disable NEON support. > Then I tried adding -march=armv7a to the pulseaudio CFLAGS, but then > the build failed, because Meson failed some C++ linker check ("Unable > to determine dynamic linker"). > > Then I tried to remove armv7ve and add cortexa9 to TUNE_FEATURES, but > GCC didn't like that at all, nothing built any more. > > I'm still in the process of trying different combinations. Maybe it > would be better to try to use someting older than Cortex-A9, since A9 > has optional Neon support. If you're familiar with tweaking the target > CPU with qemuarm, suggestions are welcome. (If I sound like I know > something about Arm CPUs, that's only because I've looked up things > from Wikipedia today.) For this test I think you can just set a custom DEFAULTTUNE from within the pulseaudio recipe. > > > Right. Cpu implementations without neon do exist > > > But they are perhaps rare enough and may not use the package too so chances are slim that we encounter this issue > > > > So what's the conclusion? That CPU's without NEON are so rare that OE > > doesn't need to care about them? > > That seems overkill. PulseAudio detects Neon support at runtime, so > even if Neon is enabled at build time, the binaries should work also on > hardware without Neon. I think Khem misunderstood some details. I'm > currently just trying to figure out how to test that the Neon check in > Meson works also in the cases where the compiler can't build Neon code > - so far in my tests Meson has always enabled Neon and the compiler has > always built it without errors. With runtime detection, the Makefiles etc should be forcing hardcoded CFLAGS (or setting assembler directives etc) as required to build any CPU specific code even if the global CFLAGS etc don't support it, so I think it's expected that the NEON code will still be built even if you succeed in setting the generic CFLAGS to target a CPU which doesn't support NEON. In other words, with runtime detection, there should be no need for any build time configuration. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] Why disable NEON support in recipes if runtime detection works? 2020-07-29 22:08 ` Andre McCurdy @ 2020-08-23 8:53 ` Tanu Kaskinen 0 siblings, 0 replies; 11+ messages in thread From: Tanu Kaskinen @ 2020-08-23 8:53 UTC (permalink / raw) To: Andre McCurdy; +Cc: Khem Raj, openembedded-core On Wed, 2020-07-29 at 15:08 -0700, Andre McCurdy wrote: > On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote: > > > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <raj.khem@gmail.com> wrote: > > > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote: > > > > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote: > > > > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen <tanuk@iki.fi> wrote: > > > > > > > > Hi! > > > > > > > > > > > > > > > > If a recipe provides NEON optimizations, should those be explicitly > > > > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is > > > > > > > > able to detect NEON availability at runtime? > > > > > > > > > > > > > > > > I'm currently converting the pulseaudio recipe from Autotools to Meson, > > > > > > > > and the old Autotools build system supports disabling NEON > > > > > > > > optimizations but the Meson build system doesn't. So I'm wondering if I > > > > > > > > should add the missing feature to the Meson build system, or just let > > > > > > > > the runtime detection do its work. > > > > > > > > > > > > > > > > Is there ever need for disabling NEON optimizations if the CPU > > > > > > > > indicates NEON support? I guess it could be useful for testing the "no > > > > > > > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES > > > > > > > > doesn't remove NEON support from the qemuarm machine), but otherwise it > > > > > > > > seems unnecessary, unless there are CPUs that advertise NEON support > > > > > > > > but don't actually support it. > > > > > > > > > > > > > > > > > > > > > > I think the issue will result in a compiler error perhaps when neon is > > > > > > > disabled via > > > > > > > compiler command line which would be the case when neon is not in TUNE_FEATURES > > > > > > > the compiler might warn or error out when it finds neon instructions > > > > > > > being compiled via inline > > > > > > > assembly. you just can try passing something like -mfpu=vfpv3d16 or > > > > > > > some such and see if > > > > > > > compiler/assembler complains during build, if not then perhaps its fine. > > > > > > > > > > > > If the last -mfpu is something else than neon, then including > > > > > > arm_neon.h will succeed but compiling neon code will fail. > > > > > > > > > > > > I did some experiments, and what I found was that when I remove neon > > > > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very > > > > > > early in the compiler command line. PulseAudio adds -mfpu=neon to > > > > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon > > > > > > code gets built without errors. > > > > > > > > > > > > The configure check in PulseAudio only checks that the compiler accepts > > > > > > -mfpu=neon and #include <arm_neon.h>, it doesn't try to compile any > > > > > > actual neon code. This means that if the user adds -mfpu=vfp (or other > > > > > > non-neon) to CFLAGS rather than CC, configure will pass but building > > > > > > will fail. Is this something to guard against? A default qemuarm build > > > > > > doesn't do this, so I don't know if this ever happens in OE. > > > > > > > > > > > > I don't know yet how Meson behaves, I'll continue testing... > > > > > > > > > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC. > > > > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I > > > > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is > > > > > enabled in any case. > > > > > > > > > > So, Meson seems pretty safe, although I guess it would be nice not to > > > > > override the user's -mfpu setting. I think this isn't a big problem is > > > > > practice, since runtime detection works. > > > > > > > > > > I haven't tested with a compiler that truly can't build Neon code, > > > > > because I don't know how to do that. > > > > > > Presumably set a -mcpu=XXX to something which can never support NEON? > > > > No success so far... > > > > I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio > > recipe, but Neon got still enabled. GCC warned that -march=armv7ve > > conflicted with the chosen -mcpu (which makes sense, since "ve" in > > "armv7ve" means "virtualization extensinons", and Cortex-A9 doesn't > > have virtualization support, and all cores that have virtualization > > support have mandatory Neon support). > > Is that true? If so then the various armv7ve specific tuning files > (tune-cortexa15.inc, etc) could all be simplified by removing the > option to disable NEON support. (Sorry for the delay in replying.) I don't know if there's any official rule that cores with virtualization must have Neon support (I would guess not). What I wrote was only based on looking at this Wikipedia page, where every core with virtualization also has Neon: https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures Also, the GCC warning about conflicting -mcpu and -march turned out not to be about armv7ve requiring Neon, I got the same warning also with -march=armv7a and -mcpu=cortex-a9+nosimd. Maybe -mcpu and -march just aren't supposed to be used together. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-08-23 8:54 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-19 9:06 Why disable NEON support in recipes if runtime detection works? Tanu Kaskinen 2020-07-19 9:30 ` [OE-core] " Adrian Bunk 2020-07-19 9:46 ` Tanu Kaskinen 2020-07-20 22:26 ` Khem Raj 2020-07-26 6:27 ` Tanu Kaskinen [not found] ` <1625397D9F68474B.26462@lists.openembedded.org> 2020-07-26 7:59 ` Tanu Kaskinen 2020-07-26 14:01 ` Khem Raj 2020-07-27 20:45 ` Andre McCurdy 2020-07-29 13:46 ` Tanu Kaskinen 2020-07-29 22:08 ` Andre McCurdy 2020-08-23 8:53 ` Tanu Kaskinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.