| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/drivers/svga/svga_screen_texture.c
src/gallium/state_trackers/xorg/xorg_composite.c
src/gallium/state_trackers/xorg/xorg_exa.c
src/gallium/state_trackers/xorg/xorg_renderer.c
src/gallium/state_trackers/xorg/xorg_xv.c
src/mesa/main/texgetimage.c
src/mesa/main/version.h
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
progs/util/shaderutil.c
src/mesa/drivers/dri/r600/r600_context.c
src/mesa/main/version.h
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | |
| | |
| | |
| | | |
It's not implemented yet. fixes fdo bug 24047
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 284a7af274bc148f112bd0ebb40583923ee26b49.
This breaks kde desktop effects. See fdo bug 24131
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
_mesa_TexParameterf calls set_tex_parameterf, which uses the params
argument as an array.
|
| | |
| | |
| | |
| | |
| | | |
_mesa_TexParameterf calls set_tex_parameteri, which uses the params
argument as an array.
|
| | |
| | |
| | |
| | |
| | | |
Simplify gl image level <-> miptree level mapping (are equal now).
Don't allocate miptree for images that won't fit in it (fixes #25230).
|
| | |
| | |
| | |
| | | |
miptrees
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
_mesa_TexGenf calls _mesa_TexGenfv, which uses the params argument
as an array.
|
| | |
| | |
| | |
| | |
| | | |
_mesa_TexGeni calls _mesa_TexGeniv, which uses the params argument
as an array.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
_mesa_TexEnvf calls _mesa_TexEnvfv, which uses the param argument
as an array.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes progs/glsl/twoside.c demo.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
mapping ps input based on vs output;
fix bugs including constants updating for vs.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gallium/drivers/r300/r300_texture.c
src/gallium/state_trackers/xorg/xorg_exa.c
src/mesa/state_tracker/st_cb_texture.c
|
| | | |
| | | |
| | | |
| | | | |
width/height/depth arrays
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/mesa/state_tracker/st_atom_shader.c
src/mesa/state_tracker/st_program.c
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Translate vertex shaders independently of fragment shaders.
Previously tried to make fragment shader semantic indexes always start
at zero and exclude holes. This was unnecessary but meant that vertex
shader translation had to be adjusted to take this into account.
Now use a fixed scheme for labelling special FS input semantics
(color, etc), and another fixed scheme for the generics.
With this, vertex shaders can be translated independently of the bound
fragment shader, assuming mesa has done its own job and ensured that
the vertex shader provides at least the inputs the fragment shader is
looking for. The state-tracker didn't attempt to do anything about
this previously, so it shouldn't be needed now.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
One of several cases where we build mesa shaders and then translate
them to tgsi. Many of those cases it's because we're combining two
mesa programs and there are helpers for that, but in this case at
least can go straight to tgsi.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This makes the miptree rounds up to the near POT for each level for
all radeons, however since mipmaps aren't support with NPOT on previous
radeons this calculation shouldn't cause any problems. If it does
we can just make it r600 only.
I tested a few mipmap demos on r500 and they all seem to work.
Signed-off-by: Dave Airlie <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
We don't need 16K+ to store a single pointer.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We can get a lot of swtcl bo allocations - need to probably abstract
this a bit further.
Signed-off-by: Dave Airlie <[email protected]>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This moves the bo mapping outside the DMA layer and makes it explicit,
this should in theory make it simpler to split the clean up the dma/cmdbuf
linkage that I created before that is broken.
Tested on: r600, rv380 (tcl/no-tcl), rv200 (tcl/no-tcl)
Signed-off-by: Dave Airlie <[email protected]>
|
| | | | | |
|