Allen Akin <> writes:
> On Mon, Dec 21, 2009 at 10:49:14AM -0700, tom fogal wrote:
> |                                                          ... 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.
[snip -- it's hard to know what to report]
> The only reliable way to solve the problem is to benchmark the
> operations you want to use, in precisely the conditions you intend
> to use them, and then make a judgement as to whether the performance
> is good enough.  This tends to be application-specific, so previous
> attempts to make a centralized database of results failed.  I
> wouldn't say it's impossible, but it is very difficult.

That's not nearly good enough either.

Rendering a 128^3 dataset in a 400x400 window (which is *tiny* for us)
on some Apple platforms (I think some Intels, older 10.5 with some ATI
cards) can take upwards of ten minutes, during which the application
is hung.  On Linux systems with really old nvidia drivers, it crashes
the system.  On Linux systems with old nvidia drivers, it crashes the
X server.  On Linux systems with new nvidia drivers, a watchdog timer
kicks in after 4 seconds and the screen visibly blinks, corruption is
observed in other apps such as firefox, etc.

Further, drivers can do whatever they want on just about any GL call.
We recently added such a `benchmark' feature to our application,
choosing the LoD dynamically based on the time to render the previous
few frames.  Many drivers will take, e.g. ~50ms for the majority of
frames, and then spike with e.g. a 300ms frame before dropping back
down to 50.

This `solution' is like asking app developers to benchmark JITted code;
there's far too much variability for it to actually work.  I would much
rather deal with a state explosion.

> I haven't tracked this subject since I left the ARB, but maybe the
> Khronos folks have done some more work on it.

What is the appropriate forum for this?

> As you say, using extension advertisements seems to be the most
> common workaround, though it's far from perfect.

As I argue initially and above, since it is the only possibility at
this point, I'm going to argue strongly that extension advertisement
implies some sort of standard on performance.  Alex reported the HW
capabilities in reference to this, which in our case would mean we can
use the HW-supported NPOT textures.  However in the absence of, say, a
vendor extension for reporting this, I'd rather just implicitly enable
our workaround at the app level.


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 
Mesa3d-dev mailing list

Reply via email to