Page 1 of 2 12 LastLast
Results 1 to 10 of 19

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

  1. #1
    Join Date
    Oct 2007
    Posts
    285

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

    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

  2. #2
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

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

  3. #3
    Join Date
    Oct 2007
    Posts
    285

    Default

    Quote Originally Posted by whizse View Post
    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.

  4. #4
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    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.

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    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.

  6. #6
    Join Date
    Jan 2009
    Posts
    624

    Default

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

    Gallium=Gallium3D, Mesa=Mesa3D

    The classic Mesa scheme:

    Code:
    Mesa core --> classic OpenGL driver
    In Gallium, the classic driver is split into two components:

    Code:
    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:

    Code:
    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.

  7. #7
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,595

    Default

    Quote Originally Posted by marek View Post
    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.

  8. #8
    Join Date
    Jan 2009
    Posts
    624

    Default

    Quote Originally Posted by nanonyme View Post
    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).

  9. #9
    Join Date
    Oct 2007
    Posts
    285

    Default

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

  10. #10
    Join Date
    Jan 2009
    Posts
    80

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •