Galium3d, mesa, mesa 3d, state trackers and drivers... help!

[markg85]

Hey,

I've been curious about this for some time now and i still don't fully get it.

Here on phoronix sometimes i see mesa and mesa 3d in combination with galium3d ... and i'm getting confused by it.

What exactly is Galium3d?
How do the state trackers work in Galium3d?
Where does mesa fit in this picture..? isn't galium3d replacing mesa/mesa 3d?
What is meas 3d or is it just mesa..?

Enough confusion as you can see.
Could someone please explain to me in clear understandable language what the new Galium3d is exactly and how state trackers and mesa fir within this?

(a diagram would be nice as well)

Regards,
Mark

[whizse]

Does this clear things up? (The thread right above yours )

http://www.phoronix.com/forums/showthread.php?t=7221

[markg85]

Does this clear things up? (The thread right above yours )
http://www.phoronix.com/forums/showthread.php?t=7221

I actually read it and it doesn't explain what I want I'm looking for. It explains some X11 history and just skims the surface of galium3d but that's about it.

[pingufunkybeat]

Mesa provides an OpenGL API to programs that need OpenGL to run.

Mesa also provides hardware drivers for different chips that implement parts of OpenGL in hardware.

The idea behind Gallium3d is to separate the two. There is a layer which deals with the OpenGL API, and which connects to an abstraction layer, and then there are the hardware-dependent drivers which connect this layer to the hardware.

The main benefit is that you don't have to reimplement everything every time you write a new driver. You only need to implement the hardware-specific part. The parts that are the same for all hardware can then be used by all hardware.

So Gallium3d is not replacing Mesa, it is replacing a part of Mesa -- the 3d drivers. The OpenGL API will still be provided by Mesa, running on top of the Gallium3D infrastructure.

[bridgman]

One more thing - state trackers sit above the Gallium3D drivers and translate a specific API into a series of Gallium3D calls, ie they implement the API. In the case of GL, Mesa (aka mesa3d) would be the state tracker. There are also state trackers in various stages of development for OpenVG, OpenCL, the acceleration portion of an X driver etc...

If you want to see how all this fits together, start at :

http://cgit.freedesktop.org/mesa/mesa/tree/

This is the source tree for the mesa project. The src/mesa folder contains all of mesa itself, including the "classic" HW drivers and the code required to let mesa run over Gallium3D (but it does not contain Gallium3D itself). The src/mesa/drivers/dri folder contains the "classic mesa" HW drivers, while src/gallium contains the Gallium3D framework including Gallium3D drivers.

[marek]

I've put together some info too, so here it is.

Gallium=Gallium3D, Mesa=Mesa3D

The classic Mesa scheme:

Mesa core --> classic OpenGL driver

In Gallium, the classic driver is split into two components:

Mesa core --> [Mesa state tracker/generic OpenGL driver --> Gallium driver]

The Gallium driver has a very nice, generic interface (let's face it, it looks almost like Direct3D 10), making it easier to implement other APIs on top of it. The whole image now looks like this:

Mesa core --> Mesa state tracker/generic OpenGL driver --+
                                                         |
Xorg state tracker/generic DDX driver -------------------+
                                                         +--> Gallium driver
OpenVG state tracker ------------------------------------+
                                                         |
Other state tracker -------------------------------------+

The state tracker is something that talks to the Gallium driver. It can be a direct implemention of some API or an intermediate layer translating commands of some other interface to the Gallium driver. Just FYI there are more state trackers than is depicted in the scheme.

[nanonyme]

let's face it, it looks almost like Direct3D 10

This is nothing new, I recall seeing Tungsten comparing Direct3D to Gallium3D before and noting the similarities in their slides year or more ago. This was counted as a good thing.

[marek]

This is nothing new, I recall seeing Tungsten comparing Direct3D to Gallium3D before and noting the similarities in their slides year or more ago. This was counted as a good thing.

And I am really glad they have taken that path (I used to develop shaders in HLSL a lot, and I do so occasionally even today).

[markg85]

I'm beginning to understand how the layers are organized now. Thanks to all for clearing it up.

[loonyphoenix]

Do I understand correctly that OpenGL (and other non-hardware state trackers) gets converted into a Gallium3D-sepcific language, which then gets converted to hardware calls by other hardware-specific state trackers?

I have a question about that abstraction layer. It seems to me to be a kind of a powerful tool if it can do whatever OpenGL, GLSL, Direct3D and whatever other graphical abstraction layers there are can do (seeing as those get converted into this abstract layer) while maintaining independence from specific hardware. It seems like a lower-level OpenGL or something. Is there a state tracker to talk to that language directly? It seems to me like coding in this specific language would be more efficient performance-wise and might be of interest to some people. For example, the developer of Lightspark has talked about creating his own state-tracker specically for that application. Wouldn't it be easier to expose that kind of power to the userland, instead of keeping it inside Gallium3D?