On 02/06/2012 03:08 PM, Eric Anholt wrote:
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.
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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
