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.
Related
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.
Is there much difference (in terms of performance) between two ARM SoCs that have the same core?
e.g., What differences (aside from those that can be attributed to the different clock rates) could be expected between:
Apple A5, based on 1GHz dual-core ARM Cortex-A9
Samsung Exynos GT-I9100, based on 1.2 GHz dual-core ARM Cortex-A9
Are some ARM SoCs with the same core better than others? (if so, why?)
The cores have rev numbers and that plays a roll. And sometimes you can get them with say a 32 bit AXI interface or a 64 bit AXI interface and that plays a big role in performance. Also, certainly with a Cortex-A you probably want to add an L2 cache, and that will sit between the core and stuff costing you some clocks. there are add on items to the core like the L2 that I assume you are not required to buy.
Yes, you can see differences between vendors that have bought the same core. the core itself will likely perform very much like its family members or namesake. Understand that ARM stops at the edge of the core or the cache or other ARM add ons. the chip vendor has to turn that AXI or AMBA bus into something inside and in a case like a Cortex-A likely outside the chip (DRAM for system memory for example). And that will vary from chip vendor to chip vendor and can vary dramatically. If the chip supports DDR DRAM for example they probably bought a IP from yet another vendor to implement the DDR interface and each chip and chip vendor is free to chose whatever ip they want to plant in their chip.
If you stay in the core say L1 and L2 memory systems if it has an L2 you will probably see similar but not necessarily exact performance (assuming you ran your two examples at the same clock frequency), once it goes outside the arm into the rest of the chip all bets are off I would expect noticeable performance differences. Depending on the interface one chip would win one performance contest, then change to another interface and the other chip might do much better.
The term better core is a loaded question. You have to decide what you think is meant by "better". One might have a good mixture of I/O that is fast the other might have nice on chip stuff but have horrible external interfaces. One might provide a real network interface another might just give you usb and you have to turn that into network, storage, video, etc. That part of your question cannot be answered by anyone else but you. if you had a very detailed requirements spec for your product then sure, the community could converge on an opinion but depending on your requirements and similarities in features of the contest might result in a tie.
I have no idea what your project/goals are but if you are going to need to push then envelope you should buy or build eval boards for each of the contestants and put your application on all of them and see what happens. The only performance benchmark that matters is how fast YOUR application runs on something not some other application.
Snapdragon is especially different here. Qualcomm didn't license the architecture, but only the instruction set from ARM just to remain binary compatible with others.
They claim it to be more like A9 than A8, but Snapdragon unfortunately belongs rather to the worse ones among major Coretex-A SoCs.
Note that Apple's A series and Samsung's Hummingbird/Exynos are overall the top performing ones in this league.
So, if you are doing some benchmarking on an iPhone with your optimized routines, beware that it will most probably perform not that great on other platforms with different SoCs. The difference might be marginal or significant, depending on the nature of the benchmarking algorithms.
Besides, most MMU related instructions like PLD/PLI have been optional all the time along, I don't know this for sure with the ARMv7 though.
cheers
I am almost done with my app..when i run it on the emulator ,at certain points,
it is very slow and what i see is undesirable..when I run the same on my phone (xperia X8)
it works fine.
I really tried understanding why this is happening but of no avail!
What should I do now? run some more tests and try optimizing or just
release it in the market?
Is what I am seeing expected? Any info will be appreciated
You really should buy as many Android phones as you can. You definitely should have one with a physical keyboard, one slate phone, and one for the lowest API you are supporting. Personally, I have G1, Droid, and Nexus S that I test my apps on. Its so much faster than the emulator and easier to use. Its also a better metric of how your app works due to it being on actual hardware.
The emulator will always be slower than a real device (most likely, slower than any real device), so don't worry too much about it.
However, due to it's slowness, it can highlight areas where you may want to spend some time optimising your code that you may not necessarily find on your hardware. This is especially true on portable devices with limited CPU power, resources, and electrical power available.
It may be worth trying to find out what is causing the slowdowns in the emulator - if it's regular enough and accompanied by (for example) high CPU usage, then while a physical device may handle it better, you may find that you are unnecessarily consuming battery power and your users may not thank you for that.
The emulator is generally much slower than a physical device, so it's not a problem with your application. As long as it runs well on your phone it should be fine.
I agree with everything dbaugh said. At least at the time of this writing, the emulator is of limited use. Google has acknowledged the limitations of the current emulator and indicated they are working to revamp it. But until that happens. Stick to hardware testing.
There are many low-end Android devices that have really miserable OpenGL performance, like the HTC Wildfire. How can I figure out what percentage of the users has such devices with bad OpenGL performance?
These two links should help:
Android screens and densities
Android Platform Versions
Usually, those with older versions of android (1.x) and small screen sizes are the ones with low-end hardware.
You can't figure that out, unless you have accurate statistics.
I'm recommending (instead of trusting statistics) that you should have a target device as your goal when you're developing. For example -> G1, Hero, Nexus One, Nexus S etc...
Make your application work on the target device and after that you can continue building on your application based on its behaviour from your target device.
Think of android game development like PC game development. If the user's device is slower than the device you developed for, make sure you have a settings implementation that allows them to reduce the quality of the game.
Creating a little benchmark would help too, just run the camera through a typical scenario in the game and assess the fps at the end to decide on quality.
It doesn't even need to be that complex, just 3 levels of quality maybe, based on lighting/textures: low, medium, high.
Looking for write once deploy across multiple platforms, is there such a thing? Also looking for an tools that would help speed up mobile development, OSX/Linux based preferred.
No, there really isn't such a thing. There are some tools that are out or upcoming (Unity3D, Flash CS5, MonoTouch, etc) that allow you to share substantial amounts of code between mobile platforms, but if you want to write once and deploy you will end up with a pretty poor app.
The big issue is the devices are wildly different. Some have accelerometers, some don't. Some have hard keyboard, some have soft keyboard, some are multitouch capable, some are not. They range for 64MB to 256MB of ram, their CPUs vary wildly, and their screen sizes and resolutions are highly variable. The interface you design for multitouch with a 480x320 screen is completely differen than what you design for a pressure sensitive (stylus) based device with a 320x240 screen.
Even if you are only looking at Android you really need to tune your interface for many different devices (on iPhone it is a bit simpler because there are only a few different devices and their capabilities/features are fairly similiar).