[Mesa-dev] [PATCH 2/4] intel: Clean up intel_render_texture with a rename and a helper function.

[Chad Versace]

On Fri, 10 Jun 2011 13:56:44 -0700, Eric Anholt <eric at anholt.net> wrote:
> On Fri, 10 Jun 2011 12:58:12 -0700, Kenneth Graunke <kenneth at whitecape.org> wrote:
> > On 06/07/2011 11:47 AM, Eric Anholt wrote:
> > > The "newImage" isn't particularly new -- it might be the same texture
> > > that was attached to the same attachment point before.  This function
> > > also gets called when just rebinding back to an FBO with a texture
> > > attachment.
> > > ---
> > >   src/mesa/drivers/dri/intel/intel_fbo.c |   16 ++++++----------
> > >   1 files changed, 6 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c
> > > index 0a67caa..8fda37b 100644
> > > --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> > > +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> > > @@ -567,16 +567,12 @@ intel_render_texture(struct gl_context * ctx,
> > >                        struct gl_framebuffer *fb,
> > >                        struct gl_renderbuffer_attachment *att)
> > >   {
> > > -   struct gl_texture_image *newImage
> > > -      = att->Texture->Image[att->CubeMapFace][att->TextureLevel];
> > > +   struct gl_texture_image *image = _mesa_get_attachment_teximage(att);
> > >      struct intel_renderbuffer *irb = intel_renderbuffer(att->Renderbuffer);
> > > -   struct intel_texture_image *intel_image;
> > > +   struct intel_texture_image *intel_image = intel_texture_image(image);
> > >
> > >      (void) fb;
> > >
> > > -   ASSERT(newImage);
> > > -
> > > -   intel_image = intel_texture_image(newImage);
> > >      if (!intel_image->mt) {
> > >         /* Fallback on drawing to a texture that doesn't have a miptree
> > >          * (has a border, width/height 0, etc.)
> > > @@ -586,7 +582,7 @@ intel_render_texture(struct gl_context * ctx,
> > 
> > Any particular reason for removing the assertion?
> 
> Trying not to confuse people about there being some risk here. :)
> 
> > Patch 4 seems to be fixing a bug, but I don't see any statement of 
> > impact on either piglit or applications.  Was this actually breaking 
> > something in the wild, or just found by inspection (and allergic 
> > reactions to piles of yak hair)? :)
> 
> Mostly just trying to increase sanity of the code.  No more "This code
> is written in an absurd fashion, and would be better <the way it is
> after the patch>." 

I have encountered so many spurious assertions lately. They are more
misleading than they are helpful. Thanks for eliminating one.