# Overhead of glDrawArrays vs. glMultiDrawArrays

**URL:** https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879
**Category:** Uncategorized
**Created:** [February 18, 2019, 7:57pm UTC](https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879 "2019-02-18T19:57:55Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![desperado](https://avatars.discourse-cdn.com/v4/letter/d/3ab097/32.png) [@desperado](https://forums.imgtec.com/u/desperado)
#### Post date: [February 18, 2019, 7:57pm UTC](https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879/1 "2019-02-18T19:57:55Z")

</div>

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++) {  
glDrawArrays(GL\_TRIANGLES,  
object[n]-\>first\_vertex,  
object[n]-\>vertex\_count);  
}

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?

---

<div class="post-metadata">

### Author: ![MartonTamas](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/martontamas/32/297_2.png) [@MartonTamas](https://forums.imgtec.com/u/MartonTamas)
#### Post date: [February 28, 2019, 10:24am UTC](https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879/2 "2019-02-28T10:24:56Z")

</div>

Hi,

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.

bests,  
Marton

---

<div class="post-metadata">

### Author: ![desperado](https://avatars.discourse-cdn.com/v4/letter/d/3ab097/32.png) [@desperado](https://forums.imgtec.com/u/desperado)
#### Post date: [March 1, 2019, 12:53am UTC](https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879/3 "2019-03-01T00:53:25Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![MartonTamas](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/martontamas/32/297_2.png) [@MartonTamas](https://forums.imgtec.com/u/MartonTamas)
#### Post date: [March 1, 2019, 11:19am UTC](https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879/4 "2019-03-01T11:19:22Z")

</div>

Hi,

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.

bests,  
Marton

---

<div class="post-metadata">

### Author: ![desperado](https://avatars.discourse-cdn.com/v4/letter/d/3ab097/32.png) [@desperado](https://forums.imgtec.com/u/desperado)
#### Post date: [March 1, 2019, 2:22pm UTC](https://forums.imgtec.com/t/overhead-of-gldrawarrays-vs-glmultidrawarrays/2879/5 "2019-03-01T14:22:38Z")

</div>

Excellent. This was the precise answer I hoped for!

Regards
