LLVMpipe is an especially interesting Gallium3D driver since it allows accelerating the state trackers atop any modern CPU, but for any close to decent level of performance when using OpenGL you need a hefty multi-core CPU (here's some LLVMpipe benchmarks just from last week) that supports the latest SSE4 instructions as well. While some OpenGL games will run with LLVMpipe and the performance of this driver that leverages the Low-Level Virtual Machine is much faster and better than Mesa's old software rasterizer or the Gallium3D Softpipe driver, Compiz nor the GNOME Shell (and most other compositing window managers) yet work with this driver.
As we reported last month, Intel's Open-Source Technology Center developers responsible for working on their open-source Linux graphics stack has been wanting to merge their GLSL2 shader compiler into the mainline Mesa code-base by the end of August so that it can be released as part of Mesa 7.9 by the end of this quarter. Over the night this milestone was hit and the GLSL2 compiler is now in Mesa master and has replaced the antiquated GL Shading Language compiler long used by Mesa.
There's good news for those interested in the open-source Gallium3D driver for the ATI R600/R700 (Radeon HD 2000/3000/4000 series) graphics cards: the R600g driver is beginning to work. While there's been the classic Mesa R600/R700 driver for months now that is working fine for most users, once finished the Gallium3D version should offer better performance, better OpenGL support (OpenGL 2.1 support off the bat, but that's still a ways behind OpenGL 4.1), and many other possibilities via Gallium3D's different state trackers.
If you read the previous R600g news post from less than an hour ago this should come as no surprise, but: the ATI R600g Gallium3D driver has finally reached the milestone of being able to properly run glxgears. This GLX demo is simple and useless as a benchmark, but is an important development milestone and as talked about in that previous news piece, Jerome hopes to tackle texture support within a few days so then we will see more interesting OpenGL capabilities and we are potentially just days away from being able to run Quake with R600g and a modern ATI graphics processor (you can already do so with an open-source driver stack using the classic Mesa R600/700 driver).
Yesterday we reported on Intel preparing to push its new GLSL compiler into Mesa by the end of next month so that it can be released with Mesa 7.9 by the end of this quarter. While Intel has developed this new compiler for the OpenGL Shading Language for their own needs and hardware, other Mesa drivers -- including those for Gallium3D -- will be using it once merged. After any initial bugs are addressed in the other drivers from this new GLSL compiler banging them in different ways, what good will this new shader compiler be for the end-user?
Originally set as a goal for the summer of 2009, it was not until late August of last year that the OpenCL state tracker for Mesa's Gallium3D driver architecture was finally published. However, the code was incomplete and a very early work-in-progress. Nearly a year later, this "Clover" branch of Mesa that contains the OpenCL over Mesa support is still largely incomplete and useless to end-users. Fortunately, however, a new developer has stepped up to the plate and is in the process of submitting patches.
Mesa 7.9 is shaping up to be one hell of a release. Mesa 7.9 is already set to carry many ATI Gallium3D driver improvements along with enhancements to the LLVMpipe driver that uses the CPU for rendering, the early R600g driver, various Gallium3D architectural and state tracker improvements (MSAA, Stream Out, etc), more OpenGL 3.x functionality, and tons of other changes. But there's still more coming! Intel's Ian Romanick has announced on the Mesa development list that they would like to merge their new GLSL compiler into Mesa in August.
If the impressive rate of Gallium3D improvements was not enough, there's more good news for those of you running ATI Radeon R300-R500 graphics cards (up through the Radeon X1000 series) with the open-source Gallium3D driver: the Wine graphics support just got a tiny bit better. Committed to the Mesa repository this afternoon is support for the GL_ARB_depth_clamp OpenGL extension within the Mesa state tracker and as of right now it's hooked-up for use by the R300g driver.
The OpenGL 3.0 specification was announced in August of 2007 and has already been succeeded by OpenGL 3.1, OpenGL 3.2, and then earlier this year came OpenGL 3.3 and OpenGL 4.0. While the 3.0 revision to this industry standard graphics API has been around for nearly three years, it's still not fully supported by the open-source Mesa graphics stack. Progress though is being made.
Besides a VDPAU state tracker for Gallium3D having emerged in the past couple of days, a new Gallium3D driver called "Galahad" has been committed to the Mesa mainline repository and has been worked on over the past week.
Committed to a branch of the Mesa repository over the weekend is an initial Gallium3D state tracker for providing VDPAU support. Yes, VDPAU as in NVIDIA's Video Decode and Presentation API for Unix that has become quite popular with Linux users and is supported by many media applications.
The very latest work going on within Mesa's core, the DRI drivers, and the Gallium3D stack for the past several months are what will eventually form Mesa 7.9 once released in the coming months. However, for those living atop Mesa's stable code-base and not this experimental code, the second point release of Mesa 7.8 has arrived.
Intel's Eric Anholt has been working on writing a GLSL2 compiler for their open-source Mesa graphics stack. Mesa's GL Shading Language compiler has been limited to version 1.4 support, but that is changing. In response to the recent ATI R300 GLSL discussion, Eric has provided an update on the Intel efforts.
As we talked about back in April, there are five summer X/Mesa projects as part of Google's Summer of Code. One of these projects is to improve the GLSL (GL Shading Language) compiler for the ATI R300 class graphics processors and while the summer has just begun, there is already some work emerging.
On the same-day as publishing new Gallium3D benchmarks of the ATI R300g driver, we have more Gallium3D news to share. Zack Rusin has just announced a new Gallium3D branch that provides support for "Stream Out" with this advanced graphics driver architecture.
A $600 bounty came around a while back within the AROS (AROS Research Operating System) community to port Gallium3D and the Nouveau driver to this operating system that is a free software implementation of the AmigaOS 3.1 APIs. This bounty was successful in getting an OpenGL subsystem running on this free AmigaOS alternative via Mesa and Gallium3D and now a 2D architecture is also being implemented atop Gallium3D -- it sounds familiar to how the X.Org developers are implementing the Xorg state tracker to accelerate EXA and X-Video.
VMware's Roland Scheidegger has announced he soon will be merging gallium-msaa to Mesa master soon, which will put this branch into the mainline Mesa code-base in time for the Mesa 7.9 release in the coming months.
Last week we published our first benchmarks of LLVMpipe, which is a new driver for Gallium3D that's to serve as a software rasterizer on the CPU. LLVMpipe is ideal for cases where a GPU is not available or supported and it leverages LLVM (the Low-Level Virtual Machine) for optimization and providing much better software acceleration than Mesa's traditional software rasterizer or Gallium3D's previous Softpipe driver. LLVMpipe really likes modern, fast processors with SSE3/SSE4 support especially for best performance, but will work with nearly any 64-bit Intel/AMD processor. Unfortunately, LLVMpipe doesn't yet play well with GNOME Shell.
Red Hat's David Airlie has started a new mailing list discussion that's surrounding the "stupid development model" of Mesa. Their accepted policy of developing in stable branches and then pulling the code into the master code-base periodically (rather than just working directly on master) is causing many frustrations for Dave in being able to back-port fixes to existing stable branches of Mesa.
A month ago we talked about Gallium3D's LLVMpipe performing well and providing a much better software rasterizer than what is available with classic Mesa. Using LLVMpipe and a modest CPU for acceleration, the OpenArena was just about playable without any GPU assistance. Now a month later LLVMpipe is becoming a even more serious performer. LLVMpipe now is able to tap into the new geometry processing pipeline and it's causing some major performance gains.
While OpenGL 3.0 was announced in August of 2007, nearly three years later its coverage in the open-source Mesa stack is lacking even while the 3.1/3.2/3.3 revisions have been introduced and OpenGL 4.0 was already introduced this year. Slowly but surely though, the open-source developers are making progress in implementing OpenGL 3.x support for Mesa.
In May of last year there were Gallium3D state trackers published for OpenGL ES 1.1 and OpenGL ES 2.0. These were among the first major working state trackers for this new graphics architecture, but in the months since they have continued to receive much affection from a few developers and continue to improve. The OpenGL ES 1.1/2.0 support though may now be reworked by Kristian Høgsberg.
Mesa 7.8 was released last week (and then yesterday an emergency 7.8.1 release arrived) in its traditional bundled form with the DRI drivers, but this afternoon a version with the popular hardware drivers modularized and built around an SDK, has been published.
Mesa 7.8 was only released one week ago, but an "emergency" release of Mesa 7.8.1 will be arriving in just a few hours.
Besides the Mesa 7.8 release announcement hitting the Mesa mailing list over the weekend, also catching our interest is a new discussion concerning S3TC texture compression in this open-source software stack. One of the developers working on Spring RTS, an open-source real-time strategy game engine for Linux and Windows, is wanting the open-source Mesa developers to implement S3TC texture compression/decompression. But this is a rather sticky situation.
Ian Romanick has just released the 7.7.1 and 7.8.0 versions of the Mesa3D open-source OpenGL stack with the DRI/Gallium3D drivers. As planned, this release is coming right on time for the end of March with Intel preparing to make its quarterly Linux graphics driver update and there is also the release of X Server 1.8 coming in the near future.
Coming just one week after the first release candidate, the second release candidate for Mesa 7.8 is now available. This is in hopes of meeting the release schedule and pushing out the final release on Friday.
OpenGL 3.0 was announced in the summer of 2007 and since then we have seen the subsequent releases of the 3.1, 3.2, and 3.3 specifications. Just last week there was even the release of OpenGL 4.0. The proprietary Linux graphics drivers have picked up support for these latest industry standard specifications, but it hasn't been smooth sailing in the open-source world.
Three days ago we reported on Luc Verhaegen and his expedition of modularizing Mesa and its DRI drivers following his talk last month at FOSDEM concerning the ways of cleaning up the Linux graphics driver stack. While we were early to report on Luc's work, yesterday he announced his modularized DRI drivers and Mesa SDK on the Mesa3D development list, but his work has fallen on deaf ears.
Mesa 7.8 was branched earlier this month in preparation for a release later this month, and today the first planned release candidate of this major update to this critical piece of the open-source Linux 3D stack has arrived.
765 Mesa news articles published on Phoronix.