[Mesa-stable] [Mesa-dev] [PATCH 2/4] i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2
Chad Versace
chadversary at chromium.org
Thu Nov 30 00:42:03 UTC 2017
On Tue 28 Nov 2017, Jason Ekstrand wrote:
>
>
> On Tue, Nov 21, 2017 at 3:05 PM, Chad Versace <[1]chadversary at chromium.org>
> wrote:
> > @@ -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);
> > @@ -464,31 +464,24 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint
> target,
> > if (rb->mt->cpp == 4) {
> > if (texture_format == __DRI_TEXTURE_FORMAT_RGB) {
> > internal_format = GL_RGB;
> > - texFormat = MESA_FORMAT_B8G8R8X8_UNORM;
> > + texFormat = MESA_FORMAT_B8G8R8A8_UNORM;
>
> Why replace rgbx with rgba? I suspect the replace is due to the same
> reasons explained in intel_miptree_create_for_dri_image(). Whatever the
> reasons are, they're subtle and deserve a comment.
>
>
> I believe your fears go away if you re-order things and put 3 before 2. Why
> RGBA instead of RGBX? Because the underlying miptree of the renderbuffer is
> likely to have that format. That said, it's not actually guaranteed so making
> that change in this patch is a bit bogus. If we just make the change in 2
> instead, I believe all bogosity is gone.
If I conceptually place patch 3 before patch 2, I see the correctness of
everything. That makes this patch (patch 2)
Reviewed-by: Chad Versace <chadversary at chromium.org>
If choose to fidget the code a little in this patch due to my complaint,
my rb still stands.
More information about the mesa-stable
mailing list