Faking those wrap modes is something that could be done either in the draw module (by decomposing triangles and adjusting the texcoords) or in the pixel shader (by adding logic to adjust the texcoord on a per-pixel basis). Probably the draw-module approach is the easiest to implement and is appropriate for an infrequently used path - you still get hardware rasterization speeds, just a more expensive vertex path.
Keith ________________________________________ From: Alex Deucher [alexdeuc...@gmail.com] Sent: Monday, December 21, 2009 10:18 AM To: tom fogal Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more r300g fear and loathing... > I work on real-time visualization apps; the one in particular I'm > thinking of does texture sampling of potentially-NPOT textures via > GLSL. If sampling a NPOT texture is not going to run in hardware, > the app is useless. Further, our app keeps track of the amount of GL > memory allocated for textures, FBOs and the like. If a texture is > going to be silently extended, that messes with our management routines > [1]. > The hardware supports rectangular texture sampling. What's missing is support for certain wrap modes and mipmaps with npot textures. Neither of which are used that often. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
