| Age | Commit message (Collapse) | Author |
|---|
|
- 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;
|
|
DestroyTexObj has a dependence on the glCtx and may segfault otherwise.
|
|
with different methods to calculate the announced maximum texture sizes. Default is still the same (that is, radeon/r200 default to not announce anything which might not fit, i830/i915 default to 1 texture must fit). Bug #5785.
|
|
it, and guessing that the two remaining entries in the 3-bit values were the
new funcs. Tested with modified stencilwrap test. Also, remove the commented
fallback stuff -- more modification to stencilwrap suggests that those issues
were just from span readback, not stencil implementation.
|
|
back on. Tested using seccolor modified to use the blue channel instead of
green, since green stays in the same place across RGB/BGR mistakes. Also hook
in UpdateSpecular on COLOR_EXT change, which might have resulted in missing
statechanges before.
|
|
output from indirect rendering).
|
|
_glapi_add_entrypoint has been replaced by a new routine called
_glapi_add_dispatch. This new routine dynamically assignes dispatch offsets
to functions added. This allows IHVs to add support for extension functions
that do not have assigned dispatch offsets.
It also means that a driver has no idea what offset will be assigned to a
function. The vast majority of the changes in this commit account for that.
An additional table, driDispatchRemapTable, is added. Functions not in the
Linux OpenGL ABI (i.e., anything not in GL 1.2 + ARB_multitexture) has a
fixed offset in this new table. The entry in this table specifies the
offset in of the function in the real dispatch table.
The internal interface was also bumped from version 20050725 to 20050727.
This has been tested with various programs in progs/demos on:
radeon (Radeon Mobility M6)
r128 (Rage 128 Pro)
mga (G400)
|
|
device-specific code. A new Python script
(src/mesa/glapi/extension_helper.py) generates a list of all
entry-points for all known extensions. Each driver the selects only
the extensions that it needs and enables the via either
driInitExtensions or driInitSingleExtension.
This code has been compile-tested on a drivers, but has only been
run-tested on mga and i915 (on i830 hardware).
These changes were discussed at length on the mesa3d-dev mailing list.
http://marc.theaimsgroup.com/?t=111947074700001&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.
|
|
Now, the driver's Viewport routine should call _mesa_ResizeBuffersMESA()
if necessary.
Cleaned up code related to GLframebuffer width/height initialization.
Set initial viewport/scissor params in _mesa_make_current2(), instead of
in the drivers' MakeCurrent functions.
|
|
so that we can use the env var to get output. Add a no_rast driconf option to
force software fallbacks.
|
|
it's not that big of a deal in more normal apps, and axes a good bit of code.
And I assume that t_vertex will only get faster. Removes ~43k from compiled
binary.
Tested with: quake3, ut, ipers, texcyl, chromium, tuxracer, neverball (kinda)
|
|
GL_EXT_blend_subtract was already enabled via GL_ARB_imaging, but now
one of the added modes is supported in hardware. GL_NV_blend_square
was tested with progs/tests/blendsquare on an Rage128 Pro with PCI ID
1002:5046. I know there are some differences with some versions of
the chip.
|
|
and r128_sarea.h since they are redundant now.
|
|
|
|
in Mesa. This is analogous to changes idr made to the r200 driver. Patch
submitted by Andreas Stenglein.
|
|
by calling _mesa_init_driver_functions() and then plugging in the driver-
specific functions.
In particular, make sure ctx->Driver.NewTextureObject points to the
appropriate driver function so that _all_ texture objects are augmented
with the driver-specific data.
Put in a bunch of assertions in the texture-related driver functions that
texObj->DriverData is valid. Remove old dead code in near future.
|
|
|
|
automatically enables "duplicate" extensions without the driver
explicitly enabling them.
|
|
|
|
|
|
deleting the textures. Essentially move the assertion after the destruction
of the heap.
|
|
|
|
|
|
|
