| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Need to take the draw buffer's up/down orientation into consideration
when setting the sprite_coord_mode field.
Fixes inverted sprites when drawing into an FBO.
|
|
Prevents segmentation fault when trying to set the viewport/scissor
after a context/drawable visual mismatch.
|
|
Fixes segfault in glRasterPos()
|
|
|
|
|
|
|
|
Conflicts:
Makefile
src/mesa/main/version.h
|
|
The stride needs to be in texels, not bytes.
|
|
We were passing a GL texture target instead of a pipe_texture_target enum.
|
|
|
|
Conflicts:
Makefile
src/mesa/main/version.h
|
|
|
|
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.
|
|
Previously only non-indexed or indicies-in-a-vbo cases were handled in
this code. This change adds the missing regular indices-in-memory
case.
|
|
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
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.
|
|
Previously only non-indexed or indicies-in-a-vbo cases were handled in
this code. This change adds the missing regular indices-in-memory
case.
|
|
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
|
|
Previously we created the pipe_surface during framebuffer validation.
But if we did a glCopyTex[Sub]Image() before anything else we wouldn't yet
have the surface. This fixes that.
|
|
Furthermore, return pointer(s) to the front color buffer(s).
|
|
When we create a new front color buffer (user called glDrawBuffer(GL_FRONT))
initialize it to the contents of the back buffer. Any previous call to
SwapBuffers() would have done that in effect, so make it reality.
|
|
Indicates whether there's defined image contents, or garbage/don't care.
This is set when we draw into a renderbuffer and cleared when we resize/
reallocate a renderbuffer or do a buffer swap (back buffer becomes undefined).
We use this to determine whether the front color buffer has been drawn to,
and whether to display its contents upon glFlush/Finish(), when the new
st_swapbuffers() function is used.
|
|
The pointers to the front/back renderbuffers are exchanged.
This new function isn't actually used yet...
|
|
Before we always created the front color buffer, even if was never used.
This can save some memory.
|
|
Already doing this for driver.flush()
|
|
|
|
It seems quake4 can hit these attributes sometimes.
|
|
Proper fix for this hasn't been identified, but avoid crashing.
|
|
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
We were incorrectly applying the destination texture face and level
when requesting a transfer to the temporary texture, which has only
one face and level. This would obviously cause problems uploading to
compressed cube and mipmap textures.
|
|
|
|
This is a follow-on to commit c1a3b852807fb160f0cd246c1364b7336b4b947e.
Note that (at this time) wherever _NEW_PROGRAM_CONSTANTS is set we're still
setting _NEW_PROGRAM so this won't really make any difference (for now).
|
|
Lost in commit e50dd26ca6d0eb0d0f97c2780020ea16e3d4a687.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
When a new program is bound but no constants are updated we still need
to update the Gallium const buffer.
|
|
We can simplify this now that we no longer have any dynamic atoms.
|
|
Just use the new _NEW_PROGRAM_CONSTANTS flag instead.
|
|
|
|
|
|
This needs a proper fix to propogate the out-of-memory condition back
up to Mesa and the app as a GL error. Until then, at least catch the
problem at its source.
|
|
|
|
|
|
There are two usage types of buffer CPU accesses:
One where we try to use the buffer contents for multiple draw commands in
a batch. (batch := sequence of commands that are flushed together),
like incrementally adding bitmaps to a bitmap texture that is reallocated
on flush.
And one where we assume we can safely overwrite the old buffer contexts, like
glTexSubImage. In this case we need to make sure all old drawing commands
referencing the buffer are flushed before we map the buffer.
This is easily forgotten.
Add wrappers for the most common of these operations. The first type is
prefixed with "st_no_flush" and the second type is prefixed with
"st_cond_flush", where "cond" indicates that we attmpt to only flush
if there is indeed unflushed draw commands referencing the buffer.
Prefixed functions are
screen::get_tex_transfer
pipe_buffer_write
pipe_buffer_read
pipe_buffer_map
Please use the wrappers whenever possible.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
|
