On 07/15/2011 10:07 AM, Dave Airlie wrote:
On Fri, Jul 15, 2011 at 4:10 AM, Brian Paul<brian.e.p...@gmail.com> wrote:
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul<bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
