<p>I don't have a definite authoritive answer for you but I'm very confident that the answer is &quot;yes&quot;. Here's why:</p>
<p>When using framebuffer objects, <a href="https://www.khronos.org/opengl/wiki/Image_Format#Depth_stencil_formats" rel="nofollow noreferrer">stencil attachments are usually combined</a> with the depth attachment in a single texture (<code>GL_DEPTH24_STENCIL8</code> or <code>GL_DEPTH32F_STENCIL8</code>). In fact, until recently, a combined depth and stencil was the only way to get a stencil buffer. It is now possible to create a stencil only attachment for an FBO.</p>
<p>This <a href="https://www.khronos.org/opengl/wiki/Framebuffer_Object" rel="nofollow noreferrer">OpenGL wiki article on FBOs</a> states (emphasis mine):</p>
<blockquote>
<p>These color formats can be combined with a depth attachment with any of the required depth formats. Stencil attachments can also be used, again with the required stencil formats, as well as the combined depth/stencil formats. However, <strong>implementations are only required to support both a depth and stencil attachment simultaneously if both attachments refer to the same image</strong>.</p>
<p>This means that if you want stencil with no depth, you can use one of the required stencil formats. If you want depth with no stencil, you can use one of the required depth formats. <strong>But if you want depth and stencil, you must use a depth/stencil format and the same image in that texture must be attached to both the depth and stencil attachments</strong>.</p>
</blockquote>
<p>All this strongly hints towards an accelerated storage format for stencils similar to the one used by depth buffers.</p>
<p>Also, empirically, over the years many rendering algorithms (e.g. stencil shadows) using the stencil buffer would have been prohibitively slow if stencil buffers did not use some form of accelerated structure.</p>
<p>The <a href="https://www.khronos.org/registry/OpenGL/extensions/NV/NV_packed_depth_stencil.txt" rel="nofollow noreferrer">NV_packed_depth_stencil extension</a> (2001) spec also provides interesting insight:</p>
<blockquote>
<p>Many OpenGL implementations have chosen to interleave the depth and stencil buffers into one buffer, often with 24 bits of depth precision and 8 bits of stencil data.</p>
</blockquote>
<p>and (emphasis mine)</p>
<blockquote>
<p>Should the depth/stencil format support other standard types, like GL_FLOAT or GL_UNSIGNED_INT?</p>
<p>RESOLVED: No, this extension is designed to be minimalist. Supporting more types gains little because the new types will just require data format conversions.  <strong>Our goal is to match the native format of the buffer</strong>, not add broad new classes of functionality.</p>
</blockquote>

CC BY-SA 3.0
2017-11-29T03:34:59.240Z
It should also be noted that, while OpenGL only requires support for combined depth/stencil, the API still technically allows it for hardware that could handle it. Vulkan, by contrast, makes it *impossible* to separate them. In a Vulkan renderpass, there is exactly one depth/stencil attachment, in a render pass, and that image can provide depth, stencil, or both. But there is only one image allowed there.
Nicol Bolas
CC BY-SA 3.0
2017-11-28T19:06:32.767Z
2017-11-28T19:06:32.767Z
2020-06-18T08:32:12.800Z
bernie
<p>Stencil bits are often used for optimizations, for instance having full screen lighting passes only affect certain pixels.</p>

<p>Does the stencil test mechanism use any acceleration structures of any kind (like maybe dividing the screen into a coarser grid?) or do the perf benefits come solely from having a pre-pixel shader test that can early out waves of shaders?</p>

<optimisation><stencil-test>
Do stencil tests use any acceleration techniques?
Alan Wolfe
# Do stencil tests use any acceleration techniques?

(Asked by: username_0 on 2017-11-28)

Stencil bits are often used for optimizations, for instance having full screen lighting passes only affect certain pixels.

Does the stencil test mechanism use any acceleration structures of any kind (like maybe dividing the screen into a coarser grid?) or do the perf benefits come solely from having a pre-pixel shader test that can early out waves of shaders?

**Tags:** optimisation, stencil-test


---

## 1 answers

### Answer by username_1 on 2017-11-28. Score: 4 | Accepted answer

I don't have a definite authoritive answer for you but I'm very confident that the answer is "yes". Here's why:

When using framebuffer objects, [stencil attachments are usually combined](https://www.khronos.org/opengl/wiki/Image_Format#Depth_stencil_formats) with the depth attachment in a single texture (`GL_DEPTH24_STENCIL8` or `GL_DEPTH32F_STENCIL8`). In fact, until recently, a combined depth and stencil was the only way to get a stencil buffer. It is now possible to create a stencil only attachment for an FBO.

This [OpenGL wiki article on FBOs](https://www.khronos.org/opengl/wiki/Framebuffer_Object) states (emphasis mine):

> These color formats can be combined with a depth attachment with any of the required depth formats. Stencil attachments can also be used, again with the required stencil formats, as well as the combined depth/stencil formats. However, **implementations are only required to support both a depth and stencil attachment simultaneously if both attachments refer to the same image**.
>
> This means that if you want stencil with no depth, you can use one of the required stencil formats. If you want depth with no stencil, you can use one of the required depth formats. **But if you want depth and stencil, you must use a depth/stencil format and the same image in that texture must be attached to both the depth and stencil attachments**.

All this strongly hints towards an accelerated storage format for stencils similar to the one used by depth buffers.

Also, empirically, over the years many rendering algorithms (e.g. stencil shadows) using the stencil buffer would have been prohibitively slow if stencil buffers did not use some form of accelerated structure.

The [NV\_packed\_depth\_stencil extension](https://www.khronos.org/registry/OpenGL/extensions/NV/NV_packed_depth_stencil.txt) (2001) spec also provides interesting insight:

> Many OpenGL implementations have chosen to interleave the depth and stencil buffers into one buffer, often with 24 bits of depth precision and 8 bits of stencil data.

and (emphasis mine)

> Should the depth/stencil format support other standard types, like GL\_FLOAT or GL\_UNSIGNED\_INT?
>
> RESOLVED: No, this extension is designed to be minimalist. Supporting more types gains little because the new types will just require data format conversions. **Our goal is to match the native format of the buffer**, not add broad new classes of functionality.

> **Comments:**
> **username_2**: It should also be noted that, while OpenGL only requires support for combined depth/stencil, the API still technically allows it for hardware that could handle it. Vulkan, by contrast, makes it *impossible* to separate them. In a Vulkan renderpass, there is exactly one depth/stencil attachment, in a render pass, and that image can provide depth, stencil, or both. But there is only one image allowed there.  

---

