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

Dave Airlie airlied at gmail.com
Fri Jul 15 09:07:21 PDT 2011

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.


More information about the mesa-dev mailing list