| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
|
| |
Add explicit casts, fix constant types, fix variable types.
Fixes about 340 warnings in MSFT Visual Studio.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GL_TRUE indicates that the driver accepts the program.
GL_FALSE indicates the program can't be compiled/translated by the
driver for some reason (too many resources used, etc).
Propogate this result up to the GL API: set GL_INVALID_OPERATION
error if glProgramString() was called. Set shader program link
status to GL_FALSE if glLinkProgram() was called.
At this point, drivers still don't do any program checking and
always return GL_TRUE.
|
|
|
|
|
|
|
|
| |
(cherry picked from commit 9fd3c74724e557bc6ecc851d8552615ab3becfe2)
Conflicts:
src/mesa/tnl/t_draw.c
|
|
|
|
| |
Reported by Karl Schultz.
|
|
|
|
|
|
|
|
| |
Adds the extension to the list + support to the APIs.
also add t_draw.c support to convert for sw rast.
Signed-off-by: Dave Airlie <[email protected]>
|
|\
| |
| |
| |
| |
| |
| | |
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
|