I wonder if we could lose mt->first_level entirely? It looks like it's always going to be zero in i965 now.
On Sat, Feb 1, 2014 at 10:10 PM, Kenneth Graunke <[email protected]> wrote: > In commit 16060c5adcd4d809f97e874fcde763260c17ac18, Eric changed the > code to not relayout just for baselevel changes - only if the range of > miplevels actually increases. So this comment is now wrong. > > Notably, the i915 version of the code actually does what the comment > says. > > Signed-off-by: Kenneth Graunke <[email protected]> > --- > src/mesa/drivers/dri/i965/intel_tex_validate.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c > b/src/mesa/drivers/dri/i965/intel_tex_validate.c > index d8497a6..e4587fc 100644 > --- a/src/mesa/drivers/dri/i965/intel_tex_validate.c > +++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c > @@ -102,11 +102,6 @@ intel_finalize_mipmap_tree(struct brw_context *brw, > GLuint unit) > > /* Check tree can hold all active levels. Check tree matches > * target, imageFormat, etc. > - * > - * For pre-gen4, we have to match first_level == tObj->BaseLevel, > - * because we don't have the control that gen4 does to make min/mag > - * determination happen at a nonzero (hardware) baselevel. Because > - * of that, we just always relayout on baselevel change. > */ > if (intelObj->mt && > (!intel_miptree_match_image(intelObj->mt, &firstImage->base.Base) || > -- > 1.8.5.2 > > _______________________________________________ > mesa-dev mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
