Hot answers tagged profiler
Yes. FBO, shader (changing the currently active program, not necessarily shader state itself) and texture state changes tend to be the most expensive. Conversely, vertex pointers and uniforms tend to be the cheapest states to change. It is almost impossible to actually calculate the expense of any one state change in modern GL implementations; you might pay ...
What do you mean by "too slow", as in it dropped from 5000 frames per second to 500, or it went from 100 to 2 (do note that frame rate is a logarithmic time scale). For profiling, there are several java profilers, and some of them have plugins for eclipse. A quick google turns up several potential solutions. As far as OpenGL goes, a couple of things: are ...
There are two kinds of data we can profile, at the high level: We can profile the execution of the program itself -- what functions are called when and where, how long they take, and what impact they have on the environment (allocations, locks, threads spawned, et cetera). We can profile what the user is actually doing with the program -- where they are ...
One of our team mates found Imagination: http://www.imgtec.com/powervr/insider/powervr_presentations/profiling_tools_android.asp It is a set of profiling tools for Andorid. You can configure this to your tablet and profile the GPU. Would be better if Unity supported this on its own, but still, this gets the job done thoroughly.
WaitForFPS isn't really an issue (it has a specific purpose in attaining the target frame-rate of your game). Is your camera getting moved in the LateUpdate Callback? The most common reason for camera jitter in camera movement scripts is using Update, which is causes the target's movement to happen after the camera's movement is updated, leaving it always ...
Your image is hard to see, could you please upload a bigger one? GPU does happen in parallel to CPU but both sync when swapping buffers. I would move your updates to a different thread, even more than one thread and throw stuff to render to your GLThread. If done correctly you can even use different update frequencies for different stuff in your scene.
There are several Java profilers you can evaluate. That will only tell you so much, though -- basically what's going on CPU-side. If that's where your performance bottleneck is, great, but if not you may need to resort to tools like gDebugger to do analysis on your OpenGL call stream.
I have a home-made profiling system that consists of profile-probes that I've injected on a lot of none-inner-loop places in my code. The probes are initially disabled and I just enable the ones that I want to check up on. The system simply throws out the information to a .txt file (or a network stream) that I then use another language to parse the output ...
Until we have a few more specifics on your platform/OS/compiler, it's going to be hard to answer, but in the mean time, look at this answer to "In general how often and when should I optimize my code?" for some generic suggestions. Most of these suggestions will work equally well in optimized (release) or non-optimized (debug) builds. (I'll return and ...
Only top voted, non community-wiki answers of a minimum length are eligible