Allen Akin <a...@arden.org> 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. -tom ------------------------------------------------------------------------------ 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
