Age | Commit message (Collapse) | Author |
|
Set ctx->Const.MaxTextureLevels = GAMMA_TEX_MAXLEVELS = 12
Remove bogus WRITE(level 12).
Max gamma texture size is 2kx2k (note: 2k = 1 << (MaxLevels - 1))
|
|
linking, if relevant.
Updated Makefiles to use -linker option instead of setting CC, CXX env vars.
|
|
1,402 lines of code to be removed from Mesa (drivers and libGL). The
big winner is dri_util.c.
Primary changes are:
1. Remove all "deprecated" entry-points from the various structures in
dri_interface.h.
2. Rename the remaining fields to removed "version numbers." So,
bindContext3 becomes bindContext. Functions with "New" in the name
(e.g., CreateNewContext) were *not* changed, but that is an option.
Having "New" in the name is less annoying to me than having "3" in the name.
3. Remove all compatibility code that handles cases where the driver or
the loader is too old to support the latest interfaces.
4. Append the API version to the __driCreateNewScreen function name.
This is currently done by hand. In the future (i.e., the next time we
make an incompatible change to the interface) we'll want to come up with
a better way to do this. This prevents old loaders from being able to load
new (incompatible) drivers.
5. Bump the API version to 20050722. All drivers (by way of dri_util.c)
require this version.
6. All drivers are *required* to expose GLX_SGIX_fbconfig and
GLX_OML_swap_method (or the moral equivalents). Support for these
functions in implicit in the use of the "new" interface.
7. Some cases still exist that need to be compiled differently in a loader
or core Mesa versus in a driver. These are identified by the define
IN_DRI_DRIVER.
|
|
Committing in .
_mesa_sprintf crashes on OpenVMS -> replaced it by the OS-supplied sprintf
Modified Files:
Mesa/src/mesa/drivers/x11/fakeglx.c
----------------------------------------------------------------------
|
|
|
|
relative addressing can be negative.
Change some GLuint indexes to GLint in the t_vp_build.c file.
Added PROGRAM_UNDEFINED token for initializing the register File field to
avoid a gcc 4.0 warning.
|
|
|
|
|
|
|
|
|
|
for others, and being cleaner with types in fragment/vertex program structures.
One warning in r300_shader.c is still concerning.
|
|
|
|
|
|
|
|
|
|
Support NEW INTERFACE as well
|
|
|
|
|
|
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
|
|
|
|
modular X build
|
|
|
|
|
|
GL_NV_vertex_program programs can't directly reference GL state so this
pointer is always NULL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
opcodes. When enabled via environment vars, gears runs and almost
looks right but other apps are still quite buggy.
|
|
|
|
so r200SetBuffer, r200SpanRenderStart and r200SpanRenderFinish get called again.
Bugzilla #3705, #3706.
|
|
Restore that behavior with new _mesa_alloc_texmemory() function.
Should fix via_sse_memcpy() problem in found with flightgear.
|
|
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.
|
|
either with software or hardware rendering.
|
|
|
|
by Idr. This patch is based on Idr patch to radeon driver.
Change #if 1 to #if 0 (r300_context.c:l69) for old dispatch
tab.
|
|
|
|
|
|
|
|
|
|
Remove old (pre-renderbuffer) span code instead of converting that too. Remove this old code from mach64 (the dead code was not fully converted to spantmp2 previously) too.
|
|
|
|
|
|
|
|
|
|
include $(TOP)/configs/current in glapi/Makefile so those vars can be
easily overridden by any system config, if needed.
|