From: Allen A. <ak...@po...> - 2002-05-17 23:57:37
|
On Fri, May 17, 2002 at 02:06:02PM +0100, Ian Molton wrote: | ... | ...I need lists of | supported features on various video cards. | ... | Please tell me if the features are: | | (A)ccelerated | (U)naccelerated | (N)ot available on that hardware | (S)oftware rendered due to being unavailable on that hardware. There's a long history of controversy in the OpenGL community over the question of "is a given feature accelerated?" This is because the answers to such questions are rarely simple enough to be stated clearly. A driver might accelerate a feature only for some pixel formats, or only when direct-rendering (but not indirect-rendering), or only when sufficient video memory is not being used for other purposes, or only when the feature is not used at the same time as some other feature (e.g., it requires a texture unit that's not available when the app is already multitexturing), or only when the target window is unoccluded; or a feature might be "supported" by the hardware but be slower than a software implementation on high-end CPUs; or ... (you get the idea). In general, we decided to break the question into two parts: 1. Does a feature work at all? (Correctness) 2. How fast is it? (Performance) The OpenGL conformance tests and other test suites are used to answer part 1. isfast, GLperf, Viewperf, and other benchmarking tools are used to answer part 2. One of the original goals for glean (glean.sourceforge.net) was to create a set of correctness and performance tests for the features that the graphics developer community believes are important. If such tests existed, then the sort of database you need could be created automatically by running glean on each driver of interest. glean also has the ability to compare the results for two drivers, so you can get a quick sense of the significant differences between them. This lets you compare different graphics cards, and different driver releases for the same card. So, one approach to answering your question is: Rather than attempting to create a table of supported features, which can't give complete answers about how well a feature is accelerated and risks becoming out-of-date with every driver release, write glean tests for the features you really care about and the process of documenting and comparing drivers can be automated. Writing an OpenGL test is *not* trivial. However, the codebase for glean is smaller and easier to approach than the codebase for a full-blown OpenGL driver. Writing a glean test for a feature you really care about is a good way for a new developer to get an introduction to OpenGL implementation issues, and makes a lasting contribution to *all* OpenGL drivers. <End of shameless request for more glean contributors. :-)> Allen |