diff options
author | Eric Anholt <[email protected]> | 2012-02-10 12:54:25 -0800 |
---|---|---|
committer | Eric Anholt <[email protected]> | 2012-02-17 13:31:27 -0800 |
commit | e2dce7f7ee3e7da9cbb0bb33307ecd79e824426d (patch) | |
tree | 739257b5462e111c343f8b1e65ab0734741cdc61 /src/gbm/backends | |
parent | 308c6be802fc8d7cd470316ace717aa7bb6b2a08 (diff) |
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.
Diffstat (limited to 'src/gbm/backends')
0 files changed, 0 insertions, 0 deletions