Use _mesa_reference_vert/fragprog() wherever we assign program pointers.
Fixes a memory corruption bug found with glean/api2 test.
Another memory bug involving shaders yet to be fixed...
Picked from gallium-0.1
Previously, we set _NEW_PIXEL and _NEW_COLOR in these functions, respectively.
That correponds to the GL attribute groups, but doesn't make much sense
otherwise. This could improve validation efficiency in a few places too.
It looks like all the drivers are already checking for _NEW_BUFFERS in the
right places (since that's the bit for FBO state) so we can trim out
_NEW_PIXEL and _NEW_COLOR at any time.
The clamping for these values depends on whether we're drawing AA or non-AA
points, lines. Defer clamping until drawing time. Drivers could compute and
keep clamped AA and clamped non-AA values if desired.
Use the gl_shader struct as it should be.
Renamed gl_linked_program to gl_shader_program.
Store both shaders and programs in the same hash table and use the Type field
to distinguish them.
NV_vertex_program implementation has slightly incorrect aliasing
behaviour. I think this is reasonable given the simplification and
the fact that the mainstream ARB_vp continues to have the correct
behaviour.
glDeleteTextures and glDeleteTexturesEXT were erroneously listed as
aliases of each other. For anything /except/ GLX protocol they are
aliases. This set of changes allows functions that are functionally
identical but have different GLX protocol to be listed as aliases.
When building with GLX_INDIRECT_RENDERING set, different static
functions are used. These functions determine whether the current
context is direct rendering or not. If the context is direct
rendering, the aliased function (e.g., glDeleteTextures in the case of
glDeleteTexturesEXT) is called. If the context is not direct
rendering, the correct GLX protocol is sent.
For a deeper explanation of what is changed, please see:
http://dri.freedesktop.org/wiki/PartiallyAliasedFunctions
The functions for GL_EXT_paletted_texture that do not share GLX
protocol with GL_ARB_imaging are supposed to alias the similar
functions from GL_SGI_color_table. They didn't. This patch corrects
this problem and enables GLX protocol for both extensions.
Since this removes 3 entries from the dispatch table, this change
creates a lot of changes in the generated files.
and demos are also added.
Adding basic support to drivers should be as easy as just enabling the
extension, though thorough test would also be required.
Update a lot of loops, conditionals to use the _TNL_FIRST/LAST_* values
instead of specific vertex attributes.
Remove the EdgeFlagv function from the GLvertexformat struct.
- use macros to access and modify render inputs bit-field;
- un-alias generic vertex attributes for ARB vertex calls;
- use MAX_VERTEX_PROGRAM_ATTRIBS (NV code) or MAX_VERTEX_ATTRIBS
(ARB code) in place of VERT_ATTRIB_MAX;
- define VERT_ATTRIB_GENERIC0..15 for un-aliased vertex
attributes for ARB_vertex_shader;
- fix generic attribute index range check in arbprogparse.c;
- interface GLSL varyings between vertex and fragment shader;
- use 64-bit optimised bitset (bitset.h) for render inputs;
function since the matrix depends on the viewport params and the framebuffer's
depth buffer resolution.
Fixes some renderbuffer / depth range issues.
This simplifies the _mesa_set_viewport() and _mesa_DepthRange() functions too.
program->Id and program->RefCount fields were used and ATI fragment shaders
didn't have too much in common with ARB/NV vertex/fragment programs anyway.
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
