On Fri, 03 Feb 2012 16:09:25 -0700, Ian Romanick <i...@freedesktop.org> wrote: > On 02/03/2012 02:11 AM, Eric Anholt wrote: > > On Wed, 1 Feb 2012 12:29:39 -0700, "Ian Romanick"<i...@freedesktop.org> > > wrote: > >> From: Ian Romanick<ian.d.roman...@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.
pgpoLSNoXk0YZ.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
