Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
OpenGL profiling
07-10-2013, 08:23 AM
Post: #1
OpenGL profiling
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...

-[Unknown]
Find all posts by this user
Quote this message in a reply
07-12-2013, 07:37 AM
Post: #2
RE: OpenGL profiling
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.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: