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

[Kenneth Graunke]

On 07/15/2011 11:22 AM, Brian Paul wrote:
> On 07/15/2011 10:07 AM, Dave Airlie wrote:
>> 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.
> 
> Sounds good to me.  I think we'd only keep the swrast, intel and maybe
> r300/r600 drivers.  Opinions?
> 
> -Brian

Sounds good to me as well.

--Kenneth