The open-source Mesa / Gallium3D Linux drivers not only take heat for their slow performance (in many cases, dreadfully slow) compared to the proprietary drivers, their bugs causing issues like those with KWin, and their inability to run many games/applications, but also for their very belated support in enabling support for new OpenGL extensions and versions of the GL Shading Language.
Tom Stellard, the student developer who participated in last year's Google Summer of Code to improve the R300 GLSL compiler for the open-source ATI/AMD driver, is still around and contributing to upstream Mesa. Last month he announced his new R300 register allocator being ready for wider testing. He's now announced further improvements on this GPU register allocator for Mesa.
Over the weekend there was a rant by Martin Gräßlin, the lead developer of the KWin compositing window manager for KDE, about Intel's open-source driver breaking. This is the second time in recent times that the driver has outright failed with KDE, which threatens the Intel KWin support in Ubuntu 11.04, but this time it's over the OpenGL renderer string being changed and KWin using that to determine direct rendering support. Martin has now written a very lengthy e-mail to the developers of Mesa.
Martin Gräßlin, the lead KDE developer of the KWin compositing window manager, usually has fairly insightful and technical blog posts. Last week he was talking about possibly moving the KDE screensaver into the KWin compositor for KDE SC 4.8 after writing the KDE view on GNOME's new compositing manager. Today he has written a new post, but this time it's about the open-source Intel Mesa driver breaking (again) for KWin.
Here's quite a pleasant surprise to wake up to this morning: OpenGL floating-point textures and render-targets support has finally been merged to mainline Mesa master! The drawn-out process that began more than a month ago is finally over.
For those preferring to live on the stable Mesa series, Ian Romanick just announced the release of Mesa 7.10.2. This release just incorporates various bug-fixes.
For those that were excited last week by the French student proposing an H.264 VA-API/VDPAU state tracker for Gallium3D that in turn was revised to WebM or Theora acceleration support instead (since no current-generation GPUs have dedicated video decode engines for these formats), Emeric has firmed up his proposal.
In recent days I have mentioned many interesting Google Summer of Code project that have been proposed for this year: WebM VDPAU state tracker, better multi-GPU support, the OpenCL state tracker, and even a Direct3D HLSL shader compiler. It will be interesting to see which of these projects actually materialize since the success rate of GSoC projects aren't incredibly high, especially if counting the ones that end up succeeding but never end up being maintained after the summer or the code is never merged. Fortunately, one of last year's GSoC Mesa projects is still being hacked on and there's more to report on it today.
It was in early 2009 when we heard that OpenCL and OpenGL 3.1 state trackers would be here hopefully soon for Gallium3D. Well, nearly two years later, neither state tracker has yet to emerge. There's no OpenGL 3.x state tracker in development and core Mesa only has limited support for OpenGL 3.0, while the latest Khronos specification is now at OpenGL 4.1 with OpenGL 4.2 not being far off. There has been work on an OpenCL Gallium3D state tracker for nearly two years, but it's not mainline and is far from working. That may finally change in the coming months.
Earlier this week I mentioned a student developer looking to partake in Google's Summer of Code was interested in creating an H.264 state tracker for Gallium3D whereby any graphics card with a Gallium3D driver could have H.264 video decoding support using VA-API / VDPAU and accelerating the operations in shaders on the GPU, where in theory at least it would be universally supported across all drivers on this architecture. It's still looking hopeful that this will be hacked on this summer, but a few interesting points have been expressed.
Assuming the student developers participating in this year's Google Summer of Code achieve their work (after getting accepted of course), this year could be very interesting for Mesa / Gallium3D / X. While initially there was the very ambitious OpenGL 4.1 plans in a new Gallium3D state tracker that would be free of Mesa legacy code, that was changed to working on GLSL IR or something smaller (perhaps Clover, as in the long-awaited OpenCL state tracker for Gallium3D). There's also been a proposal for multi-GPU and hot-plugging support. Voiced just now by a French student is to create the -- also much-anticipated -- H.264 VA-API / VDPAU state tracker for Gallium3D drivers.
There was a Gallium3D OpenGL 4.1 State Tracker proposed for this year's Google Summer of Code to benefit X.Org / Mesa. As this state tracker was going to be written from scratch and without any dependence on Mesa itself, the consensus among the core developers was that the work was simply too ambitious for a lone student developer to complete over the course of a summer. A new proposal has now been drafted by Denis Steckelmacher, the Belgian student developer interested in open-source OpenGL 4.1 support.
Discussions surrounding S3TC Texture Compression support for mainline Mesa (right now it's an external library) is becoming an increasingly common occurrence. Newer games and OpenGL applications depend upon S3TC support and open-source developers are unable to provide "out of the box" support due to patent concerns.
To no surprise, when mentioning an OpenGL 4.1 state tracker for Gallium3D being proposed as a Google Summer of Code project on Sunday morning, there has been a lot of interest in this work via the Phoronix Forums and several responses from key Mesa developers on the project's mailing list. The consensus among these core developers have been that this project is far too large to be completed over the course of a single summer and that it may not be wise essentially throwing out the Mesa code-base, as proposed by the Belgian student.
It's not often that really interesting mailing list messages come through on the weekend, but this Sunday there is a very interesting message that was posted to the Mesa development list. A Belgian developer has offered to write an OpenGL 4.1 state tracker for Gallium3D this summer. Not only that, but that this state tracker to support the latest OpenGL specification would be free of using Mesa. This would also mean parts of the OpenGL 3.x API, EGL context-creation, LLVMpipe support, OpenVG state tracker support, and possibly even Clover capabilities for OpenCL.
Last week I mentioned that a developer called for a discussion about merging the OpenGL floating point textures and render targets branch into mainline Mesa. This code has been ready for a while but hasn't been merged due to patent concerns, but to alleviate that while pushing the code forward, the proposed idea was to add a --enable-patented build option. Over the weekend, the discussion continued and it was then also proposed to merge the S3TC texture compression work (another feature where developers are concerned about patent infringement) and to conceal that behind the new build option too. So what happened since and did the work make it into the mainline Mesa Git repository?
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.
On Friday it was mentioned the possibility of merging OpenGL floating point and render targets support into mainline Mesa but hiding these patented features behind a disabled-by-default build argument so those not wishing to have this support -- or are not legally permitted to use or redistribute -- could continue using Mesa without these capabilities while everyone else wishing to take advantage of it could rebuild Mesa.
Lucas Stach has brought a proposal to the Mesa mailing list of merging Mesa's floating point textures and render targets code branch into the mainline Mesa repository. Floating point textures have been available in OpenGL for years, but has yet to enter mainline Mesa as it's a patented feature.
While there are already lots of exciting work within Mesa's Git master repository for Mesa 7.11 within core and classic Mesa along with the Gallium3D area, for those users sticking to stable releases, Intel's Ian Romanick has announced the releases of Mesa 7.9.2 and 7.10.1.
For those that use libtxc_dxtn, the external S3TC library to Mesa to provide S3 Texture Compression support, version 1.0.0 is now available.
A student developer has written to the Mesa3D development mailing list about creating a Gallium3D state tracker for the Glide API. Yes, the 3Dfx that hasn't been used in more than a decade.
As something of value to more users than Mesa receiving EXT_texture_compression_RGTC support is that the shared DRI core patch has been merged. This results in a significantly smaller package size for Mesa (circa 30MB savings) and results in Mesa building about 13% faster.
In Mesa's quest to catch up to the proprietary Linux drivers (and the graphics drivers available under Windows), they are now a tiny bit closer. David Airlie has announced on the Mesa mailing list that he has implemented support for the EXT_texture_compression_RGTC extension into Mesa.
Hitting the Mesa tree this weekend were messages of "r600g: use the new vertex buffer manager" and "r300g: use the new vertex buffer manager."
In October of last year there was a proposal by LunarG, a small consulting company focusing upon Gallium3D and Mesa that was formed by some of the original Tungsten Graphics crew, to create a common kernel and shader compiler stack. This stack would utilize LLVM (the Low-Level Virtual Machine) for optimizations This work was published as LunarGLASS and there is now a specification and initial implementation of it for Mesa.
While the Radeon HD 6000 series is AMD's latest generation of graphics processor, and has initial open-source support available as of earlier this month, the open-source Linux GPU driver support isn't yet complete for the older Radeon HD 5000 "Evergreen" series and generations even older than that. One of the features that has been lacking for Evergreen is tiling support within the ATI Gallium3D "R600g" driver for the HD 5000 series while it is available for the R600 ASICs and earlier. Evergreen tiling support though is now being worked on, which should deliver a performance boost once fully implemented for this hardware.
The past few months Chris Wilson has been on quite a coding spree with making many changes and improvements to the xf86-video-intel DDX driver, among other components. Today though he has put out a patch to the X.Org development list that will affect far more individuals than just those using the Intel graphics driver, which is his primary focus being an employee of the Intel Open-Source Technology Center. This GLX patch has boosted the in-game frame-rate for him in one of his tests by about sixty percent!
Going back to at least 2009 there's been interest in having Gallium3D on the Haiku operating system and last year they hoped for a new graphics stack as part of GSoC 2010, but that didn't develop. They wanted Gallium3D and/or the ability to load Linux graphics drivers on this BeOS-compatible operating system. Now though they've put up a cash bounty to get Gallium3D support.
While some Mesa developers spent some time this weekend investigating WebGL issues in open-source drivers as noted by Firefox developers, Brian Paul and others have been tackling support for some new OpenGL extensions.
929 Mesa news articles published on Phoronix.