[Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks
Brian Paul
brianp at vmware.com
Thu Jun 23 18:08:51 PDT 2011
I'd like to overhaul the part of Mesa related to texture memory
reading/writing.
The basic idea would be to add two new driver functions:
/**
* Map a 2D slice of a texture image into user space.
* (x,y,w,h) defines a region of interest (ROI). Reading/writing
* texels outside of the ROI is undefined.
*
* \param texObj the texture object
* \param level the mipmap level
* \param faceSlice the cube face or 3D/array image slice
* \param x, y, w, h region of interest
* \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT
* \param mapOut returns start of mapping of ROI
* \param rowStrideOut returns row stride (in bytes)
*/
void (*MapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice,
GLuint x, GLuint y, GLuint w, GLuint h,
GLbitfield mode,
GLubyte **mapOut, GLint *rowStrideOut);
void (*UnmapTextureImage)(struct gl_context *ctx,
struct gl_texture_object *texObj,
GLuint level, GLuint faceSlice);
glTexImage() would use these when loading texture data. Similarly
when glGetTexImage() returns texture data. swrast would also use
these before/after rendering.
We'd get rid of these fields:
struct gl_texture_image
{
...
FetchTexelFuncC FetchTexelc;
FetchTexelFuncF FetchTexelf;
GLuint RowStride;
GLuint *ImageOffsets;
GLvoid *Data;
...
}
The texel fetch/store code would get pushed into swrast.
The next step would be to do the same thing for renderbuffers and get
rid of all the Read/WriteSpan() stuff.
After that, maybe unify texture images and renderbuffers. I think I'd
like to do these things step by step to avoid too much disruption.
-Brian
More information about the mesa-dev
mailing list