On Thu, Sep 29, 2005 at 01:54:00PM -0400, Adam Jackson wrote: | The deeper issue here is whether it's actually useful to require some minimum | level of functionality even when large swaths of it will be software. If I | don't have cube map support in hardware, do I really want to try it in | software? Is that a useful experience for developers or for users?
For OpenGL at least, history suggests the answer is usually "yes." The argument goes back to the pre-1.0 days, when texture mapping was only available on fairly exotic hardware. The decision was made to require it in the standard, and it turned out to be valuable on pure software implementations because (1) it was fast enough to be usable for a surprisingly large range of apps; (2) people with older hardware still had the option to use it, rather than having that option closed off up-front by the people defining the standard, and they found uses that were worthwhile; (3) development could occur on older hardware for deployment on newer hardware; (4) it served as a reference for hardware implementations and a debugging tool for apps. This experience was repeated with a number of other features as OpenGL evolved. If there's no consensus in the ARB about the desirability of a given piece of functionality, it tends to be standardized as an extension (or very rarely as a subset, like the Imaging Operations). Extensions are optional, so they provide middle ground. But eventually, if a piece of functionality proves valuable enough to achieve consensus, it moves into the OpenGL core and software implementations become mandatory. OpenGL ES has taken a slightly different route (with API profiles). I don't have firsthand knowledge of how well that's worked out. | Perhaps what I would like is a new set of glGetString tokens that describe | what version and extensions the hardware is actually capable of accelerating, | rather than what the software supports. This question also goes back to the very earliest days of OpenGL. The fundamental technical problem is that there is no tractable way to define an "operation" so that you can make a simple query to learn whether it's accelerated. So much depends on the current graphics state (how many TMUs are enabled, the size of image or texture operands vs. the size of available video memory, whether colors are specified by floats or unsigned chars, whether vertices lie in DMAable or CPU-accessible address space, etc., etc., ad infinitum) that most of the time you can't even express a simple question like "Is triangle drawing accelerated?" A number of other APIs have gone down this road in the past, and none of them found a viable solution to the problem. In practice, two approaches are used with OpenGL. One is simply to benchmark the operations you want to perform and determine whether a given OpenGL implementation is fast enough. (This is used by "isfast"-style libraries and by game developers, always during development but occasionally during installation or initialization.) The other is to assume that if an extension is advertised (via glGetString), then it's accelerated; if an extension is present but not advertised, then it's probably not accelerated. There was interest a couple of years ago in implementing a more sophisticated mechanism. One option was a query of the form "If I try to execute a given drawing operation right now, with all the graphics state that currently holds, will it be accelerated?" (D3D has a pipeline validation mechanism that's something like this). Another was a query of the form "Have any software fallbacks occurred since the last time I asked?" that you could make after you'd actually run one or more operations. There were unanswered questions about whether either of these could be made worthwhile. I haven't tracked the ARB since late last year so I don't know if any progress has been made on this front. Sorry for the long reply. These questions come up from time to time, and I wanted to make sure everyone had the background information. Allen ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel