KonstantinSeurer
/
mesa
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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 <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
This commit is contained in:
Kenneth Graunke 2014-04-13 14:19:03 -07:00
parent be000b4d19
commit 4f20b7d3dd
1 changed files with 0 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/mesa/drivers/dri/i965/brw_surface_formats.c
View File

@ -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.