| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Conflicts:
src/mesa/main/state.c
|
|
|
|
The results were incorrect for some negative values of A.
See bug 21872.
|
|
Conflicts:
src/mesa/main/api_validate.c
|
|
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 <nirr@horizonsemi.com>
|
|
add new entrypoints, new texture format, etc
translate in texenvprogram.c for drivers using the mesa-generated tex env
fragment program
also handled in swrast, but not tested (cannot work due to negative texel
results not handled correctly)
|
|
|
|
It was only used in one place in swrast.
|
|
|
|
|
|
This was never fully fleshed out and hasn't been used.
|
|
|
|
Using _EnabledUnits was wrong because it included vertex texture units.
This change plus the prev commit fixes occasional failures of glean/glsl1
vertex texture test failure.
|
|
Remove all references to aux buffers 1..3. Keep AUX0 around for now just
in case, but it'll probably go too someday. I don't know of any OpenGL
drivers since the IRIX days that support aux color buffers.
|
|
s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/
s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/
Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it.
Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
|
|
Fixed point is only used in swrast and sw-based drivers.
|
|
|
|
Use loops to consolidate lots of texture object code.
|
|
Obviously, the color of fragments produced by DrawPixels is not constant,
even if the current vertex array / vertex program state indicates that the
color for normal rendering will be constant. Therefore, we need to override
certain optimisations that have been added to texenvprogram.c
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
