<p>The result should be <em>as if</em> it was executed sequentially one triangle at a time. This is important so that each frame is deterministic. If it wasn't then drawing the same frame multiple times could create different results and create a flickering image on screen.</p>

<p>However that <em>does not mean parallelization is impossible</em>. Vertices can be computed in parallel. Their results will be ordered and fed to the rasterizer which will feed the fragment shader stage.</p>

<p>The same happens with pixels. Typically a group of pixels from a triangle can be computed in parallel and blended. A non-overlapping triangle can then also be filled at the same time however if triangle overlaps one currently busy then the result of the fragment shader must be buffered until the corresponding pixels of the previous triangle are done so blending can happen in the correct order.</p>

CC BY-SA 3.0
2015-11-05T14:44:47.070Z
It's entirely possible to run the pixel shader for overlapping triangles at the same time. All that matters is that the *blending* happens sequentially. Pixel shaders can kick off a lot of work to the blending unit in any order, which can then reorder all those blend operations depending on the triangle that it came from.
John Calsbeek
CC BY-SA 3.0
2015-11-05T16:07:18.187Z
I've seen situations where flickering does occur due to multiple triangles lying in the same plane, but I don't remember if that happened while the camera/world/etc. transforms were static or if it required movement and recalculation. That's an edge case, though.
JAB
CC BY-SA 3.0
2015-11-05T17:46:51.760Z
@JAB It sounds like you're referring to [z-fighting](https://en.wikipedia.org/wiki/Z-fighting).  This usually occurs due to the fact that even if two primitives are analytically co-planar, quantization in the interpolator produces a pattern where some pixels from both primitives are visible.  The pattern will shift, causing flickering, only if the vertices (or camera) are moved, otherwise the interference pattern should be consistent between frames.
MooseBoys
CC BY-SA 3.0
2015-11-05T18:43:21.977Z
@MooseBoys That's exactly it, yeah. It's been a few years since I did much with 3D graphics.
JAB
CC BY-SA 3.0
2015-11-05T21:15:30.600Z
Besides just running multiple vertices and pixels in parallel, it's also possible for multiple draw calls to be in flight at the same time, if enough GPU resources are available and there is no dependency between the draw calls.
Nathan Reed
CC BY-SA 3.0
2015-11-05T13:30:39.553Z
2015-11-05T14:46:13.837Z
2015-11-05T14:46:13.837Z
ratchet freak
<p>This a follow up for a question I answered on GameDev SE. The question was simply <a href="https://gamedev.stackexchange.com/questions/110781/is-gldrawarraysinstanced-in-opengl-parallel-when-drawing-those-instances">Is glDrawArraysInstanced in OpenGL parallel when drawing those instances?</a></p>

<p>My answer was in the lines of "the GPU might execute multiple draw calls in parallel depending on multiple things, for instance if two draw calls use the same vertex shaders." <a href="https://gamedev.stackexchange.com/questions/110781/is-gldrawarraysinstanced-in-opengl-parallel-when-drawing-those-instances/110806#110806">Here is the full answer</a>.</p>

<p>In the comments the OP mentioned, "I think it should be sequential. After all, some of blending mode depends of sequence"</p>

<p>Now, I am little bit confused. Is my answer of <em>it will still parallelize them when it can</em> valid? Can someone clarify this?</p>

<opengl><gpu>
Are draw calls executed in parallel or sequentially or both?
concept3d
# Are draw calls executed in parallel or sequentially or both?

(Asked by: username_0 on 2015-11-05)

This a follow up for a question I answered on GameDev SE. The question was simply [Is glDrawArraysInstanced in OpenGL parallel when drawing those instances?](https://gamedev.stackexchange.com/questions/110781/is-gldrawarraysinstanced-in-opengl-parallel-when-drawing-those-instances)

My answer was in the lines of "the GPU might execute multiple draw calls in parallel depending on multiple things, for instance if two draw calls use the same vertex shaders." [Here is the full answer](https://gamedev.stackexchange.com/questions/110781/is-gldrawarraysinstanced-in-opengl-parallel-when-drawing-those-instances/110806#110806).

In the comments the OP mentioned, "I think it should be sequential. After all, some of blending mode depends of sequence"

Now, I am little bit confused. Is my answer of *it will still parallelize them when it can* valid? Can someone clarify this?

**Tags:** opengl, gpu


---

## 1 answers

### Answer by username_1 on 2015-11-05. Score: 9 | Accepted answer

The result should be *as if* it was executed sequentially one triangle at a time. This is important so that each frame is deterministic. If it wasn't then drawing the same frame multiple times could create different results and create a flickering image on screen.

However that *does not mean parallelization is impossible*. Vertices can be computed in parallel. Their results will be ordered and fed to the rasterizer which will feed the fragment shader stage.

The same happens with pixels. Typically a group of pixels from a triangle can be computed in parallel and blended. A non-overlapping triangle can then also be filled at the same time however if triangle overlaps one currently busy then the result of the fragment shader must be buffered until the corresponding pixels of the previous triangle are done so blending can happen in the correct order.

> **Comments:**
> **username_2**: It's entirely possible to run the pixel shader for overlapping triangles at the same time. All that matters is that the *blending* happens sequentially. Pixel shaders can kick off a lot of work to the blending unit in any order, which can then reorder all those blend operations depending on the triangle that it came from.  
> **username_3**: I've seen situations where flickering does occur due to multiple triangles lying in the same plane, but I don't remember if that happened while the camera/world/etc. transforms were static or if it required movement and recalculation. That's an edge case, though.  
> **username_4**: @username_3 It sounds like you're referring to [z-fighting](https://en.wikipedia.org/wiki/Z-fighting).  This usually occurs due to the fact that even if two primitives are analytically co-planar, quantization in the interpolator produces a pattern where some pixels from both primitives are visible.  The pattern will shift, causing flickering, only if the vertices (or camera) are moved, otherwise the interference pattern should be consistent between frames.  
> **username_3**: @username_4 That's exactly it, yeah. It's been a few years since I did much with 3D graphics.  
> **username_5**: Besides just running multiple vertices and pixels in parallel, it's also possible for multiple draw calls to be in flight at the same time, if enough GPU resources are available and there is no dependency between the draw calls.  

---

