thnets
thnets copied to clipboard
mvitez
thnets on Android
According to @culurciello, it should be easy to build this to run on Android.
Any document/example as to how it could be done? Could it be really as easy as setting $CC to my android gcc?
Thanks.
No. You have to give the right options to gcc, the best thing is to set up the Android.mk and Application.mk, so the NDK will set the proper options. In Android.mk I've added LOCAL_CFLAGS += -c -fopenmp -fPIC -DARM -D__NEON__ -mcpu=cortex-a9 -mfpu=neon -O3, in Application.mk add APP_ABI := armeabi-v7a-hard APP_CFLAGS += -fopenmp APP_LDFLAGS += -fopenmp.
I am interested in that too, and am waiting for a concrete working example for Android before starting actual work with it.
Thanks
On 11-02-16 9:22 AM, yonadavs wrote:
According to @culurciello https://github.com/culurciello, it should be easy to build this to run on Android. Any document/example as to how it could be done? Could it be really as easy as setting |$CC| to my android gcc? Thanks.
@mvitez, thanks for the swift reply!
Just trying to catch up on your meaning:
I add all the source files to a project under /jni/, add them to Android.mk inLOCAL_SRC_FILES`, then add what you mentioned to Android.mk & Application.mk, then build it as a separate library? or inside my own .so?
I recently had some more time to invest on building Thnets for android, and I'm still unable to do it.
It builds fine, but when running it, it crashes at sgemm.c blas_init() at line:
saa[i] = malloc(BUFFER_SIZE);, on the first loop pass.
It crashes when I set buffer size to , and when I use a different pointer, so it definitely isn't an OOM issue.
The issue was with the redefinition of malloc to debug_malloc, where fopen is used but fopen isn't available in Android. Funny thing is, it should only be defined if MEMORYDEBUG is defined, which I haven't done, but it still defines it...
Excellent. I was about to start checking on Android now, good that you solved it. memory.h and memory.c should not be included at all if MEMORYDEBUG is not defined.
I'm now running into another problem calling THProcessFloat. Chasing it down, I found it crashes inside sgemm_kernel in sgemm_kernel_4x4_vfpv3.S. Due to my limited Assembly talent, I'm going to assume the problem is in the input I give to THProcessFloat..
for reference, I used it like this:
float *result; int outwidth, outheight, n; n = THProcessFloat(net, encoded, 1, 231, 231, &result), &outwidth, &outheight);
(231 is the size from this example using this NN)
I guess the net parameter is fine, as the init completed, and THLastError returns 0. Any pointers to what might be wrong?
I wouldn't know. sgemm_kernel_4x4_vfpv3.S reads from internal buffers and writes to the output buffer, all are allocated by thnets, so it appears to be some problem internal to thnets. I will try to compile it for Android by myself and see.
I've tried now that network with a 231x231 image on a Nexus 5 and the test succeeded. But I've tried it from ssh in a pure C application. I've added some instructions at the end of the readme if you want to try in this way.
Well, since my app is both Java and C, I tried making it work this way. I've put some time into it, but it still crashes mid sgemm_kernel with a signal 11..
I am sorry, but I don't know how I could help from here. I have tested this library on the devices that I have and this problem does not appear on my devices.
I also have the same problem as yonadavs with sgemm_kernel. The app crashes with a signal 11. yonadavs, did you find the solution?
Currently I don't have any evidence of this, but try to increase the buffer size in https://github.com/mvitez/thnets/blob/master/OpenBLAS-stripped/sgemm.c#L78, e.g. multiply it by 2 or 4.
after some investigation, I have found the program crash at spatialconvolutionMM when call kernal operation. @mvitez have u run android test on other mobile device ? I wonder whether this is devices dependent problem.
Unfortunately I only have a Nexus 5 and it's there where I tested. And it does not crash there.
@mvitez I have used the whole version of openblas build for android with USE_THREAD=0, it worked without crash
Sure, of course, there is some problem in my integration of OpenBLAS. Have you tried my suggestion given in the comment of July 12th? And using the option -a 1?
@mvitez I tried but still with option -a 2, I will try again. Thanks a lot.
@yonadavs and @austingg are you maybe using APP_ABI := armeabi-v7a inside Application.mk? I've seen that armeabi-v7a-hard is not supported anymore in the NDK. If you used armeabi-v7a, it could not work and it crashed. I've just pushed a small fix to work with armeabi-v7a.
@mvitez yes, I used armeabi-v7a, since newer NDK complains armeabi-v7a-hard, thanks a lot.