- Jul 20, 2005
-
-
Brian Paul authored
-
- Jul 19, 2005
-
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
- Jul 18, 2005
-
-
Brian Paul authored
-
Philippe Houdoin authored
GLUT callbacks.
-
Alan Hourihane authored
-
Alan Hourihane authored
Support NEW INTERFACE as well
-
Alan Hourihane authored
-
Ian Romanick authored
-
Ian Romanick authored
generated file, called src/mesa/glapi/dispatch.h, is added. This file contains three macros for each API function. It contains a GET, a SET, and a CALL. Each of the macros take a pointer to the context and a pointer to the dispatch table. In several threads on mesa3d-dev we discussed replacing _glapi_add_entrypoint with a new function called _glapi_add_dispatch. For this discussion, the important difference between the two is that the caller of _glapi_add_dispatch does *not* know what the dispatch offset will be at compile time. Because of this callers need to track the dispatch offset returned by _glapi_add_dispatch. http://marc.theaimsgroup.com/?t=111947074700001&r=1&w=2 The downside is that driver code then has to access the dispatch table two different ways. It accesses it using structure tags (e.g., exec->Begin) for functions with fixed offsets and via a remap table (e.g., exec[ remap->NewExtensionFunction ]) for functions without fixed offsets. Yuck! Using the macros allows both types of functions to be accessed identically. If a driver needs to set a pointer for Begin, it does 'SET_Begin(ctx, exec, my_begin_function)'. If it needs to set a pointer for NewExtensionFunction, it does 'SET_NewExtensionFunction(ctx, exec, my_NewExtensionFunction_function)'. Furthermore, if at some point in the future a static offset is assigned for NewExtensionFunction, only the macros need to change (instead of every single place that accesses a table for that function). This code differs slightly from the originally posted patches in that the CALL, GET, and SET marcos no longer take a context pointer as a parameter. Brian Paul had suggested that the remap table could be stored as a global since it would be set at CreateScreen time and would be constant for all contexts. This change reflects that feedback. http://marc.theaimsgroup.com/?t=112087194700001&r=1&w=2
-
- Jul 16, 2005
-
-
Adam Jackson authored
-
Adam Jackson authored
modular X build
-
- Jul 15, 2005
-
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
GL_NV_vertex_program programs can't directly reference GL state so this pointer is always NULL.
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
- Jul 14, 2005
-
-
Brian Paul authored
-
Brian Paul authored
-
- Jul 13, 2005
-
-
Keith Whitwell authored
-
Keith Whitwell authored
-
Keith Whitwell authored
-
- Jul 11, 2005
-
-
Keith Whitwell authored
-
- Jul 10, 2005
-
-
Keith Whitwell authored
opcodes. When enabled via environment vars, gears runs and almost looks right but other apps are still quite buggy.
-
Keith Whitwell authored
-
- Jul 08, 2005
-
-
Ian Romanick authored
-
- Jul 07, 2005
-
-
Ian Romanick authored
When extra code was cut from blendminmax.c's Display function, the glPopMatrix call was also accidentally cut.
-
Ian Romanick authored
-
Ian Romanick authored
-
- Jul 06, 2005
-
-
Roland Scheidegger authored
so r200SetBuffer, r200SpanRenderStart and r200SpanRenderFinish get called again. Bugzilla #3705, #3706.
-
- Jul 05, 2005
-
-
Brian Paul authored
Restore that behavior with new _mesa_alloc_texmemory() function. Should fix via_sse_memcpy() problem in found with flightgear.
-
- Jul 02, 2005
-
-
Jon Smirl authored
-
Ian Romanick authored
is basically patch #2939 from X.org bugzilla #3379. This does *not* fix the bug as it does not dynamically generate stubs at run-time. It just gets things one step closer.
-
Ian Romanick authored
'make linux-x86 ARCH_FLAGS=-m32'.
-