On Mon, Feb 24, 2003 at 09:48:42AM -0800, Ian Romanick wrote:
What about apps that send uncompressed textures into the driver, expect the driver to compress then, and then read the textures back? According to the spec, the textures app will read-back compressed data. I don't see anyway to work around that.
Mmm, didn't think about this either.
I think the main problem here is that the extension are badly done, or at least in this case. They could be split in a s3tc using extension, which would just be able to send s3tc compressed data to a s3tc aware hardware, and then you would have the more complete s3tc extension, which can do more.
It's not poorly written. It was written to be orthogonal to the rest of OpenGL. If you send a texture into the driver as GL_RGB/GL_UNSIGNED_BYTE and ask to read it back as GL_RGB332, the driver reformats it. Why should compression be any different?
I think the "problem" is that the extension was written by engineers, not lawyers. :)
The idea with the read-back is that you could render to a pbuffer, bind the pbuffer to a texture, and read back the compressed data. Then the app could re-use the compressed texture later.
BTW, what is the use of doing s3tc compression if the graphic card cannot handle it ? to save memory usage or something such ?
If the card doesn't support S3TC, it should NOT export the extension. I don't see what you're getting at. The only possible exception would be cards that support some other compression format (i.e., Voodoo4 or i830 that support FXT1) that silently convert the texture data at load time.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
