Comment 8 for bug 945441

Hi! I believe this was fixed by the following commit, which is already part of the Mesa 8.0.3 release:

commit 93e94cbb48a679b7bf67594adb6f858526b37935
Author: Eric Anholt <email address hidden>
Date: Fri Feb 10 12:54:25 2012 -0800

    intel: Fix rendering from textures after RenderTexture().

    There's a serious trap for drivers: RenderTexture() does not indicate
    that the texture is currently bound to the draw buffer, despite
    FinishRenderTexture() signaling that the texture is just now being
    unbound from the draw buffer.

    We were acting as if RenderTexture() *was* the start of rendering and
    that we could make texturing incoherent with the current contents of
    the renderbuffer. This caused intel oglconform sRGB
    Mipmap.1D_textures to fail, because we got a call to TexImage() and
    thus RenderTexture() on a texture bound to a framebuffer that wasn't
    the draw buffer, so we skipped validating the new image into the
    texture object used for rendering.

    We can't (easily) make RenderTexture() indicate the start of drawing,
    because both our driver and gallium are using it as the moment to set
    up the renderbuffer wrapper used for things like MapRenderbuffer().
    Instead, postpone the setup of the workaround render target miptree
    until update_renderbuffer time, so that we no longer need to skip
    validation of miptrees used as render targets. As a bonus, this
    should make GL_NV_texture_barrier possible.

    (This also fixes a regression in the gen4 small-mipmap rendering since
    3b38b33c1648b07e75dc4d8340758171e109c598, which switched
    set_draw_offset from image->mt to irb->mt but didn't move the irb->mt
    replacement up before set_draw_offset).

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961
    NOTE: This is a candidate for the 8.0 branch.

I tested it on a GM965, and it seems to be working for me. Feel free to reopen if problems persist.