| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
(cherry picked from commit f05a4ee6f2840590c90da4be2fe5c6295410a5af)
|
|
|
|
Allows compiz to work in depth 16.
The DRI2 getBuffersWithFormat hook is only required for 16/32 bit depth
buffers, for colour buffers the only requirement is that the format matches
the drawable depth, which we can't check here.
(cherry picked from commit c50477c255a34444720fb944c54373462ef39fb9)
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Signed-off-by: Jeff Smith <whydoubt@yahoo.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
|
|
Set the _NEW_BUFFERS flag and remove the code which updated the
parent framebuffer size. Normal Mesa state validation will do that.
Fixes issues with Warsow on r300g and possibly other bugs.
|
|
|
|
|
|
|
|
There was a DrawBuffer/ReadBuffer typo and we were neglecting to invert
the texture coords when copying from a window to an FBO.
Plus, add some surface dump/debug code (disabled).
(cherry picked from commit 34f02071618624263eba839b5aeb930d0e794078)
|
|
We weren't inverting the textured quad when drawing into an fbo.
(cherry picked from commit 8d3f629a13afb0d6acafc7a007972fdc5efe6847)
|
|
Could result in use of freed memory and consequently random crashes, e.g. on
screen resize.
(cherry picked from commit 21c91b410a2a2cbf8eb677e59e3322f86320f2b0)
Conflicts:
src/gallium/state_trackers/xorg/xorg_tracker.h
|
|
noticed by fredrikh on IRC.
|
|
Before, we only cleared the flags for the active tiles (the ones inside
the framebuffer bound). The problem is if we later bound a different,
larger surface to the tile cache we'd have some stale clear-flags still
set (and mistakenly clear some tiles in the new surface).
Fixes fd.o bug 26932.
|
|
There's no reason to release the renderbuffer from the framebuffer object
or release the gallium surface in this function (they're reference counted).
In fact, we don't want to do this because we may later use the texture as a
pixel source (ex: glBlitFramebuffer) and need the surface.
Fixes fd.o bug 26923 and is part of the fix for bug 26932.
|
|
|
|
Allow render to texture for X8_Z24 and Z24_X8 formats.
Replace big if/else with switch, etc.
|
|
|
|
|
|
|
|
|
|
R300 hw doesn't support sampling from Z24_S8 or S8_Z24 formats.
|
|
|
|
Fixes some relocation failures
|
|
|
|
|
|
|
|
Fixes two wine d3d9 unit tests
|
|
|
|
_tnl_UpdateFixedFunctionProgram is already called in r300_draw.c
|
|
|
|
MESA_FORMAT_Z16 has no stencil bits.
|
|
When the paint is color, paint_bind_samplers binds a dummy sampler
without a texture. It causes demos requiring a sampler (those use a
mask or an image) to crash.
|
|
Fixes use of uninitialized variables in non-debug builds.
|
|
allocated
Move the initialization of ext_list_first_time from all of the DRI loader's
CreateScreen routines, to where the storage for the screen config is
allocated.
It needs to get set in the screen-config even if DRI is forced off
using LIBGL_ALWAYS_INDIRECT, so that psc->direct_support is initialized
correctly, otherwise __glXExtensionBitIsEnabled() always returns FALSE
Specifically, this causes a problem with an X server which advertises
GLX<=1.2, and the GLX_SGIX_fbconfig extension.
glXGetFBConfigFromVisualSGIX() uses __glXExtensionBitIsEnabled() to
check if the GLX_SGIX_fbconfig extension is available, but that function
won't return correct information because that data has never been
initialized, because ext_list_first_time was never set...
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 96ab4d2b84178209ee59017458d9964b32b7e183)
|
|
Previously the code was erroneously using the stencil size of the
context instead of the stencil size of the DrawBuffer. With FBOs
these may be different. As a result, clearing the stencil buffer of
an FBO bound to a context that doesn't have stencil would fail.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
If the visual doesn't have an accumulation buffer, the renderbuffer
passed into _swrast_clear_accum_buffer will be NULL anyway. There is
no reason the check the visual. Moreover, the test erroneously checks
the context's visual instead of the visual of the current DrawBuffer.
With FBOs these may be different.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
In the presence of FBOs, the visual of the context may not match the,
possibly fake, visual of the current ReadBuffer. Note that the caller
of adjust_colors correctly uses the visual of the ReadBuffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
The whole structure is 836 bytes, but if only the first one or two
samplers are used (as is common), the part that matters is only 56 or
108 bytes. By using just that subset as the key (since the key size
is also part of the key), we improve firefox-talos-gfx performance by
1%.
|
|
|
|
|
