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

[Jose Fonseca]

----- Original Message -----
> 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?

Sounds good to me FWIW.

Jose