RFC: pulseaudio vs. meson vs. neon

RFC: pulseaudio vs. meson vs. neon

[Andrea Adami]

Hello,

during a core-image-sato build for armv4 I got one single build
failure with pulseaudio.

This happens after commit 80bbea0 pulseaudio: switch build system from
Autotools to Meson. In the commit text it is evidenced:

"
With Meson there's no option for disabling Neon optimizations if the
compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
because the build system adds -mfpu=neon at the end of the compiler
command line, overriding any earlier -mfpu options. This shouldn't be
a problem, because PulseAudio detects at runtime whether the CPU
supports Neon instructions.
"

At the moment to build pulseaudio for armv4/5 I have reverted to using
autotools.


There was around a patch but has not been merged.
https://lists.openembedded.org/g/openembedded-core/message/146375

Maybe a v2 will be accepted?

Cheers
A.A.

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Alexander Kanavin]

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

Seems like an upstream problem rather than a Yocto one?

Alex

On Mon, 28 Jun 2021 at 12:02, Andrea Adami <andrea.adami@gmail.com> wrote:

> Hello,
>
> during a core-image-sato build for armv4 I got one single build
> failure with pulseaudio.
>
> This happens after commit 80bbea0 pulseaudio: switch build system from
> Autotools to Meson. In the commit text it is evidenced:
>
> "
> With Meson there's no option for disabling Neon optimizations if the
> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
> because the build system adds -mfpu=neon at the end of the compiler
> command line, overriding any earlier -mfpu options. This shouldn't be
> a problem, because PulseAudio detects at runtime whether the CPU
> supports Neon instructions.
> "
>
> At the moment to build pulseaudio for armv4/5 I have reverted to using
> autotools.
>
>
> There was around a patch but has not been merged.
> https://lists.openembedded.org/g/openembedded-core/message/146375
>
> Maybe a v2 will be accepted?
>
> Cheers
> A.A.
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 1598 bytes --]

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Andrea Adami]

On Mon, Jun 28, 2021 at 1:00 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> Seems like an upstream problem rather than a Yocto one?

Indeed,

from
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/
"
One difference from Autotools is that the --disable-neon-opt option
for disabling NEON optimizations doesn't have a counterpart in Meson
due to how Meson's NEON detection works. NEON will always be enabled
if the compiler supports it, but even if the target machine doesn't
support NEON, that shouldn't be a problem, because PulseAudio disables
NEON at run-time if the processor doesn't support it.
"
Upstream *thinks* this is not an issue because all will be fine at runtime :)

Cheers
A.A:

>
> Alex
>
> On Mon, 28 Jun 2021 at 12:02, Andrea Adami <andrea.adami@gmail.com> wrote:
>>
>> Hello,
>>
>> during a core-image-sato build for armv4 I got one single build
>> failure with pulseaudio.
>>
>> This happens after commit 80bbea0 pulseaudio: switch build system from
>> Autotools to Meson. In the commit text it is evidenced:
>>
>> "
>> With Meson there's no option for disabling Neon optimizations if the
>> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
>> because the build system adds -mfpu=neon at the end of the compiler
>> command line, overriding any earlier -mfpu options. This shouldn't be
>> a problem, because PulseAudio detects at runtime whether the CPU
>> supports Neon instructions.
>> "
>>
>> At the moment to build pulseaudio for armv4/5 I have reverted to using
>> autotools.
>>
>>
>> There was around a patch but has not been merged.
>> https://lists.openembedded.org/g/openembedded-core/message/146375
>>
>> Maybe a v2 will be accepted?
>>
>> Cheers
>> A.A.
>>
>> 
>>

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Alexander Kanavin]

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

What I am saying is, can you discuss this with upstream first please?

Alex

On Mon, 28 Jun 2021 at 14:08, Andrea Adami <andrea.adami@gmail.com> wrote:

> On Mon, Jun 28, 2021 at 1:00 PM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > Seems like an upstream problem rather than a Yocto one?
>
> Indeed,
>
> from
> https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/
> "
> One difference from Autotools is that the --disable-neon-opt option
> for disabling NEON optimizations doesn't have a counterpart in Meson
> due to how Meson's NEON detection works. NEON will always be enabled
> if the compiler supports it, but even if the target machine doesn't
> support NEON, that shouldn't be a problem, because PulseAudio disables
> NEON at run-time if the processor doesn't support it.
> "
> Upstream *thinks* this is not an issue because all will be fine at runtime
> :)
>
> Cheers
> A.A:
>
> >
> > Alex
> >
> > On Mon, 28 Jun 2021 at 12:02, Andrea Adami <andrea.adami@gmail.com>
> wrote:
> >>
> >> Hello,
> >>
> >> during a core-image-sato build for armv4 I got one single build
> >> failure with pulseaudio.
> >>
> >> This happens after commit 80bbea0 pulseaudio: switch build system from
> >> Autotools to Meson. In the commit text it is evidenced:
> >>
> >> "
> >> With Meson there's no option for disabling Neon optimizations if the
> >> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
> >> because the build system adds -mfpu=neon at the end of the compiler
> >> command line, overriding any earlier -mfpu options. This shouldn't be
> >> a problem, because PulseAudio detects at runtime whether the CPU
> >> supports Neon instructions.
> >> "
> >>
> >> At the moment to build pulseaudio for armv4/5 I have reverted to using
> >> autotools.
> >>
> >>
> >> There was around a patch but has not been merged.
> >> https://lists.openembedded.org/g/openembedded-core/message/146375
> >>
> >> Maybe a v2 will be accepted?
> >>
> >> Cheers
> >> A.A.
> >>
> >> 
> >>
>

[-- Attachment #2: Type: text/html, Size: 3122 bytes --]

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Andrea Adami]

On Mon, Jun 28, 2021 at 2:36 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> What I am saying is, can you discuss this with upstream first please?

Sorry, no, I'm not in the position to do that.
Besides, I am dispatching my armv4/armv5te Zaurus hardware so I will
not be able to test anymore.

My point here is, for this pulseaudio 14.x release (in Honister) we
could do an effort and patch the damn file.
I write this because this is the only failing recipe for
core-image-sato for armv4 and this arch is still supported in oe-core
(thank you so much Khem).

So I'd say as long as armv4 and armv5t are supported we need to patch
the recipe.

With next pulseaudio 15.x the older arm will maybe lose support, I
don't know now.

My 2 cents
A.A.



>
> Alex
>
> On Mon, 28 Jun 2021 at 14:08, Andrea Adami <andrea.adami@gmail.com> wrote:
>>
>> On Mon, Jun 28, 2021 at 1:00 PM Alexander Kanavin
>> <alex.kanavin@gmail.com> wrote:
>> >
>> > Seems like an upstream problem rather than a Yocto one?
>>
>> Indeed,
>>
>> from
>> https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/
>> "
>> One difference from Autotools is that the --disable-neon-opt option
>> for disabling NEON optimizations doesn't have a counterpart in Meson
>> due to how Meson's NEON detection works. NEON will always be enabled
>> if the compiler supports it, but even if the target machine doesn't
>> support NEON, that shouldn't be a problem, because PulseAudio disables
>> NEON at run-time if the processor doesn't support it.
>> "
>> Upstream *thinks* this is not an issue because all will be fine at runtime :)
>>
>> Cheers
>> A.A:
>>
>> >
>> > Alex
>> >
>> > On Mon, 28 Jun 2021 at 12:02, Andrea Adami <andrea.adami@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> during a core-image-sato build for armv4 I got one single build
>> >> failure with pulseaudio.
>> >>
>> >> This happens after commit 80bbea0 pulseaudio: switch build system from
>> >> Autotools to Meson. In the commit text it is evidenced:
>> >>
>> >> "
>> >> With Meson there's no option for disabling Neon optimizations if the
>> >> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
>> >> because the build system adds -mfpu=neon at the end of the compiler
>> >> command line, overriding any earlier -mfpu options. This shouldn't be
>> >> a problem, because PulseAudio detects at runtime whether the CPU
>> >> supports Neon instructions.
>> >> "
>> >>
>> >> At the moment to build pulseaudio for armv4/5 I have reverted to using
>> >> autotools.
>> >>
>> >>
>> >> There was around a patch but has not been merged.
>> >> https://lists.openembedded.org/g/openembedded-core/message/146375
>> >>
>> >> Maybe a v2 will be accepted?
>> >>
>> >> Cheers
>> >> A.A.
>> >>
>> >> 
>> >>

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Richard Purdie]

On Mon, 2021-06-28 at 14:44 +0200, Andrea Adami wrote:
> On Mon, Jun 28, 2021 at 2:36 PM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> > 
> > What I am saying is, can you discuss this with upstream first please?
> 
> Sorry, no, I'm not in the position to do that.
> Besides, I am dispatching my armv4/armv5te Zaurus hardware so I will
> not be able to test anymore.
> 
> My point here is, for this pulseaudio 14.x release (in Honister) we
> could do an effort and patch the damn file.
> I write this because this is the only failing recipe for
> core-image-sato for armv4 and this arch is still supported in oe-core
> (thank you so much Khem).
> 
> So I'd say as long as armv4 and armv5t are supported we need to patch
> the recipe.
> 
> With next pulseaudio 15.x the older arm will maybe lose support, I
> don't know now.

We've left armv4 "support" in there mainly as it doesn't really cost us
anything to do so and does help some users. We're not in a position
where we have many people interested in helping carry patches like this
to pulseaudio.

What that means is that where there are fixes, they need to be easy to 
maintain and not impact the more modern tunes.

Hacking CC as in the patch you linked to isn't particularly nice, nor
is a global export it requires (changing the behaviour of other arches). 
It is also risky as the pulseaudio build system tries to do something
quite different and this workaround is liable to break.

I'm not against patching in an explicit option to pulseaudio but it
would also be good to mention that to upstream, raising the fact there
is a problem, contra to what their commit says.

Cheers,

Richard

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Andrea Adami]

On Mon, Jun 28, 2021 at 3:03 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2021-06-28 at 14:44 +0200, Andrea Adami wrote:
> > On Mon, Jun 28, 2021 at 2:36 PM Alexander Kanavin
> > <alex.kanavin@gmail.com> wrote:
> > >
> > > What I am saying is, can you discuss this with upstream first please?
> >
> > Sorry, no, I'm not in the position to do that.
> > Besides, I am dispatching my armv4/armv5te Zaurus hardware so I will
> > not be able to test anymore.
> >
> > My point here is, for this pulseaudio 14.x release (in Honister) we
> > could do an effort and patch the damn file.
> > I write this because this is the only failing recipe for
> > core-image-sato for armv4 and this arch is still supported in oe-core
> > (thank you so much Khem).
> >
> > So I'd say as long as armv4 and armv5t are supported we need to patch
> > the recipe.
> >
> > With next pulseaudio 15.x the older arm will maybe lose support, I
> > don't know now.
>
> We've left armv4 "support" in there mainly as it doesn't really cost us
> anything to do so and does help some users. We're not in a position
> where we have many people interested in helping carry patches like this
> to pulseaudio.
>
> What that means is that where there are fixes, they need to be easy to
> maintain and not impact the more modern tunes.
>
> Hacking CC as in the patch you linked to isn't particularly nice, nor
> is a global export it requires (changing the behaviour of other arches).
> It is also risky as the pulseaudio build system tries to do something
> quite different and this workaround is liable to break.
>
> I'm not against patching in an explicit option to pulseaudio but it
> would also be good to mention that to upstream, raising the fact there
> is a problem, contra to what their commit says.
>
> Cheers,
>
> Richard
>
>
Richard,
thanks for reviewing this.
As you know I'm mumbling about this on irc these days.
Please let's wait and read what Khem proposes.

Note that the switch to meson wasn't mandatory.
"we will be dropping support for the autotools build in 15.0"

A.A.
>

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Khem Raj]

Hi Andrea

On 6/28/21 3:01 AM, Andrea Adami wrote:
> Hello,
> 
> during a core-image-sato build for armv4 I got one single build
> failure with pulseaudio.
> 
> This happens after commit 80bbea0 pulseaudio: switch build system from
> Autotools to Meson. In the commit text it is evidenced:
> 
> "
> With Meson there's no option for disabling Neon optimizations if the
> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
> because the build system adds -mfpu=neon at the end of the compiler
> command line, overriding any earlier -mfpu options. This shouldn't be
> a problem, because PulseAudio detects at runtime whether the CPU
> supports Neon instructions.
> "
> 
> At the moment to build pulseaudio for armv4/5 I have reverted to using
> autotools.
> 
> 
> There was around a patch but has not been merged.
> https://lists.openembedded.org/g/openembedded-core/message/146375
> 

this patch is not right. It might let us compile but it will still emit 
code that will expect VFP at runtime and hence fail to run.

> Maybe a v2 will be accepted?

right fix would be to add a proper neon support check in pulseaudio 
meson'ary, and if PA has dropped the ball on non VFP ARM then it will be 
hard to convince upstream to accept it but atleast you can try.

> 
> Cheers
> A.A.
> 
> 
> 
> 
> 

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Andrea Adami]

On Mon, Jun 28, 2021 at 7:55 PM Khem Raj <raj.khem@gmail.com> wrote:
>
> Hi Andrea
>
> On 6/28/21 3:01 AM, Andrea Adami wrote:
> > Hello,
> >
> > during a core-image-sato build for armv4 I got one single build
> > failure with pulseaudio.
> >
> > This happens after commit 80bbea0 pulseaudio: switch build system from
> > Autotools to Meson. In the commit text it is evidenced:
> >
> > "
> > With Meson there's no option for disabling Neon optimizations if the
> > compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
> > because the build system adds -mfpu=neon at the end of the compiler
> > command line, overriding any earlier -mfpu options. This shouldn't be
> > a problem, because PulseAudio detects at runtime whether the CPU
> > supports Neon instructions.
> > "
> >
> > At the moment to build pulseaudio for armv4/5 I have reverted to using
> > autotools.
> >
> >
> > There was around a patch but has not been merged.
> > https://lists.openembedded.org/g/openembedded-core/message/146375
> >
>
> this patch is not right. It might let us compile but it will still emit
> code that will expect VFP at runtime and hence fail to run.
>
> > Maybe a v2 will be accepted?
>
> right fix would be to add a proper neon support check in pulseaudio
> meson'ary, and if PA has dropped the ball on non VFP ARM then it will be
> hard to convince upstream to accept it but atleast you can try.
>

Thank you for the review.
I knew the patch was not right, I tried other workarounds and I
failed. That's why the RFC was sent.

With my very limited knowledge about the matter it would be impossible
for me to argue with L.P. upstream.
My personal opinion is that the switch to meson was done too early, at
least 14.x could have used autotools and less meson patches.

But if upstream deliberately breaks compatibility there isn't much we
can do, maybe overpatching. sigh...

Cheers
A.A.
> >
> > Cheers
> > A.A.
> >
> >
> >
> > 
> >

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Khem Raj]

On 6/28/21 11:20 AM, Andrea Adami wrote:
> On Mon, Jun 28, 2021 at 7:55 PM Khem Raj <raj.khem@gmail.com> wrote:
>>
>> Hi Andrea
>>
>> On 6/28/21 3:01 AM, Andrea Adami wrote:
>>> Hello,
>>>
>>> during a core-image-sato build for armv4 I got one single build
>>> failure with pulseaudio.
>>>
>>> This happens after commit 80bbea0 pulseaudio: switch build system from
>>> Autotools to Meson. In the commit text it is evidenced:
>>>
>>> "
>>> With Meson there's no option for disabling Neon optimizations if the
>>> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
>>> because the build system adds -mfpu=neon at the end of the compiler
>>> command line, overriding any earlier -mfpu options. This shouldn't be
>>> a problem, because PulseAudio detects at runtime whether the CPU
>>> supports Neon instructions.
>>> "
>>>
>>> At the moment to build pulseaudio for armv4/5 I have reverted to using
>>> autotools.
>>>
>>>
>>> There was around a patch but has not been merged.
>>> https://lists.openembedded.org/g/openembedded-core/message/146375
>>>
>>
>> this patch is not right. It might let us compile but it will still emit
>> code that will expect VFP at runtime and hence fail to run.
>>
>>> Maybe a v2 will be accepted?
>>
>> right fix would be to add a proper neon support check in pulseaudio
>> meson'ary, and if PA has dropped the ball on non VFP ARM then it will be
>> hard to convince upstream to accept it but atleast you can try.
>>
> 
> Thank you for the review.
> I knew the patch was not right, I tried other workarounds and I
> failed. That's why the RFC was sent.
> 
> With my very limited knowledge about the matter it would be impossible
> for me to argue with L.P. upstream.
> My personal opinion is that the switch to meson was done too early, at
> least 14.x could have used autotools and less meson patches.
> 
> But if upstream deliberately breaks compatibility there isn't much we
> can do, maybe overpatching. sigh...
> 

I still hope that if we can add a proper neon detection patch to meson
they would be ok to accept it.


> Cheers
> A.A.
>>>
>>> Cheers
>>> A.A.
>>>
>>>
>>>
>>> 
>>>

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Phil Blundell]

On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote:
> I still hope that if we can add a proper neon detection patch to meson
> they would be ok to accept it.

Why doesn't the runtime detection work in the way that upstream clearly
think it ought to?

p.

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Khem Raj]

On Mon, Jun 28, 2021 at 12:10 PM Phil Blundell <pb@pbcl.net> wrote:
>
> On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote:
> > I still hope that if we can add a proper neon detection patch to meson
> > they would be ok to accept it.
>
> Why doesn't the runtime detection work in the way that upstream clearly
> think it ought to?

probably it does, someone has to test it on device without vfp.
Currently it is still failing to compile.
so first that needs to be fixed.
>
> p.
>

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Phil Blundell]

On Mon, Jun 28, 2021 at 12:42:55PM -0700, Khem Raj wrote:
> On Mon, Jun 28, 2021 at 12:10 PM Phil Blundell <pb@pbcl.net> wrote:
> >
> > On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote:
> > > I still hope that if we can add a proper neon detection patch to meson
> > > they would be ok to accept it.
> >
> > Why doesn't the runtime detection work in the way that upstream clearly
> > think it ought to?
> 
> probably it does, someone has to test it on device without vfp.
> Currently it is still failing to compile.
> so first that needs to be fixed.

Okay, but if the runtime detection does in fact work then there's no need
for any NEON detection in Meson, right?

p.

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Khem Raj]

On 6/28/21 12:52 PM, Phil Blundell wrote:
> On Mon, Jun 28, 2021 at 12:42:55PM -0700, Khem Raj wrote:
>> On Mon, Jun 28, 2021 at 12:10 PM Phil Blundell <pb@pbcl.net> wrote:
>>>
>>> On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote:
>>>> I still hope that if we can add a proper neon detection patch to meson
>>>> they would be ok to accept it.
>>>
>>> Why doesn't the runtime detection work in the way that upstream clearly
>>> think it ought to?
>>
>> probably it does, someone has to test it on device without vfp.
>> Currently it is still failing to compile.
>> so first that needs to be fixed.
> 
> Okay, but if the runtime detection does in fact work then there's no need
> for any NEON detection in Meson, right?

well, if we can beat the compiler to not complain about using neon on a 
non-neon system then yes, but changing float ABI to make compiler happy 
seems a bit iffy, since compiler will generate code expecting VFP and 
that could trip the system.

> 
> p.
> 

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Phil Blundell]

On Mon, Jun 28, 2021 at 02:10:39PM -0700, Khem Raj wrote:
> well, if we can beat the compiler to not complain about using neon on a
> non-neon system then yes, but changing float ABI to make compiler happy
> seems a bit iffy, since compiler will generate code expecting VFP and that
> could trip the system.

Right, that's a separate issue.  I'm not 100% clear what you mean by "trip
the system" but I think it's probably reasonable to say that no ABI ought
to be changing here.  I think that's orthogonal, though, to the question of
whether Meson ought to be detecting NEON at compile time.

p.

Re: [OE-core] RFC: pulseaudio vs. meson vs. neon

[Khem Raj]

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

On Mon, Jun 28, 2021 at 2:21 PM Phil Blundell <pb@pbcl.net> wrote:

> On Mon, Jun 28, 2021 at 02:10:39PM -0700, Khem Raj wrote:
> > well, if we can beat the compiler to not complain about using neon on a
> > non-neon system then yes, but changing float ABI to make compiler happy
> > seems a bit iffy, since compiler will generate code expecting VFP and
> that
> > could trip the system.
>
> Right, that's a separate issue.  I'm not 100% clear what you mean by "trip
> the system" but I think it's probably reasonable to say that no ABI ought
> to be changing here.  I think that's orthogonal, though, to the question of
> whether Meson ought to be detecting NEON at compile time.


Yes they are orthogonal although both are needed for what Andrea is looking
for

>
>
> p.
>
>

[-- Attachment #2: Type: text/html, Size: 1284 bytes --]