search

ARM-software / android-nn-driver

MIT License
151 stars 60 forks source link

Is there a way to use android-nn-driver on existing smartphones? #6

Closed nadongguri closed 5 years ago

nadongguri commented 5 years ago

Hi ARM-software,

I have a question about ARM HAL driver (android.hardware.neuralnetworks@1.1-service-armnn). (I am new to the Android build system. So my question would be trivial.) I refered to #2 and #4.

I have a galaxy s10+ device and I'd like to run tf-lite with ARM GPU by using android-nn-api path. In order to accelerate ARM GPU by using android-nn-api on smart phones, do I have to build this android-nn-driver in manual? (Isn't there prebuilt android-nn-driver?) I'm also wondering it's possible to copy this driver(android.hardware.neuralnetworks@1.1-service-armnn) to the existing target without flashing full image.

Regards, Dongjin.

MatthewARM commented 5 years ago

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.

nadongguri commented 5 years ago

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?

MatthewARM commented 5 years ago

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

nadongguri commented 5 years ago

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: libarmnn-driver@1.0: LOCAL_MODULE_TAGS := eng is obsolete. -> commented that macro, solved

  2. vendor/arm/android-nn-driver/Android.mk: error: "android.hardware.neuralnetworks@1.0-service-armnn (EXECUTABLES android-arm) missing libOpenCL (SHARED_LIBRARIES android-arm)" -> Is it right to place libOpenCL.so in /prebuilts/vndk/* folder?

MatthewARM commented 5 years ago

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

nadongguri commented 5 years ago

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 += android.hardware.neuralnetworks@1.1-service-armnn" in device.mk it seems that line doesn't work.

I could see outputs are in ./vendor/etc/init/android.hardware.neuralnetworks@1.0-service-armnn.rc ./vendor/bin/armnn-tests ./symbols/vendor/bin/armnn-tests ... ./obj/EXECUTABLES/android.hardware.neuralnetworks@1.0-service-armnn_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'

MatthewARM commented 5 years ago

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

To clarify, are you seeing two problems:

  1. "mm" doesn't build android.hardware.neuralnetworks@1.1-service-armnn 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.

MatthewARM commented 5 years ago

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.

nadongguri commented 5 years ago

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. :)

MatthewARM commented 5 years ago

Many thanks.