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

[Keith Packard]

Kenneth Graunke <kenneth at whitecape.org> writes:

> I remember commenting about this to Keith at one point, and I seem to recall 
> him preferring idempotency - each operation alters some state, then puts it 
> back when it's done.  Except that we're really just mashing it on then mashing 
> it off, not saving/restoring state.  It's sort of "putting it back", but only 
> because we have the global convention that logic operations should be disabled 
> at the start/end of each Glamor operation.

I suspect I was just reflecting the existing "conventions" in the
code. The most important thing, of course, is to be consistent. Ideally,
we'd write down the rules and then construct assertions to validate them
at each entry point.

For each piece of state, we can either:

 1) Set it at startup and never change it. This is easiest to validate;
    make sure there's only one call to set the state.
   
 2) Set it explicitly everywhere. This makes sense where GL
    already short-circuits re-writing the same value (scissor rects?)

 3) Remember the state and change when necessary. When it's expensive
    for GL to short-circuit an operation, Glamor could do that itself
    (logic ops?)

 4) Ensure that it always has the same value on entry. This is mostly
    what we do today, and frankly it sucks, as we're frequently flipping
    state around for no good reason. It might make sense for
    infrequently exercised paths that change things which GL can't
    easily short-circuit though.

We can just look at how Mesa deals with each state change that we do and
use that as a first approximation of how to handle each value.

-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150104/5955b847/attachment-0001.sig>