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

[Dave Airlie]

On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul <brian.e.paul at gmail.com> wrote:
> On Thu, Jun 23, 2011 at 7:08 PM, 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.
>
>
> The map-texture-image-v4 branch that I just pushed implements this
> change.  It really cleaned things up for the better and will lead to a
> few more follow-on improvements.
>
> There's no obvious regressions with swrast or the gallium drivers.  I
> updated the intel driver code and tested i915 and it seems OK too, but
> I didn't do a full piglit run on it.  I also updated the legacy r600
> driver in case anyone cares but didn't do any testing of it.
>
> I didn't update any of the other legacy DRI drivers.  Would anyone
> object if we simply stop building mach64, r128, unichrome, sis, etc?
> I'd be happy to remove those drivers altogether for that matter.

we could EOL those in 7.11, and if anyone wants to ship them, they can
just build 7.11 for them.

Dave.