<p>There is nothing surprising about this.</p>
<p>The biggest cost of multisampling is that you're rendering to larger buffers and therefore require more bandwidth to cover the same pixel-space area. This is especially true for doing depth tests, as the fragment's depth has to be computed and compared per-sample, not per-fragment. The more primitives you send, the more depth tests you're going to have, and therefore the more bandwidth you're going to use.</p>
<p>So if your shaders aren't doing much, your performance is going to be governed by framebuffer bandwidth.</p>
<p>Early depth tests are generally orthogonal to multisampling. But since multisampling typically executes the fragment shader at a lower frequency than the depth test, all of the depth samples that represent a fragment have to fail in order to cull the fragment itself. So I could imagine that some implementations turn off early tests for multisampling, but I rather doubt that this is the case.</p>

CC BY-SA 4.0
2021-05-27T16:36:29.730Z
After reading your post, I revisited the topic of GPU multisampling, and turns out I had wrong understanding of it, which is why the assumptions in my question don't make sense. But this definitely answered the question, thanks!
Lenny White
CC BY-SA 4.0
2021-05-27T15:56:20.667Z
2021-05-27T15:56:20.667Z
Nicol Bolas
<p>I have done some tests in OpenGL with multisampling, by specifying a multisample buffer as the default framebuffer. I used forward shading for rendering. From what I've observed the more primitives I have on the screen the higher the performance hit by multisampling. Is this because the built-in MSAA does multisampling in the fragment shader for each primitive we specify, even if its fragments are discarded because of depth testing? In order to fix this problem we could use deferred shading, <s>but then we would have do multisampling ourselves.</s></p>
<p><s>Does this mean then that in practice for scenes with overlapping objects the built-in MSAA is pretty much never going to be used?</s></p>

<sampling><supersampling>
MSAA performance with forward shading
Lenny White
# MSAA performance with forward shading

(Asked by: username_0 on 2021-05-27)

I have done some tests in OpenGL with multisampling, by specifying a multisample buffer as the default framebuffer. I used forward shading for rendering. From what I've observed the more primitives I have on the screen the higher the performance hit by multisampling. Is this because the built-in MSAA does multisampling in the fragment shader for each primitive we specify, even if its fragments are discarded because of depth testing? In order to fix this problem we could use deferred shading, ~~but then we would have do multisampling ourselves.~~

~~Does this mean then that in practice for scenes with overlapping objects the built-in MSAA is pretty much never going to be used?~~

**Tags:** sampling, supersampling


---

## 1 answers

### Answer by username_1 on 2021-05-27. Score: 1 | Accepted answer

There is nothing surprising about this.

The biggest cost of multisampling is that you're rendering to larger buffers and therefore require more bandwidth to cover the same pixel-space area. This is especially true for doing depth tests, as the fragment's depth has to be computed and compared per-sample, not per-fragment. The more primitives you send, the more depth tests you're going to have, and therefore the more bandwidth you're going to use.

So if your shaders aren't doing much, your performance is going to be governed by framebuffer bandwidth.

Early depth tests are generally orthogonal to multisampling. But since multisampling typically executes the fragment shader at a lower frequency than the depth test, all of the depth samples that represent a fragment have to fail in order to cull the fragment itself. So I could imagine that some implementations turn off early tests for multisampling, but I rather doubt that this is the case.

> **Comments:**
> **username_0**: After reading your post, I revisited the topic of GPU multisampling, and turns out I had wrong understanding of it, which is why the assumptions in my question don't make sense. But this definitely answered the question, thanks!  

---

