On Mon, Dec 21, 2009 at 12:49 PM, tom fogal <tfo...@alumni.unh.edu> wrote: > Corbin Simpson <mostawesomed...@gmail.com> writes: >> So, yet another thing that r300 sucks balls at: NPOT textures. We've >> been talking it over on IRC, and here's the options. >> >> 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept >> non-NPOT dimensions on textures. This sucks because it means that we >> don't get GL 2.0, which means most apps (bless their non-compliant >> souls) will refuse to attempt GLSL, which means that there's really >> no point in continuing this driver. > > What's the performance of NPOT when implemented in the driver? > > 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. Alex > We don't have the resources to maintain a card database of "this card > with this driver advertises <X> but implements it in software", though > such a thing is desperately needed. It would be much easier for us if > "advertising <X> means we implement it in HW". Incorrect reporting of > NPOT in particular is so prevalent that we have a settings dialog that > allows a user to "force power of two textures", causing us to silently > extend our textures before uploading them. Many of our users don't > even know what a GPU is. What else can we do, though? > > Anyway, all that said, if performance suffers in any way I vote for > not advertising the extension or GL 2.0. If an application is broken, > an application is broken. Maybe add a debug statement so that the > application author can figure out what they've done wrong, should they > ever find the desire to fix their code. > > I realize this is getting beyond the scope of your inquiry. GL really > needs a query that allows an application developer to figure out if a > feature is accelerated by the hardware or not. Since it lacks this, > the advertising of extensions is just about the only thing we, as app > developers, can use as a heuristic. > > -tom > > [1] ... maybe this isn't such a big deal. GL's memory management is > lame/opaque and as such we haven't found a way to utilize this > information usefully, yet. > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
