On Fri, Aug 1, 2014 at 6:44 AM, Neil Roberts <n...@linux.intel.com> wrote:
> Is this patch necessary? I think the read buffer is part of the > framebuffer state so any meta function that binds its own framebuffer > won't need to save the read buffer, right? This is the case for > _mesa_meta_CopyImageSubData_uncompressed which binds both a read and > write FBO so I think it shouldn't be needed at least for this patch > series. Presumably the _mesa_meta_begin there can just pass 0 for the > state to save because hardly any state affects glBlitFramebuffer and it > is binding its own framebuffers. > Neil, Thanks for pointing that out. Some how in all the confusion of GL API's, I missed the fact that it's implicitly bound to the framebuffer. The docs for gl[Read/Draw]Buffer say nothing about that. I'll drop this patch. > > If we do use this patch then I think MESA_META_READ_BUFFER would have to > be removed from the state that is saved in > copytexsubimage_using_blit_framebuffer because in that case we do want > to read from whatever the application has chosen for the read buffer. > There seems to be a number of other meta functions that explicitly > disable MESA_META_DRAW_BUFFER even though they bind their own > framebuffer. Maybe this is just for performance, but arguably these > functions should also disable saving MESA_META_READ_BUFFER. > > Regards, > - Neil > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
