I'm using a series of shaders to perform realtime image processing on the iPhone (3GS/4/iPad). The fps isn't what I'd like it to be.
Are there any tools that I can use to help me work out what the bottlenecks are?
I assume you already know that performance tests on the Simulator are worthless and that you're testing on real metal, so Instruments is always a good place to start - specifically in your case you'd be interested in the OpenGL ES and OpenGL ES Analyzer instruments.
Generally speaking for GLSL, there's a list of common GLSL mistakes at the OpenGL.org site. The O'Reilly labs "iPhone 3D Programming" book has some further hints, such as avoiding expensive operations in conditionals, and watching for texture lookups.
Also, it's going to depend on what kind of image processing you're doing; if you're trying to apply heavy Photoshop-esqe filters that would give a quad-core pause to render, it's going to be costly on a lowly phone.
The only currently available tool is the PVRUniSCo editor, which will give you a cycle count for each line of code in your shader (though only on Windows, it seems).
Related
Can anyone tell me if there is a limit to the maximum number of OpenGL ES calls that can be made on iPad (i.e. OpenGL draw calls and state changes)?
I am working on a game and seeing low FPS, so I wonder if it has any thing to with my large number of OpenGL calls.
There's no real maximum for OpenGL ES commands, but each one does have some overhead associated with it. Redundant state changes should be eliminated, and expensive state changes should be reduced by grouping geometry in ways that everything using one state is drawn, then the next. Apple has some recommendations for this in their OpenGL ES Programming Guide for iOS.
However, I've rarely found the OpenGL ES commands to be the cause of significant performance degradation in my applications. The larger problems tend to be due to the size of your geometry or from the complexity of any shaders or other effects you apply to your scene. I share some tips that I've applied for reducing geometry size here, and one tool for profiling shaders here, but I'm still learning the ins-and-outs of shader tuning myself.
If you do really care about fine-tuning the OpenGL calls you're making, the best profiling tool to use is the new OpenGL ES Analyzer instrument that comes with Xcode 4. I show a couple of example screens from that instrument in my answer here, where I used it to identify some redundant settings. It will find these calls for you, and point out where they are in your code. You can also use Time Profiler to see if you're putting more load on the CPU than you should be when rendering your frames, and track down the offending lines of code.
As far as I know, there is no such limit as maximum number of glCalls. But definitely, the more the number of gl calls, time taken would be more. Batched rendering is one of the main optimizations that has to be made with OpenGL.
Instead of suspecting the bottleneck, use Instruments to locate it.
Trace Template OpenGL ES Analysis is the weapon of choice. Last time I used it, you had to manually attach it to a running process on the device (all other startup options failed).
We are developing an iphone app that needs to process audio data in real time, but we are suffering with performance. The bottlenecks are in audio effects, which are in fact quite simple, but the performance hit is noticeable when several are added.
Most of the audio effects code is written in C.
We think there are two places we can use gpu hardware to speed things up: using openCL for effects and hardware for interpolation/smoothing. We are fairly new to this and don't know where to begin.
You probably mean OpenGL, as OpenCL is only present on the desktop. Yes, you could use OpenGL ES 2.0 programmable shaders for this, if you wanted to perform some very fast parallel processing, but that will be extremely complex to pull off.
You might first want to look at the Accelerate framework, which has hardware-accelerated functions for doing just the kind of tasks needed for audio processing. A great place to start is Apple's WWDC 2010 session 202 - "The Accelerate framework for iPhone OS", along with their "Taking Advantage of the Accelerate Framework" article.
Also, don't dismiss Hans' suggestion that you profile your code first, because your performance bottleneck might be somewhere you don't expect.
You might get better DSP acceleration coding for the ARM NEON SIMD unit. NEON is designed for DSP operations and can pipeline multiple single precision floating point operations per cycle. Whereas getting audio data in and out of GPU memory may be possible, but may not be that fast.
But you might want to profile your code to see if something else is the bottleneck. The iPhone 4 CPU can easily keep up with doing multiple FFT's and IIR filters on a real-time audio stream.
I'm currently working on a couple of shaders for an iPad game and it seems as if Apple's GLSL compiler isn't doing any optimizations (or very few). I can move a single line in a shader and drop my FPS from 30 to 24 but I really have no idea why this is happening.
Does anyone have any references for the following:
what PowerVR instructions are generated from GLSL instructions?
what are the timings of the PowerVR instructions?
what sort of parallel processing units are in the PowerVR535 and how can they be exploited?
Thanks,
Tristan
Imagination Technologies recently added Mac support for their PVRUniSCo compiler and PVRUniSCoEditor interactive shader editor. These can be downloaded for free as part of the PowerVR SDK. The compiler has support for both the PowerVR SGX 53x series as well as the 540 series in the iPad 2. Unfortunately, the editor runs as a clunky X11 application, but at least it works now.
The editor gives you line-by-line estimates of the number of GPU cycles required throughout your vertex or fragment shader, as well as more accurate best and worst case estimates of total cycles required.
I've been using it to profile my iOS shaders, and it has proven to be extremely useful in finding hotspots:
http://www.imgtec.net/factsheets/SDK/POWERVR%20SGX.OpenGL%20ES%202.0%20Application%20Development%20Recommendations.1.1f.External.pdf
This documet should help you to optimize your shaders for maximum performance. Apple should provide similar information as well.
If I want to render just a huge map, what is the best practice when using OpenGL ES with a mobile device (Android or iPhone based)?
What is the best structure to contain all the vertices, normales and texture coordinates?
I guess using a interleaved structure may give you some performance benefits caused by memory caching. Ok?
Should I use drawArrays or drawElements to push my data to OpenGL ES?
Well, I did no testing at all but I might think, that drawElements might be faster if the GFX does not use shared memory since you do not have to push that much data. Since this is really close to metall, what do you think? (the iPhone is ARM based while the Android platform is Qualcomm based (also an ARM?))
Best regards,
Friedrich
In theory using Vertex Buffer Objects should yield the best results. You have already given the reasons.
Although I remember hearing in one of the Stanford lectures on iPhone-development, that the use of VBOs does not produce better performance than using vertex pointers. Then again, this information is a bit dated. So, going for VBOs on the iPhone will definitely not be a bad idea.
Up until Android 1.5 there was a memory leak in the OpenGL-implementation that was triggered by glDrawElements. Although I would assume that it has been fixed by now, I haven't checked it in a while.
And here some Infos on how to best use VBOs.
I like the approach presented in this presentation. Check out slides 26-32.
The presentation is android specific but should apply to the iPhone as well. Basically, check your GL extensions, and if you can use them Vertex Buffer Objects are the way to go.
Remember that your target architecture (ARM in both cases) is probably not going to have an FPU, so state changes are going to be very very expensive.
I have been developing iPhone Applications for a couple of months. I would like to know your views about the Quartz vs OpenGL ES 1.x or 2.0 learning curve. You can tell your perspective. My Questions are
*I am a wannabe game developer, So is it a good idea to first develop in quartz , then move
on to OpenGL ES or does it not make an difference
*Can you please tell your experiences when you were having the similar question
Thanks :)
Quartz 2D is not applicable for game development IMHO. It is a software rendering API. It won't give you realtime rendering speed. It's good for drawing charts or vector text with shadows, or for blending several images together. Just not for games. Unless you want to make a game where few images are moving against a monochrome background and even in that case I doubt it will be really smooth on older devices. I've seen some games obviously coded with Quartz. A pitiful sight.
Sooner or later you'll end up using Open GL ES or a game framework build on top of it. I recommend you to check cocos2D, SIO2 engine, or examples from SDK.
With careful programming it is possible to make an Open GL ES game with parallax scrolling and relatively small amount of objects work at 60 FPS even on 2nd gen devices. Tiny Wings is an example of such game. And maintaining stable 30 FPS is not a problem at all.
I skipped Quartz and went right to OpenGL ES. I started with a 2D sprite based game. Thought it was pretty easy.
The key is having a good example to look at. I used the Lunar Lander clone (Crash Lander), but I don't think that's easy to find anymore. Maybe someone who has done it recently knows of a better, newer example that uses current best practices.
I'm in the same boat as you describe, although I have no programming background. (Although I don't know what your background is either) Currently, I am in the process of learning to code as I learn the various API's that are available. I'm an objective-c guy going backwards to the c-based Quartz API, and it's a little bit of a challenge. Luckily, Programming in Objective-C 2.0 by S. Kochan has a great chapter on underlying C features to keep you afloat.
I have taken a couple of stabs # OpenGLES, and I have to say, that from a conceptual standpoint, I'm not ready for it. The Quartz2d API is a bit easier to learn conceptually because it's very easy to get up & running with a few commands. Right now, I'm at the point where I can define shapes and point to point images with out too much trouble.
OpenGLES is going to be something in my future, but it takes such an enormous amount of code to configure the drawing view, set up buffers, etc. If you are familiar with everything the code is doing, then it's a bit easier. However, from a learning perspective, Quartz is an easier way to get going, quickly.
Resources I'm using: The aforementioned book, and an anemic amount of blogs containing tutorials, which are limited # best. At this point, make an appointment with the apple docs and get cozy, because it's about the best (free) stuff that's out there (& exhaustive) With that said, I'd love for someone to prove me wrong on this site by posting a great resource for learning, but that's about it. Good Luck.
I have been looking for the fundamental differences so I can decide between OpenGL (ES) or Quartz or a hybrid. The good news is that the hybrid is an option. Clearly Quartz is easier to master for O-O programming and the answer from Apple appears to be that OpenGL, "...is ideal for immersive types of applications..."
http://developer.apple.com/library/ios/#DOCUMENTATION/General/Conceptual/Devpedia-CocoaApp/DrawingModel.html
I don't want to limit the category to games as I believe any game UX can be applied to a business App, a productivity App, entertainment viewing, etc. By the same token, I fully expect the technology (both h/w and s/w) to advance to make either a choice.