I am looking for a safe way to detect whether the current GPU belongs to the current high end profile (such as Motorola's Atrix or Galaxy s2) so I can, in run-time, enable some more sophisticated visual effects in my game.
Has anyone successfully done anything similar? I though about detecting dual-core CPU, which would usually come with a good GPU, but I don't have enough devices to test if it is going to work OK on most situations.
Get available processors:
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Runtime.html#availableProcessors()
If those "more sophisticated visual effects" require OpenGL ES extensions, you can simply test for the presence of those extensions.
If they do not, it would probably be better in the long run to simply allow the user to configure their graphics setup. Otherwise, if a new GPU comes out, it won't be on your hard-coded list of GPUs and thus they'll get low-quality graphics.
Android being above a Linux kernel, did you consider reading sequentially and parsing the /proc/cpuinfo file ?
Since I'm making an application not a game, I need to auto configure what is best. For the size of the textures I test for heap size and used heap. Also small textures if running in software mode (PixelFlinger).
If it has good amount of heap free and 2 cpus then I run the 3d engine in OpenGL 2.0 with AA. So far this works great with the amount of devices we have.
Note: I have noticed that some phone roms report 1 cpu free when there is 2.
Related
More specifically, I'm wanting to run OpenCL / Renderscript code in an Android Emulator that actually runs on my computer's GPU instead of CPU. Unluckily I'm using an AMD CPU and GPU.
I know that AMD has OpenGL ES support (and everything supports OpenCL pretty much) via SDKs but that's as far as I've gotten on that front - the only OpenCL / Renderscript information I've found regarding emulators is that they either don't work at all or, if I had an Intel CPU, I could install OpenCL in the emulator but it would only use the CPU (and frankly I wouldn't be surprised if behind the scenes my emulator(s) aren't already doing this - OpenCV runs without incident but OpenCL-Z says there's no OpenCL support).
Is there some way to send the commands from the emulator to my OS and have it automatically run? The only ways I've come up with involve saving and loading a text file which isn't likely to be faster (or good for my hard drive) given I'm running 2 Emulator Instances.
I found some mention of RenderScript being supported in the official emulator but said emulator isn't meant for my use-case and I strongly doubt that it's going to use my GPU.
I'm using Memu at the moment because Bluestacks 3 uses more resources when running 2 instances and the 2nd instance doesn't work very well with adb commands / root for some reason - it thinks it's working but it doesn't do anything. If there's a faster emulator when it comes to running 2 instances I'm sure it would help but oddly enough comparing them is difficult and time consuming (especially when every one of them is like "No, I'M the fastest - look at MY bar graphs!" lol) and ultimately I believe my problem to be with OpenCV not getting GPU acceleration (because it runs much faster on my phone) and not the emulator's base speed.
I have AMD's virtualization features enabled (confirmed with Leomoon or w/e) and they're enabled in the manager for Memu. Perhaps this is already working behind the scenes, then? Either way, emulation costs increase by 10% per instance once the OpenCV stuff comes into play (taking it from 60 to 80%+)
Use a language (like Python) and send commands via ADB. Python can hook into OpenCL and OpenCV; ADB can be used to get the Framebuffer for screenshots or Python can just capture the emulator's window render.
Alternatively, a connection can be made using SocketIO (Flask Socket IO and Javascript's client socket IO in my case) and they can communicate that way. Confirmed via the browser on the emulator and real device. Every emulator has ports to communicate to your native OS. I ultimately chose not to go this route as it's a little convoluted (2 servers, different languages, no better than ADB over LAN) but it's an option. Java (iirc) also runs SocketIO just fine and would likely be a decent option for many devs who are familiar with the language and wish to run some stuff natively on Android Devices.
Feeling physically ill atm and typing on a phone so my apologies for the present lack of examples and assistance. Hopefully I can catch the time to address this but, frankly, there are few use cases for this outside of the one I'm presently targeting and it's quite niche to begin with.
Renderscript is claimed to support "different types of processors such as the CPU, GPU or DSP." Now, probably the most popular DSP these days in the Android world is Hexagon present in Snapdragon SOCs. Can Renderscript code be made to run on Hexagon at all? If so, how to do it and what are the limitations?
UPDATE
regarding my hitherto investigation of the issue - there is no documentation nor examples available, so reverse engineering Qualcomm drivers seems like logical next step. For obvious reasons, I thought I'd ask first.
You can't force RenderScript to run on any particular processor, so there is really nothing you can do here (unless you are going to write a Hexagon compiler + driver). As far as the existence of a Hexagon driver/compiler, none of the Nexus devices currently ship with Hexagon support for RenderScript, although each of them does have GPU support for RenderScript.
How RenderScript split a kernel across multiple devices? Is always equals to the devices? (i.e. In nexus 5 execute 1/2 on CPU and 1/2 on GPU?).
We have created a game in Unity and are currently testing on various devices.
Some devices as you'd expect perform better than others, but we are surprised by our testing on iPad 3 and iPhone 4, which we'd have thought would cope better. (simple movements of objects appear quite jittery)
With regards to troubleshooting we have placed a frame rate readout on the screen and we can see that this is very erratic (a target of 60fps can flick anywhere between 24 and 60 seemingly randomly), but I was wondering what other performance diagnostics can be done. Are there plugins that can give readouts/log performance as the game plays that could point to specific events or graphics that cause it all to struggle?
Any other ideas would be much appreciated.
Thanks in advance
Profile
Unity has some excellent tools to enable you to profile your code while it is running, both in the editor and on devices.
This generally involves:
Connecting your device to the same wifi network as your development machine, or plugging it in via USB cable
Selecting "Dev Build" and "Autoconnect Profiler" when you build your project
Opening the profiling window in Unity.
I would suggest that before you try profiling your application on your tablets, you try profiling it in the editor. This will give you an idea of how to best use the profiler, and you may realise what parts of code you can optimise before even running it on your device.
Profiler: http://docs.unity3d.com/Manual/Profiler.html
Read up on optimisation
Not so much an answer to your question, but read up on various performance gotchas. You don't want to prematurely optimise, but there are certain practices you need to be aware of when developing for mobile devices, keeping your shaders simple, reducing draw-calls, dynamic batching etc.
Various notes on optimisations:
http://answers.unity3d.com/questions/37293/general-ways-to-optimize-frame-rate.html
http://www.paladinstudios.com/2012/07/30/4-ways-to-increase-performance-of-your-unity-game/
I'm making an Android game and the performance difference between single core phones such as Galaxy S and dual-core Galaxy S2 is comparable to night and day. Thus instead of making different versions for single cores and dual/quad-cores, I thought about using the processor count of the device to turn off and on certain graphical features.
But how reliable is getting the processor count? Do some single core phones have threading like Intel Hyperthreading which shows one core as two? Or are some dual-core phones a lot slower than the Galaxy S2?
While I recognize your good intentions behind the idea of checking for cores and automatically adjusting settings, so the user doesn't have to adjust settings themselves & to improve performance, it won't work in practice.
This is because there are too many devices and corner cases to cover. For example:
Some multi-core devices will have core parking and might not be detected by whatever core detection you use.
Some single-core devices may or may not have hyperthreading, but won't display as multiple cores.
If the user has their phone on power-save mode, you'll still detect multiple cores, but not recognize that they're running at limited capacity.
I'm sure many other examples exist. The point is, it would probably be a nightmare for you to cover most/all of these cases in order to automatically adjust your app's settings, especially given a relatively simpler solution: ask the user what settings they want at the app's launch, and make it easy to adjust these settings at any time.
Sometimes it's better to just put a burden on the user's lap, especially if it takes little to no effort for them to do it, and proportionally waaay more effort for the developer to do it. Good luck!
Graphic effects should be drawn by GPU, not CPU.
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.