| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/auxiliary/util/Makefile
src/gallium/drivers/r300/r300_state_derived.c
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_emit.c
|
| |
| |
| |
| | |
Fixed FDO bug 23397.
|
| | |
|
| |
| |
| |
| |
| | |
It does nothing else while being less useful than exit() because it lacks
attributes that real exit() has.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
|
|
|
|
|
|
|
|
|
| |
processing"
This reverts commit f058b25881e08c9d89a33345e5c84e1357396932.
This change is completely wrong in so many ways. When clip distances
are generated as part of vertex processing, they must be interpolated
to perform clipping. Geometric clipping goes right out the window.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once the clipping distance is calculated and stored per vertex, the
distances can be re-used when clipping is actually performed. This
doesn't have any immediate benefit, but it paves the way for
implementing gl_ClipDistance in vertex shaders and result.clip[] in
vertex programs.
This has not produces any oglconform regressions on my G31 system
which uses software TNL.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Fixed gallium build breakage.
|
| |
|
|
|
|
|
| |
This currently doesn't include fixing up the cliptests in the assembly
paths to support ARB_depth_clamp, so enabling depth_clamp forces the C path.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves mapping the index buffer to get a bounds on the indices that
drivers just drop on the floor in the VBO case (cache win), saves a bonus
walk of the indices in the CheckArrayBounds case, and other miscellaneous
validation. On intel it's a particularly a large win (50-100% in my app)
because even though we let the indices stay in both CPU and GPU caches, we
still end up waiting for the GPU to be done with the buffer before reading
from it.
Drivers that want the min/max_index fields must now check index_bounds_valid
and use vbo_get_minmax_index before using them.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
docs/relnotes-7.6.html
progs/tests/Makefile
src/gallium/drivers/softpipe/sp_prim_vbuf.c
src/glx/x11/indirect.c
src/mesa/glapi/Makefile
src/mesa/glapi/dispatch.h
src/mesa/glapi/glapioffsets.h
src/mesa/glapi/glapitable.h
src/mesa/glapi/glapitemp.h
src/mesa/glapi/glprocs.h
src/mesa/main/dlist.c
src/mesa/main/enums.c
src/mesa/sparc/glapi_sparc.S
src/mesa/x86-64/glapi_x86-64.S
src/mesa/x86/glapi_x86.S
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
Use MAX_VERTEX_GENERIC_ATTRIBS instead. No need for two #defines for
the same quantity.
|
| |
|
| |
|
|
|
|
|
| |
EyeDirection -> SpotDirection
_NormDirection -> _NormSpotDirection
|
|
|
|
|
| |
The code's cleaner and a step toward supporting float-valued texture sampling.
Some optimizations for common cases can be added and re-enabled...
|
|
|
|
|
| |
For some reason makedepend doesn't seem to find the dependency on this
header in these two files. Directly including the header is a work-around.
|
| |
|
| |
|
|
|
|
| |
New gl_texgen struct allows quite a bit of code reduction.
|
|
|
|
|
|
|
|
|
| |
segfault
_tnl_free_vertices() is called from several places during context tear-down.
Depending on the order in which the swrast, swrast_setup and tnl context is
destroyed we could hit a null pointer here. This doesn't seem to be an
actual issue with any Mesa drivers, but let's be safe.
|
|
|
|
|
|
|
|
|
|
|
| |
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()
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Merge commit 'origin/gallium-0.2' into gallium-master-merge
Conflicts:
Makefile
docs/relnotes-7.4.html
docs/relnotes.html
src/mesa/drivers/dri/i965/brw_wm.h
src/mesa/main/imports.c
src/mesa/main/mtypes.h
src/mesa/main/texcompress.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_save_draw.c
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
windows/VC8/mesa/osmesa/osmesa.vcproj
windows/VC8/progs/demos/gears.vcproj
windows/VC8/progs/progs.sln
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <[email protected]>
|
| |\ \ |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/mesa/glapi/descrip.mms
src/mesa/shader/grammar/descrip.mms
|