[Mesa-dev] [PATCH 3/5] mesa/meta: Add support for storing the current read buffer

[Jason Ekstrand]

On Fri, Aug 1, 2014 at 6:44 AM, Neil Roberts <neil at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140801/5b63b139/attachment.html>