We've been trying to get a port of mkxp to android. It uses SDL 2 and opengl es 2. The game works perfectly on Mali GPUs, but doesn't work as expected on PowerVR and is completely broken on Adreno. Is there any work around? Is it, for example, possible to completely bypass hardware acceleration and use software rendering, because some parts (eg the backgrounds etc.) work on all devices. I'm a beginner, so please don't mind any foolish question :)
Related
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?).
I am profiling a JNI Android Application . So far I managed to profile it with Android-NDK-profiler. It is very simple so I want to go further and get info of the hardware too, like cache misses, bus speed etc.
I have read that the NVidia Tegra profiler is very powerfull but there is not much info about the devices that support it. I know that it needs Tegra 4, and that for example this device supports it: http://shield.nvidia.com/.
The problem is thta it has no camara integrated so it is not valid for me.
Has anybody tried any device like a mobile or tablet that is compatible with Nvidia Tegra profiler??
normally any Tegra4 and K1 based device should work, but I would recommend the Shield/Note from Nvidia for your work, not only are they quit cheap, but their android is left very much vanilla (aside from some stylus things on the note) which makes it easier to work with.
There is also the advantage (so far) of a "usable" update policy.
I have spent a few dozen man hours searching Google and asking questions on forums trying to figure out whether or not my OpenGL ES 2.0 application on Android is lagging due to errors on my end, a virus on my device, OpenGL implementation on Android, or OpenGL implementation on the Samsung Galaxy Express.
I have found nothing, if anyone wants to try answer that root issue I would greatly appreciate it, but my question is if I should revert back to OpenGL ES 1.0 and if that is what everyone else uses.
The exact same application (single spinning triangle) using the exact same timestep with the only difference being a barebones OpenGL ES 1.0 vs OpenGL ES 2.0 change causes stuttering in the 2.0 app and smooth animation in the 1.0 app.
Do other games only use 1.0? If they use 2.0 can you point me to an example that is known to cause no noticeable stuttering, that I may download and test on my device? I have downloaded the OpenGL ES 2.0 sample from Google themselves, stutters the same.
Does Samsung Galaxy Express not handle OpenGL ES 2.0 gracefully? Is there any way to get another Android device without stealing or asking random strangers, I have no money.
Thank you.
Thing is that OpenGL ( not just ES ) is a specification, the other part the implementation is not governed by anyone, well by the specification to a certain extent meaning that the implementations can differ greatly altho they shouldn't.
This is due to the fact that OpenGL uses client drivers to handle the commands and those are written by the GPU creators ( usually ). For PCs you can easily name all the prominent GPU builders, nVidia and ATI so there you can at least know what to expect.
For phones there are lots of GPU/CPU combos so more errors to be discovered due to faulty or wrong form the start designs, not just the GPU's drivers, since the phone's creator may also make changes to the system or use low speed/grad parts which will result in poor performance.
OpenGL ES 1.0 I would say is more common since 2.0, mainly because it's backwards compatible so a device that supports 2.0 will most certainly support 1.0 as well. For development you can skip the whole "build on phone" thing by making a framework and using an emulator ( OpenGL ES ) on PC and when you are done just copy over your OpenGL code into your phone app.
Since manufactures try to keep their costs low, they tend to lie about what they actually do, or support so ES 1.0 being more simple and hard-wired than 2.0 it is possible that the lag may be due to the poorly supported OpenGL.
According to the latest Android Platform Dashboards, Open GL 2.0 makes up 98.3% of devices that visited the Play Store in the last 7 days, making it the standard for game development.
I have noticed a lot of people seem to have trouble with the OpenGL ES drivers for Samsung Android devices. You should try another device with a different graphics core.
Since Ice Cream Sandwich, the Android platform itself mostly uses OpenGL ES 2.0, including major components, such as the SurfaceFlinger. It's not optional anymore. Check out this article.
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.
I'm trying to chose the ARM development board for education purpose.
The goal is to learn how to run and play around with systems like Android (version 2.0 or higher),Linux, Windows CE. It must support touch-screen, Ethernet, USB host and device.
I've found many boards, the most interesting is Android6410. I've search Google and it seems that it is not very popular. Has anyone used it? Is it well documented? What about the support? How about the performance under Android?
I've also found some other development boards:
http://www.friendlyarm.net/products/mini2440?lang=en - the most popular one but probably it is too slow for android 2.0.
http://www.friendlyarm.net/products/mini6410?lang=en - the same CPU like Android6410 but it seems to be a new product so the support may be pretty bad
http://beagleboard.org/ - quite interesting and popular but no touch-screen in standard version. The external ones are very expensive (twice as expensive as the board itself)
http://pandaboard.org/ - very fast but also doesn't have standard touch-screen connector, no Windows CE support
Any hints will be appreciated.
Samsung has provided an android kernel, as well as a reasonably current "generic" linux kernel) that, amongst other Samsung SoCs, also supports the 6410. The Git repos are here:
https://android.googlesource.com/kernel/samsung
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
These do provide smdk6410 defconfig targets.
You also need an odroid bootloader (uboot for 6410) to be able to flash new kernels onto the board and/or the SDcard it boots from, as Samsung uses a special "fastboot" utility for this purpose (very different from OMAP which just puts the kernel into a file).
I can't comment on the performance of the device compared to others, as I haven't run extensive benchmark tests or anything, sorry. You're right, it's way ahead of 2440; it's an ARM1136 CPU, so it'll end up somewhat slower than the Cortex-A chips from omap3/4 boards.
Try the FL6410: http://www.arm9board.net/sel/prddetail.aspx?id=363&pid=200
A nice board with great Android support!