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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
