* RFC: pulseaudio vs. meson vs. neon @ 2021-06-28 10:01 Andrea Adami 2021-06-28 10:59 ` [OE-core] " Alexander Kanavin 2021-06-28 17:55 ` Khem Raj 0 siblings, 2 replies; 16+ messages in thread From: Andrea Adami @ 2021-06-28 10:01 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 10:01 RFC: pulseaudio vs. meson vs. neon Andrea Adami @ 2021-06-28 10:59 ` Alexander Kanavin 2021-06-28 12:08 ` Andrea Adami 2021-06-28 17:55 ` Khem Raj 1 sibling, 1 reply; 16+ messages in thread From: Alexander Kanavin @ 2021-06-28 10:59 UTC (permalink / raw) To: Andrea Adami; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 10:59 ` [OE-core] " Alexander Kanavin @ 2021-06-28 12:08 ` Andrea Adami 2021-06-28 12:36 ` Alexander Kanavin 0 siblings, 1 reply; 16+ messages in thread From: Andrea Adami @ 2021-06-28 12:08 UTC (permalink / raw) To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer 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. >> >> >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 12:08 ` Andrea Adami @ 2021-06-28 12:36 ` Alexander Kanavin 2021-06-28 12:44 ` Andrea Adami 0 siblings, 1 reply; 16+ messages in thread From: Alexander Kanavin @ 2021-06-28 12:36 UTC (permalink / raw) To: Andrea Adami; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 12:36 ` Alexander Kanavin @ 2021-06-28 12:44 ` Andrea Adami 2021-06-28 13:03 ` Richard Purdie 0 siblings, 1 reply; 16+ messages in thread From: Andrea Adami @ 2021-06-28 12:44 UTC (permalink / raw) To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer 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. >> >> >> >> >> >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 12:44 ` Andrea Adami @ 2021-06-28 13:03 ` Richard Purdie 2021-06-28 13:10 ` Andrea Adami 0 siblings, 1 reply; 16+ messages in thread From: Richard Purdie @ 2021-06-28 13:03 UTC (permalink / raw) To: Andrea Adami, Alexander Kanavin Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 13:03 ` Richard Purdie @ 2021-06-28 13:10 ` Andrea Adami 0 siblings, 0 replies; 16+ messages in thread From: Andrea Adami @ 2021-06-28 13:10 UTC (permalink / raw) To: Richard Purdie Cc: Alexander Kanavin, Patches and discussions about the oe-core layer 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. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 10:01 RFC: pulseaudio vs. meson vs. neon Andrea Adami 2021-06-28 10:59 ` [OE-core] " Alexander Kanavin @ 2021-06-28 17:55 ` Khem Raj 2021-06-28 18:20 ` Andrea Adami 1 sibling, 1 reply; 16+ messages in thread From: Khem Raj @ 2021-06-28 17:55 UTC (permalink / raw) To: Andrea Adami, Patches and discussions about the oe-core layer 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. > > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 17:55 ` Khem Raj @ 2021-06-28 18:20 ` Andrea Adami 2021-06-28 18:46 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Andrea Adami @ 2021-06-28 18:20 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer 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. > > > > > > > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 18:20 ` Andrea Adami @ 2021-06-28 18:46 ` Khem Raj 2021-06-28 19:10 ` Phil Blundell 0 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2021-06-28 18:46 UTC (permalink / raw) To: Andrea Adami; +Cc: Patches and discussions about the oe-core layer 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. >>> >>> >>> >>> >>> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 18:46 ` Khem Raj @ 2021-06-28 19:10 ` Phil Blundell 2021-06-28 19:42 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Phil Blundell @ 2021-06-28 19:10 UTC (permalink / raw) To: Khem Raj; +Cc: Andrea Adami, Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 19:10 ` Phil Blundell @ 2021-06-28 19:42 ` Khem Raj 2021-06-28 19:52 ` Phil Blundell 0 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2021-06-28 19:42 UTC (permalink / raw) To: Phil Blundell Cc: Andrea Adami, Patches and discussions about the oe-core layer 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. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 19:42 ` Khem Raj @ 2021-06-28 19:52 ` Phil Blundell 2021-06-28 21:10 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Phil Blundell @ 2021-06-28 19:52 UTC (permalink / raw) To: Khem Raj; +Cc: Andrea Adami, Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 19:52 ` Phil Blundell @ 2021-06-28 21:10 ` Khem Raj 2021-06-28 21:21 ` Phil Blundell 0 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2021-06-28 21:10 UTC (permalink / raw) To: Phil Blundell Cc: Andrea Adami, Patches and discussions about the oe-core layer 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. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 21:10 ` Khem Raj @ 2021-06-28 21:21 ` Phil Blundell 2021-06-28 21:40 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Phil Blundell @ 2021-06-28 21:21 UTC (permalink / raw) To: Khem Raj; +Cc: Andrea Adami, Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [OE-core] RFC: pulseaudio vs. meson vs. neon 2021-06-28 21:21 ` Phil Blundell @ 2021-06-28 21:40 ` Khem Raj 0 siblings, 0 replies; 16+ messages in thread From: Khem Raj @ 2021-06-28 21:40 UTC (permalink / raw) To: Phil Blundell Cc: Andrea Adami, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-06-28 21:40 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-28 10:01 RFC: pulseaudio vs. meson vs. neon Andrea Adami 2021-06-28 10:59 ` [OE-core] " Alexander Kanavin 2021-06-28 12:08 ` Andrea Adami 2021-06-28 12:36 ` Alexander Kanavin 2021-06-28 12:44 ` Andrea Adami 2021-06-28 13:03 ` Richard Purdie 2021-06-28 13:10 ` Andrea Adami 2021-06-28 17:55 ` Khem Raj 2021-06-28 18:20 ` Andrea Adami 2021-06-28 18:46 ` Khem Raj 2021-06-28 19:10 ` Phil Blundell 2021-06-28 19:42 ` Khem Raj 2021-06-28 19:52 ` Phil Blundell 2021-06-28 21:10 ` Khem Raj 2021-06-28 21:21 ` Phil Blundell 2021-06-28 21:40 ` Khem Raj
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.