Lines Matching defs:of
4 Several factors combine to make efficient dispatch of OpenGL functions
5 fairly complicated. This document attempts to explain some of the issues
8 :ref:`overview of Mesa's implementation <overview>`.
10 1. Complexity of GL Dispatch
15 of the GL related state for the application. Every texture, every buffer
26 This creates the first bit of dispatch complexity. An application can
35 change the behavior of GL functions depending on current state. For
46 2. Overview of Mesa's Implementation
50 of the context current in the thread, and the second pointer stores the
51 address of the *dispatch table* associated with that context. The
56 The implementation of functions such as ``glVertex3fv`` becomes
64 This can be implemented in just a few lines of C code. The file
77 The problem with this simple implementation is the large amount of
80 In a multithreaded environment, a naive implementation of
88 A number of optimizations have been made over the years to diminish the
90 optimizations. The benefits of each optimization and the situations
96 The vast majority of OpenGL applications use the API in a single
104 of the executing thread. If the same thread ID is always seen, Mesa
105 knows that the application is, from OpenGL's point of view, single
116 resulting implementation of ``GET_DISPATCH`` is slightly more complex,
131 of per-thread, global storage. Variables can be put in this area using
133 area, the expensive call to ``pthread_getspecific`` and the test of
151 Use of this path is controlled by the preprocessor define
152 ``USE_ELF_TLS``. Any platform capable of using ELF TLS should use this
156 libraries can take advantage of compiler-assisted TLS. This TLS data
158 for the limited number of slots available there, and so ``USE_ELF_TLS`` can
166 seem to have even more difficulty optimizing these routines. All of the
168 assembly language versions. The amount of optimization provided by using
191 Selection of the dispatch table pointer access method is controlled by a
196 - If none of the preceding are defined, method #1 is used.
199 On x86 and SPARC, a macro called ``GL_STUB`` is used. In the preamble of
200 the assembly source file different implementations of the macro are
202 then consists of a series of invocations of the macros such as:
205 :caption: SPARC Assembly Implementation of ``glColor3fv``
209 The benefit of this technique is that changes to the calling pattern
210 (i.e., addition of a new dispatch table pointer access method) require
218 registers, varying amounts of code needs to be inserted around the call
224 implementation of each function. This makes the assembly file
227 function implementation to generate many lines of diffs. Since the
235 ``src/mesa/glapi/glapi_dispatch.c`` to prevent the C version of the
246 platforms, storing all of those pointers is inefficient. On most
251 stored for every function. The location of the function can instead be
252 calculated by multiplying the size of the dispatch stub by the offset of
253 the function in the table. This value is then added to the address of