[Mesa-stable] [Mesa-dev] [PATCH 4/6] i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2
Chad Versace
chadversary at chromium.org
Mon Feb 19 18:36:11 UTC 2018
On Wed 24 Jan 2018, Jason Ekstrand wrote:
> The old code made a new miptree that referenced the same BO as the
> renderbuffer and just trusted in the memory aliasing to work. There are
> only two ways in which the new miptree is liable to differ from the one
> in the renderbuffer and neither of them matter:
>
> 1) It may have a different target. The only targets that we can ever
> see in intelSetTexBuffer2 are GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE
> and the difference between the two doesn't matter as far as the
> miptree is concerned; genX(update_sampler_state) only looks at the
> gl_texture_object and not the miptree when determining whether or
> not to use normalized coordinates.
>
> 2) It may have a very slightly different format. Again, this doesn't
> matter because we've supported texture views for quite some time so
> we always look at the gl_texture_object format instead of the
> miptree format for hardware setup anyway.
>
> On the other hand, because we were recreating the miptree, we were using
> intel_miptree_create_for_bo which doesn't understand modifiers. We
> really want this function to work without doing a resolve so long as you
> have modifiers so we need to fix that.
>
> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
> Cc: "17.3" <mesa-stable at lists.freedesktop.org>
> ---
> src/mesa/drivers/dri/i965/intel_tex_image.c | 19 +++++--------------
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c b/src/mesa/drivers/dri/i965/intel_tex_image.c
> index 9d2ede1..a4e7f81 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> @@ -405,6 +405,7 @@ static void
> intel_set_texture_image_mt(struct brw_context *brw,
> struct gl_texture_image *image,
> GLenum internal_format,
> + mesa_format format,
> struct intel_mipmap_tree *mt)
>
> {
> @@ -415,7 +416,7 @@ intel_set_texture_image_mt(struct brw_context *brw,
> _mesa_init_teximage_fields(&brw->ctx, image,
> mt->surf.logical_level0_px.width,
> mt->surf.logical_level0_px.height, 1,
> - 0, internal_format, mt->format);
> + 0, internal_format, format);
>
> brw->ctx.Driver.FreeTextureImageBuffer(&brw->ctx, image);
>
> @@ -442,7 +443,6 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
> struct gl_texture_object *texObj;
> struct gl_texture_image *texImage;
> mesa_format texFormat = MESA_FORMAT_NONE;
> - struct intel_mipmap_tree *mt;
> GLenum internal_format = 0;
>
> texObj = _mesa_get_current_tex_object(ctx, target);
> @@ -488,20 +488,11 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
> }
>
> intel_miptree_make_shareable(brw, rb->mt);
> - mt = intel_miptree_create_for_bo(brw, rb->mt->bo, texFormat, 0,
> - rb->Base.Base.Width,
> - rb->Base.Base.Height,
> - 1, rb->mt->surf.row_pitch,
> - rb->mt->surf.tiling,
> - MIPTREE_CREATE_DEFAULT);
> - if (mt == NULL)
> - return;
> - mt->target = target;
>
> _mesa_lock_texture(&brw->ctx, texObj);
> texImage = _mesa_get_tex_image(ctx, texObj, target, 0);
> - intel_set_texture_image_mt(brw, texImage, internal_format, mt);
> - intel_miptree_release(&mt);
> + intel_set_texture_image_mt(brw, texImage, internal_format,
> + texFormat, rb->mt);
> _mesa_unlock_texture(&brw->ctx, texObj);
> }
>
> @@ -594,7 +585,7 @@ intel_image_target_texture_2d(struct gl_context *ctx, GLenum target,
> const GLenum internal_format =
> image->internal_format != 0 ?
> image->internal_format : _mesa_get_format_base_format(mt->format);
> - intel_set_texture_image_mt(brw, texImage, internal_format, mt);
> + intel_set_texture_image_mt(brw, texImage, internal_format, mt->format, mt);
I was unsure whether this hunk should've used mt->format or image->format.
After digging, I discovered that for EGLImages, image->format should == mt->format except
(1) for depth-stencil formats, which we don't care about and (2) when
intel_miptree_create_for_dri_image() does a rgbx->rgba fallback, in
which case we definitely want mt->format instead of image->format.
The hunk looks correct to me.
Reviewed-by: Chad Versace <chadversary at chromium.org>
More information about the mesa-stable
mailing list