[Mesa-dev] [PATCH] intel: Also check renderability in intel_renderbuffer_update_wrapper

[Eric Anholt]

On Thu, 09 Feb 2012 17:27:14 -0800, Ian Romanick <idr at freedesktop.org> wrote:
> On 02/06/2012 03:08 PM, Eric Anholt wrote:
> > On Fri, 03 Feb 2012 16:09:25 -0700, Ian Romanick<idr at freedesktop.org>  wrote:
> >> On 02/03/2012 02:11 AM, Eric Anholt wrote:
> >>> On Wed,  1 Feb 2012 12:29:39 -0700, "Ian Romanick"<idr at freedesktop.org>   wrote:
> >>>> From: Ian Romanick<ian.d.romanick at intel.com>
> >>>>
> >>>> A similar check was removed in 05ab8fc.  The check is not complete
> >>>> redundand because some paths, such as
> >>>> _mesa_meta_check_generate_mipmap_fallback, can get to
> >>>> intel_renderbuffer_update_wrapper but not get to
> >>>> intel_validate_framebuffer.  This occurs when trying to generate
> >>>> mipmaps for GL_SLUMINANCE8 textures.
> >>>
> >>> Err, are you saying that glCheckFramebufferStatusEXT in the meta is not
> >>> triggering intel_validate_framebuffer?  That seems Bad.
> >>
> >> The last call to intel_renderbuffer_update_wrapper before the test case
> >> starts crying is not followed by a call to intel_validate_framebuffer or
> >> _mesa_CheckFramebufferStatusEXT.  The backtrace is below.  It appears
> >> that the texture is already bound to an FBO.  The expectation is that
> >> the glTexImage1D call will automatically update the framebuffer status
> >> based on any changes made to the texture.
> >
> > It doesn't look that way to me.  specifically, teximage ->
> > _mesa_update_fbo_texture ->  check_rtt_cb should be setting fb->_Status
> > to 0, which means that validate is supposed to be called again.
> 
> I agree.  It seems like it should, but the breakpoints don't lie. 
> What's even more weird is that unbinding the texture after the FBO 
> completeness check (patch coming) also "fixes" it.  I noticed this while 
> poking at a different mipmap generation bug (#43325).  I'm baffled.

Looks like we're getting a start render texture at a time when that
texture is not being rendered to, it just happens to be bound to some
framebuffer out there.  Papering it over with either of those two
patches would leave rendering bugs still availaable.

Working out how to fix it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120210/e7036d43/attachment.pgp>