On Mon, Feb 24, 2003 at 06:44:05PM -0800, Ian Romanick wrote: > Sven Luther wrote: > >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?
Because the patent limits it. > I think the "problem" is that the extension was written by engineers, > not lawyers. :) Yes. > 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. Yes, but that would only be usefull if the hardware is able to handle the compressed data. But again, the problem is that the driver cannot (legally) compress data if the hardware cannot do it. > >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. Sure, ... If the card do not support compression, then it does not export the extension, and that is it, if in the contrary the card support decompression and compression, then we can export the extension as it is, but if it only supports decompression, then we are not able to tell it to the app right now. If the app wants to have the driver compress the data, then this mean it has already the data in uncompressed form and should either use its own algorithm (for which it pays a licence or whatever) to compress the data, or use another format. All this is as it stands now, we either have a licence and export the full s3tc extension, or we don't have a licence and don't export it, and the app either will not run, or not use s3tc. Now, there is also the case where the app pre-compresses the textures, or has obtained a licence to use s3tc, or whatever, and wants to feed the compressed data to the card, which is able to support s3tc decompression, but currently has no way of advertissing that. By adding a partial s3tc extension or whatever, that signals the app that it is able to send compressed textures to the board but not do the compression for the app, it would be possible for such apps to take profit of the hardware, without us needing to worry about the patent. And i seriously doubt there is any patent against setting the needed bits in the command registers and moving the compressed data around, i may be wrong though, but that would mean the patent is breaking your fair use rights, or something such. Now, there may be political reasons why we don't want to implement such a thing, but we cannot hide behind the patent problem. Friendly, Sven Luther ------------------------------------------------------- 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
