[Mesa-dev] Naked DXTn support via ARB_texture_compression?

[Petr Sebor]

On 18.3.2011 16:50, Henri Verbeet wrote:
> On 18 March 2011 14:19, Petr Sebor<petr at scssoft.com>  wrote:
>> I know that at least our games would benefit from this feature immediately,
>> but I guess Wine people might welcome this as well, where 'benefit' means -
>> do not have to
>> painfully install the external DXT library, which is very likely not needed
>> at all.
>>
> As far as Wine is concerned, not without a proper extension. At this
> stage having the external library or driconf option is good enough for
> Wine. In the end this is a legal problem rather than a technical
> problem though.

Henri,
*
*with all respect, I encourage you to lookup the S3TC patent US 5956431 
once more to see
what is actually claimed. The patent relates to image processing systems 
that actually actively
perform image compression or decompression. This is actually the reason 
why the Mesa uses
external processing library to be free of this legally covered stuff.

Of course, without the help of such external library, Mesa cannot claim 
to support
GL_EXT_texture_compression_s3tc, because if it does, it has to implement 
the patented
algorithm.

The situation is different in this case. I am just saying - please, 
relax the enforcement of the existence
of the external image processing library in the Mesa in the cases when 
hardware natively supports
DXTn formats and the Mesa client provides DXTn precompressed data, 
merely allowing
a binary passthrough via well documented and available interface defined 
in the
abstract ARB_texture_compression extension, allowing exactly for such 
cases where the
OpenGL implementation doesn't claim the availability of given compressed 
format processing,
but allowing the data to be just passed through.

In this situation, the DXTn (S3TC) related agorithms were all 
implemented and used outside of the
Mesa body and as far as I can see, nothing of the patent applies here.

In the past days, applications (games) relied on the existence of the 
GL_S3_s3tc
or GL_EXT_texture_compression_s3tc extensions, because they expected the 
implementation
to optionally compress the data for them to save video memory and bandwidth,
without precompressing the data themselves.

Nowadays the situation is quite different, whereas almost any modern 
game relies on the
existence of the hardware s3tc and provides preauthored data in the form 
it wants
the implementation to use it, without actually requesting on-the-fly 
image compression.
But just because we are all 'used to' simply check for the existence
of the GL_EXT_texture_compression_s3tc doesn't mean we really want to 
use it at all.
Many of the current applications do not. Limited ARB_texture_compression 
is sufficient enough
for all our needs.

Regards,
Petr

--
Petr Sebor / SCS Software [ http://www.scssoft.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110319/ab8a8fdb/attachment.html>