We sometimes need a rendering context when deleting renderbuffers.
Pass it explicitly instead of trying to grab a current context
(which might be NULL). The next patch will make use of this.
Note: this is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
_mesa_delete_renderbuffer() should free the mutex (though that may be a
no-op) and then free the renderbuffer object itself. Subclasses of
gl_renderbuffer can use this function too.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The former was only used for clearing buffers. The later wasn't used
anywhere! Remove them and all implementations of those functions.
Reviewed-by: Eric Anholt <eric@anholt.net>
This was only used by the xlib driver to add an alpha channel to the
front/window color buffer. This was no longer going to work well with
the move to direct mapping of renderbuffers.
Reviewed-by: Eric Anholt <eric@anholt.net>
This fixes a regression from the recent glReadPixels changes found
with the piglit hiz tests.
Use either MESA_FORMAT_RGBA8888 or MESA_FORMAT_RGBA8888_REV for color
buffers depending on endian-ness. Before, the gl_renderbuffer::Format
field was MESA_FORMAT_RGBA8888 but the data was really stored as
MESA_FORMAT_RGBA8888_REV when using a little endian machine.
Getting this right matters now that we can access renderbuffer data
without going through the span functions (namely glReadPixels() +
MapRenderbuffer()).
These vars will just get overwritten when we call _mesa_add_renderbuffer()
anyway. We only need to set the InternalFormat field when we create the
software renderbuffer.
Reviewed-by: Eric Anholt <eric@anholt.net>
EXT_framebuffer_object bspec says:
Get Value Type Get Command Initial Value
------------------------------- ------ ----------- -----------
RENDERBUFFER_INTERNAL_FORMAT_EXT Z+ GetRenderbufferParameterivEXT RGBA
NOTE: this is a candidate for the 7.11 branch
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Mesa core's is generic for things like osmesa.
For swrast_dri.so, we have to do Y flipping. The front-buffer path
isn't actually tested, though, because both before and after it fails
with a BadMatch in XGetImage.
Reviewed-by: Brian Paul <brianp@vmware.com>
Using GL_NONE as DataType of Z32_FLOAT_X24S8, not sure what I should put there.
The spec says the type is n/a.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Of these, intel will be using I and L initially, and A once we rewrite
fragment shaders and the CC for rendering to it as R.
Reviewed-by: Brian Paul <brianp@vmware.com>
This will replace the current (broken by trying to use an enum in the
preprocessor) spantmp2.h support I wrote for the intel driver.
Reviewed-by: Brian Paul <brianp@vmware.com>
Since we're using GTT mappings now (no manual detiling), there's
really nothing special to accessing these buffers, other than needing
the new RowStride field of gl_renderbuffer to accomodate padding.
Reduces the driver size by 2.7kb, and improves glean depthStencil
performance 3-10x (!)
Reviewed-by: Brian Paul <brianp@vmware.com>
This will allow some drivers to reuse the core renderbuffer.c get/put
row functions in place of using the spantmp.h macros. Note that
unlike textures, we use a signed integer here to allow for handling
FBO orientation.
Reviewed-by: Brian Paul <brianp@vmware.com>
We use this format to represent the accum buffer. No snorm texture
sampling or rendering takes place.
Fixes failed assertion with swrast and any app using the accum buffer
(and glxinfo).
After all the recent color-index visual support removal,
_mesa_add_color_index_renderbuffers is no longer used anywhere.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The rb->InternalFormat field will be set by the caller if the allocation
succeeds. Until then, this field's value can't be used. Fixes a failed
assertion with FlightGear.
