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

[Brian Paul]

On 06/24/2011 11:27 AM, Eric Anholt wrote:
> 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.

OK, I'll be on vacation next week but I hope to have some time to work 
on this then.

-Brian