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