-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Corbin Simpson wrote: > On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick <i...@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® 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