On Fri, Jul 15, 2011 at 2:22 PM, Brian Paul <bri...@vmware.com> wrote: > 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?
Maybe radeon and r200 as well for now. Most of the radeon code is shared across the classic drivers. Alex _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev