On Mon, Apr 14, 2014 at 1:04 PM, Kenneth Graunke <kenn...@whitecape.org> wrote: > 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 s/batch/patch/
Both patches look good to me. Unless I overlooked your patch for piglit, this is needed http://lists.freedesktop.org/archives/piglit/2014-February/009650.html to avoid a false regression. It would be great if you could review and commit the piglit fix, as I do not have commit access. > Z16 to be used. It's not required, and there's apparently no benefit > to actually using it. > > Signed-off-by: Kenneth Graunke <kenn...@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 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
