| Name |
| |
| EXT_packed_depth_stencil |
| |
| Name Strings |
| |
| GL_EXT_packed_depth_stencil |
| |
| Contributors |
| |
| Pat Brown |
| Matt Craighead |
| Cass Everitt |
| Michael Gold |
| Evan Hart |
| Jeff Juliano |
| John Kessenich |
| Mark Kilgard |
| Jon Leech |
| Bill Licea-Kane |
| Barthold Lichtenbelt |
| Kent Lin |
| Brian Paul |
| Ian Romanick |
| John Rosasco |
| Jeremy Sandmel |
| |
| Contact |
| |
| Jeff Juliano, NVIDIA Corporation (jjuliano 'at' nvidia.com) |
| |
| Status |
| |
| Incomplete |
| |
| Version |
| |
| Last Modified Date: September 26, 2005 |
| Revision: #12 |
| |
| Number |
| |
| 312 |
| |
| Dependencies |
| |
| OpenGL 1.1 and EXT_framebuffer_object are required. |
| |
| Written based on the wording of the OpenGL 2.0 specification. |
| |
| Written based on the wording of EXT_framebuffer_object version 117. |
| |
| This extension interacts with EXT_framebuffer_object. |
| |
| This extension modifies NV_packed_depth_stencil. |
| |
| ARB_depth_texture affects the definition of this extension. |
| |
| SGIX_depth_texture affects the definition of this extension. |
| |
| Overview |
| |
| 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. 32 bits is more than is |
| needed for the depth buffer much of the time; a 24-bit depth buffer, |
| on the other hand, requires that reads and writes of depth data be |
| unaligned with respect to power-of-two boundaries. On the other |
| hand, 8 bits of stencil data is more than sufficient for most |
| applications, so it is only natural to pack the two buffers into a |
| single buffer with both depth and stencil data. OpenGL never |
| provides direct access to the buffers, so the OpenGL implementation |
| can provide an interface to applications where it appears the one |
| merged buffer is composed of two logical buffers. |
| |
| One disadvantage of this scheme is that OpenGL lacks any means by |
| which this packed data can be handled efficiently. For example, |
| when an application reads from the 24-bit depth buffer, using the |
| type GL_UNSIGNED_SHORT will lose 8 bits of data, while |
| GL_UNSIGNED_INT has 8 too many. Both require expensive format |
| conversion operations. A 24-bit format would be no more suitable, |
| because it would also suffer from the unaligned memory accesses that |
| made the standalone 24-bit depth buffer an unattractive proposition |
| in the first place. |
| |
| Many applications, such as parallel rendering applications, may also |
| wish to draw to or read back from both the depth and stencil buffers |
| at the same time. Currently this requires two separate operations, |
| reducing performance. Since the buffers are interleaved, drawing to |
| or reading from both should be no more expensive than using just |
| one; in some cases, it may even be cheaper. |
| |
| This extension provides a new data format, GL_DEPTH_STENCIL_EXT, |
| that can be used with the glDrawPixels, glReadPixels, and |
| glCopyPixels commands, as well as a packed data type, |
| GL_UNSIGNED_INT_24_8_EXT, that is meant to be used with |
| GL_DEPTH_STENCIL_EXT. No other data types are supported with |
| GL_DEPTH_STENCIL_EXT. If ARB_depth_texture or SGIX_depth_texture is |
| supported, GL_DEPTH_STENCIL_EXT/GL_UNSIGNED_INT_24_8_EXT data can |
| also be used for textures; this provides a more efficient way to |
| supply data for a 24-bit depth texture. |
| |
| GL_DEPTH_STENCIL_EXT data, when passed through the pixel path, |
| undergoes both depth and stencil operations. The depth data is |
| scaled and biased by the current GL_DEPTH_SCALE and GL_DEPTH_BIAS, |
| while the stencil data is shifted and offset by the current |
| GL_INDEX_SHIFT and GL_INDEX_OFFSET. The stencil data is also put |
| through the stencil-to-stencil pixel map. |
| |
| glDrawPixels of GL_DEPTH_STENCIL_EXT data operates similarly to that |
| of GL_STENCIL_INDEX data, bypassing the OpenGL fragment pipeline |
| entirely, unlike the treatment of GL_DEPTH_COMPONENT data. The |
| stencil and depth masks are applied, as are the pixel ownership and |
| scissor tests, but all other operations are skipped. |
| |
| glReadPixels of GL_DEPTH_STENCIL_EXT data reads back a rectangle |
| from both the depth and stencil buffers. |
| |
| glCopyPixels of GL_DEPTH_STENCIL_EXT data copies a rectangle from |
| both the depth and stencil buffers. Like glDrawPixels, it applies |
| both the stencil and depth masks but skips the remainder of the |
| OpenGL fragment pipeline. |
| |
| glTex[Sub]Image[1,2,3]D of GL_DEPTH_STENCIL_EXT data loads depth and |
| stencil data into a depth_stencil texture. glGetTexImage of |
| GL_DEPTH_STENCIL_EXT data can be used to retrieve depth and stencil |
| data from a depth/stencil texture. |
| |
| In addition, a new base internal format, GL_DEPTH_STENCIL_EXT, can |
| be used by both texture images and renderbuffer storage. When an |
| image with a DEPTH_STENCIL_EXT internal format is attached to both |
| the depth and stencil attachment points of a framebuffer object (see |
| EXT_framebuffer_object), then it becomes both the depth and stencil |
| buffers of the framebuffer. This fits nicely with hardware that |
| interleaves both depth and stencil data into a single buffer. When |
| a texture with DEPTH_STENCIL_EXT data is bound for texturing, only |
| the depth component is accessible through the texture fetcher. The |
| stencil data can be written with TexImage or CopyTexImage, and can |
| be read with GetTexImage. When a DEPTH_STENCIL_EXT image is |
| attached to the stencil attachment of the bound framebuffer object, |
| the stencil data can be accessed through any operation that reads |
| from or writes to the framebuffer's stencil buffer. |
| |
| New Procedures and Functions |
| |
| None. |
| |
| New Tokens |
| |
| Accepted by the <format> parameter of DrawPixels, ReadPixels, |
| TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, |
| TexSubImage3D, and GetTexImage, by the <type> parameter of |
| CopyPixels, by the <internalformat> parameter of TexImage1D, |
| TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and |
| RenderbufferStorageEXT, and returned in the <data> parameter of |
| GetTexLevelParameter and GetRenderbufferParameterivEXT: |
| |
| DEPTH_STENCIL_EXT 0x84F9 |
| |
| Accepted by the <type> parameter of DrawPixels, ReadPixels, |
| TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, |
| TexSubImage3D, and GetTexImage: |
| |
| UNSIGNED_INT_24_8_EXT 0x84FA |
| |
| Accepted by the <internalformat> parameter of TexImage1D, |
| TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and |
| RenderbufferStorageEXT, and returned in the <data> parameter of |
| GetTexLevelParameter and GetRenderbufferParameterivEXT: |
| |
| DEPTH24_STENCIL8_EXT 0x88F0 |
| |
| Accepted by the <value> parameter of GetTexLevelParameter: |
| |
| TEXTURE_STENCIL_SIZE_EXT 0x88F1 |
| |
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL |
| Operation) |
| |
| Starting with the bullet list on page 86, update section 2.15.4 |
| "Shader Execution" to say: |
| |
| "* The sampler used in a texture lookup function is of type |
| sampler1D or sampler2D, and the texture object's base internal |
| format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT, and the |
| TEXTURE_COMPARE_MODE is not NONE. |
| |
| * The sampler used in a texture lookup function is of type |
| sampler1DShadow or sampler2DShadow, and the texture object's base |
| internal format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT, and the |
| TEXTURE_COMPARE_MODE is NONE. |
| |
| * The sampler used in a texture lookup function is of type |
| sampler1DShadow or sampler2DShadow, and the texture object's base |
| internal format is not DEPTH_COMPONENT or DEPTH_STENCIL_EXT. |
| |
| The stencil index texture internal component is ignored if the base |
| internal format is DEPTH_STENCIL_EXT. |
| |
| If a vertex shader uses..." |
| |
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
| |
| Update the first paragraph on page 118, in the definition of |
| ColorTable, to say: |
| |
| "... The <formats> COLOR_INDEX, DEPTH_COMPONENT, DEPTH_STENCIL_EXT, |
| and STENCIL_INDEX and the <type> BITMAP are not allowed." |
| |
| Update the third paragraph on page 118, in the definition of |
| ColorTable, to say: |
| |
| "... <internalformat> must be one of the formats in table 3.15 or |
| table 3.16, other than the DEPTH or DEPTH_STENCIL_EXT formats in |
| those tables." |
| |
| On page 121, update the first paragraph in the definition of |
| ConvolutionFilter2D to say: |
| |
| "... The formats COLOR_INDEX, DEPTH_COMPONENT, DEPTH_STENCIL_EXT, |
| and STENCIL_INDEX and the type BITMAP are not allowed." |
| |
| Update the paragraph that spans pages 121 and 122, in the definition |
| of ConvolutionFilter2D, to say: |
| |
| "... <internalformat> must be one of the formats in table 3.15 or |
| table 3.16, other than the DEPTH or DEPTH_STENCIL_EXT formats in |
| those tables." |
| |
| Update the third paragraph on page 125, in the definition of |
| Histogram, to say: |
| |
| "... The error INVALID ENUM is generated if internalformat is not |
| one of the formats in table 3.15 or table 3.16, or is 1, 2, 3, 4, or |
| any of the DEPTH_COMPONENT or DEPTH_STENCIL_EXT or INTENSITY formats |
| in those tables." |
| |
| On page 126, update the second paragraph in the definition of Minmax |
| to say: |
| |
| "... The error INVALID ENUM is generated if internalformat is not |
| one of the formats in table 3.15 or table 3.16, or is 1, 2, 3, 4, or |
| any of the DEPTH_COMPONENT or DEPTH_STENCIL_EXT or INTENSITY formats |
| in those tables. The resulting..." |
| |
| Add a row to Table 3.5 (page 128): |
| |
| type Parameter GL Type Special |
| ------------------------------------------------ |
| ... ... ... |
| UNSIGNED_INT_2_10_10_10_REV uint Yes |
| UNSIGNED_INT_24_8_EXT uint Yes |
| |
| Update the paragraph on page 128, in the definition of DrawPixels, |
| to say: |
| |
| "... If the GL is in color index mode and <format> is not one of |
| COLOR_INDEX, STENCIL_INDEX, DEPTH_COMPONENT, or DEPTH_STENCIL_EXT, |
| then the error INVALID_OPERATION occurs. If <type> is BITMAP and |
| <format> is not COLOR_INDEX or STENCIL_INDEX then the error |
| INVALID_ENUM occurs. If <format> is DEPTH_STENCIL_EXT and <type> is |
| not UNSIGNED_INT_24_8_EXT then the error INVALID_ENUM occurs. Some |
| additional constraints on the combinations of <format> and <type> |
| values that are accepted is discussed below." |
| |
| Add a row to Table 3.6 (page 129): |
| |
| Format Name Element Meaning and Order Target Buffer |
| ------------------------------------------------------------------ |
| ... ... ... |
| DEPTH_COMPONENT Depth Depth |
| DEPTH_STENCIL_EXT Depth and Stencil Index Depth and Stencil |
| ... ... ... |
| |
| Add a row to Table 3.8 (page 132): |
| |
| type Parameter GL Type Components Pixel Formats |
| ------------------------------------------------------------------ |
| ... ... ... ... |
| UNSIGNED_INT_2_10_10_10_REV uint 4 RGBA,BGRA |
| UNSIGNED_INT_24_8_EXT uint 2 DEPTH_STENCIL_EXT |
| |
| Update the last paragraph on page 130 to say: |
| |
| "Calling DrawPixels with a <type> of UNSIGNED_BYTE_3_3_2, ..., |
| UNSIGNED_INT_2_10_10_10_REV, or UNSIGNED_INT_24_8_EXT is a special |
| case in which all the components of each group are packed into a |
| single unsigned byte, unsigned short, or unsigned int, depending on |
| the type." |
| |
| Add the following diagram to Table 3.11 (page 134): |
| |
| UNSIGNED_INT_24_8_EXT |
| |
| 31 30 29 28 27 26 ... 12 11 10 9 8 7 6 5 4 3 2 1 0 |
| +----------------------------------+---------------+ |
| | 1st Component | 2nd Component | |
| +----------------------------------+---------------+ |
| |
| Add a row to Table 3.12 (page 135): |
| |
| Format | 1st 2nd 3rd 4th |
| ------------------+------------------------------- |
| ... | ... ... ... ... |
| BGRA | blue green red alpha |
| DEPTH_STENCIL_EXT | depth stencil N/A N/A |
| |
| Add the following paragraph to the end of the section "Conversion to |
| floating-point" (page 135-136): |
| |
| "For groups of components that contain both standard components and |
| index elements, such as DEPTH_STENCIL_EXT, the index elements are |
| not converted." |
| |
| Update the last paragraph in the section "Conversion to Fragments" |
| (page 137) to say: |
| |
| "... Groups arising from DrawPixels with a <format> of STENCIL_INDEX |
| or DEPTH_STENCIL_EXT are treated specially and are described in |
| section 4.3.1." |
| |
| Update the first paragraph of section 3.6.5 "Pixel Transfer |
| Operations" (pages 137-138) to say: |
| |
| "The GL defines five kinds of pixel groups: |
| |
| 1. RGBA component: Each group comprises four color components: |
| red, green, blue, and alpha. |
| 2. Depth component: Each group comprises a single depth |
| component. |
| 3. Color index: Each group comprises a single color index. |
| 4. Stencil index: Each group comprises a single stencil index. |
| 5. Depth/stencil: Each group comprises a single depth component |
| and a single stencil index." |
| |
| Update the first paragraph in the section "Arithmetic on Components" |
| (page 138) to say: |
| |
| "This step applies only to RGBA component and depth component |
| groups, and to the depth components in depth/stencil groups. ..." |
| |
| Update the first paragraph in the section "Arithmetic on Indices" |
| (page 138) to say: |
| |
| "This step applies only to color index and stencil index groups, and |
| to the stencil indices in depth/stencil groups. ..." |
| |
| Update the first paragraph in the section "Stencil Index Lookup" |
| (page 139) to say: |
| |
| "This step applies only to stencil index groups and to the stencil |
| indices in depth/stencil groups. ..." |
| |
| In section 3.8.1 "Texture Image Specification", update page 151 to |
| say: |
| |
| "The selected groups are processed exactly as for DrawPixels, |
| stopping just before final conversion. Each R, G, B, A, or depth |
| value so generated is clamped to [0, 1], while the stencil index |
| values are masked by 2^n-1, where n is the number of stencil bits in |
| the internal format resolution (see below). If the base internal |
| format is DEPTH_STENCIL_EXT and <format> is not DEPTH_STENCIL_EXT, |
| then the values of the stencil index texture component are |
| undefined. |
| |
| Components are then selected from the resulting R, G, B, A, depth, |
| or stencil index values to obtain a texture with the base internal |
| format specified by (or derived from) <internalformat>. Table 3.15 |
| summarizes the mapping of R, G, B, A, depth, or stencil values to |
| texture components, as a function of the base internal format of the |
| texture image. <internalformat> may be specified as one of the |
| eight internal format symbolic constants listed in table 3.15, as |
| one of ... |
| |
| Textures with a base internal format of DEPTH_COMPONENT or |
| DEPTH_STENCIL_EXT are supported by texture image specification |
| commands only if <target> is TEXTURE_1D, TEXTURE_2D, |
| PROXY_TEXTURE_1D or PROXY_TEXTURE_2D. Using this format in |
| conjunction with any other <target> will result in an |
| INVALID_OPERATION error. |
| |
| Textures with a base internal format of DEPTH_COMPONENT or |
| DEPTH_STENCIL_EXT require either depth component data or |
| depth/stencil component data. Textures with other base internal |
| formats require RGBA component data. The error INVALID_OPERATION is |
| generated if the base internal format is DEPTH_COMPONENT or |
| DEPTH_STENCIL_EXT and <format> is not DEPTH_COMPONENT or |
| DEPTH_STENCIL_EXT, or if the base internal format is not |
| DEPTH_COMPONENT or DEPTH_STENCIL_EXT and <format> is DEPTH_COMPONENT |
| or DEPTH_STENCIL_EXT." |
| |
| Update the second paragraph on page 152 to say: |
| |
| "...the mapping of the R, G, B, A, depth and stencil values to |
| texture components..." |
| |
| Update the third paragraph on page 152 to say: |
| |
| "...the mapping of the R, G, B, A, depth, and stencil values to |
| texture components..." |
| |
| Add a row to table 3.15 (page 153), and update the title of the |
| second column: |
| |
| Base Internal Format RGBA and Depth and Stencil Values Internal Components |
| ---------------------------------------------------------------------------- |
| ... ... ... |
| DEPTH_STENCIL_EXT Depth,Stencil D,S |
| ... ... ... |
| |
| Update the caption for table 3.15 (page 153) |
| |
| "Table 3.15: Conversion from RGBA, depth, and stencil pixel |
| components to internal texture, table, or filter components. See |
| section 3.8.13 for a description of the texture components R, G, B, |
| A, L, I, D, and S." |
| |
| Add a new column to table 3.16 (page 153) labled "S bits". The |
| value of this column is blank for all rows except a new row: |
| |
| Sized Base R G B A L I D S |
| Internal Format InternalFormat bits bits bits bits bits bits bits bits |
| ------------------------------------------------------------------------------ |
| ... ... ... ... ... ... ... ... ... ... |
| DEPTH24_STENCIL8_EXT DEPTH_STENCIL_EXT 24 8 |
| ... ... ... ... ... ... ... ... ... ... |
| |
| Update the second paragraph on page 159, in the definition of |
| CopyTexImage2D, to say: |
| |
| "...The image is taken from the framebuffer exactly as if these |
| arguments were passed to CopyPixels with argument type set to COLOR |
| DEPTH, or DEPTH_STENCIL_EXT, depending on <internalformat>, stopping |
| after pixel transfer processing is complete. RGBA data is taken |
| from the current color buffer, while depth component and stencil |
| index data are taken from the depth and stencil buffers, |
| respectively. If depth component data is required and no depth |
| buffer is present, or if stencil index data is required and there is |
| no stencil buffer, the error INVALID_OPERATION is generated. |
| Subsequent processing is identical to that described for TexImage2D, |
| beginning with clamping of the R, G, B, A, or depth values, and |
| masking of the stencil index value, from the resulting pixel |
| groups..." |
| |
| Update the third paragraph on page 161 to say: |
| |
| "...except that the assignment of R, G, B, A, depth, and stencil |
| pixel group values to the texture components is controlled by the |
| internalformat of the texture array, not by an argument to the |
| command..." |
| |
| Update section 3.8.5 "Depth Component Textures" (page 168) to say: |
| |
| "Depth textures and the depth components of depth/stencil textures |
| can be treated as LUMINANCE, INTENSITY or ALPHA textures during |
| texture filtering and application. The initial state for depth and |
| depth/stencil textures treats them as LUMINANCE textures." |
| |
| Add a new section between sections 3.8.9 and 3.8.10, after the first |
| paragraph on page 177: |
| |
| "3.8.9-1/2 DEPTH/STENCIL Textures |
| |
| If the texture image has a base internal format of |
| DEPTH_STENCIL_EXT, then the stencil index texture component is |
| ignored. The texture value Tau does not include a stencil index |
| component, but includes only the depth component." |
| |
| Update the first paragraph of section 3.8.11 "Texture State and |
| Proxy State" on page 178 to say: |
| |
| "...eight integer values describing the resolutions of each of the |
| red, green, blue, alpha, luminance, intensity, depth, and stencil |
| components of the image..." |
| |
| Update the second paragraph on page 179 to say: |
| |
| "... and internal format state values, as well as state for the red, |
| green, blue, alpha, luminance, intensity, depth, and stencil |
| component resolutions." |
| |
| Update the first paragraph of "Depth Texture Comparison Mode" in |
| section 3.8.14 on page 188 to say: |
| |
| "If the currently bound texture's base internal format is |
| DEPTH_COMPONENT or DEPTH_STENCIL_EXT..." |
| |
| Update the first paragraph of section 3.8.15 "Texture Application", |
| on page 189, to say: |
| |
| "...Otherwise, a texture value is found according to the parameter |
| values of the currently bound texture image of the appropriate |
| dimensionality using the rules given in sections 3.8.6 through |
| 3.8.9. Note that the texture value may contain R, G, B, A, L, I, or |
| D components, but it does not contain an S component. If the |
| texture's base internal format is DEPTH_STENCIL_EXT, for the |
| purposes of texture application, it is as if the base internal |
| format was DEPTH..." |
| |
| Starting with the bullet list on page 195, update section 3.11.2 |
| "Shader Execution" to say: |
| |
| "* The sampler used in a texture lookup function is of type |
| sampler1D or sampler2D, and the texture object's base internal |
| format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT, and the |
| TEXTURE_COMPARE_MODE is not NONE. |
| |
| * The sampler used in a texture lookup function is of type |
| sampler1DShadow or sampler2DShadow, and the texture object's base |
| internal format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT, and the |
| TEXTURE_COMPARE_MODE is NONE. |
| |
| * The sampler used in a texture lookup function is of type |
| sampler1DShadow or sampler2DShadow, and the texture object's base |
| internal format is not DEPTH_COMPONENT or DEPTH_STENCIL_EXT. |
| |
| The stencil index texture internal component is ignored if the base |
| internal format is DEPTH_STENCIL_EXT. |
| |
| If a fragment shader uses..." |
| |
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| Replace section 4.3.1 "Writing to the Stencil Buffer" (page 218) |
| with the following: |
| |
| "4.3.1 Writing to the Stencil Buffer or to the Depth and Stencil |
| Buffers |
| |
| The operation of DrawPixels was described in section 3.6.4, except |
| if the <format> argument was STENCIL_INDEX or DEPTH_STENCIL_EXT. In |
| this case, all operations described for DrawPixels take place, but |
| window (x,y) coordinates, each with the corresponding stencil index, |
| or depth value and stencil index, are produced in lieu of fragments. |
| Each coordinate-data pair is sent directly to the per-fragment |
| operations, bypassing the texture, fog, and antialiasing application |
| stages of rasterization. Each pair is then treated as a fragment |
| for purposes of the pixel ownership and scissor tests; all other |
| per-fragment operations are bypassed. Finally, each stencil index |
| is written to its indicated location in the framebuffer, subject to |
| the current front stencil mask (set with StencilMask or |
| StencilMaskSeparate). If a depth component is present, and if the |
| setting of DepthMask is not FALSE, the depth component is also |
| written to the framebuffer; the setting of DepthTest is ignored. |
| |
| The error INVALID_OPERATION results if the <format> argument is |
| STENCIL_INDEX and there is no stencil buffer, or if <format> is |
| DEPTH_STENCIL_EXT and there is neither a depth nor a stencil |
| buffer." |
| |
| Add the following paragraph after the second paragraph of the |
| section "Obtaining Pixels from the Framebuffer" (page 219): |
| |
| "If the <format> is DEPTH_STENCIL_EXT, then values are taken from |
| both the depth buffer and the stencil buffer. If there is no depth |
| buffer or if there is no stencil buffer, then the error |
| INVALID_OPERATION occurs. If the <type> parameter is not |
| UNSIGNED_INT_24_8_EXT, then the error INVALID_ENUM occurs. |
| |
| If there is a multisample buffer, then values are obtained from the |
| depth and stencil samples in this buffer. It is recommended that the |
| depth and stencil values of the centermost sample be used, though |
| implementations may choose any function of the depth and stencil |
| sample values at each pixel." |
| |
| Update the third paragraph on page 221 to say: |
| |
| "... If the GL is in color index mode, and <format> is not |
| DEPTH_COMPONENT, STENCIL_INDEX, or DEPTH_STENCIL_EXT, then the color |
| index is obtained at each pixel location." |
| |
| Update the first sentence of the section "Conversion of RGBA values" |
| (page 222) to say: |
| |
| "This step applies only if the GL is in RGBA mode, and then only if |
| <format> is neither STENCIL_INDEX, DEPTH_COMPONENT, nor |
| DEPTH_STENCIL_EXT." |
| |
| Update the section "Conversion of Depth values" (page 222) to say: |
| |
| "This step applies only if <format> is DEPTH_COMPONENT or |
| DEPTH_STENCIL_EXT. Each element taken from the depth buffer is |
| taken to be a fixed-point value in [0,1] with m bits, where m is the |
| number of bits in the depth buffer (see section 2.11.1)." |
| |
| Add a row to Table 4.6 (page 223): |
| |
| type Parameter Index Mask |
| --------------------------------- |
| ... ... |
| INT 2^31-1 |
| UNSIGNED_INT_24_8_EXT 2^8-1 |
| |
| Update the second and third paragraphs of section 4.3.3 (page 223) |
| to say: |
| |
| "<type> is a symbolic constant that must be one of COLOR, STENCIL, |
| DEPTH, or DEPTH_STENCIL_EXT, indicating that the values to be |
| transferred are colors, stencil values, depth values, or |
| depth/stencil pairs, respectively. The first four arguments have the |
| same interpretation as the corresponding arguments to ReadPixels. |
| |
| Values are obtained from the framebuffer, converted (if |
| appropriate), then subjected to the pixel transfer operations |
| described in section 3.6.5, just as if ReadPixels were called with |
| the corresponding arguments. If the <type> is STENCIL or DEPTH, |
| then it is as if the <format> for ReadPixels were STENCIL_INDEX, or |
| DEPTH_COMPONENT, respectively. If the <type> is DEPTH_STENCIL_EXT, |
| then it is as if the <format> for ReadPixels were specified as |
| described in table 4.6b. If the <type> is COLOR, then if the GL is |
| in RGBA mode, it is as if the <format> were RGBA, while if the GL is |
| in color index mode, it is as if the <format> were COLOR_INDEX." |
| |
| Add Table 4.6b: |
| |
| DEPTH_BITS STENCIL_BITS format |
| ------------------------------------------- |
| zero zero DEPTH_STENCIL_EXT |
| zero non-zero DEPTH_COMPONENT |
| non-zero zero STENCIL_INDEX |
| non-zero non-zero DEPTH_STENCIL_EXT |
| |
| Table 4.6b: Effective ReadPixels format for DEPTH_STENCIL_EXT |
| CopyPixels operation. |
| |
| Add a row to Table 4.7 (page 224): |
| |
| type Parameter GL Type Component Conversion ... |
| ------------------------------------------------------------------ |
| ... ... ... |
| UNSIGNED_INT_2_10_10_10_REV uint c = (2^N - 1)f |
| UNSIGNED_INT_24_8_EXT uint c = (2^N - 1)f (depth only) |
| |
| Additions to Chapter 4 of the OpenGL 2.0 Specification, as modified by |
| the EXT_framebuffer_object specification |
| |
| In section 4.4.2.1 "Renderbuffer Objects", modify the first |
| paragraph in the definition of RenderbufferStorageEXT to say: |
| |
| "... <internalformat> must be RGB, RGBA, DEPTH_COMPONENT, |
| STENCIL_INDEX, DEPTH_STENCIL_EXT, or one of the internal formats |
| from table 3.16 or table 2.nnn that has a base internal format of |
| RGB, RGBA, DEPTH_COMPONENT, STENCIL_INDEX, or DEPTH_STENCIL_EXT..." |
| |
| In section 4.4.4 "Framebuffer Completeness", modify the definition of |
| "depth-renderable" and "stencil-renderable" to say: |
| |
| "* An internal format is "depth-renderable" if it is |
| DEPTH_COMPONENT or one of the formats from table 3.16 whose |
| base internal format is DEPTH_COMPONENT or DEPTH_STENCIL_EXT. |
| No other formats are depth-renderable. |
| |
| * An internal format is "stencil-renderable" if it is |
| STENCIL_INDEX or DEPTH_STENCIL_EXT, if it is one of the |
| STENCIL_INDEX formats from table 2.nnn, or if it is one of the |
| formats from table 3.16 whose base internal format is |
| DEPTH_STENCIL_EXT. No other formats are stencil-renderable." |
| |
| In section 4.4.4.2 "Framebuffer Completeness", modify the |
| duplicate attachment clause of "framebuffer complete" to say: |
| |
| "* A single image is not attached more than once to the framebuffer |
| object. The exception is that an image with a DEPTH_STENCIL_EXT |
| base internal format may be simultaneously attached to both |
| FRAMEBUFFER_DEPTH_ATTACHMENT and FRAMEBUFFER_STENCIL_ATTACHMENT. |
| { FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT }" |
| |
| Additions to Chapter 5 of the OpenGL 2.0 Specification (Special |
| Functions) |
| |
| None. |
| |
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State |
| Requests) |
| |
| Update the third paragraph on page 247, of section 6.1.3 "Enumerated |
| Queries", to say: |
| |
| "For texture images with uncompressed internal formats, queries of |
| value of TEXTURE_RED_SIZE, TEXTURE_GREEN_SIZE, TEXTURE_BLUE_SIZE, |
| TEXTURE_ALPHA_SIZE, TEXTURE_LUMINANCE_SIZE, TEXTURE_INTENSITY_SIZE, |
| TEXTURE_DEPTH_SIZE, and TEXTURE_STENCIL_SIZE_EXT return the actual |
| resolutions of the stored image array components..." |
| |
| Section 6.1.4, Texture Queries, p. 248, replace the first two |
| sentences of paragraph two as follows: |
| |
| "Calling GetTexImage with a color format (one of RED, GREEN, |
| BLUE, ALPHA, RGB, BGR, RGBA, BGRA, LUMINANCE, or |
| LUMINANCE_ALPHA) when the internal format of the texture image |
| is not a color format causes the error INVALID_OPERATION. |
| |
| Calling GetTexImage with a <format> of DEPTH_COMPONENT when the |
| base internal format of the texture image is not DEPTH_COMPONENT |
| or DEPTH_STENCIL_EXT causes the error INVALID_OPERATION. |
| |
| Calling GetTexImage with a <format> of DEPTH_STENCIL_EXT when |
| the base internal format of the texture image is not |
| DEPTH_STENCIL_EXT causes the error INVALID_OPERATION. |
| |
| GetTexImage obtains component groups from a texture image with |
| the indicated level-of-detail. If <format> is a color format, |
| then the components are assigned among R, G, B, and A according |
| to Table 6.1, starting with the first group in the first row, |
| and continuing by obtaining groups in order from each row and |
| proceeding from the first row to the last, and from the first |
| image to the last for three-dimensional textures. If <format> |
| is DEPTH_COMPONENT, then each depth component is assigned with |
| the same ordering of rows and images. If <format> is |
| DEPTH_STENCIL_EXT, then each depth component and each stencil |
| index is assigned with the same ordering of rows and images." |
| |
| Add a row to table 6.17 "Textures (state per texture image)" on page |
| 278: |
| |
| Get value Type Get Cmd IV Description Sec. |
| ------------------------------------------------------------------------------------------------------- |
| ... ... ... ... ... ... |
| TEXTURE_STENCIL_SIZE_EXT n x Z+ GetTexLevelParameter 0 texture image's intensity resolution 3.8.3 |
| |
| Update |
| |
| Dependencies on EXT_framebuffer_object |
| |
| If EXT_framebuffer_object is not supported, then all discussion of |
| framebuffer objects and renderbuffer objects should be removed. |
| |
| GLX Protocol |
| |
| None. |
| |
| Errors |
| |
| The error INVALID_ENUM is generated if DrawPixels or ReadPixels is |
| called where format is DEPTH_STENCIL_EXT and type is not |
| UNSIGNED_INT_24_8_EXT. |
| |
| The error INVALID_OPERATION is generated if DrawPixels or ReadPixels |
| is called where type is UNSIGNED_INT_24_8_EXT and format is not |
| DEPTH_STENCIL_EXT. |
| |
| The error INVALID_OPERATION is generated if DrawPixels or ReadPixels |
| is called where format is DEPTH_STENCIL_EXT and there is not both a |
| depth buffer and a stencil buffer. |
| |
| The error INVALID_OPERATION is generated if CopyPixels is called |
| where type is DEPTH_STENCIL_EXT and there is not both a depth buffer |
| and a stencil buffer. |
| |
| Update the following error in the EXT_framebuffer_object |
| specification by adding mention of DEPTH_STENCIL_EXT formats: |
| |
| "The error INVALID_ENUM is generated if RenderbufferStorageEXT is |
| called with an <internalformat> that is not RGB, RGBA, |
| DEPTH_COMPONENT, STENCIL_INDEX, DEPTH_STENCIL_EXT, or one of the |
| internal formats from table 3.16 or table 2.nnn that has a base |
| internal format of RGB, RGBA, DEPTH_COMPONENT, STENCIL_INDEX, or |
| DEPTH_STENCIL_EXT." |
| |
| New State |
| |
| None. |
| |
| Usage ExampleS |
| |
| (1) Attach a DEPTH_STENCIL_EXT texture image to an FBO as both the |
| depth and stencil buffers. |
| |
| glGenFramebuffersEXT(1, &fb); |
| glGenTextures(1, &tex_color); |
| glGenTextures(1, &tex_depthstencil); |
| |
| glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb); |
| |
| // Setup color texture (mipmap) |
| glBindTexture(GL_TEXTURE_2D, tex_color); |
| glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, |
| 512, 512, 0, GL_RGBA, GL_INT, NULL); |
| glGenerateMipmapEXT(GL_TEXTURE_2D); |
| glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, |
| GL_COLOR_ATTACHMENT0_EXT, |
| GL_TEXTURE_2D, tex_color, 0); |
| |
| // Setup depth_stencil texture (not mipmap) |
| glBindTexture(GL_TEXTURE_2D, tex_depthstencil); |
| glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); |
| glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT, |
| 512, 512, 0, GL_DEPTH_STENCIL_EXT, |
| GL_UNSIGNED_INT_24_8_EXT, NULL); |
| glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, |
| GL_DEPTH_ATTACHMENT_EXT, |
| GL_TEXTURE_2D, tex_depthstencil, 0); |
| glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, |
| GL_STENCIL_ATTACHMENT_EXT, |
| GL_TEXTURE_2D, tex_depthstencil, 0); |
| |
| // Check framebuffer completeness at the end of initialization. |
| |
| loop { |
| glBindTexture(GL_TEXTURE_2D, 0); |
| glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb); |
| <render to color, depth, and stencil textures> |
| glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); |
| |
| glBindTexture(GL_TEXTURE_2D, tex_color); |
| glGenerateMipmapEXT(GL_TEXTURE_2D); |
| <draw to the window, reading from the color texture> |
| |
| glBindTexture(GL_TEXTURE_2D, tex_depthstencil); |
| <draw to the window, reading depth from the depthstencil texture> |
| } |
| |
| Issues |
| |
| 01) Depth data has a format of GL_DEPTH_COMPONENT, and stencil data |
| has a format of STENCIL_INDEX. So shouldn't the enumerant be |
| called DEPTH_COMPONENT_STENCIL_INDEX_EXT? |
| |
| RESOLVED: No, this is fairly clumsy. |
| |
| 02) Should we support CopyPixels? |
| |
| RESOLVED: Yes. Right now copying stencil data means masking off |
| just the stencil bits, while copying depth data has strange |
| unintended consequences (fragment operations) and is difficult |
| to implement. It is easy and useful to add CopyPixels support. |
| |
| 03) Should we support textures? |
| |
| RESOLVED: Yes. 24-bit depth textures have no good format |
| without this extension. |
| |
| 04) Should the depth/stencil format support other standard types, |
| like FLOAT or 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. |
| |
| 05) Should the 24/8 format be supported for other formats, such as |
| LUMINANCE_ALPHA? Should we support an 8/24 reversed format as |
| well? |
| |
| RESOLVED: No and no, this adds implementation burden and gains |
| us little, if anything. |
| |
| 06) Should anything be said about performance? |
| |
| RESOLVED: No, not in the spec. However, common sense should |
| apply. Apps should probably check that DEPTH_BITS is 24 and |
| that STENCIL_BITS is 8 before using either the new DrawPixels or |
| ReadPixels formats. CopyPixels is probably safe regardless of |
| the size of either buffer. The 24/8 format should probably only |
| be used with 24-bit depth textures. |
| |
| 07) What happens when the format of a DEPTH_STENCIL_EXT pixel path |
| operation specifies more components than are present in the |
| source? |
| |
| RESOLVED: INVALID_OPERATION is generated. |
| |
| Operations affected by this issue include ReadPixels and |
| operations defined in terms of ReadPixels, such as CopyPixels, |
| CopyTexImage, CopyTexSubImage, and GetTexImage. |
| |
| For example, if the framebuffer has non-zero DEPTH_BITS but zero |
| STENCIL_BITS, then ReadPixels of DEPTH_COMPONENT is legal. But |
| ReadPixels of DEPTH_STENCIL_EXT will generate INVALID_OPERATION. |
| |
| 08) What happens when the format of a DEPTH_STENCIL_EXT pixel path |
| operation specifies more components than are present in the |
| destination? |
| |
| RESOLVED: The extra information is thrown away. No GL error is |
| generated because the source contains more components than the |
| destination. |
| |
| For example, consider a TexSubImage operation where the source |
| data is DEPTH_STENCIL_EXT but the existing texture format is |
| DEPTH_COMPONENT. |
| |
| 09) What happens when the format of a DEPTH_STENCIL_EXT pixel path |
| operation specifies fewer components than are present in the |
| destination? |
| |
| RESOLVED: the existing values of the unspecified components are |
| preserved. |
| |
| For example, consider a TexSubImage operation where the <format> |
| is DEPTH_COMPONENT and the existing internalformat is |
| DEPTH_STENCIL_EXT. The texture image's depth component will be |
| updated, but the texture's existing stencil component will be |
| preserved. |
| |
| 10) And, for completeness, what happens when the format of a |
| DEPTH_STENCIL_EXT pixel path operation specifies fewer |
| components than are present in the source? |
| |
| RESOLVED: trivial. Only the specified components are read. |
| |
| 11) How does the texture border color interact with a |
| DEPTH_STENCIL_EXT texture? |
| |
| RESOLVED: nothing special needs to be stated here. |
| |
| There is no stencil component in the border color. Either |
| you're rendering to it, in which case it's just a buffer, or |
| texturing from it, in which case stencil is irrelevant. If a |
| future use case comes up, the second component of |
| TEXTURE_BORDER_COLOR could be used at the stencil border value, |
| just as the first component is used as the depth value today. |
| |
| 12) How does automatic mipmap generation deal with the stencil |
| component of a DEPTH_STENCIL_EXT texture? |
| |
| RESOLVED: The 2.0 spec doesn't talk about depth textures |
| specifically. Stencils, which are indexes / counts, are even |
| harder. We'll leave this undefined. |
| |
| Also, an application that wants to generate a stencil mipmap can |
| follow the procedure given in example 5 of the |
| EXT_framebuffer_object specification. |
| |
| 13) Should GetTexImage permit <format> of DEPTH_STENCIL_EXT? |
| |
| RESOLVED: Yes. |
| |
| The GL 2.0 spec disallows GetTexImage of DEPTH_COMPONENT data. |
| But that seems to be an unintentional spec bug. |
| ARB_depth_texture permitted it and even addressed the question |
| as issue 9. Appendix G.4 of the GL 2.0 spec does not mention |
| this discrepancy. |
| |
| GetTexImage of DEPTH_STENCIL_EXT format should follow the |
| resolution for GetTexImage of DEPTH_COMPONENT format. |
| |
| A future version of the core GL spec will be modified to state |
| that GetTexImage of DEPTH_COMPONENT data is legal. |
| |
| 14) Does DrawPixels with DEPTH_STENCIL_EXT format behave like |
| DrawPixels of DEPTH_COMPONENT format, or like DrawPixels of |
| STENCIL_INDEX format? |
| |
| RESOLVED: It behaves like DrawPixels of STENCIL_INDEX format. |
| |
| See sections 3.6.4 and 4.3.1. It is desirable to give similar |
| treatment to both the depth and the stencil components. |
| |
| 15) If depth/stencil images are mixed such that they violate the |
| framebuffer completeness rule in section 4.4.4.2, what |
| FRAMEBUFFER_INCOMPLETE_ enum should be used? |
| |
| UNRESOLVED: FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT and |
| FRAMEBUFFER_INCOMPLETE_MIXED_DEPTH_STENCIL_EXT are possible |
| answers. |
| |
| 16) What happens if DEPTH_STENCIL_EXT and STENCIL_ATTACHMENT_EXT |
| name distinct framebuffer-attachable images, but the format of |
| one or both is DEPTH_STENCIL_EXT? |
| |
| RESOLVED: This is permitted. The depth component of the depth |
| attachment should be updated, the stencil component of the |
| stencil attachment should be updated, and the other components |
| are preserved. However, it should be noted that some |
| implementations might not support such mix-matching, and that |
| these implementations are free to label such a framebuffer as |
| FRAMEBUFFER_UNSUPPORTED_EXT. |
| |
| An earlier drafts of this extension contained the following |
| language. |
| |
| In section 4.4.4.2 "Framebuffer Completeness", add a clause |
| to the definition of "framebuffer complete": |
| |
| "* If both attachment points FRAMEBUFFER_DEPTH_ATTACHMENT |
| and FRAMEBUFFER_STENCIL_ATTACHMENT have an attached |
| image, and if either image's base internal format is |
| DEPTH_STENCIL_EXT, then the same image must be attached |
| to both FRAMEBUFFER_DEPTH_ATTACHMENT and |
| FRAMEBUFFER_STENCIL_ATTACHMENT. |
| { FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT }" |
| |
| That clause was removed from section 4.4.4.2 in revision #10 |
| after it was pointed out that, on implementations where such |
| mix-matching is supported, it need not result in an incomplete |
| framebuffer. |
| |
| Revision History |
| |
| #12 September 26, 2005 |
| - Fix copy/paste error in the example. |
| |
| #11 September 20, 2005 |
| - Assign enum values. |
| |
| #10 September 19, 2005 |
| - Remove FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT clause and add the |
| accompanying issue 16 explaining why. |
| |
| #09 September 19, 2005 |
| - Add issue 15. |
| - Fix FBO interaction. (depth_stencil can be attached twice) |
| - Add Usage Examples section and example 1. |
| - Move issues to the end according to new precedent. |
| - Add more dependencies, add contributors. |
| - Fix typos pointed out at ARB meeting. |
| |
| #08 September 9, 2005 |
| - Resolve issues 13 and 14. |
| - Add issue 10 for completeness. |
| - Modify GetTexImage to permit depth and depth/stencil. |
| - Incorporate feedback from Barthold's review. |
| |
| #07 August 29, 2005 |
| - Record resolutions for issues 7-12. |
| - Update the spec body to reflect the issue resolutions. |
| - Add new issues 13-14. |
| - Remove interaction with copy_depth_to_color (no resolution needed) |
| |
| #06 July 15, 2005 |
| - Improve some wording in the issues section. |
| - Add issue on interaction with NV_copy_depth_to_color. |
| - Remove interaction with stenci_clear_tag (no resolution needed) |
| |
| #05 June 20, 2005 |
| - Add (now removed) unresolved issue 12 on interactions with |
| EXT_stencil_clear_tag. |
| |
| #04 June 10, 2005 |
| - Add modifications to the EXT_framebuffer_object specification. |
| |
| #03 May 28, 2005 |
| - Add DEPTH_STENCIL_EXT as a new base internal format, |
| - Add DEPTH24_STENCIL8_EXT as a new sized internal format. |
| |
| #02 May 12, 2005 |
| - Update to be written against OpenGL 2.0 specification. |
| |
| #01 May 12, 2005 |
| - Start with NV_packed_depth_stencil as the basis for |
| EXT_packed_depth_stencil. |
| - Rename to EXT. |