From: Mark Hatle <mark.hatle@windriver.com>
To: Philip Balister <philip@balister.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Enabling NEON instructions for fftw
Date: Fri, 4 Jan 2013 09:46:24 -0600 [thread overview]
Message-ID: <50E6F950.2070306@windriver.com> (raw)
In-Reply-To: <50E6F6F0.2070502@balister.org>
On 1/4/13 9:36 AM, Philip Balister wrote:
> On 01/03/2013 02:21 PM, Mark Hatle wrote:
>> On 1/3/13 12:42 PM, Philip Balister wrote:
>>> So, recent versions of fftw have NEON support for the single precision
>>> build. In the poast, I just passed --enable-neon to configure or the
>>> armv7a case. Now, this is not entirely correct, since some armv7a's lack
>>> a NEON coprocessor.
>>>
>>> Does anyone have a suggestion for how to handle this better? Personally,
>>> I think if you want to run fftwf without NEON, you should have your head
>>> examined, but I would like to avoid generating packages that SIGILL on
>>> people.
>>
>> This says to me that either you need a machine specific package, or use
>> an alternative architecture for that package.. (that is compatible)..
>> then the package can switch neon on/off depending on arch of tuning flags.
>>
>> There is an armv7a-neon tuning defined. This enabled the TUNE_FEATURES
>> of 'neon'. So you should be able to check for that in the fftw recipe,
>> and enable the --enable-neon when it's set. (Using PACKAGECONFIG is
>> likely best...)
>>
>> Then you can change the DEFAULTTUNE_<recipe> = "armv7-neon" in your
>> local.conf.
>
> I really do not want to depend on users putting entries in local.conf to
> obtain proper operation on a specific machine. It looks like the neon
> tune is already selected for the machine I am building for.
>
> In the end, this boils down to, do we care about supporting machines
> with/without NEON from one set of packages by making ones with NEON
> machine specific.
Machine specific is one answer, but my preference is to have a neon specific
package arch selected. Looking at the definitions, my expectation is that once
the -neon version of armv7 is selected the package arch should similarly be
modified to end in "-neon".
So as long as the BSP/machine uses the neon tune, then everything should be
compiled and labeled properly.
> For now, I will purse the route of fftwf building with --enable if the
> neon tune is available for the machine.
Definitely the right way to do it, no matter how the package's arch is named.
> Philip
>
> Philip
>
> Philip
>
>>
>> --Mark
>>
>>> Philip
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
prev parent reply other threads:[~2013-01-04 16:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-03 18:42 Enabling NEON instructions for fftw Philip Balister
2013-01-03 19:21 ` Mark Hatle
2013-01-04 15:36 ` Philip Balister
2013-01-04 15:46 ` Mark Hatle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50E6F950.2070306@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=philip@balister.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.