Keith Packard <[email protected]> writes: > 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.
If logic op is enabled, blending doesn't happen. > >> 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. Yeah, I was a bit bothered by doing this, because it means if we ever get logic ops in gles2, this check would need to be updated. But so far, ephyr isn't using glamor_priv.h. I feel an in-tree use of glamor private functions is fine, though.
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
