On Mon, 09 Feb 2004 09:14:28 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:

> Felix Kühling wrote:
> 
> > I tracked down the Savage4 texture corruption problem last night. A
> > patch is attached, but it'll break ProSavages. A real solution will have
> > to wait at least until the 3D driver can determine the chipset. The
> > whole texture upload code is terribly inefficient the way it implements
> > tiling and sub-tiling of texture memory right now. I'm going to rewrite
> > that sometime.
> 
> This is something that I've thought about from time to time.  There are 
> a few cards that support (or encourage) some sort of tiled texture 
> format.  This has gone unsupported in the past because of the expense in 
> tiling on texture upload.  The tiling has to be done at upload because 
> the original texture needs to be kept around for software fallbacks.
> 
> Here's my question.  Are there any of the tiled formats that are common 
> to more than one card?  That is, do Savage and Rage128 use the same 

I'm not sure what exactly you have in mind when you say "the same
tiling". On the savages the exact tiling format depends on the texel
color depth and on the chipset (that was the problem I fixed).

> tiling?  If so, we should add support for those formats to core Mesa. 
> If not, then we need to look at how to make it easier for drivers to add 
> custom formats.  Adding the structures and functions to support the 
> fallbacks is easy, the hard part is converting the incoming texture to 
> the internal format.  This is handled by _mesa_convert_texsubimage*d in 
> texutil.c, which uses a static internal table to look-up the conversion 
> function.  If that fails, then transfer_teximage in texstore.c is used.

I have to look at that code. I think that there is some more stuff that
the savage driver could take advantage of. Right now it also does color
depth conversion at upload time. Is that how all the other driver work?

> 
> One sollution would be to add a SelectConvertSubimage method to the 
> gl_texture_format structure.  This method would work like the 
> convert_teximage*d_* functions in texutil.c.  I'm still trying to grasp 
> the inner workings of all that code, so forgive me if that's a silly 
> suggestion.

Let's discuss this at the IRC meeting. I'm going to be a bit late, as
usual.

Cya,
  Felix


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to