Re: [Dri-devel] Detecting software fallbacks

[Ove K. <ov...@tr...>]

man, 04.08.2003 kl. 20.05 skrev Ian Romanick:
> I think the conclusion was that as a tool for anything other than 
> development / debugging, such a thing was not terribly useful.

Then I beg to differ. Many advanced 3D engines can switch between
several types of texture rendering techniques depending on what the
hardware can support. It has nothing to do with debugging, since this is
all about making an application or game give maximum performance on any
*user's* system, not on the developer's system. Perhaps the idea of
having apps automatically tune themselves to the user's system is an
unheard one for the DRI, but it's not in the real world. For example, I
believe the Max Payne engine could scale itself from taking advantage of
any cool environment-mapping features present in a high-end graphics
card, through relatively simple and flat graphics on a low-end card, and
even all the way down to doing its own software rendering on a 2D card
(at least the version of MAX-FX used in 3DMark2000 could). I'm also
pretty sure that the Grand Theft Auto 3 engine is similarly adaptable to
the texturing capabilities of the user's system. And the fact that some
Linux games have also a need for this feature, which they've worked
around by checking vendor/renderer strings, should also have spoken for
itself.

> The problem with it is, especially in the case of the MGA, changing one 
> subtle thing (like changing the texture constant color from 0x00ffffff 
> to 0x00ffff00) can change whether or not there is a fallback.  I don't 
> think that apps should or would, at run time, detect these types of 
> things and change their behavior.

But Direct3D allows them to do exactly that, and this facility is
*used*. A lot. Maybe you don't like it, but game developers are not
interested in having users complain about "your game runs like crap on
my G400, but it runs quake3 fine, can't you program?" if they can avoid
it by simply checking at runtime that "using this nifty texturing method
causes a software fallback in the user's driver, probably because of
hardware limitations, switch to this other less cool method instead",
and thus get a decent framerate even on low-end cards, and still be able
to take advantage of high-end cards.

> Either it needs a constant color of 
> 0x00ffff00 or it doesn't.

If you mean the app, then this is a naive view. In most cases, the
engine may not *need* such a constant color, it can work fine without
it, it'll just disable the particular effect that needs it, or replace
it with a less realistic and less demanding one, or just a more
compatible multipass technique, as software fallbacks are still worse.
But it'd still be nice for the engine to know when this constant color
does *not* cause a software fallback, so that the more demanding
technique can be used if the user upgrades his card.

Just look at GTA3 to see how important this is - it does not have *any*
3D options whatsoever - it's designed to Just Work on the user's system,
autodetecting its capabilities and tuning itself to it. And Direct3D
lets it - why can't OpenGL implementations be as end-user-friendly? Can
Linux really win on the desktop if 3D games can't be made this simple?