| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
remove
|
|
|
|
|
| |
Since the texformat branch merge, the value of intel_renderbuffer::texformat
is just a copy of gl_renderbuffer::Format.
|
|
|
|
|
|
|
|
|
|
| |
Back when we were flushing the entire batch at BindFramebuffer, the kernel
would notice the domain transition when someone went to texture from it and
flush for us. We no longer do the batch flushing every time, so we get to
do aggressive flushing until we move batchbuffer handling to libdrm.
Fixes piglit fbo-flushing. Bug #25377. No noticeable performance loss
on cairo-gl (so this is better than batch flushing).
|
|
|
|
|
| |
Commit cd6b8dd9e82fedc55d033131fbc0f8ee950567c8 deleted
src/mesa/state_tracker/st_cb_get.c.
|
|
|
|
|
|
|
| |
If the active texture unit on entry to mipmap generation is not zero, bind the
texture to unit zero.
Fixes bug #24219.
|
|
|
|
|
|
|
|
|
|
|
| |
The assertion is that the correct read type to be using is the native
type of the underlying read renderbuffer. For some fallback paths, this
may be worse than GL_RGBA/GL_UNSIGNED_BYTE for reads today, but it gets
all drivers the expected GL_BGRA/GL_UNSIGNED_BYTE for ARGB8888 or
GL_BGR//GL_UNSIGNED_SHORT_5_6_5_REV for rgb565 with no work.
This fixes the intel (and other) DRI drivers to report read formats that
should hit blit PBO readpixels paths.
|
|
|
|
| |
Passes piglit pbo-read-argb8888, and doesn't otherwise regress quick.tests.
|
|\ |
|
| |
| |
| |
| |
| | |
makes testing other things easier - does not hang the card
TODO: enable TEX dependency tracking in vertex programs
|
| |
| |
| |
| |
| |
| |
| | |
First time around render targets are not enabled yet (done in
r700SendRenderTargetState) so blend state is not emitted for any targets.
Affects first glClear in some mesa tests.
As a quick fix reorder state emit so that target is set first
|
| |
| |
| |
| | |
Also modify the Makefile to use the correct version for the tarballs.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
progs/demos/projtex.c
progs/xdemos/glxinfo.c
src/mesa/main/version.h
To fix the confilicts in projtex.c and glxinfo.c I just took the code from
mesa_7_6_branch. The conflicts seem to have occured from cherry-picks from
mesa_7_7_branch to mesa_7_6_branch followed by commmits just to
mesa_7_6_branch.
|
| | |
|
| |
| |
| |
| | |
(cherry picked from commit 919898e92fa23ff71a59d86a46ff0886a6f34e4d)
|
| |
| |
| |
| | |
(cherry picked from commit 364070b1f2b08d43fb205ec198894a35bec6b2f3)
|
| |
| |
| |
| |
| |
| | |
_mesa_TexGenf calls _mesa_TexGenfv, which uses the params argument
as an array.
(cherry picked from commit ca5a7aadb4361e7d053aea8687372cd44cbd8795)
|
| |
| |
| |
| |
| |
| | |
_mesa_TexGeni calls _mesa_TexGeniv, which uses the params argument
as an array.
(cherry picked from commit d55fb7c835b56951f05a058083e7eda264ba192e)
|
| |
| |
| |
| |
| |
| | |
_mesa_TexParameterf calls set_tex_parameterf, which uses the params
argument as an array.
(cherry picked from commit 270d36da146b899d39e08f830fe34b63833a3731)
|
| |
| |
| |
| |
| |
| | |
_mesa_TexParameterf calls set_tex_parameteri, which uses the params
argument as an array.
(cherry picked from commit a201dfb6bf28b89d6f511c2ec9ae0d81ef18511d)
|
| |
| |
| |
| |
| |
| | |
_mesa_TexEnvf calls _mesa_TexEnvfv, which uses the param argument
as an array.
(cherry picked from commit a11d60d14caf8efc07f70af63b57b33273f8cf9b)
|
| |
| |
| |
| |
| |
| | |
fixes fdo bug 25354
Signed-off-by: Alex Deucher <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
buffers."
This reverts commit 4598942b1b88a2a7d5af7febae7e79eedf00e385.
XRGB8888 doesn't work as intended. Revert this for now, and we'll revisit it
for 7.8 or something.
|
| |
| |
| |
| | |
Make sure that minimal width, height and depth of texture image is 1.
|
| |
| |
| |
| | |
memcpy would give incorrect results if src rowstride != dst rowstride
|
| |
| |
| |
| | |
Fixes #21501
|
| |
| |
| |
| | |
Fixes #25355
|
|\|
| |
| |
| |
| | |
Conflicts:
src/mesa/main/version.h
|
| |
| |
| |
| |
| |
| | |
fixes fdo bug 25354
Signed-off-by: Alex Deucher <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
bcbfda71b03303d3f008a6f3cf8cb7d9667bf8d2 left out many blit paths.
This fixes up more of them to get Blender to work again.
Bug #25030.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
state in KMM mode"
This reverts commit 286bf89e5a1fc931dbf523ded861b809859485e2.
This doesn't appear to be correct, regression so revert it.
http://bugs.freedesktop.org/show_bug.cgi?id=25193
|
| |
| |
| |
| | |
This fixes invalid failed assertions when running multi-threaded apps.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
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]>
|