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

[Ian Romanick]

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.