On 03/04/2014 02:17 PM, Eric Anholt wrote:
> Now that BindRenderbufferTexImage() is a thing that drivers can do, winsys
> FBOs *can* have NeedsFinishRenderTexture set. The early exit here
> predated the NFRT flag, so it did make sense at the time.
> ---
> src/mesa/main/fbobject.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index a9dcc51..12d6332 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2008,9 +2008,6 @@ check_begin_texture_render(struct gl_context *ctx,
> struct gl_framebuffer *fb)
> static void
> check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb)
> {
> - if (_mesa_is_winsys_fbo(fb))
> - return; /* can't render to texture with winsys framebuffers */
> -
> if (ctx->Driver.FinishRenderTexture) {
> GLuint i;
> for (i = 0; i < BUFFER_COUNT; i++) {
> The asymmetry here strikes me as a little odd...now you can have FinishRenderTexture called for renderbuffers, but RenderTexture still retains the "no winsys fbos" check. I guess that makes some sense, since the driver is already handling BindRenderbufferTexImage, so there's no need for a second "begin" hook. This is all fairly theoretical though: i965 is the only driver that exposes BindRenderbufferTexImage, and it no longer has RenderTexture or FinishRenderTexture hooks. So, you could actually drop this patch. But I'm not thrilled about that, since other drivers may implement BindRenderbufferTexImage, and would almost certainly forget this. Maybe instead change it to: if (_mesa_is_winsys_fbo(fb) && !ctx->Driver.BindRenderbufferTexImage) That avoids the overhead of the BUFFER_COUNT loop for existing drivers. *shrug*
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
