C++ and OpenGL ES: glDrawArrays calls are time consuming

Question

Currently, I'm profiling my iOS. All the calls to glDrawArrays are expensive. For example, here is a screenshot of the rendering part of a particle system:

As you can see, the glDrawArrays call takes from that method 39% of the CPU time. While other calls like glUniform1i and glBindVertexArrayOES are very quick. Why isn't glDrawArrays as quick as the others are? Aren't all these methods starting with gl*** short functions that will add a command to the driver queue? So, why does it take longer for a glDrawArrays call to be added to the queue, in comparation with all the other gl calls?

Is this normal, or does this mean that I'm doing something wrong?

---

In response to doug: Nope, that didn't work. The glFinish() call actually took a while, but the glDrawArrays call is still taking much time in comparation with the state changes (like glBindVertexArrayOES).

Answer 1

The way most drivers operate is by using a "lazy state changes" model. What this means is that the vast majority of your gl* calls will actually do nothing much more than recording a state, storing off some parameters, then return immediately. This works perfectly fine up until a gl* call is made that actually needs to do something with all that state (or that depends on the result of some other previously made call); at that point in time all the previously buffered-up state needs to be gathered together and flushed before the call can be made.

So what you're seeing is perfectly normal, if slightly misleading, behaviour: the time recorded for glDrawArrays is not actually the time taken by glDrawArrays alone, but also includes time for actually committing a whole bunch of previous GL calls.

There's a discussion of this for D3D available here but the same basic principle will apply to any modern implementation of either API. The key point to take away from it is: "in general, trying to profile your GPU by timing the CPU is going to be confusing and misleading".

Answer 2

You may be seeing the effects of queueing. Most likely the command queue blocks at that call because, for example, the queue is too full or you are getting ahead of vsync. It is probably doing a bunch of work from before the glDrawArrays call.

You could try putting a glFinish right before glDrawArrays, just to see if it is the commands in the queue taking the time or actually the glDrawArrays call. If the queueing effects are your actual performance bottleneck, it will blame glFinish instead of the innocent glDrawArrays call.

On the other hand, glDrawArrays may indeed be using a lot of CPU. I would try the above to be sure you're looking at the right thing.

EDIT: glFinish, NOT glFlush

I AM NOT SAYING LEAVE THE glFlush CALL THERE. Come on guys, do you really think I am saying leave the glFlush call there? Its a performance investigation.

Answer 3

Naive implementation of just writing to a command buffer on every gl call makes little sense, when the driver can possibly optimize out state changes. Thus, it makes sense to postpone processing as late as possible, especially on a tiled/binned rendering architecture, which most OpenGL ES implementations are.

On some architectures it actually makes sense to do some shader processing as late as on a glDrawArrays call. (And yes, even your ES1.x hardware likely has some form of shaders under the hood).

Calling glFinish/glFlush like doug65536 suggests won't help on tiled/binned architectures, as it causes a total pipeline flush which has a very, very, VERY heavy overhead on such - causing the rendering of everything queued so far to every tile and forcing a unresolve on the next render cycle.