Overhead of glDrawArrays vs. glMultiDrawArrays

Can someone tell what exactly causes the overhead of a loop of multiple glDrawArrays calls without state changes over one glMultiDrawArrays call? Like, why this

for (int i = 0; i < num_objects; i++) {

is supposedly more expensive than one glMultiDrawArrays call?

Or in other words: Is there anything beside state change checks that makes multiple draw calls expensive?


in today’s GPU drivers draw calls are designed to do very minimal work so that you can submit a lot of them. Only when actual GPU work is required is when all of that data is processed and sent to kernel space for the GPU to process. So if you are worried about user-kernel space switching that probably doesn’t happen.
One thing that you could be saving is the cost of the actual function call.

To make sure that you are using the optimal way of doing draw calls, please use a CPU profiler with both methods.


If you disregard the kernel space, how much more is the overhead of multiple glDrawArrays vs. one glMultiDrawArrays call if the state doesn’t change and only offset/count does?


I took a look for you at the actual driver code. Both functions check your parameters of course and the GL state in general, so that part is pretty similar. There’s a bit of extra work on glMultiDrawArrays as it has to check all the primitive ranges you passed.
Then for all the primitive ranges (which is 1 for glDrawArrays) the driver emits the actual draw command. This is all pretty much expected I would say.

So the crucial difference is that if you call glDrawArray 100 times, all this parameter checking and state checking will happen 100 times. If you call glMultiDrawArrays it will only happen once.
However this state checking should be pretty low-overhead, so I would still check the performance using a CPU profiler. There shouldn’t be much difference unless you are going crazy with the draw call numbers.


1 Like

Excellent. This was the precise answer I hoped for!