Eric Anholt <[email protected]> writes:

> By dropping the unconditional logic op disable at the end of
> rendering, this fixes GL errors being thrown in GLES2 contexts (which
> don't have logic ops).  On desktop, this also means a little less
> overhead per draw call from taking one less trip through the
> glEnable/glDisable switch statement of doom in Mesa.

Reviewed-by: Keith Packard <[email protected]>

Could this be further optimized by not calling glDisable/glEnable in
glamor_set_alu when unnecessary? If those are expensive, keeping track
of the current value would seem like a good optimization.

> diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c 
> b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> index 8fe7516..582e3af 100644
> --- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
> +++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> @@ -214,6 +214,8 @@ ephyr_glamor_damage_redisplay(struct ephyr_glamor *glamor,
>      glBindFramebuffer(GL_FRAMEBUFFER, 0);
>      glUseProgram(glamor->texture_shader);
>      glViewport(0, 0, glamor->width, glamor->height);
> +    if (!ephyr_glamor_gles2)
> +        glDisable(GL_COLOR_LOGIC_OP);

I'd suggest an unconditional call to glamor_set_alu(screen, GXcopy)
here; that way any future optimizations to avoid calling
glDisable/glEnable would work without having to remember to fix ephyr too.

-- 
-keith

Attachment: signature.asc
Description: PGP signature

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to