On Tue, Aug 05, 2003 at 12:43:51AM +0200, Ove Kaaven wrote:

 > I don't buy this argument. ValidateDevice doesn't do a lot of explaining
 > either. The interface it presents is not hard to implement. I'm only
 > asking for knowing at runtime that with the current environment, a
 > fallback kicks in. *Why* it kicks in is secondary and can be checked
 > at development time with the debugging techniques you already
 > mentioned, but when the game is finished and deployed, only *whether*
 > the fallback kicks in really matter.

 That's a common request of OpenGL programmers and a common
 misunderstanding spread by Direct3D programmers (because of
 capabilities and the like).  Checking the extensions string reported by
 the driver you might see GL_EXT_texture3D.  Many OpenGL programmers ask
 immediately "is that software or hardware?"  The correct answer is "who
 cares?"  What you want to know is if that's fast or not.  With or
 without Direct3D-like capabilities, you *have* to code multiple
 rendering paths (and this is the misunderstanding spread by Direct3D
 programmers, many seem to think that capabilities saves them from this
 "redundant" work, which is utter bovine excrement).  The question is
 _not_ "does this rendering path run in software or hardware" but "if I
 take this path, can I still call this interactive rendering?"  And the
 only reliable way to do that is to try the path.  It's really not that
 hard:

    for each rendering path
        is the path supported?
            measure path performance

    select best path according to predefined criteria

 and predefined criteria can be something like:

    * Best absolute performance (you end up with oh,-not-so-feature-rich
      paths, but some users want that)

    * The path with the most features which still delivers more than N
      fps

 The only question is how to get a reliable measuremnet of the path's
 performance.  If initialization time is an issue, you can move the path
 selection into the loop and use the second criterion (i.e. "if the path
 manages more than N fps I'm happy, break")

 Point is, you have to render.  No ammount of capabilities and
 ValidateDevice non-sense is going to be able to tell you that rendering
 large multitextured polygons brings the whole thing to its knees
 because the CPU can't send geometry fast enough or because the card
 can't rasterize fast enough.

 Marcelo


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to