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 . 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  ... 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 Mesa3dfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/mesa3d-dev