Well there are many tutorials and post about this, but I am not getting exactly how to deal with libOpenCL.so file. Many vendors does not include it inside phone, but my app needs to support maximum available phones today, so do I need to get compatible libOpenCL.so file for each of them?
OpenCL is not officially supported by Android Open Source Project
See: Why did Google choose RenderScript instead of OpenCL
However it appears that Device Manufacturers are including support by adding in the driver.
See: Does Android support OpenCL?
Realize that OpenCL is at a similar layer in the hardware stack as the graphics driver and any particular implementation will depend on the manufacturer and would be specific to that device. You can't just take a libOpenCL.so from one ARM64 device and expect to work for another due to system-on-a-chip specific customizations (number of cores, DSPs, GPUs etc.)
My recommendation from: C++, OpenCV and "what" for cross-platform GPU programing
If you want maximum support - stick to C/C++ code.
If you need OpenCL to make your app performant even with parallelized code, your option is to check if the library is there and warn the user about the lack of support. Ideally then fall back to the parallelized code on those devices without OpenCL.
Until Google makes OpenCL part of the Android Compatibility Definition Document and requires some metadata property, only by the app checking on the device can the app know that OpenCL is even available.
Adding to the answer of #Morrison Chang:
You can not rely on all version of OpenCL in all devices to have everything supported. So I would do a dinamic library loading, and query at runtime for the OpenCL methods are available.
Regarding the library with OpenCL support, sometimes is not even called like that. For example libGLESmali.so has OpenCL symbols and can be used directly.
Related
I am using Marmalde and C/C++ to write an game for android.
Now I eant to write some important parts in assembler to improve the performance.
But I am wondering me whether this app could run on the most android devices? (about 90%)
Because in general assembler code depends on the processor and different android phones may have different processors, for example Intel or ARM, so I would have to write these parts in different assembler languages for every different processor!?
Yes, of course you will have to write the assembly code for every processor ABI.
The Android NDK has specific support for different ABIs.
Keep in mind that, while there are currently only three processor families supported (Intel x86/64, ARM and MIPS) you have to target all the different ABIs not the processors families themselves.
You can drop MIPS devices safely, they are very rare.
Intel devices are mostly tablet, but there are some phone too.
The vast majority of devices out there is ARM.
If you look at an official optimization guide from ARM v8 or at a very useful optimization guide for Intel you can see that it actually will take some time to write good assembly code, it's not just about making something work (which you should already be able to do easily).
Hint
Write first the critical parts in C++, then look at the disassembly and see if you can do better or if you can recognize some sub-optimal patterns.
Only then rewrite the code in assembly.
Also before doing such micro-optimizations, try to use better data structures, better algorithms and better resource handling.
Is Way To Run Machine Code Instead Android OS In Android Devices ?
I Want Remove Android Os And Work With Cpu And Other Devices Directly .
What Compiler I Can Use ?
MASM is an x86 assembler, so it would not be suitable for most Android devices as the vast majority use ARM-based processors.
That said, Android phones are computers just like any other and can be programmed in assembly. The first thing you'll need to do is select a device running a well documented CPU and chipset.
Since you'll be removing Android and plan on programming in assembly you'll need to write your own routines for nearly everything. An understanding of the CPU, power management and some form of I/O (you can avoid having to write complex display code if you plan to interface with the phone through serial communication, for example).
Unfortunately, much of the information required for successfully writing your own OS for an Android device is unavailable so you'll need some hardware analysis tools to assist in reverse engineering some of this information. A logic analyzer may be useful in sniffing some of the protocols used between chips, although much of modern phones is done on a single SoC, so you'll need to experiment heavily and compile information from a wide variety of online sources.
Aside from that, it's smooth sailing. Programming an OS in assembly for Android is pretty much the same as programming an OS in assembly for any other computer and you'll find it to be rather familiar territory.
I am programming a native app on Android using Opencv4Android. I am using the Opencv Manager. At the staup of the app, I receive these logs:
But how to know if openCv is really using OpenCl for acceleration or not ?
Unfortunately Google dropped OpenCL support for Android, for quite a while. This was done in favor of RenderScript.
So the first thing to do is to check your OpenCL availability on your platform. You could use OpenCL-Z. The tool will likely tell you if OpenCL runtime is present and if it can use both the GPU and the CPU.
The fact that OpenCV4Android is compiled with OpenCL support means that you can use the OpenCL specific namespaces. So if your platform has OpenCL, and in your code you use OpenCL specific objects (e.g. oclMat) your native code will use OpenCL.
Finally, you cannot be sure what OpenCL device (GPU / CPU) will be used by the OpenCV implementation. You can browse through the source of OpenCV and see the specific implementation for your kernels, or you could use the system profilers that are available for your Android device, and watch for GPU and CPU activity.
Thanks to VAndrei, I am now sure that I was not using OpenCL. I was not using the ocl package. Moreover I then tried the ocl package but I got an error at running at the first ocl code line. Then I checked with OpenCl-z and it seems that OpenCL is not available on the device (Rk3188).
I am quite surprised by the performance of the system (ARM Cortex-A9). For these lines, with a resolution of 160x120 on grayscale:
cv::absdiff(_inputMat, _previousMat, _outputMat);
_inputMat.copyTo(_previousMat);
cv::GaussianBlur(_outputMat, _outputMat, cv::Size(3,3), 2.0, 2.0);
cv::threshold(_outputMat, _outputMat, 100, 255, 0);
the system requires ~1.5ms. That is why I was wondering if OpenCl was used or not. Seems that Rk3288 is supporting OpenCl. I will have to check the improvements on htis other system.
In latest Android releases, the AOSP release typically comes with tinyALSA and tinyCompress. In this question, Simon has mentioned that all Nexus devices shall support tinyALSA.
My question is why is android not integrating libasound which has all features required for an audio sub-system as compared to tinyALSA? Is it mainly due to the licensing issues as indicated in source.android.com site?
I can't speak on the behalf of the Android developers, but if I had to guess it's because ALSA has a very old API that hasn't changed due to backwards compatibility reasons.
If you're choosing an audio system where backwards compatibility isn't a concern, the best thing to do is start with a clean slate and a more modern API.
This is consistent with their approach for X.Org Server - completely throw out the system and replace it with something better although one could argue that this was done because X.Org wasn't built with touch screens in mind.
Lastly as you mentioned, Google recommends tinyALSA over ALSA because of the license.
I am pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)
The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.
Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.
QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform
the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.