mesa3d-dev

[Mesa3d-dev] Who is working on Texture Compression (other than me?)

[Bill W. <bil...@gr...>]

Who is working on texture compression in Mesa?  I have an implementation
of the ARB extension (mostly done by Brian Paul) and an implementation of
the GL_3DFX_texture_compression_FXT1 extension.  These are in the 
tdfx-2-1-branch
branch of the DRI tree.

If someone else is working on this, and depends on the implementation, please
let me know.  For something I am working on, the driver interface needs to
change.  In particular, there is a routine which calculates the specific
texture compression format given a generic one.  For example, given
GL_COMPRESSED_RGB_ARB, the routine might return GL_COMPRESSED_RGB_FXT1_3DFX.
This routine needs to have more parameters to support some more compressed
texture formats.

Please let me know if you are working in this area, and I can give you
more details.  They are generally pretty harmless, and I think they are
backward compatible, though I have not tested for this.

Re: [Mesa3d-dev] Who is working on Texture Compression (other than me?)

[Brian P. <br...@va...>]

Bill White wrote:
> 
> Who is working on texture compression in Mesa?  I have an implementation
> of the ARB extension (mostly done by Brian Paul) and an implementation of
> the GL_3DFX_texture_compression_FXT1 extension.  These are in the
> tdfx-2-1-branch
> branch of the DRI tree.
> 
> If someone else is working on this, and depends on the implementation, please
> let me know.  For something I am working on, the driver interface needs to
> change.  In particular, there is a routine which calculates the specific
> texture compression format given a generic one.  For example, given
> GL_COMPRESSED_RGB_ARB, the routine might return GL_COMPRESSED_RGB_FXT1_3DFX.
> This routine needs to have more parameters to support some more compressed
> texture formats.
> 
> Please let me know if you are working in this area, and I can give you
> more details.  They are generally pretty harmless, and I think they are
> backward compatible, though I have not tested for this.

You and I are the only ones who've touched that code.  Go ahead and make
your changes.

-Brian

[Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Ian D R. <id...@cs...>]

> Who is working on texture compression in Mesa?  I have an implementation
> of the ARB extension (mostly done by Brian Paul) and an implementation of
> the GL_3DFX_texture_compression_FXT1 extension.  These are in the 
> tdfx-2-1-branch branch of the DRI tree.

Is this extension going to only be supported on 3dfx hardware or will there
be a software fallback?  It sure would be nice to make sure that one's code
works right with the FXT1 textures without having to go out and buy a Voodoo
4/5/6.  The same could also be done with S3TC format textures, I suppose.

If this is not work that is currently planned, could someone perhaps provide
some guidance for others that might want to try and tackle this?

-- 
"You must understand...that there are two ways of fighting: by
 law or by force.  The first way is natural to man, and the 
 second to beasts.  But as the first way often proves inadequate
 one must have recourse in the second."  -- Machiavelli, The Prince

[Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Daryll S. <da...@va...>]

On Fri, Sep 22, 2000 at 09:10:24AM -0700, Ian D Romanick wrote:
> Is this extension going to only be supported on 3dfx hardware or will there
> be a software fallback?  It sure would be nice to make sure that one's code
> works right with the FXT1 textures without having to go out and buy a Voodoo
> 4/5/6.  The same could also be done with S3TC format textures, I suppose.

I don't think there are plans for software fallbacks, but in reality you
are much better off using non-compressed textures than using software
fallbacks. What really happens is that other drivers that don't
implement the feature don't advertise and it and the application doesn't
use it. 

I am not a lawyer, but from what I understand FXT1 can be implemented in
software, because 3dfx made it open source and even provided code to do
so. S3TC is very heavily protected and I wouldn't want to go near it for
a software implementation for fear of legal issues.

> If this is not work that is currently planned, could someone perhaps provide
> some guidance for others that might want to try and tackle this?

Guidance: FXT1 should be portable, but isn't useful unless the hardware
you're using supports FXT1. S3TC is supported on lots of hardware, but
due to legal restraints I wouldn't go near it.

						- |Daryll

[Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Ian D R. <id...@cs...>]

> > Is this extension going to only be supported on 3dfx hardware or will there
> > be a software fallback?  It sure would be nice to make sure that one's code
> > works right with the FXT1 textures without having to go out and buy a Voodoo
> > 4/5/6.  The same could also be done with S3TC format textures, I suppose.
> 
> I don't think there are plans for software fallbacks, but in reality you
> are much better off using non-compressed textures than using software
> fallbacks. What really happens is that other drivers that don't
> implement the feature don't advertise and it and the application doesn't
> use it. 

Well, it could be useful so that a person could write and test code that
uses that extension without having to have hardware the explicitly supports
it.  I for one don't have the extra $$$ just sitting around to go out and
buy a Voodoo5, but I'd really like for my code to correctly support its
texture compression extensions.

> I am not a lawyer, but from what I understand FXT1 can be implemented in
> software, because 3dfx made it open source and even provided code to do
> so. S3TC is very heavily protected and I wouldn't want to go near it for
> a software implementation for fear of legal issues.

You are probably right there.  It could possibly go either way, but I'd
rather not press my luck. :)

-- 
"The [300MHz P-II computer] is clearly not optimized for word processing.
 But when we pushed it to produce high-end 3D graphics, it truly shined."
                            -- Byte, Sept 97, pp. 33
What the hell does it take to do word processing?  http://www.cs.pdx.edu/~idr/

Re: [Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Brian P. <br...@va...>]

Ian D Romanick wrote:
> 
> > Who is working on texture compression in Mesa?  I have an implementation
> > of the ARB extension (mostly done by Brian Paul) and an implementation of
> > the GL_3DFX_texture_compression_FXT1 extension.  These are in the
> > tdfx-2-1-branch branch of the DRI tree.
> 
> Is this extension going to only be supported on 3dfx hardware or will there
> be a software fallback?  It sure would be nice to make sure that one's code
> works right with the FXT1 textures without having to go out and buy a Voodoo
> 4/5/6.  The same could also be done with S3TC format textures, I suppose.
> 
> If this is not work that is currently planned, could someone perhaps provide
> some guidance for others that might want to try and tackle this?

We're not doing a software implementation of texture compression.  It would
be impractical.

-Brian

Re: [Mesa3d-dev] Re: [Dri-devel] Who is working on Texture Compression (other than me?)

[Bill W. <bil...@gr...>]

I don't think it is possible or sensible to create a SW fallback,
especially for testing porpoises.  Unless you test with the real
HW, you won't know if it will work on the real HW.  Only 3Dfx
implements FXT1 as far as I know.

Certainly I don't plan to do anything with it unless I can think
of how it might be useful.