I'm computing the Fourier transform of a 2^18 samples vector using the FFT included in Ne10 ARM library and it doesn't seem to work. It produces a Sigsev error on the Android Studio. The funny thing is that a 512 samples FFT works well. My questions are:
Is there a limitation on the maximum amount of samples I can compute the fft on with this library?:
I'm using:
fftPlan = ne10_fft_alloc_c2c_float32_neon(fftSize);
fftIn = (ne10_fft_cpx_float32_t*)NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));
fftOut = (ne10_fft_cpx_float32_t*)NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));
Are these memory allocating functions thread safe? (I've tested and they seem to)
Leaving out their own FFT benchmark comparisons. Is there any other 3rd party site where I can compare its performance with fftw?
The library produces a "text relocations warning" when I use NDK10e for building the native shared library loaded from my android app, which when using ndk13 produces the following error :
D:/AndroidDevelop/android-ndk-r13/build//../toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: warning: shared library text segment is not shareable
D:/AndroidDevelop/android-ndk-r13/build//../toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: error: treating warnings as errors clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)
Related
I am trying to use TensorFlow Lite with GPU delegate on Android. I am using the lib version (.so files) built from sources from the master branch of the repo. The problem is: the ModifyGraphWithDelegate function always returns error. And there is the following error message in logs:
2019-04-22 15:21:16.212 688-688/com.my.app E/tflite: TfLiteGpuDelegate Prepare: Shader compilation failed: ERROR: 0:6: 'unknown' : not a legal layout qualifier id
ERROR: 0:6: 'unknown' : Syntax error: syntax error
INTERNAL ERROR: no main() function!
ERROR: 2 compilation errors. No code generated.
2019-04-22 15:21:16.212 688-688/com.my.app E/tflite: Node number 54 (TfLiteGpuDelegate) failed to prepare.
If I use JAVA/JNI prebuilt lib version ('org.tensorflow:tensorflow-lite:0.0.0-gpu-experimental') like in official example project - there are no such errors. But I really need to use C++ interface for my cross-platform code.
Any thoughts / suggestions appreciated.
If you're building native shared library then you might need to manually load the .so library.
See https://groups.google.com/a/tensorflow.org/forum/#!topic/tflite/5YhFsCFtKi4
I finally made it work. The internal reason of the error is still completely unknown for me but the point is:
The used (master branch) version of the TFLite GPU delegate for Android fails to properly prepare for running on GPU the standard (for regression task) output nodes combination = flatten + dense.
If replace it with reshape + convolution (pointwise) + squeeze, then it works fine.
I'm trying to compile using Linaro 6 and I'm receiving this error which I believe have something do do with GCC 6? I'm very amateur with compiling kernels or coding for that matter, but I couldn't figure this out even search similar terms:
CC drivers/iommu/msm_iommu-v1.o
In file included from include/linux/io.h:22:0,
from drivers/iommu/msm_iommu-v1.c:20:
drivers/iommu/msm_iommu-v1.c: In function '__program_context':
drivers/iommu/msm_iommu_hw-v1.h:78:31: warning: result of '16777215 << 14' requires 39 bits to represent, but 'int' only has 32 bits [-Wshift-overflow=]
error, forbidden warning: msm_iommu_hw-v1.h:78
scripts/Makefile.build:308: recipe for target 'drivers/iommu/msm_iommu-v1.o' failed
this is my GitHUB:
https://github.com/mykesorrel/surnia_kernel
Looks like a bug with that iommu driver. It's trying to do a bit-shift into an int instead of a long, an int doesn't have enough bits to complete the operation. I'm guessing the -Wno-error isn't used, so all warnings are treated as errors.
This question will help you: How to compile without warnings being treated as errors?
What I personally do is update CFLAGS in my .bashrc (Assuming you're using Linux). This is what I use:
# Ensure C builds don't fail on warnings
export CFLAGS="-Wno-error"
export CXXFLAGS="-Wno-error"
I am porting to SDL2 and the Android platform a C++ game that uses SDL 1.2. Everything went well so far except for one thing: when I try to access the fields of SDL_Window, the compiler tells me
error: invalid use of incomplete type 'SDL_Window {aka struct SDL_Window}'
I think my installation of SDL may be faulty. I have compiled SDL 2.0.0 from the source found on libsdl.org using the folloing command:
ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APP_PLATFORM=android-18
Then, I have copied the freshly built libSDL2.so into $ANDROID_TOOLCHAIN/sysroot/usr/lib and the files in the include/ directory in $ANDROID_TOOLCHAIN/sysroot/usr/include/SDL. These files are given to CMake and referenced by the game's code. I managed to convert every SDL calls and now I am stuck with this SDL_Window problem.
I did a quick search in SDL's source code and found that SDL.h includes SDL_video.h which contains a typedef SDL_Window on struct SDL_Window. Then I searched for this struct and did not find anything except in the original source archive, in a file named src/video/SDL_sysvideo.h. Since it is not a file of the API, I doubt I have to include it in my code.
So, how to find a definition of SDL_Window in SDL2, for Android (if this is relevant)?
It appears that the problem is a lack of knowledge of SDL 2's API. Let's remember that one does not access the fields of struct SDL_Window: there are functions to get the size and the flags of the window, such as SDL_GetWindowFlags and SDL_GetWindowSize.
So the problem is absolutely not related to the installation of the SDL or to Android builds. Sorry for the waste of time, people of the Web.
I would expect that you are expected to only deal in pointers to SDL_Window objects, and not actually put a full SDL_Window object on the stack.
I have problems with using NEON intrinsics and inline assembly in Android NDK.
NEON types like float32x4_t give an "invalid arguments" error when compiling C++ code with GCC 4.6 and 4.8, however, the code compiles fine if compiled as C.
For example, here's some code:
inline float32x4_t VectorAdd(float32x4_t a, float32x4_t b)
{
return vaddq_f32(a, b);
}
I get two errors here:
In the function itself: Invalid arguments ' Candidates are: ? vaddq_f32(?, ?) '.
Where the function is called: Invalid arguments ' Candidates are: ? VectorAdd(?, ?) '.
All NEON types are displayed as ? in the error message, while non-NEON types are displayed correctly.
What is also strange is that functions which only use NEON types as return values (for example, vld1q_f32 and my abstract wrapper of it) don't suffer from the error.
I tried the same code in GCC Explorer 4.6 and 4.5, and there is no error, and correct and optimized assembly is generated, however, it doesn't work with Android NDK.
As a workaround, in Window / Preferences / C/C++ / Code Analysis, set the Severity of "Invalid Arguments" errors to Warning, so that these bogus errors won't prevent launching the application.
i need to use a classifier J48 in android. But running into heapspace problems. Is there a way to fix the same? I get an error that states. Dalvik format failed: Failed to convert dex. PermGen space.
So you have a memory problem using J48 in Weka on android.
I would try to diagnose this in the following order:
How much memory does your program consume? See here and here for Weka memory consumption.
Add more memory to the JVM (also in the earlier links).
Try running this on a more affluent JVM - can this run on a desktop? Or is the problem unrelated to the OS resources?
Tune your algorithm - build a smaller tree or prune it more heavily.
Prune your dataset - remove unnecessary attributes.
Prune your dataset - use fewer instances.
Use a different algorithm.
If all else fails - implement your decision tree using a different library (scipy/Orange/KNIME/Rapid miner), or roll your own.