Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Conflicts:
configure.ac
src/mesa/drivers/dri/r200/r200_context.c
src/mesa/drivers/dri/r300/r300_render.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
will fixup makefiles later to detect and use libdrm_Radeon in proper
places
|
|
|
|
|
|
|
|
|
|
This merges lots of the hw state atom emission and firevertices code.
it also removes a lot of the extra radeon crap from r300
and merge scissor
|
|
While running conform with render-to-texture:
conform -d 33 -v 2 -t -direct
the i965 driver failed this assertion:
intel_clear.c:77: intel_clear_tris: Assertion `(mask & ~((1 << BUFFER_BACK_LEFT) | (1 << BUFFER_FRONT_LEFT) | (1 << BUFFER_DEPTH) | (1 << BUFFER_STENCIL))) == 0' failed.
The problem is that intel_clear_tris() is called by intelClear() to
clear any and all of the available color buffers, but intel_clear_tris()
actually only handles the back left and front left color buffers; so
the assertion fails as soon as you try to clear a non-standard color
buffer.
The fix is to have intelClear() only call intel_clear_tris() with
buffers that intel_clear_tris() can support. intelClear() already backs
down to _swrast_Clear() for all buffers that aren't handled explicitly.
|
|
Reported-by: Siddhartha Chaudhuri <expiring_frog@yahoo.co.uk>
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
|
|
|
|
Omit math/m_xform.c from gallium builds since it's not used and it's the
one place we were pulling in the Mesa x86 codegen which collides with
gallium's x86 codegen.
Can now omit ASM_C_SOURCES from gallium build too.
|
|
Only VBO uses the evaluator code so call _math_init_eval() there.
Only TNL uses the transform/translate code so call _math_init_transformation()
and _math_init_translate9) there.
This is a step toward resolving some symbol collisions between Mesa's and
gallium's x86 codegen.
Have VBO and TNL modules call _math_init_transformation()
|
|
Commit 90b2beb661f630966788a6e909dc759c99e38973 changed the assembly
variables. Without this change, the glapi assembly wasn't being built
when it was supposed to, resulting in missing symbols in libGL.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
This is not the proper approach to disabling assembly. If there are bugs,
they should be fixed or the assembly can default to off.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
With the pixman CFLAGS at the beginning of the command line, my build
was picking up the glcore.h from glproto, which doesn't have any of the
TFP fields in __GLcontextmodes.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
|
|
|
|
Mesa's glGetUniformLocation() does support array indexes.
Minor code reformatting.
It would be great if this program were converted into a glean test...
|
|
Arrays of sampler vars haven't been tested much and might actually be broken.
Will need to be revisited someday.
Another fix for bug 20056.
|
|
location = -1 is silently ignored, but other negative values should raise
an error.
Another fix for bug 20056.
|
|
intermediate array
|
|
If too many array elements are specified, they're to be silently ignored (don't
raise a GL error).
Fixes another issue in bug 20056.
|
|
Fixes one of the issues in bug 20056.
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Johannes Engel <jcnengel@googlemail.com>
Acked-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
|
|
snprint symbol does not exist in Windows.
|
|
I wonder why we need this... It is only necessary for the MSVC build.
MinGW does not require them.
|
|
|
|
This involved fixing driConcatConfigs to not return const (which had made a
mess of a previous patch too).
|
|
|
|
|
|
|
|
Everything other than "make sure the last rendering ends up visible on the
screen" doesn't need that behavior.
|