| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
There is no current pixel format. Each HDC has its pixelformat which is
kept by gdi and set/get via the SetPixelFormat/GetPixelFormat functions.
Now the HDC's pixelformat is kept in the stw_framebuffer, which is
created during the SetPixelFormat.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Stderr of Windows applications without console is not usually
visible.
|
|
|
|
|
| |
Prevents segmentation fault when trying to set the viewport/scissor
after a context/drawable visual mismatch.
|
| |
|
|
|
|
|
|
|
| |
This fixes the incorrect colors seen when rendering flat-shaded polygons.
Note that clipped polygons were correct, but unclipped polygons were wrong.
See the glean/clipFlat test for regression testing.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
The rationale here is to avoid updating a timestamp for a file that
hasn't changed. Needless updates of the timestamp can ripple into
other projects, (xserver, etc.), useless recompiling due to a
'make install' in mesa that didn't actually change anything.
|
|
|
|
| |
See sourceforge bug #2793846.
|
|
|
|
| |
When we render to a depth/stencil texture there are stencil bits.
|
|
|
|
| |
The stride needs to be in texels, not bytes.
|
| |
|
| |
|
|
|
|
| |
We were passing a GL texture target instead of a pipe_texture_target enum.
|
|
|
|
| |
Contributed by Nicolas Noble. See SF bug #2792536
|
| |
|
| |
|
|
|
|
| |
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21053 .
|
| |
|
| |
|
|
|
|
| |
Fixes potential texture object leaks.
|
|
|
|
| |
Fixes segfault in context tear-down when glClear was never called.
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
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 <[email protected]>
(cherry picked from commit 2085cf24628be7cd297ab0f9ef5ce02bd5a006e2)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
pixel formats.
Fix a segfault when using softpipe.
|
|
|
|
|
|
|
| |
The src/dest x,y, and w,h arguments of the pipe->surface_copy
function are unsigned and the drivers aren't expecting negative
(or extremly-large unsigned) values as inputs. Trim the requests
at the state-tracker level before passing down.
|
|
|
|
|
| |
Rendering should already have been flushed, any synchronization will
be done by the driver or memory manager.
|