[PATCH 1/3] glamor: Just set the logic op to what we want at the start of all rendering.

Eric Anholt eric at anholt.net
Thu Feb 5 10:25:13 PST 2015

Keith Packard <keithp at keithp.com> writes:

> Eric Anholt <eric at anholt.net> 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 <keithp at keithp.com>
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150205/7e3c1ee6/attachment.sig>

More information about the xorg-devel mailing list