[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