| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Replaced by new, simpler meta functions.
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Instead of _mesa_map_readpix_pbo() use _mesa_map_pbo_source().
Instead of _mesa_map_drawpix_pbo() and _mesa_map_bitmap_pbo() use
_mesa_map_pbo_dest().
|
|
|
|
|
| |
This fixes a conform selection/feedback regression introduced by commit
8f4d66c5f893b49eb3973aa3b31a856314c045c7
|
|
|
|
|
|
| |
If the fragment program uses KIL, we have to execute it before z/stencil
testing. Otherwise, deferred texture/shading lets us skip shading for
pixels that fail z/stencil testing.
|
| |
|
|\ |
|
| |
| |
| |
| | |
See bug 16866.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
This branch introduces new FRAG_ATTRIB_FACE and FRAG_ATTRIB_PNTC fragment
program inputs for GLSL gl_FrontFacing and gl_PointCoord. Before, these
attributes were packed with the FOG attribute. That made things
complicated elsewhere.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, the FOGC attribute contained the fragment fog coord, front/back-
face flag and the gl_PointCoord.xy values. Now each of those things are
separate fragment program attributes. This simplifies quite a few things in
Mesa and gallium.
Need to test i965 driver and fix up point coord handling in the gallium/draw
module...
|
| | | |
|
|\ \ \
| |/ /
|/| /
| |/
| |
| | |
Conflicts:
src/mesa/main/state.c
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/api_validate.c
|
| |
| |
| |
| |
| | |
The results were incorrect for some negative values of A.
See bug 21872.
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/state_tracker/st_cb_fbo.c
src/mesa/state_tracker/st_framebuffer.c
|
| |
| |
| |
| |
| |
| |
| | |
Add _NEW_PROGRAM_CONSTANTS to _SWRAST_NEW_DERIVED.
This makes sure that we update the fragment shader's constants when state
vars (such as point size) changes.
Fixes the progs/glsl/points.c demo.
|
| |
| |
| |
| |
| |
| |
| |
| | |
It's possible for mis-behaving vertex programs to produce vertex data
with very large/NaN values. This doesn't get handled reliably by the
clipper code so we may try to rasterize triangles that extend beyond
the viewport/window. Always clip spans to avoid invalid memory accesses
later.
|
| | |
|
|/
|
|
|
| |
Since shared array objects may point to the null/default buffer object,
the null/default buffer object should be part of the shared state.
|
|
|
|
|
| |
If a horizontal span of pixels was located at x < 0 we could sometimes
read/write outside of renderbuffer bounds.
|
|
|
|
| |
See bug 21461.
|
| |
|
|
|
|
| |
This came from commit 1b2ab023673261b4b942e1126c0b599d02fbd4a0
|
| |
|
|
|
|
|
| |
Need to clamp default point size to min/max range before checking if it's one.
Fixes glean pointAtten test.
|
|
|
|
| |
Fixes a regression from commit 76ac75af8e5481b498981c133836efa2101be2dc.
|
| |
|
| |
|
|
|
|
|
| |
Also, clean up the logic involved in choosing per-vertex vs. per-fragment
primary+secondary color addition.
|
| |
|
|
|
|
|
|
|
| |
The texture border color must be interpreted according to the texture's
base format. For example, for a GL_ALPHA texture, sampling the border
color should return (0,0,0,borderAlpha). This wasn't an issue here until
I removed the legacy texenv code (we always use the combiner path now).
|
|
|
|
|
| |
It was only set to GL_TRUE in one place where it isn't really needed
(glGetTexImage(sRGB format)).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Use MAX_COMBINER_TERMS instead of 4.
Rename some vars.
Update comments.
|
| |
|
| |
|
|
|
|
|
| |
The code's cleaner and a step toward supporting float-valued texture sampling.
Some optimizations for common cases can be added and re-enabled...
|
|
|
|
| |
We weren't putting the right colors into the back buffer in this mode.
|
|
|
|
|
| |
This is a (partial) backport of the signed texture format support in OGL 3.1.
Since it wasn't promoted from an existing extension roll our own.
|
|
|
|
|
|
|
|
|
|
| |
The MAX-based function can produce values that are non-monotonic for a span
which causes glitches in texture filtering. The sqrt-based one avoids that.
This is perhaps slightly slower than before, but the difference
probably isn't noticable given we're doing software mipmap filtering.
Issue reported by Nir Radian <[email protected]>
|