| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 5b925b7daa566d799c4f50911a7fcca114131503)
|
|
(cherry picked from commit b611f639b4bffdcca376293f7ce71af9f6bdbff3)
|
|
(cherry picked from commit a9c540f5dedbf593f8038fdbc95eecb60826ab26)
|
|
(cherry picked from commit d3b4c99c703f70a9d0e715a97e52672f7f8fc980)
|
|
(cherry picked from commit 36e2074b63e3e5bc489eb74cad0cd97eafcedb40)
|
|
fixes fdo bug 25354
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
i830 does not (and cannot!) support the any of the non-default
GL_POINT_SPRITE_R_MODE_NV settings. i915 and i965 could, but
currently do not. In both cases it would require mucking about with
the fragment shader.
|
|
|
|
|
|
|
|
|
|
Support still isn't completely correct, but it's better. piglit
point-sprite now passes. However, glean's pointSprite test fails. In
that test the texture on the sprite is somehow inverted as though
GL_POINT_SPRITE_COORD_ORIGIN were set to GL_LOWER_LEFT. i915 hardware
shouldn't be able to do that!
I believe there are also problems when not all texture units have
GL_COORD_REPLACE set. The hardware enable seems to be all or nothing.
Fixes bug #25313.
|
|
This enum is only supported for OpenGL 2.0. If a driver supports
OpenGL 1.4 and GL_ARB_point_sprite, using this enum should generate an
error. This is important because, for example, i915 and i830 can
support GL_ARB_point_sprite, but they cannot support
GL_POINT_SPRITE_COORD_ORIGIN.
This commit just removes the check for NV_point_sprite, which is
completely wrong, and add some comments describing what the code
should do. I don't see an easy way to check for version >= 2.0 from
inside Mesa. Perhaps we should add an extension
GL_MESA_point_sprite_20 (like Intel's old GL_EXT_packed_pixels_12) to
indicate that this added bit of functionality is available.
Also note that glean's pointSprite test only checks for
GL_ARB_point_sprite before trying to use
GL_POINT_SPRITE_COORD_ORIGIN. Naturally, that fails on
non-2.0 implementations (i.e., Mac OS X on GMA 950).
|
|
Thanks to Intel code which I've just stolen pretty much as usual.
This fixes fdo bug 22851 which is a dri1 regression since rewrite.
Tested by: fpiobaf (Fabio) on #radeon
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This fixes an assertion failure in _mesa_MapBufferARB.
Fixes bugzilla #25253.
|
|
Too bad I didn't realize earlier how easy this could be...
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=22767 .
|
|
Fixes `xlib' driver build on AIX.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
It's not implemented yet. fixes fdo bug 24047
|
|
This reverts commit 284a7af274bc148f112bd0ebb40583923ee26b49.
This breaks kde desktop effects. See fdo bug 24131
|
|
|
|
(cherry picked from master, commit e9d6ab72be065becf7a077c33919d37faa8db92e)
|
|
The cube map array index arg is always present.
|
|
Instead of doing math based on the (broken for VBO && offset != 0)
input->count number, just use the BO size. Fixes assertion failure in ETQW.
|
|
This didn't work for quad/quadstrips at all, and for all other primitive types
it only worked when they were unclipped.
Fix up the former in gs stage (could probably do without these changes and
instead set QuadsFollowProvokingVertexConvention to false), and the rest in
clip stage.
|
|
Previously, we'd load linearly from ParameterValues[0] for the constants,
though ParameterValues[1] may not equal ParameterValues[0] + 4. Additionally,
the STATE_VAL type paramters didn't get updated.
Fixes piglit vp-constant-array-huge.vpfp and ET:QW object locations.
Bug #23226.
|
|
Fixes piglit vp-sge-alias test, and the googleearth ground shader. \o/
Bug #22228
(cherry picked from commit 56ab92bad8f1d05bc22b8a8471d5aeb663f220de)
|
|
Fixes piglit arl.vp.
(cherry picked from commit d52d78b4bcd6d4c0578f972c0b8ebac09e632196)
|
|
These are needed for HiZ which is not currently used and
the _BASE reg requires a reloc which is not currently supported
in the drm.
|
|
|
|
Handle both NV vertex programs and NV vertex state programs passed to
glProgramStringARB.
|
|
|
|
|
|
This change allows a certain closed-source browser plug-in to work
with open-source drivers.
|
|
|
|
_mesa_parse_arb_{fragment,vertex}_program
The program structure passed to _mesa_parse_arb_program is just a
place holder. The stings that actually need to be released are only
known to the functions calling _mesa_parse_arb_program, so they should
be freed there.
|
|
be kept
|
|
This reverts commit 93dae6761bc90bbd43b450d2673620ec189b2c7a.
This change was completely broken when the parser uses multiple
strings in a single production. It would be nice if bug fixes could
initially land somewhere other than the stable branch.
|
|
The code was assuming ctx->DrawBuffer == ctx->ReadBuffer.
Passing the pixmap is simpler and better.
Fixes a potential segfault.
|
|
|
|
The exec->vtx.inputs[] array was being written past its end. This was
clobbering the following vbo_exec_context::eval state. Probably not noticed
since evaluators and immediate mode rendering don't happen at the same time.
Fixed the loop in vbo_exec_vtx_init().
Changed the size of the vbo_exec_context::vtx.arrays[] array.
Added a bunch of debug-build assertions.
Issue found by Vinson Lee.
|
|
|
|
|
|
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Revised version of a patch from Karl Schultz.
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
util_blit_pixels_writemask() only works for color formats at this time.
Also, it might never work for depth/stencil surfaces since we can't get
handle stencil values in a fragment shader.
Fixes glCopyTexSubImage(GL_DEPTH_COMPONENT).
|
