Patches Published For Merging S3TC Library Into Mesa

It's a slightly more interesting Sunday than usual. Besides working on a large file-system comparison (Linux 2.6.38 w/ EXT3, EXT4, XFS, JFS, Btrfs, etc) and new OpenBenchmarking.org features, there's an interesting development regarding the topic from earlier today about patented OpenGL support within Mesa. Not only has the email thread about integrating floating point textures support been resurrected, but another developer has now pushed patches that would integrate the S3TC texture compression library in Mesa while living behind the --enable-patented switch.

Lucas Stach restarted the OpenGL floating point / render buffers branch merging discussion this morning after the only developer to respond to his original message earlier in the week was Intel's Eric Anholt. Eric was in support of this capability being merged, but no one else commented.

After the e-mail from Lucas this morning, Matt Turner responded also being in support of this move. Matt also notes that the FreeType project did a similar move for pushing similar patented/legally-protected code into their mainline tree and it too was hidden behind a build switch.

Jose Fonseca of VMware, the company that employs most of the core Mesa developers following their acquisition of Tungsten Graphics a few years back, decided to comment. But all his comment's been so far is asking what floating point branch is in question, since one of the branches hasn't been updated in a while.

Marek Olšák, the developer behind this OpenGL floating point work for Mesa, then responded and commented on the floating2 branch. This is the branch that's in question for merging and is derived from Luca Barbieri's branch. It has complete floating-point texture and render-buffer support. This support is available within classic Mesa and Gallium3D. With Marek being one of the popular ATI Radeon Gallium3D driver developers, this support has been tested under the ATI R300g driver in particular for ARB_texture_float and ARB_color_buffer_float support. "I constantly keep it in sync with master (recently I have been rebasing it instead of doing git merges). The Luca's commits are squashed to have one commit per feature/component and to allow for easier review. Each commit has its own history for reference."

As of publishing, no one else has commented on the floating point / render buffers work yet. Let's see what next week brings when more developers are back to work and what they say about integrating this legally murky code into Mesa.

What's new this afternoon though is that Jon Severinsson, a developer whose name isn't too common to the Mesa community, has posted four patches to the mailing list for "import the txc_dxtn code from libtxc_dxtn into mesa." Jon's message says:

As you are about to introduce --enable-patented for floating point textures, I thought the same functionality should be used for s3tc support.

This patch series does so by importing the code from libtxc_dxtn into mesa and build it instead of the dlopened library.

For it do make any sence you need at least the configure.ac changes from Lucas Stach's patch "put patented features under configure enable switch" [1].

This is a direct pull of Marek's libtxc_dxtn branch, which recently hit version 1.0 and this external S3TC library now works with the ATI R600 Gallium3D driver.

It will be interesting if this S3TC texture compression code makes it into Mesa alongside the floating point / render buffers code (personal note: hopefully there will also be separate configure switches for each of these items rather than only providing one large macro --enable-patented switch). This could make for one interesting Mesa 7.11 release, which already has a number of Mesa and Gallium3D driver advancements, an incredible Intel Sandy Bridge performance improvement (thanks to a bug-fix), and -- hopefully -- AMD Cayman Gallium3D support.

Pulling this code into Mesa will not mean you'll find it enabled by default or that any of the major Linux distributions will ship packages with the S3TC/floating-point support enabled as they cannot legally do so in the United States and other countries due to patents that aren't expiring for a number of years and as of right now there doesn't appear to be any viable solution or workaround.

What pulling this code into Mesa does mean is that it will be easier for developers to maintain, there is no longer a need to re-base the support against the current Mesa Git, no compatibility problems with S3TC as an external and dynamically loaded library, etc. It's also easier and simpler for the interested end-users to try out this legally-iffy code. Some third-party package repositories may also end up creating binaries out of it.

These though aren't the only two features of OpenGL that are crippled with patents and other legal protections, so hopefully the Linux Foundation will work something out or another major Linux vendor will decide to contribute to the legal effort. If not, this open-source project that's critical to the free software Linux desktop will continue to lag behind the OpenGL specification and result in more desktop users being dependent upon the binary AMD and NVIDIA drivers just not for much faster performance, but simply for supporting the full OpenGL specification. Mesa is still in a OpenGL 2.1 world, not OpenGL 4.1 (the latest standard right now, but will be outdone by OpenGL 4.2 in a matter of months) or even OpenGL 3.x.

Let's see what next week holds and whether either code-base is pulled or once again rejected from mainline inclusion. It's not the first time that integrating such features have been talked about.