| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
framebuffer.c
(cherry picked from commit 9091015a9782ad15e58540a8fd61df83ea2bfe31)
|
|
Primitive begin in one dlist, end in another.
|
|
|
|
Use floor() to convert to int (per Mark Kildard and the SI).
Also, change translate_id() to return a signed integer since we may be
offsetting from GL_LIST_BASE.
|
|
More such shader functions are needed...
|
|
these should be the same functions (as per spec).
|
|
|
|
|
|
|
|
As glPixelStore(GL_UNPACK) affect the bits into a stipple pattern,
hence 128 bytes used to store the pattern in a display list aren't
enough sometimes.
|
|
of -I flags.
|
|
|
|
|
|
Conflicts:
src/mesa/main/texcompress_s3tc.c
src/mesa/tnl/t_array_api.c
|
|
|
|
Remove display list opcodes for INDEX and EDGEFLAG, handle them
through the regular ATTRIB mechanism now that Mesa understands them
to just be regular attribs.
|
|
OpenGL 2.0 function of the same name.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
