Mesa 7.11 has been branched in preparation for its release next month. What this means is that now Mesa Git master is for Mesa 7.12, which will be the graphics code in-development until next January when it's either released as 7.12, or Mesa 8.0 should the OpenGL 3.0 support land by year's end.
Benjamin Franzke, a developer who as of the past several months has been hacking on Wayland and working to get it running over OpenWF along with making other improvements, has written a graphics buffer manager (GBM) for Mesa.
One of the Google Summer of Code projects pertaining to Mesa / X.Org is to bring-up open-source OpenCL support with the Gallium3D driver architecture. There's long been a branch of Mesa dubbed "Clover" that provides an OpenCL state tracker for the Gallium3D driver architecture, but it hasn't been usable as there's a lot of work to be finished. This GSoC project attempts to change that and there's already been a big milestone achieved.
Back in April we reported on the ambitious project by a lone, independent developer to write a GLSL IR to TGSI translator for Mesa that wouldn't involve using Mesa's crufty IR. This work would also be a stepping-stone to GLSL 1.30 support in Mesa, which is needed for OpenGL 3.0 support in this critical free software project. Today the developer is reporting that he believes this translator is ready to be merged into Mesa.
Hurra! A new Gallium3D state tracker was just released! But it's not the state tracker for OpenCL support, VDPAU or VA-API encoding/decoding, or anything else like that, but rather it's for something new: the XA State Tracker. This state tracker provides a new means of X.Org Acceleration (hence the "XA" name) and was developed by VMware.
Marek Olšák, the open-source community developer known for his contributions to Mesa / Gallium3D and to the Radeon driver in particular, has submitted a set of patches to the Mesa mailing list. This time around, these patches overhaul the Gallium3D configure/build-time options. These patches are meant to make it easier to configure Gallium3D with the Gallium3D EGL support and in automatically determining what state trackers to build. In addition, there is one prominent change in default behavior.
For those living in a very stable world, Mesa 7.10.3 is now for your building pleasure. Mesa 7.10.3 just incorporates bug-fixes, but none of the new work found in the six-months-in-development Mesa 7.11 code-base.
Finally, Mesa 7.11 is set to be released in early July. Ian Romanick of Intel has laid out plans to do a Mesa 7.10.3 point release in two weeks and then to release the proper Mesa 7.11 release in 7/11 (July of 2011).
Last September there was the release of a Direct3D 10/11 state tracker for Gallium3D. This natively implemented Microsoft's graphics API from DirectX for the latest versions 10 and 11 with Gallium3D Linux graphics drivers. While it sounded quite enticing when the code was first released, there hasn't been much activity since that point.
After releasing open-source Ivy Bridge code last month for the Linux kernel to go in Intel's DRM (Direct Rendering Manager) driver for graphics acceleration and kernel mode-setting, Intel then landed Ivy Bridge support in their X.Org driver although that isn't too interesting with most of the exciting code these days happening in the Linux kernel or Mesa library. Yesterday, however, the final big piece of the Linux support for Ivy Bridge was pushed out there: the Mesa 3D support.
Submitted to the mailing list over the weekend was a patch by Carl-Philip Haensch that implements support for Anisotropic Filtering (AF) in the ATI/AMD R600 Gallium3D driver.
What's been talked about extensively and for quite a while but not acted upon too much is ridding Mesa of Mesa IR, it's intermediate representation used internally by core Mesa and its drivers. It was also talked about as a possible summer project of replacing Mesa IR with GLSL IR. Now though an individual has begun gutting out Mesa IR and providing a direct GL Shading Language IR to TGSI (the Gallium3D IR) translator.
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.
911 Mesa news articles published on Phoronix.