glx: use glFunction()
Kristian Høgsberg
krh at bitplanet.net
Mon Mar 1 17:19:13 PST 2010
On Mon, Mar 1, 2010 at 7:21 PM, George Sapountzis <gsapountzis at gmail.com> wrote:
> On Mon, Mar 1, 2010 at 11:56 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> George Sapountzis wrote:
>>
>>> This is about using glFunction() calls instead of the CALL_Function(
>>> GET_DISPATCH(), () ) macros. Obviously, this is code clarity vs. call
>>> overhead and RSS overhead, hopefully, it can be done on a case-by-case
>>> basis where it makes sense. I put patches at
>>> http://people.freedesktop.org/~gsap7/xgl/ for an example conversion of
>>> glxcmds.c and glxdri.c, the patches are on top of the glapi sync
>>> patches at http://people.freedesktop.org/~gsap7/glapi/ . I am posting
>>> because I thought it may be useful in some cases.
>>
>> I haven't reviewed these patches yet, but I do have a couple general
>> comments. We considered doing this initially, but rejected it for a
>> couple of reasons. Most of the places where GL functions are called are
>> automatically generated. The script doesn't care if it's generating
>> glFoo or CALL_Foo(GET_DISPATCH(), ()). On the client-side, the loader
>> provides, with some effort, the static dispatch functions. On the
>> server-side, the only use of GL functions *is* the loader. It didn't
>> seem to make much sense to bring all that mechanism into the server just
>> for the server to use.
>>
>> I seem to recall some discussion about creating a set of wrapper macros
>> like:
>>
>> #define glFoo(x, y, z) CALL_Foo(GET_DISPATCH(), (x, y, z))
>>
>> for use in the server. Given that most of the calls are generated by
>> scripts, there didn't seem to be much benefit.
>
> You are right, there does not seem to be much benefit.
That was my initial reaction too... there are very few hand-coded
calls to GL entry points.
Kristian
More information about the xorg-devel
mailing list