[Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks

[Eric Anholt]

On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paul <brianp at vmware.com> wrote:
> 
> 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.

I'm thoroughly in favor of this plan.  Also, thanks for making stride in
bytes -- strides in pixels is one of the things I want to get rid of in
our driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110624/9b673fc8/attachment.pgp>