OpenGL profiling - Printable Version

+- (
+-- Forum: PPSSPP - Playstation Portable Simulator Suitable for Playing Portably (/forumdisplay.php?fid=1)
+--- Forum: Development (/forumdisplay.php?fid=3)
+--- Thread: OpenGL profiling (/showthread.php?tid=4753)

OpenGL profiling - [Unknown] - 07-10-2013 08:23 AM

I was looking at gDEBugger, and noticed the following things, but I don't know how much benefit they could give:

When switching shaders, we disable/enable vertex arrays. Often the same ones are used (especially a_position.) It seems like glBindAttribLocation() could even force a particular value across all shaders.

In the game I was profiling, glEnableVertexAttribArray and glDisableVertexAttribArray were each 21.19% of function calls (it doesn't seem to do time, which sucks?) Of course, this game is flushing a lot, and is GPU limited on my desktop (99.78% of vertex batches are 6.)

It also calls out a lot of redundant calls, for example glViewport(). While STATE4() seems to check for redundancy, restore() doesn't, but that should only be once per frame. It also calls out glColorMask(), glBlendFunc(), glCullFace(), etc. glColorMask(), for example, it says had 148 redundant calls, and I think it was only 50 frames, (buffered rendering -> copy to output is 2 extra, so that makes sense.) This makes me think something is wrong in the redundancy checks...


RE: OpenGL profiling - Orphis - 07-12-2013 07:37 AM

Restore is used when the state has been altered externally, thus no way to know what may have changed. It was kind of required when I implemented it, now, don't know if that's still the case.
If there are redundant calls, then you could break on them in gDebugger and see where they come from. Or grep through the code to search who is calling glViewport and not going through our state tracker.