Hardware vs. software - again

[zed]

this is something where we could help ourselves instead of bitching to the driver makers, all we need is a table like so
btw the info is bogus.

                   radeon  |  tnt1 | savage3
3dtextures         HW(1.23)|       |   sw
antialiased lines   sw     |HW(6.5)|   
max texture size 
etc

the numbers are in what driver version the functionality came.
blanks mean its not possible.
NOTE there will prolly be a lot of little numbers denoting notes in the table but some info is better than none.

lets help ourselves (im willing to find out the info about the vanta)

[mcraighead]

ET3D: That's not fair, to say that this is a new problem. In fact, it was a *much* bigger problem several years ago, when large portions of the OpenGL API were *completely* unaccelerated on the majority of drivers.

I think there is also a lot of fundamental confusion about "HW vs. SW" and "fast vs. slow". I would assert that you, the app developer, don't _actually_ care about HW vs. SW; you care about fast vs. slow. This is not an on-or-off thing, either, since there are different degrees of SW and many different degrees of performance. Furthermore, you'll have a very hard time building a table, because it's usually not just one feature that does it; it's combinations of multiple features at the same time. And when you start asking for that kind of information, well, some of it is definitely not the kind we're going to share.

If anyone has *real* problems with this in a real app, they should consult with our devrel people to figure out what they need to change in their app, or, what *we* need to change in our driver.

- Matt

[ET3D]

Matt, I agree that there were some essential problems some years ago. Some cards didn't have any OpenGL acceleration, or just "miniGL" for Quake engine support. A lot of hardware didn't support all OpenGL features, and silently failed to use them, that is, there was no indication to the program that the feature wasn't available. It may be argued that providing a software only rendering path in these cases is preferable (although I'm not sure that it is). So I agree that what I said might have beautified reality a bit

About "fast vs. slow", yes, this is indeed what I care about, but it's more than this. I think that I described it somewhere, but it may be buried in my long and convoluted first post in this thread, or in another thread, so I'll explain it again shortly.

I do care first and foremost about speed, but I also care about _potential_ speed. That is, I see a major difference between running on a chip that is too slow for my program's basic requirements, and running on a chip that would be fast enough if I didn't drop into software rendering. In the latter case, if I can drop some eye candy for good frame rates, I'd like to know this.

This feature is mainly a convenience. It's a time saver for both developer and user. From the user's point of view, it saves the need to tweak options manually, or run benchmarks I provide, just in order to get basic performance or image quality (which also alters the initial perception of my software). From the developer point of view, it provides a means to detect sources of bad performance more easily, and adjust to them more easily at runtime when running on hardware that I haven't tested with.

Even though in many cases it's a combination of features that may cause a need to drop to software rendering, or it could be just a code path that is not yet optimised in the drivers, there are cases that are much more obvious, and could easily be tested for. Things like using stencil or accumulation buffers, or 3D textures, or antialiased lines - unavailable hardware features that can easily be listed in a table. I admit that I'm not a driver writer, and certainly don't know the innards of your chips, but I would imagine that such features, that can be put in a table, can also be provided by the driver to a program through some mechanism.

I don't claim that this is a complete solution, but I also don't require a complete solution. Even if not all potential software rendering scenarios are detectable, it should be possible, I imagine, to cover a lot of the most common cases that would be interesting.