Bug 97790 - Vulkan cts regressions due to 24be63066
Summary: Vulkan cts regressions due to 24be63066
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Jason Ekstrand
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-13 16:23 UTC by Mark Janes
Modified: 2016-09-13 17:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Janes 2016-09-13 16:23:01 UTC
Several hundred tests regressed with

24be6306609179efddfb7e5cc6ec5d6a335c9b88
Author:     Jason Ekstrand <jason@jlekstrand.net>

Revert "i965: Drop the maximum 3D texture size to 512 on Sandy Bridge"

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>


Jason already has a fix tested but not reviewed.
Comment 1 Jason Ekstrand 2016-09-13 16:26:19 UTC
(In reply to Mark Janes from comment #0)
> Several hundred tests regressed with
> 
> 24be6306609179efddfb7e5cc6ec5d6a335c9b88
> Author:     Jason Ekstrand <jason@jlekstrand.net>
> 
> Revert "i965: Drop the maximum 3D texture size to 512 on Sandy Bridge"

Actually, the regression is do to

commit 48f195d7c6483ed00a6d02526c6f35bb527fcaba
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Mon Sep 12 08:13:43 2016 -0700

    intel/isl: Treat 3-D textures as 2-D arrays for rendering
    
    In particular, this means that isl_view::base_array_layer and
    isl_view::array_len get applied to 3-D textures but only when rendering.
    We were already applying isl_view::base_array_layer for rendering into 3-D
    textures so this isn't a huge deviation.
    
    Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Comment 2 Jason Ekstrand 2016-09-13 17:47:18 UTC
Should be fixed by

commit 3943888c94beca69e575b8d3d1ec7a6cbf474ee4
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Mon Sep 12 22:31:00 2016 -0700

    intel/isl: Ignore base_array_layer and array_len for 3D storage surfaces
    
    The time we want to restrict the Z range of a 3-D surface is when rendering
    to it.  For storage surfaces, we always want he full range.  However, we
    still need to set MinimumArrayElement and RenderTargetViewExtent to
    sensible values so we'll just set them to the reasonable defaults we used
    before we started respecting the base_array_layer and array_len.
    
    This fixes a bunch of Vulkan CTS regressions caused by 48f195d7c6483ed.
    
    Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97790
    Reviewed-by: Chad Versace <chadversary@chromium.org>


bug/show.html.tmpl processed on Feb 19, 2017 at 16:41:09.
(provided by the Example extension).