Re: [Dri-devel] texture compression and a thing to add to the driver support list.

[Michael <le...@nt...>]

On Sun, Jun 09, 2002 at 12:11:58AM -0700, Mike Mestnik wrote:
> --- Jacek Pop?awski <jp...@in...> wrote:
> > On Fri, Jun 07, 2002 at 09:42:22AM -0400, Al Tobey wrote:
> > > I don't forsee a big problem performance wise if the textures are mangled
> > > during the loading stage, but I'm still learning ...
> > 
> > Please keep in mind that some applications update texture every frame.
> > 
> 
> GASP!
> 
> Are there any cards or drivers that actually upload textures every frame?

I think the key word was applications, not drivers/cards.

It's how rtcw does the in game videos, unless I'm mistaken.

Plus, you'll swap textures if the app uses more texture space per frame than
you have free, so yes, in some situations you'll have a few swaps per frame.
(rtcw with textures on max with a 32mb card for instance  - or simply
running from one part of a level to another)

> Is there any thing like this for DRI?
> This to me would seem to be an important thing to add to the supported feature list.

Well it's Mesa (an opengl implementation) atop a hardware specific card
driver using the DRI architecture. 

What Mesa implements is OpenGL 1.x + extensions - that's the place
to look to see what 'supported features' there are. 

What the drivers implement is typically hardware features that
improve the performance of those OpenGL features + extensions - falling
back to software if the state means the hardware implementation can't be
used.

Some hw features might not be enabled but, in principle, they could be
as they'll improve performance for an existing OpenGL feature (e.g.
Radeon hyperz)

Some features might not have a corresponding OpenGL feature, in which
case you're not likely to gain much by adding it to DRI unless there is
either a) an OpenGL extension you can add to Mesa that will let you use
the feature from an application or you write one, or b) you invent your
own API and plug it on top of DRI.

-- 
Michael.