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.
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).
It's been a while since iPhone 3GS came out, and now there might be enough market share of OpenGL ES 2.0 supporting devices to warrant developing in it.
But the situation is a lot of developers probably already have huge code bases in OpenGL ES 1.1
How does one transitionf rom ES 1.1 to ES 2.0? I suppose the matrices need to be taken care of, as well as stuff like GL_FOG, GL_CULL maybe?
Is it possible to write "substitutes" for these functions, e.g your own glTranslatef, glPushmatrix etc? Will this mean performance hit?
What other considerations are there for transitioning to ES 2.0? What advantages and disadvantages (besides the obvious device support issue) comes with using either of these?
Looking at the amount of es 2.0 tags compared to standard es tags in stackoverflow, it looks like it's not the time for 2.0 yet though.
Don't just go by activity in the tags on Stack Overflow when trying to determine whether or not to use OpenGL ES 2.0. For one thing, not every 2.0 or shader-related question is tagged as such. Also, a lot of information was present about OpenGL ES 1.1 at or soon after the launch of the iPhone SDK, so people are much more familiar with that API. There clearly is a lot of interest in OpenGL ES 2.0, as evidenced by the fact that my one class session on the subject is by far the most popular of all of my course videos.
For the most part, the way you handle your geometry will be the same between 1.1 and 2.0, as well as things like your framebuffers, but everything else shifts from being determined by built-in functions to your own shaders. You will have to write some code to replicate simple functions like using the model view matrix or texturing, but those tend to only require a few lines in a shader. For example, using the model view matrix to adjust your vertices is as simple as placing a line like this in your vertex shader:
vec4 transformedPosition = modelViewProjMatrix * position;
Personally, I replaced the glRotate(), etc. functions a long while ago using the Core Animation helper functions to manipulate what effectively is a model view matrix. This made it trivial to move that code across to OpenGL ES 2.0.
Jeff LaMarche also has an extremely useful helper class for wrapping most of your shader program setup code in his article here.
For a great guide on making the transition to OpenGL ES 1.1, see the "Migration from OpenGL ES 1.0 to OpenGL ES 2.0" article which is a chapter in the book GPU Pro and can be found within the documentation that accompanies the free PowerVR SDK.
I've explained what OpenGL ES 2.0 can be good for in my previous answers here and here, but perhaps it would be useful to demonstrate a before-and-after in regards to what the new API can give you.
OpenGL ES 1.1:
OpenGL ES 2.0:
Hopefully, you can see the payoff of replacing some of the built-in functions with shaders.
If you have existing projects, I wouldn't recommend moving to 2.0, considering the effort required is very likely more than it'd be worth. That said, for any new projects, there's no reason to even bother to consider 1.1 anymore in my opinion. Most of the devices that have been sold are 3GS' or 4s, both of which are more than capable of handling 2.0.
OpenGL ES 2.0 has a few common things with OpenGL ES 1.1 (in rendering i mean). For each rendering you'll need a shader. For example, FOG also is created with shader. But you will have more power.
+1 to #jer his answer
Does anyone have an example of how to compile a shader, save the shader binary, and use glShaderBinary to later load the shader with iPhone/iOS (OpenGL ES 2.0)?
It's not possible to do this (at least with iOS 4 and below). iOS doesn't support any precompiled binary shaders. If you query OpenGL for the number of binary shader formats it supports, you get back zero.
You're forced to compile the shaders every time you start the app.
(Answered my own question.)
The best place to start is the XCode OpenGL template project, which for some time has included ES 2.0 shaders by default. It also has the distinct advantage of being a very, very simple example.
I'm looking for a comparison of iPhone 3G / 3GS graphical systems (opengl) to the ones on a PC / MAC.
Google didn't help. Perhaps anybody here?
While this might be more of a hardware question, there is enough that might influence the design of an OpenGL-based application here that I'll bite.
Using my Molecules application as a template, I benchmarked the rendering throughput of that running on iPhone 3G, iPad, and a 2nd generation MacBook Air (Nvidia GeForce 9400M). For the MacBook, the numbers were generated from running the application in the Simulator with nothing else executing on the system:
iPhone 3G: 423,000 triangles / s
iPad: 1,830,000 triangles / s
MacBook Air: 2,150,000 triangles / s
You can grab the code for the application and try this yourself by enabling the RUN_OPENGL_BENCHMARKS define in SLSMoleculeGLViewController. This causes structures to be rendered for 100 frames, then the total time measured and the rendering rate figured from the complexity of the model being shown.
Note that this is an OpenGL ES 1.1 application which is geometry-limited in its current state. A fill-rate-limited application might have completely different performance characteristics, same as with one that uses OpenGL / OpenGL ES 2.0 shaders.
Aside from performance differences, the OpenGL command set differs between iOS and the Mac. OpenGL ES cuts out a lot of the cruft that's built up in OpenGL over the years (immediate mode, etc.). In general, OpenGL ES is a subset of OpenGL, so you can pretty much port something written for OpenGL ES to OpenGL without a lot of trouble. OpenGL on the desktop also uses a newer version of GLSL for its shaders (1.4, I believe), so some of the commands supported there will not work on iOS devices.
Apple has more about platform-specific differences in their Platform Notes section in the OpenGL ES Programming Guide for iOS.
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).