- Sep 28, 2009
-
-
Ian Romanick authored
-
Ian Romanick authored
-
Build was broken by commit 9666529b I'm not certain that this is entirely the correct fix since the demo from bug #23774 seemed to work before the commit that broke the build. Signed-off-by:
Robert Noland <rnoland@2hip.net> Signed-off-by:
Brian Paul <brianp@vmware.com>
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
The main issue is we didn't always have a gallium texture object with enough space to store the to-be-generated mipmap levels. When that's the case, allocate a new gallium texture and use st_texure_finalize() to copy images from the old texture to the new one. We also had the baseLevel parameter to st_render_mipmap() wrong.
-
Brian Paul authored
Don't compute the st_texture_object::lastLevel field based on the texture filters. Use the _MaxLevel value that core Mesa computes for us. When called from the GenerateMipmap path, we'll use the lastLevel field as-is.
-
Brian Paul authored
-
- Sep 25, 2009
-
-
Emma Anholt authored
Bug #23760 (crashes in wine)
-
- Sep 24, 2009
-
-
-
Brian Paul authored
At the time of the enable there may not be a Z buffer, but one may be attached to the FBO later.
-
Brian Paul authored
If the currently bound FBO isn't yet validated it's possible for rgbMode to be zero so we'll lose the texture enable. This could fix some FBO rendering glitches, but I don't know of any specific instances.
-
- Sep 23, 2009
-
-
Brian Paul authored
Mostly fixes progs/demos/lodbias when MESA_TEX_PROG=1. But the LOD still seems off by -1 or so. May be an issue with the params passed to _swrast_compute_lambda()
-
Brian Paul authored
-
Brian Paul authored
-
Keith Whitwell authored
In get_array_bounds we were previously defining a user buffer sized as (nr_vertices * stride). The trouble is that if the vertex data occupies less than stride bytes, the extra tailing (stride - size) bytes may extend outside the memory actually allocated by the app and caused a segfault. To fix this, define a the buffer bounds to be: ptr .. ptr + (nr-1)*stride + element_size
-
- Sep 22, 2009
-
-
Brian Paul authored
-
Brian Paul authored
-
- Sep 21, 2009
-
-
Tormod Volden authored
The warnings introduced in 1f309c40 would pour out generously from some applications. This patch adds a "warn once" wrapper macro, heavily inspired by src/mesa/drivers/dri/r600/radeon_debug.h Signed-off-by:
Tormod Volden <debian.tormod@gmail.com> Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com>
-
This happens to rendering with textures with a border, which had resulted in a segfault on dereferencing the irb. (cherry-picked from commit 8bba183b)
-
Brian Paul authored
If arx and ary are equal, we still want to choose from one of them, and not arz. (cherry picked from commit de685b37)
-
Brian Paul authored
If arx and ary are equal, we still want to choose from one of them, and not arz. This is the same as Michal's softpipe fix.
-
Michel Dänzer authored
Since commit 2921a255 ('intel: Deassociated drawables from private context struct in intelUnbindContext'), intel->driDrawable may be NULL in intel_flush().
-
- Sep 20, 2009
-
-
Nicolai Hähnle authored
Signed-off-by:
Nicolai Hähnle <nhaehnle@gmail.com>
-
- Sep 16, 2009
-
-
Ian Romanick authored
Previously srandom and random were used. This cause the global random number generator state to be modified. This caused problems for applications that called srandom before calling into GLX. By using local state the global state is left unmodified. This should fix bug #23774.
-
Brian Paul authored
We need to be sure to call the _mesa_unmap_teximage_pbo() function if we called _mesa_validate_pbo_teximage().
-
Brian Paul authored
The following example caused an incorrect GL_OUT_OF_MEMORY error to be raised in glTexSubImage2D: glTexImage2D(level=0, width=32, height=32, pixels=NULL); glTexImage2D(level=0, width=64, height=64, pixels=NULL); glTexSubImage2D(level=0, pixels!=NULL); The second glTexImage2D() call needs to cause the first image to be deallocated then reallocated at the new size. This was not happening because we were testing for pixels==NULL too early.
-
Ian Romanick authored
The generic DRI infrastructure makes sure that __DRIcontextRec::driDrawablePriv and __DRIcontextRec::driReadablePriv are set to NULL after unbinding a context. However, the intel_context structure keeps cached copies of these pointers. If these cached pointers are not NULLed and the drawable is actually destroyed after unbinding the context (typically by way of glXDestroyWindow), freed memory will be dereferenced in intelDestroyContext. This should fix bug #23418.
-
- Sep 15, 2009
-
-
Brian Paul authored
-
Brian Paul authored
I believe this is the last of the shader-related functions that needed display list treatment.
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
Note: there are more glUniform functions to compile...
-
Brian Paul authored
Fixes bug 23746
-
Ian Romanick authored
-
- Sep 14, 2009
-
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
When we concatenate shaders to do our form of poor-man linking, if there's multiple #version directives, preprocessing fails. This change disables the extra #version directives by changing the first two chars to //. This should help with some Wine issues such as bug 23946.
-
-