[Mesa-dev] [PATCH] i965: Delete stale "pre-gen4" comment in texture validation code.

[Chris Forbes]

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 <kenneth at whitecape.org> 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 <kenneth at whitecape.org>
> ---
>  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
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev