On 4.8.2011 12:19, Rudolf Polzer wrote:
On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote:
On 08/03/2011 12:11 PM, Bryan Cain wrote:
Pardon my ignorance, but why do hardware drivers need a decompressor?
To quote the EXT_texture_compression_s3tc spec:
WARNING: Vendors able to support S3TC texture compression in Direct3D
drivers do not necessarily have the right to use the same
functionality in
OpenGL.
This is the same issue that Linux distros have with ARB_texture_float
being enabled in hardware drivers. The hardware may implement the
functionality, and the hardware vendor may have some license for the
patent, but that license may not cover making the functionality
available in Mesa. That S3 has sued Apple is some indication that these
licenses may have very narrow scope.
Ian,
I think it is really not the same issue. The S3TC patent is about the
algorithm itself,
not about copying blocks of memory. The quote from
EXT_texture_compression_s3tc
only underlines the fact that Direct3D stack (both runtime and driver)
does not have to provide
S3TC compression/decompression algorithm at all, whereas driver
providing EXT_tc_s3tc
typically has to be able to compress the textures in the software (and
thus implement the
patented stuff). Direct3D serves as a pass-through to the hardware, they
don't have to mess
with the patent at all while the hw vendor typically has the
decompression part covered.
Feeding precompressed data, however, is also none of Mesa's business - and
also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is
taking. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds
a data block as is. So, if anyone needs IP rights then, it's the author of the
game that comes with precompressed S3TC textures - and not the graphics driver!
I had the similar argument several weeks ago. I have suggested that Mesa
could use similar
approach I have seen several years ago with GL drivers on windows - ie.
drivers reporting
DXTn formats in the available compressed format list through the
ARB_texture_compression,
whereas _not_ listing EXT_tc_s3tc in the extension string, effectively
doing the same thing as the
Direct3D, allowing a passthrough of such data. I can only guess that the
vendor didn't have had the
compression part covered nor wanted to pay for that part at the given
time. It worked well.
Regards,
Petr
--
Petr Sebor / SCS Software [ http://www.scssoft.com ]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
