On Wed 12 Jul 2017, Jason Ekstrand wrote:
> On Wed, Jul 12, 2017 at 11:18 AM, Chad Versace <[1]chadvers...@chromium.org>
> wrote:
>
> On Thu 29 Jun 2017, Jason Ekstrand wrote:
> > Reviewed-by: Topi Pohjolainen <[2]topi.pohjolai...@intel.com>
> > ---
> > src/mesa/drivers/dri/i965/intel_screen.c | 55
> +++++++++++++++++++++++++++++---
> > 1 file changed, 50 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/
> dri/i965/intel_screen.c
> > index 03226af..66fd99a 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -671,7 +671,21 @@ intel_create_image_common(__DRIscreen *dri_screen,
> > return NULL;
> > }
> >
> > - image->bo = brw_bo_alloc_tiled(screen->bufmgr, "image", surf.size,
> > + struct isl_surf aux_surf;
> > + if (mod_info->aux_usage == ISL_AUX_USAGE_CCS_E) {
> > + ok = isl_surf_get_ccs_surf(&screen->isl_dev, &surf, &aux_surf,
> 0);
> > + assert(ok);
> > + if (!ok) {
>
> Why assert(ok) then handle !ok ?
>
>
> I should probably drop the assert. This is definitely something that can
> happen if you try to import an image with bad CCS information. I thought
> maybe
> asserting in debug builds would be useful. Thoughs?
If it's an error that we recover from, then it's better to emit
an error message. Or, alternatively, do the assert and delete the
recovery code.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
