<p>For example, let's assume I'm rendering cascaded shadow mapping, but for whatever reason, instead of one of the typical approach, I do the following:</p>

<ul>
<li><p>Render the lowest resolution shadowmap</p></li>
<li><p>Copy part of the shadowmap to the next shadowmap, covering a smaller area(and thus more dense)</p></li>
<li><p>Compute a stencil mask based on different points' distance from camera, e.g. more detail on edges, and on points closer to the camera, reusing the old shadowmap elsewhere.</p></li>
<li><p>Render the next, higher-density shadowmap with the aforementioned stencil.</p></li>
</ul>

<p>What performance can I realistically expect from that? If only 50% of the pixels(or should I say fragments here?) pass the stencil test, do I save 50% of the rendering time, less, none?</p>

<p>If this is a poor example, my fallback question scenario is a static scene, where the previous frame's result is reprojected, with an error accumulator in alpha, and a stencil mask is computed based on misses or too high error rates(e.g. position of the previous frame's reprojected pixel is too far from the new target pixel).</p>

CC BY-SA 3.0
2015-12-03T10:22:03.977Z
about saving processing power: http://computergraphics.stackexchange.com/q/259/137
ratchet freak
CC BY-SA 3.0
2015-12-03T11:57:17.630Z
@ratchetfreak Interesting post. Stenciling isn't conditionals, though.
Llamageddon
CC BY-SA 3.0
2015-12-03T12:02:05.197Z
But the GPU still groups (at least) 2x2 pixels together even if 3 out of 4 will fail the stencil test.
ratchet freak
CC BY-SA 3.0
2015-12-03T12:36:46.807Z
Are you certain about that? I'd imagine that that's what happens for conditionals, while with stenciles, the GPU is a bit smarter about it.
Llamageddon
CC BY-SA 3.0
2015-12-03T14:40:19.997Z
Given that it will calculate pixels just off the triangle I doubt that it will cull the singular stencil-failing pixels.
ratchet freak
CC BY-SA 3.0
2015-12-03T15:37:16.540Z
@Llamageddon Pixel shaders are always packed together in 2x2 quads, because a pixel shader that doesn't sample at least one texture is a rare thing indeed. But if you are doing depth-only rendering, that matters less. Also, for what it's worth, shadow rendering is traditionally bound by vertices, so in traditional high-vertex-count situations this probably won't help. Also don't forget that you'd be writing to every pixel's stencil just to skip writing to that same pixel's depth (unless your pixel shader is complex).
John Calsbeek
CC BY-SA 3.0
2015-12-03T18:11:52.060Z
@JohnCalsbeek I see. What about other hypothetical scenarios, such as ones involving more complex shader code, or a more regular stencil, that discards, for example, the left half of the screen? What situations can stencils be used in to accelerate things?
Llamageddon
CC BY-SA 3.0
2015-12-04T15:48:26.510Z
@Llamageddon The canonical example for stencil these days is discarding all visible sky when doing a lighting full-screen pass. Lighting is expensive, and the sky often large.
John Calsbeek
<optimisation><stencil-test><stencil-buffer>
How much processing power does stenciling actually save?
Llamageddon
# How much processing power does stenciling actually save?

(Asked by: username_0 on 2015-12-03)

For example, let's assume I'm rendering cascaded shadow mapping, but for whatever reason, instead of one of the typical approach, I do the following:

* Render the lowest resolution shadowmap
* Copy part of the shadowmap to the next shadowmap, covering a smaller area(and thus more dense)
* Compute a stencil mask based on different points' distance from camera, e.g. more detail on edges, and on points closer to the camera, reusing the old shadowmap elsewhere.
* Render the next, higher-density shadowmap with the aforementioned stencil.

What performance can I realistically expect from that? If only 50% of the pixels(or should I say fragments here?) pass the stencil test, do I save 50% of the rendering time, less, none?

If this is a poor example, my fallback question scenario is a static scene, where the previous frame's result is reprojected, with an error accumulator in alpha, and a stencil mask is computed based on misses or too high error rates(e.g. position of the previous frame's reprojected pixel is too far from the new target pixel).

**Tags:** optimisation, stencil-test, stencil-buffer

> **Comments:**
> **username_1**: about saving processing power: http://computergraphics.stackexchange.com/q/259/137  
> **username_0**: @username_1 Interesting post. Stenciling isn't conditionals, though.  
> **username_1**: But the GPU still groups (at least) 2x2 pixels together even if 3 out of 4 will fail the stencil test.  
> **username_0**: Are you certain about that? I'd imagine that that's what happens for conditionals, while with stenciles, the GPU is a bit smarter about it.  
> **username_1**: Given that it will calculate pixels just off the triangle I doubt that it will cull the singular stencil-failing pixels.  
> **username_2**: @username_0 Pixel shaders are always packed together in 2x2 quads, because a pixel shader that doesn't sample at least one texture is a rare thing indeed. But if you are doing depth-only rendering, that matters less. Also, for what it's worth, shadow rendering is traditionally bound by vertices, so in traditional high-vertex-count situations this probably won't help. Also don't forget that you'd be writing to every pixel's stencil just to skip writing to that same pixel's depth (unless your pixel shader is complex).  
> **username_0**: @username_2 I see. What about other hypothetical scenarios, such as ones involving more complex shader code, or a more regular stencil, that discards, for example, the left half of the screen? What situations can stencils be used in to accelerate things?  
> **username_2**: @username_0 The canonical example for stencil these days is discarding all visible sky when doing a lighting full-screen pass. Lighting is expensive, and the sky often large.  

---

## 0 answers

