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].
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
