[Mesa-dev] [PATCH 2/2] intel/isl: Only create a CCS buffer if the surface format supports it

[Nanley Chery]

On Tue, Apr 18, 2017 at 07:58:37PM -0700, Jason Ekstrand wrote:
> On Tue, Apr 18, 2017 at 4:31 PM, Nanley Chery <nanleychery at gmail.com> wrote:
> 
> > Signed-off-by: Nanley Chery <nanley.g.chery at intel.com>
> > ---
> >  src/intel/isl/isl.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > index f89f351c15..09dafcbab6 100644
> > --- a/src/intel/isl/isl.c
> > +++ b/src/intel/isl/isl.c
> > @@ -1573,8 +1573,11 @@ isl_surf_get_ccs_surf(const struct isl_device *dev,
> >     if (ISL_DEV_GEN(dev) <= 8 && surf->dim != ISL_SURF_DIM_2D)
> >        return false;
> >
> > -   if (isl_format_is_compressed(surf->format))
> > +   if (!isl_format_supports_ccs_d(dev->info, surf->format)) {
> > +      /* CCS_E supported formats are a subset of CCS_D supported formats.
> > */
> > +      assert(!isl_format_supports_ccs_e(dev->info, surf->format));
> >
> 
> The code we have today fails to create a CCS under *almost* the same
> conditions.  The one case this covers but the original code does not is if
> you have a non-renderable format which happens to be 32, 64, or 128 bpb.
> One such format is R9G9B9E5.  With these exotic formats, your new code will
> return false while the old code will go ahead and create a CCS.  However,
> even with one of these exotic formats, you could create a view that does
> have a renderable format and that view could have CCS_D enabled so long as
> it's resolve before the non-renderable format is used for texturing.  I'm
> not sure if that's a case we care about or not, but it is valid.
> 
> 

You're right. I suppose I should just use the rendering helper. Does the
image view case you've mentioned only exist in GL? In Vulkan, the color
attachment is required to have the same format as the image.