This reverts commit
6ba88bce64b343761aabe3a6c7ee285c6020a959. The commit
was erroneous because GL has a separate limit, GL_MAX_FRAMEBUFFER_LAYERS
which guards the number of layers you are allowed to render into.
The GL 4.5 spec says:
"The framebuffer attachment point attachment is said to be framebuffer
attachment complete if [...] all of the following conditions are true:
[...]
If image is a three-dimensional, one- or two-dimensional array, or
cube map array texture and the attachment is layered, the depth or
layer count of the texture is less than or equal to the value of the
implementation-dependent limit MAX_FRAMEBUFFER_LAYERS."
and goes on to say that "framebuffer complete" requires all attachments to
be "framebuffer attachment complete".
On Sandy Bridge, we set GL_MAX_FRAMEBUFFER_LAYERS to 512 so creating a 3D
texture bigger than 512 is fine; you just can't render into all of the
slices at once.
Fixes ES3-CTS.gtf.GL3Tests.npot_textures.npot_tex_image on Sandy Bridge
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chadversary@chromium.org>
ctx->Const.MaxImageUnits = MAX_IMAGE_UNITS;
ctx->Const.MaxRenderbufferSize = 8192;
ctx->Const.MaxTextureLevels = MIN2(14 /* 8192 */, MAX_TEXTURE_LEVELS);
-
- /* On Sandy Bridge and prior, the "Render Target View Extent" field of
- * RENDER_SURFACE_STATE is only 9 bits so the largest 3-D texture we can do
- * a layered render into has a depth of 512. On Iron Lake and earlier, we
- * don't support layered rendering and we use manual offsetting to render
- * into the different layers so this doesn't matter. On Sandy Bridge,
- * however, we do support layered rendering so this is a problem.
- */
- ctx->Const.Max3DTextureLevels = brw->gen == 6 ? 10 /* 512 */ : 12; /* 2048 */
-
+ ctx->Const.Max3DTextureLevels = 12; /* 2048 */
ctx->Const.MaxCubeTextureLevels = 14; /* 8192 */
ctx->Const.MaxArrayTextureLayers = brw->gen >= 7 ? 2048 : 512;
ctx->Const.MaxTextureMbytes = 1536;