Is a method via the aux vectors to know at runtime if neon is or is not present?
Thanks!
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
Regards, -jserv
Perfect!
Thanks Jim!
On Sat, Sep 3, 2011 at 8:10 AM, Jim Huang jserv@0xlab.org wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
Regards, -jserv
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
On 5 September 2011 11:35, Christian Robottom Reis kiko@linaro.org wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
Yes, and might be a good topic for the NEON optimization forum as well.
--
Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 6 September 2011 13:23, Kurt Taylor kurt.taylor@linaro.org wrote:
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
Yes, and might be a good topic for the NEON optimization forum as well.
As well as features I'd like to be able to get the ID of the device; while most cases are looking as to whether the device has a feature, there are cases where you want very different optimised code for different implementations (e.g. A8 v A9).
Dave
On 6 September 2011 13:28, David Gilbert david.gilbert@linaro.org wrote:
On 6 September 2011 13:23, Kurt Taylor kurt.taylor@linaro.org wrote:
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
Yes, and might be a good topic for the NEON optimization forum as well.
As well as features I'd like to be able to get the ID of the device; while most cases are looking as to whether the device has a feature, there are cases where you want very different optimised code for different implementations (e.g. A8 v A9).
I have an old kernel patch somewhere that allows userspace to read the ID register by emulating the relevant MRC in the illegal instruction trap handler. Perhaps this is something worth reviving. With this approach, interpreting the ID value would still be left as an exercise for the application.
On 6 September 2011 14:38, Mans Rullgard mans.rullgard@linaro.org wrote:
I have an old kernel patch somewhere that allows userspace to read the ID register by emulating the relevant MRC in the illegal instruction trap handler. Perhaps this is something worth reviving. With this approach, interpreting the ID value would still be left as an exercise for the application.
Would it be better for the kernel just to pass it in the AUXV somewhere? It's fine for the user space to interpret it - I'm thinking of ifunc to be able to decide based on a libraries idea that it knows what's better for a particular core.
Dave
On 6 September 2011 14:47, David Gilbert david.gilbert@linaro.org wrote:
On 6 September 2011 14:38, Mans Rullgard mans.rullgard@linaro.org wrote:
I have an old kernel patch somewhere that allows userspace to read the ID register by emulating the relevant MRC in the illegal instruction trap handler. Perhaps this is something worth reviving. With this approach, interpreting the ID value would still be left as an exercise for the application.
Would it be better for the kernel just to pass it in the AUXV somewhere? It's fine for the user space to interpret it - I'm thinking of ifunc to be able to decide based on a libraries idea that it knows what's better for a particular core.
A third possibility would be to stick it in somewhere in sysfs.
On Tue, Sep 06, 2011 at 02:47:48PM +0100, David Gilbert wrote:
On 6 September 2011 14:38, Mans Rullgard mans.rullgard@linaro.org wrote:
I have an old kernel patch somewhere that allows userspace to read the ID register by emulating the relevant MRC in the illegal instruction trap handler. Perhaps this is something worth reviving. With this approach, interpreting the ID value would still be left as an exercise for the application.
Would it be better for the kernel just to pass it in the AUXV somewhere?
This could be done, but it feels like an abuse somehow. An independent aux vector is passed to each process, so it makes most sense for process-specific information.
Although auxv is convenient, I'd say that global, nonmodifiable properties of the system should really be exported by some different, global mechanism. It's questionable whether the hwcaps really belong in auxv at all -- it's possible that some platforms make use of this and actually report different hwcaps to different processes, but AFAIK we don't do this on ARM. Now that hwcaps is there, it should stay there, for historical reasons and consistency with other architectures.
sysfs feels like the least worst solution for exporting additional information.
---Dave
On 09/05/2011 11:35 AM, Christian Robottom Reis wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
done:
https://wiki.linaro.org/Resources/HowTo/DeterminingNeon
There are also links from our main HowTo page.
On 6 September 2011 16:09, Andy Doan andy.doan@linaro.org wrote:
On 09/05/2011 11:35 AM, Christian Robottom Reis wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
done:
For random "user at the command line" usage is this any better than the simpler "grep neon /proc/cpuinfo" ? (For that specific meego bug it serves a purpose in that it reveals that the libc/auxv is lying, but in general cpuinfo and auxv should I agree I think.)
If you're a program, you do want to use auxv I think, but you'd just read it directly rather than invoking an external binary via the shell to get the dynamic linker to read auxv for you as a side effect...
-- PMM
On 09/06/2011 10:24 AM, Peter Maydell wrote:
On 6 September 2011 16:09, Andy Doan andy.doan@linaro.org wrote:
On 09/05/2011 11:35 AM, Christian Robottom Reis wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
done:
For random "user at the command line" usage is this any better than the simpler "grep neon /proc/cpuinfo" ? (For that specific meego bug it serves a purpose in that it reveals that the libc/auxv is lying, but in general cpuinfo and auxv should I agree I think.)
I forgot you could get it there. I don't know which should be recommended.
If you're a program, you do want to use auxv I think, but you'd just read it directly rather than invoking an external binary via the shell to get the dynamic linker to read auxv for you as a side effect...
I just added a small example in C demonstrating that.
On Tue, Sep 06, 2011 at 04:24:32PM +0100, Peter Maydell wrote:
On 6 September 2011 16:09, Andy Doan andy.doan@linaro.org wrote:
On 09/05/2011 11:35 AM, Christian Robottom Reis wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
done:
For random "user at the command line" usage is this any better than the simpler "grep neon /proc/cpuinfo" ? (For that specific meego bug it serves a purpose in that it reveals that the libc/auxv is lying, but in general cpuinfo and auxv should I agree I think.)
If you're a program, you do want to use auxv I think, but you'd just read it directly rather than invoking an external binary via the shell to get the dynamic linker to read auxv for you as a side effect...
I think looking in /proc/cpuinfo is the sensible approach at the command-line.
For scripts, it's a bit more esoteric: will grepping cpuinfo introduce more flakiness into the script than is there already? Usually, the answer is "no".
---Dave
On Tue, Sep 06, 2011 at 10:09:19AM -0500, Andy Doan wrote:
On 09/05/2011 11:35 AM, Christian Robottom Reis wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
Great! But I meant for the page to be something a bit more general than just NEON -- that's an easy mod to that page if you
a. Rename it to something like /HowTo/DeterminingCPUFeatures /HowTo/CPUFeatures /HowTo/DetectingARMFeatures
b. Have a subsection with a "NEON Detection Code" heading with the code you've included.
Consider also David/Dave's thread about CPU ID detection; does that fit into a more general page?
On 09/06/2011 12:37 PM, Christian Robottom Reis wrote:
On Tue, Sep 06, 2011 at 10:09:19AM -0500, Andy Doan wrote:
On 09/05/2011 11:35 AM, Christian Robottom Reis wrote:
On Sat, Sep 03, 2011 at 09:10:58PM +0800, Jim Huang wrote:
2011/9/3 Tom Gall tom.gall@linaro.org:
Is a method via the aux vectors to know at runtime if neon is or is not present?
hi Tom,
Did you mean this? https://bugs.meego.com/show_bug.cgi?id=12448
The recipe in step #1 is probably a good candidate for a FAQ on "How do I tell what features the ARM CPU on my device has?".
Great! But I meant for the page to be something a bit more general than just NEON -- that's an easy mod to that page if you
a. Rename it to something like /HowTo/DeterminingCPUFeatures /HowTo/CPUFeatures /HowTo/DetectingARMFeatures
Good thinking. I choose the "/HowTo/DeterminingCPUFeatures" title.
b. Have a subsection with a "NEON Detection Code" heading with the code you've included.Consider also David/Dave's thread about CPU ID detection; does that fit into a more general page?
That part of the thread hasn't really come to a conclusion on the approach. If its something using auxiliary vectors, then I think the answer is same page. If not, then something more general would probably be needed.
-andy
On Tue, Sep 06, 2011 at 02:39:21PM -0500, Andy Doan wrote:
b. Have a subsection with a "NEON Detection Code" heading with the code you've included.Consider also David/Dave's thread about CPU ID detection; does that fit into a more general page?
That part of the thread hasn't really come to a conclusion on the approach. If its something using auxiliary vectors, then I think the answer is same page. If not, then something more general would probably be needed.
I think for the toolchain team they would want something that specifically tells them what the CPU implementation is (i.e. A8, A9 or one of the architectural licensee variants such as Qualcomm Scorpion, etc).
-
Andy Doan -
Christian Robottom Reis -
Dave Martin -
David Gilbert -
Jim Huang -
Kurt Taylor -
Mans Rullgard -
Peter Maydell -
Tom Gall