[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