views:

155

answers:

4

Hi guys,

This is kind of weird, but I noticed that up to 40 percents of the rendering time is spent inside glAlphaFuncx. I know that alpha testing is very expensive, but the interesting thing is I do not use it :) No single place of code uses alpha testing, neither do I invoke this function in any other way.

I also checked GL layer for blending on other sorts of stuff which might cause this to happen but it is what it is.

So, if anybody knows what might cause glAlphaFuncx to appear on the performance trace of CPU Sampler, I would be glad to hear it :)

Update: fixed the screenshot link: http://twitpic.com/2afxho/full

Update 2: the function that leads to invokation of glAlpaFuncx contains a single line:

[context presentRenderbuffer:GL_RENDERBUFFER_OES];

Update 3: I tried setting the breakpoint inside this function, but it seems it haven't been invoked at all. I guess profiler is screwed up here...

+1  A: 

It's weird that this function appears on a profiler trace, as you say you aren't using it. Try setting a breakpoint in glAlphaFuncx to see from where it is being called.

But anyway, that should not be a problem, glAlphaFunc will just set a state in the GL server side, it doesn't (or should) do any more processing than that. It shouldn't be a performance problem, maybe it's a bug in the GL implementation or in the profiler.

To be sure, you can disable alpha test with glDisable(GL_ALPHA_TEST).

Matias Valdenegro
I tried disabling it - no luck.As for the place of invokation - please look at my update, it seems to be invoked by [context presentRenderbuffer:GL_RENDERBUFFER_OES].The reason I'm worried is that the application performance is not high at all, although I'm rendering very few geometry, so it would be great if I could fix it...
Anton
Well if that function is really enabling and using alpha test, there is not much you can do.I would use a OpenGL profiler/debugger, such as gDebugger, to see what part of the GL pipeline is your bottleneck. Note that a CPU profiler is a bit worthless since the CPU and GPU run in parallel.
Matias Valdenegro
The thing is that iPod Touch runs the application perfectly (FPS = 60), so my guess CPU is a bottleneck (AFAIK they have same GPUs)
Anton
Depends on what generation iPod Touch you mean. http://en.wikipedia.org/wiki/IPod_Touch
Matias Valdenegro
2nd generation iPod Touch (and according to wiki the GPU is the same)
Anton
Ok, have you tried Apple Developer Support? Maybe it's just a bug in their GL implementation.
Matias Valdenegro
A: 

From what I can see, glAlphaFuncx could just be taking the hit for setting up the rendering or pushing the pixels. It could be that it is run either first or last in the rendering.

Do you have an actual performance problem, or are you just trying to find pieces of code to slice off / optimize?

If so, you should set a breakpoint in glAlphaFuncx and see where it is called from and why. To do this, just bring up the debugger console and type "break glAlphaFuncx".

Krumelur
Well, I want the application to run just a bit faster, this way it will be smooth enough for me. I tried setting the breakpoint inside this function, but it seems it haven't been invoked at all. I guess profiler is screwed up here...
Anton
A: 

Have you tried explicitly disabling the use of alpha channels?

glDisable(GL_ALPHA_TEST);

http://www.khronos.org/opengles/documentation/opengles1_0/html/glEnable.html

RobM
This disables the alpha test, not the use of the alpha channel.
Matias Valdenegro
Good point. But this *will* cause glAlphaFuncx to become a no-op.
RobM
A: 

Regardless of system, this sort of behaviour -- time spent presenting what's been drawn -- almost always indicates that the GPU is the bottleneck. Either you are drawing too much (if the framerate is a problem), or the CPU isn't doing enough (if the framerate is fine).

Actually, there's one other possibility -- that the amount of GPU work is fine, but the system is waiting for some kind of vertical retrace period. (That seems unlikely on a device that only ever has an LCD, and doesn't support a raster scan display, but maybe things still notionally work that way internally.) The upshot is still the same as far as the amount of CPU works goes, though, in that you've got time to do more stuff without affecting the frame rate.

I can't explain exactly why glAlphaFuncx specifically is appearing in the call stack, but if it doesn't appear ever to be actually getting called then I'd consider it a red herring until proven otherwise.

brone