Age | Commit message (Collapse) | Author |
|
If arx and ary are equal, we still want to choose from one of them,
and not arz.
This is the same as Michal's softpipe fix.
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
Same change as for softpipe
|
|
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.
|
|
|
|
Conflicts:
src/mesa/main/state.c
|
|
|
|
|
|
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/gallium/drivers/softpipe/sp_quad_blend.c
|
|
|
|
|
|
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
|
|
|
|
|
|
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)).
|