summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2014-04-13 14:19:03 -0700
committerKenneth Graunke <[email protected]>2014-04-15 02:15:11 -0700
commit4f20b7d3ddaac1d9f7822ef1b9cbed07b3ef35fe (patch)
tree85fd95378be9ca553c89cb29f5a46fc523a39f98
parentbe000b4d1911d2d520ec7b2366403d2ae3cf8bdc (diff)
i965: Disable Z16 in all APIs.
We originally thought that GL 3.0 required GL_DEPTH_COMPONENT16 to map exactly to Z16. However, we misread the specification, thanks in part to LaTeX reordering the tables in the PDF. Page 180 of the GL 3.0 specification (glspec30.20080923.pdf) says: "[...] memory allocation per texture component is assigned by the GL to match the allocations listed in tables 3.16-3.18 as closely as possible. [...] Required Texture Formats [...] In addition, implementations are required to support the following sized internal formats. Requesting one of these internal formats for any texture type will allocate exactly the internal component sizes and types shown for that format in tables 3.16-3.17:" Notably, however, GL_DEPTH_COMPONENT16 does /not/ appear in table 3.16 or table 3.17. It appears in table 3.18, where the "exact" rule doesn't apply, and it falls back to the "closely as possible" rule. The confusing part is that the ordering of the tables in the PDF is: Table 3.16 (pages 182-184) Table 3.18 (bottom of page 184 to top of 185) Table 3.17 (page 185) Presumably, people saw table 3.16, then saw the table immediately following with DEPTH_COMPONENT* formats, and assumed it was 3.17. Based on a patch by Chia-I Wu, but without the driconf option to force Z16 to be used. It's not required, and there's apparently no benefit to actually using it. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chia-I Wu <[email protected]>
-rw-r--r--src/mesa/drivers/dri/i965/brw_surface_formats.c6
1 files changed, 0 insertions, 6 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 196f13930d0..5907dd9419a 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -608,7 +608,6 @@ brw_init_surface_formats(struct brw_context *brw)
brw->format_supported_as_render_target[MESA_FORMAT_Z24_UNORM_S8_UINT] = true;
brw->format_supported_as_render_target[MESA_FORMAT_Z24_UNORM_X8_UINT] = true;
brw->format_supported_as_render_target[MESA_FORMAT_S_UINT8] = true;
- brw->format_supported_as_render_target[MESA_FORMAT_Z_UNORM16] = true;
brw->format_supported_as_render_target[MESA_FORMAT_Z_FLOAT32] = true;
brw->format_supported_as_render_target[MESA_FORMAT_Z32_FLOAT_S8X24_UINT] = true;
@@ -630,12 +629,7 @@ brw_init_surface_formats(struct brw_context *brw)
*
* Other speculation is that we may be hitting increased fragment shader
* execution from GL_LEQUAL/GL_EQUAL depth tests at reduced precision.
- *
- * However, desktop GL 3.0+ require that you get exactly 16 bits when
- * asking for DEPTH_COMPONENT16, so we have to respect that.
*/
- if (_mesa_is_desktop_gl(ctx))
- ctx->TextureFormatSupported[MESA_FORMAT_Z_UNORM16] = true;
/* On hardware that lacks support for ETC1, we map ETC1 to RGBX
* during glCompressedTexImage2D(). See intel_mipmap_tree::wraps_etc1.