Re: [Dri-devel] S3TC (again)
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
Re: [Dri-devel] S3TC (again)
Sven Luther wrote: Is there not a way to work around this ? If the hardware doesn't support s3tc, then the driver simply don't advertize the that it can handle s3tc textures, so you would get out of the need to decompress the textures in the driver. On the other hand, if it is not possible to tell the app that you don't know how to compress textures, and are asked for it, then you just send the texture uncompressed or something such. Ideally, there would be a way to tell the apps that you can receive and use s3tc compressed textures, but not uncompress them yourself. 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. Being that I'm not a lawyer, I'm not sure that the other work arounds would be legal either. Given the ambiguities and risk of it all, until we get explicit permission, I don't think any of the distros are likely to distribute ANYTHING with ANY S3TC support enabled. --- 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
Re: [Dri-devel] S3TC (again)
On Mon, Feb 24, 2003 at 09:48:42AM -0800, Ian Romanick wrote: Sven Luther wrote: Is there not a way to work around this ? If the hardware doesn't support s3tc, then the driver simply don't advertize the that it can handle s3tc textures, so you would get out of the need to decompress the textures in the driver. On the other hand, if it is not possible to tell the app that you don't know how to compress textures, and are asked for it, then you just send the texture uncompressed or something such. Ideally, there would be a way to tell the apps that you can receive and use s3tc compressed textures, but not uncompress them yourself. 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. BTW, what is the use of doing s3tc compression if the graphic card cannot handle it ? to save memory usage or something such ? Being that I'm not a lawyer, I'm not sure that the other work arounds would be legal either. Given the ambiguities and risk of it all, until we get explicit permission, I don't think any of the distros are likely to distribute ANYTHING with ANY S3TC support enabled. Sure, but i think there would be no problem in a simple sending to the graphic card extension. and any claim that this may cause problems with patents is just plain FUD. 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
Re: [Dri-devel] S3TC (again)
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? 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
Re: [Dri-devel] S3TC (again)
Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again)
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote: Now, if an OpenGL application has a pile of textures already compressed with the S3TC algorithm, then I don't understand why the dri drivers can't simply offer the S3TC interfaces to the hardware, pass the compressed textures to the hardware and let the hardware get on with its licensed decompression of the textures as required. Likewise, if the OpenGL application passes compressed textures to the S3TC API then how it gets hold of the compressed textures in the first place is it's own responsibility -- the OpenGL API just passes them on. Look at the ARB_texture_compression and EXT_texture_compression_s3tc specs again. You can specify uncompressed textures and have the driver compress the AND you can specify compressed textures and have the driver decompress them (to read them back into the application). For example, Quake3 can use the S3's vendor-specific extension (can't remember the name of it right now), but it does NOT have ANY textures pre-compressed. It expects the driver to do the work. Is there not a way to work around this ? If the hardware doesn't support s3tc, then the driver simply don't advertize the that it can handle s3tc textures, so you would get out of the need to decompress the textures in the driver. On the other hand, if it is not possible to tell the app that you don't know how to compress textures, and are asked for it, then you just send the texture uncompressed or something such. Ideally, there would be a way to tell the apps that you can receive and use s3tc compressed textures, but not uncompress them yourself. Friendly, Sven Luther --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again) - FAQ
OK, I don't exactly want to stir up this hornets nest *again*, but a couple of things aren't entirely clear to me and I'd appreciate any clarifications. As I understand it, the situation is as follows: The S3TC algorithm is patented and therefore no-one can distribute an implementation of the algorithm without a licence from the patent holders. S3TC decompression must be implemented in the hardware (otherwise what's the point), therefore hardware which uses S3TC can be assumed to have a valid licence to use the code, otherwise the patent owners would be down on the hardware manufacturers like the proverbial ton of bricks. Patent law is actually more complicated than that. I'm not in a position to go into it, but it gets complicated when you have multiple components (i.e., software and hardware) working together to implement something. As far as I'm aware, the main users of S3TC are modern games with their vast arrays of textures -- presumably such games come with the textures precompressed, or are able to compress them and cache the compressed textures themselves. Presumably again, the authors of the games have paid for a licence to use the S3TC algorithm from the patent holders. Now, if an OpenGL application has a pile of textures already compressed with the S3TC algorithm, then I don't understand why the dri drivers can't simply offer the S3TC interfaces to the hardware, pass the compressed textures to the hardware and let the hardware get on with its licensed decompression of the textures as required. Likewise, if the OpenGL application passes compressed textures to the S3TC API then how it gets hold of the compressed textures in the first place is it's own responsibility -- the OpenGL API just passes them on. Look at the ARB_texture_compression and EXT_texture_compression_s3tc specs again. You can specify uncompressed textures and have the driver compress the AND you can specify compressed textures and have the driver decompress them (to read them back into the application). For example, Quake3 can use the S3's vendor-specific extension (can't remember the name of it right now), but it does NOT have ANY textures pre-compressed. It expects the driver to do the work. Can we add this to the FAQ, please? Instructions at teh bottom of: http://dri.sourceforge.net/help.phtml Alternatively if you know how it works go straight there: http://dri.sourceforge.net/faq/faq_add.phtml No one appears to be abusing it so I'm happy to let it be open. Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again)
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote: Look at the ARB_texture_compression and EXT_texture_compression_s3tc specs again. You can specify uncompressed textures and have the driver compress the AND you can specify compressed textures and have the driver decompress them (to read them back into the application). For example, Quake3 can use the S3's vendor-specific extension (can't remember the name of it right now), but it does NOT have ANY textures pre-compressed. It expects the driver to do the work. If the hardware can't do S3TC, then the driver can simply not advertise the availability of the extension, and if the application expects the driver to compress the textures, then the driver can either refuse or just pass the textures on uncompressed. Clearly the driver can't implement the full API, but is there a legal barrier to implementing the part that says here, take these pre- compressed textures and give them to the hardware ? Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
