[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source
From:       Ian Romanick <idr () freedesktop ! org>
Date:       2010-03-30 21:27:16
Message-ID: 4BB26CB4.2010209 () freedesktop ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Corbin Simpson wrote:
> On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick <idr@freedesktop.org> wrote:
>> Philipp Klaus Krause wrote:
>>
>>> Well, there is TexSubImage2D. Assuming we have a compressed texture
>>> stored internally as some S3TC format and then the application replaces
>>> part of it using TexSubImage2D. According to ARB_texture_compression we
>>> may not go to uncompressed ("the allocation and chosen compressed image
>>> format must not be a function of any other state and cannot be changed
>>> once they are established". And while ARB_texture_compression does not
>>> require TexSubImage2D support, EXT_texture_compression_s3tc does.
>> Ah.  Good catch.  My best guess is that there are few, if any, apps that
>> do that.  Such apps would be easy to detect.  We could enable the
>> non-conformant behavior by default, and provide a driconf switch to
>> disable it.  We'd then need to blacklist apps that use unsupported
>> cases.  Since we can detect these cases, we can log a message when the
>> occur.
>>
>> Does that seem like a reasonable compromise?
> 
> We don't have to compromise at all. If the image is already compressed
> internally, then updating it with TexSubImage or CompressedTexSubImage
> must be done along the block boundaries, and must be done with
> pre-compressed blocks, so we are never decompressing and recompressing
> the texture.

I suspect that TexSubImage calls won't provide compressed data.  The
compromise is the case where the data is compressed but the subimage is
not.  Imagine the case where a game has a bunch of textures for walls.
Something happens in the games, say the player "tags" the wall with
their logo (like in Half-Life), and the game modifies the original
texture using TexSubImage (or CopyTexSubImage).

> I've pushed a branch, s3tc-by-the-book, to my personal repo
> (http://cgit.freedesktop.org/~csimpson/mesa/?h=s3tc-by-the-book), that
> changes to this newer behavior. I haven't written up test cases for
> these delightful corners and edges we're finding, but they shouldn't
> be too hard to handle. The basic idea behind this branch is that if
> the internal format request indicates that GL should compress the
> texture with S3TC, but we don't have libdxtn present, we just change
> the internal format to something more sensible and refuse to compress.

I'll take a look at it, but it sounds like the right idea.  How are
software fallbacks handled, if at all?  This actually sounds like a job
for metaops.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuybLIACgkQX1gOwKyEAw/LXACfaC2ijrir5gU2NJ+4ViqIKmct
56gAnRWe1w2NkeKFluEsWg+Ur6jmzcay
=XvYM
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[prev in list] [next in list] [prev in thread] [next in thread]