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
_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that’s a super model! Visit http://clustering.foundries.sf.net/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
