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.
While Mesa 7.10 was just released, there's already been some work beginning to land in the mainline Mesa code-base for the ATI Radeon Gallium3D drivers to improve the performance.
Mesa 7.10 has been released!
While we anticipated Mesa 7.10 being a late Q4'2010 or very early Q1'2011 release, today that's now been formalized with Intel's Ian Romanick once again stepping up to the plate to manage this next Mesa 3D release. Ian's proposal calls for Mesa 7.10 to be branched on 8 December and then for the final release to be out around or on the 7th of January. In traditional Mesa fashion, a Mesa 7.9.1 bug-fix release will also come around that time.
Chia-I Wu, the developer who previously worked on the EGL state tracker, brought Mesa to Android netbooks, and allowed Nouveau to work on Wayland (and now is doing work for LunarG), has some improvements to the Vega state tracker. Namely he has cleaned up this Gallium3D state tracker for Mesa and additionally has a branch containing OpenVG 1.1 support.
Some two years ago there was a branch of Mesa created by Zack Rusin named "Clover" with intentions of providing OpenCL over Mesa. While it looked hopeful at first, this code to support OpenCL over Mesa was never finished and after a while it didn't receive any further work. It's been months since there's been much activity in this area of GPGPU support for Mesa/Gallium3D, but recently Zack has renewed his interest in getting Mesa Clover working.
A month ago there was the surprising work done by Christian König to bring XvMC and VDPAU support to the open-source ATI Radeon "R600g" Gallium3D driver for the Radeon HD 2000/3000/4000/5000 series graphics cards. The XvMC state tracker with Gallium3D began working shortly thereafter for accelerating XvMC using shaders with this ATI Gallium3D driver, however, iDCT support was not implemented. Christian though has now added support for inverse discrete cosine transforms to this X-Video Motion Compensation code for Gallium3D.
While the Mesa software stack has made some steps towards supporting OpenGL 3.x, this free software library used by open-source graphics drivers is still a ways from supporting this industry graphics API thats years old and has already been surpassed by OpenGL 4.x. There hasn't been too much major progress lately on GL3 support, but some think it could be achieved next year. When there is OpenGL 3.0 support in Mesa, it will be released as Mesa 8.0. Regardless, the OpenGL 3 status document for Mesa has been updated.
Lately there's been a lot of talk about Gallium3D's IR known as TGSI, or Tokenized Gallium Shader Instructions, and attempts by some to replace this intermediate representation. Efforts toward improving TGSI are not particularly new, but it's been going on for a while and then just earlier this month a new shader and compiler stack was proposed by LunarG. As part of the LunarGLASS proposal, the LLVM IR would be used as a replacement to TGSI.
981 Mesa news articles published on Phoronix.