Enabling NEON instructions for fftw
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.
Philip
Quoted 9 lines · Philip Balister
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.
--Mark
Quoted 7 lines
Philip
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 15 lines · Mark Hatle
Quoted 9 lines · Philip Balister
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.
Quoted 7 lines
There is an armv7a-neon tuning defined. This enabled the
TUNE_FEATURESof '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.
For now, I will purse the route of fftwf building with --enable if the neon tune is available for the machine.
Philip
Philip
Philip
Quoted 18 lines
--Mark
Quoted 7 lines
Philip
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 24 lines · Philip Balister
Quoted 15 lines · Mark Hatle
Quoted 9 lines · Philip Balister
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.
Quoted 7 lines
There is an armv7a-neon tuning defined. This enabled the
TUNE_FEATURESof '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.
Quoted 7 lines
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.
Quoted 2 lines
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.
Quoted 24 lines
Philip
Philip
Philip
Quoted 18 lines
--Mark
Quoted 7 lines
Philip
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core