[PATCH 09/12] glamor: Replace glamor_get/put_context() with just glamor_make_current().

Eric Anholt eric at anholt.net
Wed Apr 23 00:14:14 PDT 2014

Keith Packard <keithp at keithp.com> writes:

> Adam Jackson <ajax at nwnk.net> writes:
>> On Fri, 2014-04-18 at 11:40 -0700, Eric Anholt wrote:
>>> @@ -545,9 +541,8 @@ _glamor_copy_n_to_n(DrawablePtr src, 
>>>   fail:
>>> -    glamor_get_context(glamor_priv);
>>> +    glamor_make_current(glamor_priv);
>>>      glamor_set_alu(screen, GXcopy);
>>> -    glamor_put_context(glamor_priv);
>>>      if (ok)
>>>          return TRUE;
>> This made me double-take.  I mean, it can't be wrong, but I'm not sure
>> what it'd protect against; glamor_create_pixmap() can't change to a
>> proxy GLX context, right?  Or are we assuming that the driver could be
>> using another GL context below glamor itself?  That'd be super
>> weird...
> Yeah, I think that for this case, the obvious mechanical edit isn't
> right; every path to 'fail' has already been through glamor_make_current
> There are other redundant calls to glamor_make_current:
> 	_glamor_download_sub_pixmap_to_cpu
>         glamor_fill_spans_gl
> I think glamor could use some rules about when you need to call
> glamor_make_current; right now it's very haphazard and error prone. Here
> are two possibilities:
>  * Call glamor_make_current before the first actual gl call in any
>    function.
>  * Call glamor_make_current at the top of every external glamor
>    function.

Either of these rules sounds fine to me.  And I'm wondering if #1 could
actually be done with coccinelle.  For now, I'd like this series to just
be the mechanical change, though.  (Particularly since 2/3 of the cases
people noticed of weird make_current patterns are in code keithp's
trying to delete, and the other is in fill_spans_gl where I just
misplaced a make_current at a former put_context).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140423/24998316/attachment.sig>

More information about the xorg-devel mailing list