All of lore.kernel.org
 help / color / mirror / Atom feed
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
>>
>>




      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.