| Age | Commit message (Collapse) | Author |
|---|
|
Require that GL_{ARB,EXT,NV}_texture_rectangle be supported before
allowing use of RECT texture target.
|
|
So totally awesome that _mesa_calloc has a different parameter
signature than calloc. Why do these libc wrappers still exist?!?
|
|
|
|
The changes are, as it turns out, purely cosmetic.
|
|
Valgrind doesn't complain about a leak here, so delete the comment
about possibly needing to free the state returned by yy_scan_bytes.
|
|
As far as I am able to determine via code inspection and using
Valgrind, that should be all of the leaks in the parser.
|
|
|
|
|
|
Use the type stored in the Parameters array to determine the layout
instead of the type in the instruction register field. Also, update
the instruction register field based on the parameter type.
This makes Google Earth work exactly like with Mesa master.
|
|
|
|
|
|
This gets basic texturing working. w00t!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The 965 driver expects unused source registers (e.g., SrcReg[2] of a
DP3 instruction) to have a register file of PROGRAM_UNDEFINED.
Initializing these source registers ensures that this happens.
|
|
|
|
This still needs quite a bit of work, but a bunch of the programs in progs/vp
produce correct results.
|
|
|
|
Missing file from previous commit.
|
|
|
|
Otherwise simple apps like glxgears pick up a DirectColor visual since the X
server mixes the depth 32 visual in with the other GLX visuals, and this seems
to result in a (mostly) black screen due to a bad ColorMap for a lot of people.
The bad ColorMap may be a bug in the apps, the X server or X driver, and
regardless of that I think the X server should ideally make the depth 32 GLX
visual separate from the rest again, but in the meantime this makes us cope.
(depth_bits is either 16 or 24, never 0)
|
|
|
|
This function was calling get_input_base() and get_output_base() to
get the names of a couple of register to use as temps. Those
functions no longer return registers, so adjust it to get the
registers elsewhere.
This change doesn't address the issue that it's a fairly poor way to
grab a register name by calling a function with an apparently
unrelated meaning.
|
|
|
|
|
|
|
|
|
|
|
|
Flagged by the DRM command stream checker. This allows the driver to work on
non-R500 cards.
|
|
|
|
Conflicts:
Makefile
progs/glsl/multitex.c
src/mesa/main/enums.c
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
|
|
|
|
|
|
|
|
|
|
|
|
Not sure how these got left out from earlier commit.
|
|
into r6xx-rewrite
|
|
patch from Kevin DeKorte with some minor fixes from me.
|
|
|
|
A context or surface that is neither linked to a display nor current to
a thread should be destroyed. Therefore, an unlinked context or surface
implies a pending delete automatically.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
eglTerminate should destroy the contexts and surfaces of the display.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
The latest revision of the spec explicitly requires the same handle to
be returned for the same native display.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
This commit uses the newly introduced link functions to manage EGL
contexts and surfaces. As a result of this, the API for drivers are
changed. All drivers are updated for the change.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
EGL contexts and surfaces are resources of displays. They should be
managed by displays. This commit adds a bunch of functions to
egldisplay.c to help establish the links between contexts/surfaces and
displays. How links are established is considered opaque outside
display. Functions like _eglGetSurfaceHandle or _eglLookupSurface are
therefore moved to egldisplay.c, with some small modifications.
The idea is also extended to display. That is, displays need to link to
themselves to be looked up.
This commit only adds the functions. A commit to use them should
follow.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
EGL allows multiple current contexts, as long as they are bound to
different client APIs.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
