Age | Commit message (Collapse) | Author |
|
When points or lines are decomposed into triangles, we need to be sure
to disable polygon culling, stippling, "un-filled" modes, etc.
This patch sets the rasterization state to disable those things prior to
drawing points/lines with triangles, then restores the previous state
afterward.
The new piglit point-no-line-cull test checks this problem & solution.
|
|
Commit 1454f20a991ddda35f1a2ffda953012078b407ba caused the regression.
When the vertex shader emitted both a texcoord and color we were grabbing
the wrong vertex attributes. Fix the draw_quad() code to put texcoords
in slot[1] and color in slot[2]. That's a bit cleaner than changing
the vertex shader code.
Tested with progs/tests/zreaddraw.c
|
|
|
|
|
|
Use the _mesa_clip_readpixels() function to clip the src region against
the buffer's bounds. Neatly, the resulting pixel unpack object's
SkipPixels/SkipRows fields can be used to determine the position of the
region in the destination texture.
Fixes crash in progs/samples/copy.c and probably other cases.
|
|
(cherry picked from commit f05a4ee6f2840590c90da4be2fe5c6295410a5af)
|
|
|
|
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)
|
|
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.
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
Conflicts:
src/gallium/drivers/r300/r300_blit.c
src/gallium/drivers/r300/r300_emit.c
src/gallium/drivers/r300/r300_state_derived.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Needs testing.
|
|
This fixes incorrect Z position of glBitmap, glDraw/CopyPixels for the
svga driver. Now we use 0.5, 0.5 as is typical for ordinary 3D rendering.
(cherry picked from commit bcd561c66777e58dbb29a573c4d2279772bac6c5)
|
|
The ST_SURFACE_x values should match the Mesa BUFFER_x values.
Added some assertions to prevent future mix-ups.
(cherry picked from commit 13cbb5fff68ef8831230638e9f0b29a217750e9d)
|
|
Some st functions assume that they are identical.
(cherry picked from commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd)
|
|
|
|
|
|
|
|
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
We probably don't want to propagate this condition to the pipe driver,
this reverts commit f455ca6490fcb65781b21f81c7117bd923e250d1 and the
dri_update_buffer flush altogether until an agreement is reached.
|
|
Undoes part of commit f455ca6 which would permit pipe->flush() to be
called while the VBO module still had its buffers mapped. Some
drivers care deeply about this. Sorry for not spotting this earlier.
|
|
So far the frontbuffer was only being flushed on st_glFlush and
st_glFinish, however, a co-state tracker may need to make sure that
any frontbuffer changes are already on its way to the actual front.
The dri2 state tracker will need this for event-driven GL applications
to resize properly (It could also be done calling "dri_flush_frontbuffer",
but that way we would flush unnecessarily in the double-buffered case).
Additionally this patch avoids flushing the mesa rendering cache if
PIPE_FLUSH_RENDER_CACHE wasn't specified.
|
|
Core Mesa will not call ctx->Driver.CheckQuery() if the Ready flag
is already set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes invalid calls to rastpos_point/line/tri() that can occur
when glRasterPos() is called while in feedback or selection mode.
(cherry picked from commit b3c7dc6ff232eb4c5ff6b0ddcfa90bcb56f78df1)
|
|
Don't use pipe->draw_range_elements() if min_index=max_index=~0 since
that doesn't provide any useful info.
Also, implement the loop around pipe->draw_range_elements() when
nr_prims > 1.
|