Age | Commit message (Collapse) | Author |
|
|
|
either GL_ARB_vertex_program or GL_ARB_fragment_program should enable this
extension as well.
|
|
hash table. Make _mesa_destroy_list() static.
|
|
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;
|
|
glVertexAttrib() w/ bad index should generate GL_INVALID_VALUE, not
GL_INVALID_ENUM.
Misc clean-ups.
|
|
|
|
|
|
the instruction size in _mesa_alloc_instruction().
|
|
|
|
done with fragment programs nowadays.
|
|
Use COPY_4FV() where possible.
Added some comments, clean-ups.
|
|
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
|
|
Main driver impacts:
- new code for creating the Mesa GLframebuffer
- new span/pixel read/write code
Some drivers not yet updated/tested.
|
|
|
|
which have to be processed in the 'loopback' path. If so, send
all vertices that way as the transition from playback->loopback has
several problems.
|
|
|
|
no error detection, slow, may not be 100% correct but a good start
|
|
alias with the corresponding ARB functions.
GL_ARB_vertex_shader (and OpenGL 2.0's) VertexAttrib functions don't alias
with conventional vertex attributes, as GL_NV_vertex_program does.
So, the ARB and NV version of VertexAttrib need to be distinct.
|
|
|
|
and ignored for 1D and 2D images.
Need to pass in image dimensions (1,2,3) to the _mesa_image_address() function.
This change gets propogated to some other routines.
Also added new _mesa_image_address[123]d() convenience functions.
|
|
through the GL API directly, but should instead use the GL_CALL macro.
|
|
|
|
|
|
1015696)
|
|
|
|
|
|
|
|
appropriate number of param values
|
|
|
|
|
|
Note: extension may not be finalized yet - subject to change!
Note: implementation not fully suitable for h/w implementation yet.
|
|
|
|
|
|
|
|
The internal driver interface was also changed to use
BlendEquationSeparate instead of BlendEquation.
|
|
|
|
dd_function_table:BlendFuncSeparate. If a driver does not actually
support EXT_blend_func_separate, it can assume that the RGB and alpha
blend functions are the same.
|
|
|
|
|
|
|
|
|
|
points so that the calling conventions will work correctly with the assembler
stubs with the Open Watcom compiler.
|
|
|
|
|
|
|
|
|
|
|