Allen Akin wrote:
On Thu, Oct 17, 2002 at 10:35:17AM -0700, Ian Romanick wrote:
| On Thu, Oct 17, 2002 at 10:09:28AM -0700, Allen Akin wrote:
| > Also, I wouldn't want to encourage app developers to use the absence of
| > an extension string to determine whether a core function is hardware
| > accelerated. ...
| | I'm not suggesting that the semantic be "if it's in the extension string
| then it is absolutely accelerated." There are plenty of other things in
| core OpenGL that don't meet that. I am suggesting that the semantic be "if
| it's NOT in the extension string then it is absolutely NOT accelerated."
That's exactly what I was worried about. Though it would have been
clearer if I'd said "...the absence of an extension string to determine
whether *or not* a core function is hardware accelerated."
| From reading ARB meeting minutes, I can see that this problem has long
| plagued the ARB. My person opinion is that OpenGL drier and application
| developers need to take a cue from other computer optimization: the only
| way to determine if something is "fast enough" is to try it. ...
I've been a vocal proponent of that approach for a long time, and even
wrote the first version of the isfast library to suggest ways to
implement it. But nowadays I'm a lot more open to a standardized query
mechanism than I used to be.
I think what most people are leaning toward is a "did I fall back to
software?" flag. You'd use it by enabling the query, executing a
command to clear the flag, setting state, drawing some stuff, then
executing a command to query the flag. If it's set, then the driver
found it necessary to fall back to some slower alternate implementation
(whatever that means is driver-dependent; it doesn't have to be HW vs.
SW). That's fairly easy to implement, and efficient if it can be
limited to validation-time rather than drawing-time. Interpreting the
result is easy for some cases, very hard for others, but probably always
easier than isfast (or other benchmarking schemes).
Actually, this would be a good small project for someone to implement in
Mesa. If it seems to work well, it would make a great proposal for the
ARB.
It would be an interesting project. I've already thought of one wrinkle.
If we only return a true/false result from the slow/fast query it may not be obvious to the application writer what caused the slow path to be taken, or what to do about it. As a concrete example, suppose you want to render with a cube map, a special tex combine mode and blend-func-separate. If glIsFast() returns false, it might be because any of those three features is not hardware accelerated. You might try all eight combinations of enabling/disabling those features before you found glIsFast() = true. Or, some other state besides those three factors might have put you on the slow path. <sigh> In the DRI drivers we keep a bitfield to determine if/why we need a software fallback. I suppose IsFast() could return a similar bitfield but coming up with a set of meaningful bits at the right granularity would be a challenge too. -Brian ------------------------------------------------------- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
