[Mesa-dev] [PATCH 2/2] i965: Disable Z16 in all APIs.

[Kenneth Graunke]

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 batch 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 <kenneth at whitecape.org>
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 6 ------
 1 file changed, 6 deletions(-)

Sorry if this is a duplicate of an earlier patch...the only one I could
find in my inbox was the one with the driconf option.

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 196f139..5907dd9 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.
-- 
1.9.2