On Fri, 10 Feb 2012 16:19:14 -0700, Brian Paul <[email protected]> wrote: > On 02/10/2012 03:53 PM, Eric Anholt wrote: > > If we're only starting for new draw buffers, why would we end for old > > read buffers along with draw buffers? > > --- > > src/mesa/main/fbobject.c | 7 ++----- > > 1 files changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c > > index 987d687..64c3393 100644 > > --- a/src/mesa/main/fbobject.c > > +++ b/src/mesa/main/fbobject.c > > @@ -1758,11 +1758,8 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint > > framebuffer) > > if (bindDrawBuf) { > > FLUSH_VERTICES(ctx, _NEW_BUFFERS); > > > > - /* check if old read/draw buffers were render-to-texture */ > > - if (!bindReadBuf) > > - check_end_texture_render(ctx, oldReadFb); > > - > > - if (oldDrawFb != oldReadFb) > > + /* check if old framebuffer had any texture attachments */ > > + if (oldDrawFb) > > check_end_texture_render(ctx, oldDrawFb); > > > > /* check if newly bound framebuffer has any texture attachments */ > > This looks OK to me, but it's one of those things that deserves a lot > of testing. > > FWIW, I've never been totally happy with the > ctx->Driver.RenderTexture() and FinishRenderTexture() hooks. It's > been hard to concisely define when RTT starts and stops. > > Maybe we should just have a driver hook to create a renderbuffer that > wraps a texture slice when glFrameBufferTexture() is called. Then, > leave it up to the driver to figure out the rest at draw-validation time.
This patch is not strictly needed for the rest of the series, so I'll be fine with reverting it if things go weird. It at least survived a piglit run for me. You may have seen the commit message of despair in 3/3. I had an alternate series that made RT/FRT actually occur only during drawing to the buffer, but then I lost my gl_renderbuffers for attachments and things went badly. If we separated RT into RT and BeginRenderTexture (and that operation was paired with FinishRenderTexture), it might be useful. But the only thing I would need to do in BRT is the gen4 workaround, which went fairly naturally into brw_update_renderbuffer_surface(). So at least for my needs, I can leave RT as being "called at least once to set up my gl_renderbuffer". and the actual tracking of render-to-texture lives in the driver. I do rely on FinishRenderTexture currently to get the flushing right, but it wouldn't be hard to live without.
pgpg9Ax0sdrro.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
