In a comment I was recently asked where Gallium3D does fit in in regards to Mesa and OpenGL. Given that I’m not an expert the answer was short and simple but might interest others as well.
There is quite some information flowing around regarding Gallium3D. Tungsten Graphics has for example a project wiki page and there are of course talks and presentations available.
However I was recently asked by Max what Gallium3D is and tried to fit it into a short and handy answer:
Currently Mesa3D implements the specifications of the OpenGL API on Linux. Mesa3D has backends for each hardware driver type, so implementing parts of the API again and again for each driver.
Gallium3D will now hop in by being the only backend Mesa3D needs to focus on. At the same time Gallium3D will also provide a single API to the driver developers: they only need to produce one driver, no matter if DirectX, OpenGL or OpenVG is used (yes, Gallium3D could even help on Windows). This makes developing drivers for new device classes (OpenVZ is interesting for example for mobile phones) much easier.
So developing driver as well as implementing graphic specifications will become much easier with Gallium3D. That necessarily means that Gallium3D isn’t an easy piece of software. However, quite some time and effort is saved by not duplicating stuff in Mesa3D for each driver and by also not duplicating again stuff in the drivers for different graphic API’s.
Currently Gallium3D is not production ready yet. Early 2008 the state was that the first real world driver, an older Intel one, was working quite well. It might take a while until Gallium3D really enters the stage.
A last note: the information given above only tries to give a simpe overview. In fact it is so simple it doesn’t really cover what Gallium3D is (the tracker, the pipe drivers, winsys, the modules) and is probably even not entirely correct. Still, it gives interested people a first glance from they can start off searching for information.
/home/liquidat 
… So this essentially means the KDE project (well, as far as Z.Rusin is part of it anyway) /is/ actually working on fixing the darn nVidia drivers? 😉 The sheer awesomeness blows the mind!
@S Kind of. The nouveau nvidia driver has focused on providing a pipe driver for gallium3d, but our darling Zack isn’t directly involved. It’s also a very incomplete and driver right now.
Zack also had a talk about it on akademy, which is more recent than the one you linked. Slides and sample application is available on http://akademy.kde.org/conference/presentation/9.php
Did you perhaps mean OpenVG instead of OpenVZ? In any case, Gallium3D is great news for graphics driver writers.
Isnt a new abstraction layer bad for performance?
Thanks for elaborating. 🙂
Gunni Says:
Isnt a new abstraction layer bad for performance?
Not necessarily. Gallium3D will use LLVM for run-time optimizing, so it should perform better than the actual model.
Sami, of course, thx for pointing out.
Max, you’re welcome!
“Isnt a new abstraction layer bad for performance?”
As far as I understand it Gallium3D is written to work in a similar way to the real hardware used in modern graphics cards. This, combined with LLVM optimisation, means that the path from Gallium3D to the hardware should be rather fast.
Since a lot of code duplication will then be unnecessary I would expect the path from XYZ-graphics-library (for example OpenGL) to Gallium3D to become more efficient than the present models, since the efforts of intel, nvidia, nouveau, radeonhd, ati, etc. hackers could all build upon each other to make a single good implementation, rather than being spread between several drivers (many of which are struggling to get much even working, never mind efficiently).
Combining Gallium3D with DRI2 and the work at getting memory management, mode setting and things into the kernel in a generic way, the work needed from drivers is being dramatically reduced. This should mean cards with limited support, like the ATI in my laptop, will gain complete drivers sooner, and cards which already work should benefit from developers having more time for optimisation.
As a final thought, Nvidia are usually regarded as the wizards of Linux graphics drivers but their magic is locked up within their proprietary driver. With the introduction of these common APIs it seems likely that some of that magic will not only move from the Nvidia driver to a Free Software layer, but that it will do so in a way which benefits everyone (assuming, that is, that Nvidia start using these things when they are in place).
So, would this ease the efforts of wine / cedega in creating a *nix port of direct X?
Great project, nice 3d
Nathan:
Here’s a quote from Zack Rusin:
“1) DirectX is a complete stack that is a lot more than 3D graphics. One could certainly use Gallium3D for Direct3D part of it. Either as a Windows specific driver, or within Wine. DirectX depends and assumes windows specific api’s so only these two combinations for Direct3D would work. At Tungsten we are using Gallium3D for Windows Direct3D work. I’m not aware of any efforts to bring Direct3D to GNU/Linux on top of Gallium3D though.”
Source: http://zrusin.blogspot.com/2008/02/gpgpu.html
Thx all for the explanation, although i am not 100% convinced of the performance not dropping.
But i am no expert so i have to trust you 🙂
thanks Max, that certainly answered my question 🙂