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>
Quotes are important to make sure the argument to test -n really
is the empty string, but that requires stringifying PROGRAM_DIRS.
Signed-off-by: Brian Paul <brianp@vmware.com>
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.
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.
This reverts commit 93dae6761b.
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 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.
Ian Romanick
Dave Airlie
Jakob Bornecrantz
Michel Dänzer
Brian Paul
Tom Fogal
Alex Deucher
Eric Anholt
Roland Scheidegger
Vinson Lee
Alan Hourihane