On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> On Sun, Jul 26, 2020 at 7:01 AM Khem Raj <[email protected]> wrote:
> > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen <[email protected]> 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 <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141094):
https://lists.openembedded.org/g/openembedded-core/message/141094
Mute This Topic: https://lists.openembedded.org/mt/75658822/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
