[Mesa-dev] [PATCH] intel: Also check renderability in intel_renderbuffer_update_wrapper
idr at freedesktop.org
Thu Feb 9 17:27:14 PST 2012
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.
More information about the mesa-dev