Is there a way to use android-nn-driver on existing smartphones? about android-nn-driver HOT 10 CLOSED

Hi @nadongguri it's hard to answer with specifics. I don't know what drivers Samsung include in the S10+, but perhaps you could run an NNAPI benchmark to find out what the performance is of the NNAPI on your phone?

Copying the driver might work, you would also need to run it, and I suspect you would have to root the phone in order to get it working correctly.

from android-nn-driver.

Hi @MatthewARM, thanks for your comment.
I ran the TF-lite sample on the galaxy s10+. This sample app provides a mode to choose which backends to use such as GLES compute, NN-API or CPU. I don't know which nn-api backend this device uses but it seems using CPU.

As you said, I will try to root this device first, then build this driver. :)
And I have one more question. As you pointed out in #4 , is opencl source code required in order to build this driver? Or can I use libOpenCL.so in the target?

from android-nn-driver.

Rooting the phone should really be a last resort as it may make other stuff break...

from android-nn-driver.

Hi @MatthewARM, I agree. I don't want to root the device but there's no way to copy HAL driver to the vendor partition without permission, though..

As you commented in another issue, you tested this driver on hikey 960 and rooted phone right?
I got AOSP source then set lunch as hikey960-userdebug, then followed the installation guide but some issues were coming.

1. vendor/arm/android-nn-driver/Android.mk: error: [email protected]: LOCAL_MODULE_TAGS := eng is obsolete. -> commented that macro, solved

2. vendor/arm/android-nn-driver/Android.mk: error: "[email protected] (EXECUTABLES android-arm) missing libOpenCL (SHARED_LIBRARIES android-arm)"
   -> Is it right to place libOpenCL.so in /prebuilts/vndk/* folder?

from android-nn-driver.

Hi @nadongguri I'm sorry I don't really know the answer to that question, this step is usually performed by a phone vendor when preparing the Android OS for their device. I'm not sure how to make it work for an AOSP community build.
That being said, I would presume that after adding it to a library directory somewhere, you would probably need to declare it from a .mk or a .bp file so that the build file for android-nn-driver knows where to find it. Maybe there is some documentation somewhere in the AOSP project for how to import a prebuilt library?
Yet another alternative is that the Compute Library has the source code to build 'stub' libOpenCL.so that can be used just for linking, then when your program runs on the target device it can use the proper OpenCL from the system. However, in the Android build environment we don't provide a build file for the stub OpenCL, but you could try to add one? The sources would be in clframework/opencl-1.2-stubs

from android-nn-driver.

Hi @MatthewARM, there's no build issue after applying opencl stub in android-nn-driver with platform code pi(9). I'll check the driver and test binary on both a development board(hikey960) and a rooted device(s10+). Thank you for your support.

===========================================

update) As I expected, this seems to be my build setup issue. I will check this at my side.

===========================================
update) Finally I could build arm-android-nn-driver by adding more flags and macros. :)
Can I ask one more thing?
I've used a command 'mm' in that directory then when build is done I got the message as follows.

[100% 498/498] target StaticLib: libarmnn_32 (out/target/product/hikey960/obj_arm/STATIC_LIBRARIES/libarmnn_intermediates/libarmnn.a)

Even though I added "PRODUCT_PACKAGES += [email protected]" in device.mk it seems that line doesn't work.

I could see outputs are in
./vendor/etc/init/[email protected]
./vendor/bin/armnn-tests
./symbols/vendor/bin/armnn-tests
...
./obj/EXECUTABLES/[email protected]_intermediates

I think this issue would be related to my setup or build sequences.. but it will be very helpful if I get a bit of hint.

===========================================

update) I added -fno-addrsig in Android.bp then those errors gone but another error coming with boost compilation.
I'm wondering if OpenCL stub is used so there's no dependency issue to build android arm ann and this driver should be built with hikey960-userdebug config right?

============================================
Hi @MatthewARM, as your guide. I could build libOpenCL.so in android-nn-driver by using opencl-1.2-stubs. Thanks! And then I got some minor errors then these were avoided by adding wno flags in Android.mk but finally I got clang errors as follows. (I added -v option.)

/tmp/AccessWindowAutoPadding-ec7249.s: Assembler messages:
/tmp/AccessWindowAutoPadding-ec7249.s:15825: Error: unknown pseudo-op: `.addrsig'

from android-nn-driver.

Hi @nadongguri sorry for the delay, I somehow missed your last message.

To clarify, are you seeing two problems:

1. "mm" doesn't build [email protected]
   I think this could be due to the PLATFORM_VERSION being too low for neuralnetworks HAL 1.1. Please could you the config options that are displayed when you type "make", e.g.:
   android$ make ============================================ PLATFORM_VERSION_CODENAME=REL PLATFORM_VERSION=9 TARGET_PRODUCT=hikey960 TARGET_BUILD_VARIANT=userdebug TARGET_BUILD_TYPE=release TARGET_ARCH=arm64 TARGET_ARCH_VARIANT=armv8-a
   etc.

2. Error: unknown pseudo-op: `.addrsig'. I've not seen this before, but I suspect it might be because the assembler is too old. My suggestion for this is to try to ask for help from the AOSP developer community, as someone else might have seen something like that.

from android-nn-driver.

Hi @nadongguri

For 2. Error: unknown pseudo-op: `.addrsig' it seems this is because we are using the gnu assembler for Compute Library. The fix is to add "-fno-addrsig" to the compiler options for Compute Library. We'll be fixing this on the master branch soon.

from android-nn-driver.

Hi @MatthewARM, thanks for your comments.
Those errors were due to the wrong PLATFORM_VERSION, honestly... I was using the latest AOSP source so PLATOFRM_VERSION was android q. It made tons of errors. Anyway, I could remove all the errors by adding flags or commenting source code but when I made the PLATFORM_VERSION right then there were no errors during the build.
I think you can close this issue. :)

from android-nn-driver.

Many thanks.

from android-nn-driver.