| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This comes from a radeon-rewrite fallback fix, but may also fix stencil
clear failure when the polygon winding mode is flipped.
|
|
|
|
With 1D textures, GL_TEXTURE_WRAP_T should be ignored (only
GL_TEXTURE_WRAP_S should be respected). But the i965 hardware
seems to follow the value of GL_TEXTURE_WRAP_T even when sampling
1D textures.
This fix forces GL_TEXTURE_WRAP_T to be GL_REPEAT whenever 1D
textures are used; this allows the texture to be sampled
correctly, avoiding "imaginary" border elements in the T direction.
This bug was demonstrated in the Piglit tex1d-2dborder test.
With this fix, that test passes.
|
|
One warning message:
drm_i915_getparam: -22
was still being sent to fprintf(). This causes all Piglit tests to fail,
even with MESA_DEBUG=0.
Using _mesa_warning() to emit the message allows the general Mesa controls
for messages like this to be applied.
|
|
Fixes potential texture object leaks.
|
|
|
|
|
|
|
|
Fixes segfault in context tear-down when glClear was never called.
|
|
No special driver changes are needed for this extension.
|
|
|
|
Conflicts:
src/mesa/main/arrayobj.c
src/mesa/main/arrayobj.h
src/mesa/main/context.c
|
|
gl_array_object encapsulates a set of vertex arrays (see the
GL_APPLE_vertex_array_object extension).
Create a private gl_array_object for drawing the quad for intel_clear_tris()
so we don't have to worry about the user's vertex array state.
This fixes the no-op glClear bug #21638 and removes the need to call
_mesa_PushClientAttrib() and _mesa_PopClientAttrib().
|
|
The former may point to the later.
|
|
Don't really delete vertex array objects until the refcount hits zero.
At that time, unbind any pointers to VBOs.
(cherry picked from commit 32b851c80792623195069d7a41a5808cff3b2f6f)
|
|
Every kind of object that can be shared by multiple contexts should be
refcounted.
(cherry picked from commit 1030bf0ded2a88a5e27f7a4d393c11cfde3d3c5a)
|
|
Not 100% sure this is right, but the invalid assertion is fixed...
|
|
|
|
|
|
Yeah, that was stupid
|
|
This was all phoenix64's idea. Credit goes to him
|
|
|
|
This looks to be a win of a few percent in cairogears with new vbo code,
thanks to not polluting caches.
|
|
|
|
|
|
This can fail, e.g. when XLIB_SKIP_ARGB_VISUALS=1 is set.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524794 and
http://bugs.freedesktop.org/show_bug.cgi?id=21600 .
|
|
For non-stereo visuals, which is all we support, we treat
GL_FRONT_LEFT as GL_FRONT. However, they are technically different,
and they have different enum values. Test for either one to determine
if we're in front-buffer rendering mode.
This fix was suggested by Pierre Willenbrock.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2085cf24628be7cd297ab0f9ef5ce02bd5a006e2)
|
|
Conflicts:
Makefile
src/mesa/main/version.h
|
|
|
|
|
|
I haven't tested, but this may unbreak surface copies.
|
|
|
|
Still dies in assert, but at least it's not my assert anymore. :3
|
|
|
|
This makes non-hybrid kernels like newttm from drm-next-radeon work
while avoiding breakage with Fedora/Ubuntu/etc.
|
|
|
|
Fixes failed assertion in progs/glsl/twoside.c (but still wrong rendering).
|
|
Drivers such as i965 define extra instruction opcodes and register files.
Improve the program printing code to handle those opcodes/files better.
|
|
The current texture for any particular texture unit is given an additional
reference in update_texture_state(); but if the context is closed before
that texture can be released (which is quite frequent in normal use, unless
a program unbinds and deletes the texture and renders without it to force
a call to update_texture_state(), the memory is lost.
This affects general Mesa; but the i965 is particularly affected because
it allocates a considerable amount of additional memory for each allocated
texture.
(cherry picked from master, commit c230767d6956b63a2b101acb48f98823bb5dd31a)
|
|
|
|
|
|
|
|
|
|
This should be all the opcodes for basic TCL.
|
|
|
|
Icky icky icky icky. Icky icky, icky icky. Icky.
|
|
|
|
Boy, is my face red. :C
|
|
|
