| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This was hit during screen tear-down.
|
|
|
|
|
|
|
| |
This was a call to _mesa_reference_framebuffer(ptr, NULL) but the NULL
pointer is incorrect in Mesa 7.4.x.
Fixes a failed assertion during screen tear-down.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first time a context is bound to a drawable, the viewport and scissor
bounds are initialized to the buffer's size. This is actually a bit tricky.
A new _mesa_check_init_viewport() function is called in several places
to check if the viewport has been initialized. We also use a new
ctx->ViewportInitialized flag instead of the overloaded
ctx->FirstTimeCurrent flag.
Hand-picked from mesa_7_5_branch, commit 3f856c6b6b7fa95ef97a8712876de88d7d57932e
|
|
|
|
|
|
| |
Fixes segfault in progs/xdemos/glxgears_pixmap.c
(cherry picked from master, commit d18c57aaeac37cde0cb551191ecd3c3a56a0ffba)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two parts to this:
One we don't keep pointers to possibly freed memory anymore once we unbind the
drawables from the context. Brian I need to figure out what the comment
you made there, can we get a glean/piglit test so we can fix it properly?
If the new gc is the same as the oldGC, we call the unbind even though
we just bound it in that function. doh.
(cherry picked from master, commit 77506dac8e81e9548a7e9680ce367175fe5747af)
|
| |
|
|
|
|
|
| |
A 0 by 0 viewport size is legal. Don't clamp against lower bound of one.
The error checking earlier in the function prevents negative values.
|
| |
|
|
|
|
|
|
|
| |
The results were incorrect for some negative values of A.
See bug 21872.
(cherry picked from mesa_7_5_branch, commit ed7f4b42307bff4633689d6781cd3643f10041e5)
|
| |
|
|
|
|
|
|
| |
Fixes memory leak when destroying framebuffers.
(cherry picked from mesa_7_5_branch, commit d027e8feff7d38cccadc6aaccc0454b21ce4dca0)
|
|
|
|
| |
(cherry picked from master, commit 7fdd64ab29576e607434fb8c82ddfa61e8ea6aa8)
|
|
|
|
| |
(cherry picked from master, commit cc22620e4b11425997f3bc1fc70f4c88cec22d2e)
|
|
|
|
| |
(cherry picked from master, commit d9617deb008b75f4a605a30408aeb1948139c33e)
|
|
|
|
| |
(cherry picked from master, commit ef8caec29ae73bb2bbeb48f0578d839ef29348cd)
|
|
|
|
| |
(cherry picked from master, commit 19a54d9f1055c366fd77026dd67007a8d5921f58)
|
|
|
|
| |
(cherry picked from master, commit 854151ba62e4b1cb6a755f6c131ee2e0f680f39b)
|
| |
|
|
|
|
|
|
|
| |
Now that the dlopen wrappers are built into libmesa.a, we need to link
standalone libOSMesa with libdl to resolve dlopen and friends on
platforms that need it.
(cherry picked from commit 4795dd5950d4dcd7c8d421c8fb4851c193297ba1)
|
|
|
|
|
|
|
|
|
|
| |
autoconf had been designating the 8 bit libOSMesa as the default
standalone osmesa, but the Makefile expected it to be linked to libGL.
Fix up the osmesa Makefile so that it allows any of the combinations of
standalone and channel width to be built.
Fixes bug #21980.
(cherry picked from commit 7441dcd90b01df8351026af8bbb50e11bb86071a)
|
|
|
|
| |
(cherry picked from commit 1045481dd96dec6e37f4b623b1dbae8af381de75)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the multitex.vert shader uses the VertCoord generic vertex attribute
instead of the pre-defined gl_Vertex attribute, we need to make sure that
VertCoord gets bound to generic vertex attribute zero.
That's because we need to call glVertexAttrib2fv(0, xy) after all the other
vertex attributes have been set since setting generic attribute 0 triggers
vertex submission. Before, we wound up issuing the vertex attributes in
the order 0, 1, 2 which caused the first vertex to be submitted before all
the attributes were set. Now, the attributes are set in 1, 2, 0 order.
(cherry picked from commit 58fadc624281b3f0bbe084e3e8af28a61036ca94)
|
|
|
|
|
|
|
|
|
|
|
| |
When a vertex shader uses generic vertex attribute 0, but not gl_Vertex,
we need to set attribute[16] to point to attribute[0]. We were setting the
attribute size, but not the pointer.
Fixes crash in glsl/multitex.c when using the VertCoord attribute instead
of gl_Vertex.
(cherry picked from commit c3538969e1ae3e626a618934aa8f35a7a22ddb39)
|
|
|
|
|
|
|
|
|
| |
It's possible to hand a GL_COLOR_INDEX/GL_BITMAP image to glTexImage3D()
which gets converted to RGBA via the glPixelMap tables.
This fixes a failure with piglit/fdo10370 with Gallium.
(cherry picked from commit 995456f9305593005f8466520314ee087f3d422a)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The generic_array[] is 16 elements in size, but the loop was doing 32
iterations. The out of bounds array write was clobbering the following
inputs[] array but as luck would have it, that didn't matter.
(cherry picked from commit 8da09e6924ca22ba7951d5a7673dfab2a711a997)
|
| |
|
|
|
|
| |
(cherry picked from commit 70c4b81e88e18e354e8dfaf47e5455e463b207d8)
|
|
|
|
|
|
|
| |
A follow-on to commit 46a2aad2cfec0ae54bc1a3ba5aacf6f59065d64b which
fixes a texture object memory leak.
See bug 21756.
|
| |
|
| |
|
|
|
|
|
|
| |
See sourceforge bug #2793846.
(cherry picked from commit 042d9a513213b1fa356c0d80abc62b9327e0bcc2)
|
|
|
|
|
|
| |
When we render to a depth/stencil texture there are stencil bits.
(cherry picked from commit c99a60c40d4ece363d37a5af895124f08a645c6b)
|
|
|
|
| |
Fixes bug 21756: r200: Mesa-7.4.2 release regression: "Quit on exit".
|
|
|
|
|
| |
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21053 .
(cherry picked from commit f2445dfd85b42aafe0634e17b2929b4122ff3f03)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Anytime we're not rendering to the default/window FBO, need to invert
rendering, not just when rendering to a texture. Otherwise, if a FBO
consists of a mix of textures and renderbuffers the up/down orientation
was inconsistant.
Fixes shadowtex.c bad rendering.
(cherry picked from commit ba367f68ccacf255f78ac0c8dd066e64bbb1e5c2)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|