There are some games that require the S3TC extension but use it only for decompressing texture. Full S3TC requires libtxc_dxtn, but decompression only S3TC is supported also without it. When using games using only S3TC decompression, but when not using libtxc_dxtn, one can force S3TC with driconf, however: a) that won't work for all games; b) it's not very practical to do (think at millions of users that should enable it this way); It would be nice if a Mesa specific extension would be added to declare availability of S3TC for decompression only. The game that uses decompression only S3TC could then check for both S3TC and Mesa specific extension, and, if at least one of the two is supported, enable S3TC decompression. See also this ticket [0] on 0 A.D. game [1] support site: "maybe we could detect the situation where we're running on Linux and the driver really does support decompression even though it doesn't claim to fully support S3TC, since the game should actually run fine with S3TC in that case and we don't need to tell the user to do anything." According to [2]: "Without S3TC support, the game will uncompress all of its textures before using them, which causes it to use between 4 and 8 times as much memory (and video memory) and will probably slow it down a lot. " [0]: http://trac.wildfiregames.com/ticket/313 [1]: http://os.wildfiregames.com/ [2]: http://trac.wildfiregames.com/ticket/306#comment:4
There already is such an extension. See: http://www.opengl.org/registry/specs/EXT/texture_compression_dxt1.txt However, supporting this outright still does not resolve the potential legal problem. Furthermore, we still have to be able to support potential software fallbacks. We can't do that without a way to handle compressed textures in software. Without a license for S3TC, we're not going to add any further support for S3TC textures. Sorry.
(In reply to comment #1) > There already is such an extension. See: > > http://www.opengl.org/registry/specs/EXT/texture_compression_dxt1.txt > > However, supporting this outright still does not resolve the potential legal > problem. Furthermore, we still have to be able to support potential software > fallbacks. We can't do that without a way to handle compressed textures in > software. Without a license for S3TC, we're not going to add any further > support for S3TC textures. > for fallbacks, it can work as follows: render the texture to a buffer on the GPU (which decompresses it on the way) and then work from the buffer. That doesn't infringe the S3TC license.
Maybe I am missing something here, but since decompression is already supported (indeed the games work fine when forcing it with driconf) is there a way to make it aware to games, other than forcing S3TC with driconf or try to guess it as the 0 A.D. game would do (e.g. checking if the game is running on Linux and whitelisting some combinations of drivers type and version)?
(In reply to comment #2) > GPU (which decompresses it on the way) and then work from the buffer. That > doesn't infringe the S3TC license. Unless you're a lawyer and have seen any of the S3TC license agreements, I'm pretty sure you're in no position to make such statements. From the discussions that I have had with people in these positions about their license agreements, it seems that they are very, very narrow: they seem to cover one implementation of one API on one operating system. Logic does not apply to legal matters. Ever.
(In reply to comment #4) > (In reply to comment #2) > > > GPU (which decompresses it on the way) and then work from the buffer. That > > doesn't infringe the S3TC license. > > Unless you're a lawyer and have seen any of the S3TC license agreements, I'm > pretty sure you're in no position to make such statements. From the > discussions that I have had with people in these positions about their license > agreements, it seems that they are very, very narrow: they seem to cover one > implementation of one API on one operating system. Logic does not apply to > legal matters. Ever. > Well, as far as I know, you're not a lawyer either but still spreading their FUD. Anyway, we're wasting time while the solution is pretty simple: we should just ignore patents (in particular, they don't apply in my country, so I can't feel sad). If the powers that be don't want it in mesa git, maybe someone should just fork mesa, add the patended bits and let distros pick their choice.
(In reply to comment #5) > Anyway, we're wasting time while the solution is pretty simple: we should just > ignore patents (in particular, they don't apply in my country, so I can't feel > sad). You and me both. > If the powers that be don't want it in mesa git, maybe someone should > just fork mesa, add the patended bits and let distros pick their choice. While we're trying to actually fix this issue with the help of OIN, the plan that came out of XDC is to take the freetype approach: have configure-time options to enable certain bits of code. These options would be, by default, disabled. I believe S3TC should stay in an external library. It works that way, and is easier for users: just drop the library into your system and be happy.
The solution should make life easier for the end user. It's a lot easier to install an extra gstreamer codec compared to "apt-get source totem" and rebuilding totem with some special switch. Packing S3TC into it's own package might make it easier for end users to make use of it (this way we could also not install that package by default in the US but install it by default in France etc). For French users stuff should just work out of the box; i.e. only Americans should suffer from the obscure laws that they Americans adopted for themselves etc.
That solution might work for linux users....but anyone have a solution for windows users? Believe it or not, but I'm using this project for windows in a VM environment for some autoplay testing. S3TC would be very valuable for that effort. I just need a DLL and a patch for mesa to use the dll correctly. On Fri, Oct 2, 2009 at 11:15 PM, <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=24207 > > > > > > --- Comment #6 from Ian Romanick <idr@freedesktop.org> 2009-10-02 23:15:12 PST --- > (In reply to comment #5) > >> Anyway, we're wasting time while the solution is pretty simple: we should just >> ignore patents (in particular, they don't apply in my country, so I can't feel >> sad). > > You and me both. > >> If the powers that be don't want it in mesa git, maybe someone should >> just fork mesa, add the patended bits and let distros pick their choice. > > While we're trying to actually fix this issue with the help of OIN, the plan > that came out of XDC is to take the freetype approach: have configure-time > options to enable certain bits of code. These options would be, by default, > disabled. I believe S3TC should stay in an external library. It works that > way, and is easier for users: just drop the library into your system and be > happy. > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev >
about the "the potential legal problem" pointed by Ian Romanick, has anyone noticed that Firefox 15 will support the WEBGL_compressed_texture_s3tc extension [1] ? Does anyone know what is Mozilla's position regarding this situation ? [1] https://developer.mozilla.org/en-US/docs/Firefox_15_for_developers
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.