Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    Does this clear things up? (The thread right above yours )
    http://www.phoronix.com/forums/showthread.php?t=7221

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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).

                Comment


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

                  Comment


                  • #10
                    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?

                    Comment


                    • #11
                      I'd think coding in the gallium IR would be just like x86 asm.

                      Comment


                      • #12
                        Originally posted by curaga View Post
                        I'd think coding in the gallium IR would be just like x86 asm.
                        One of the main drawbacks of ASM is that it is difficult to port. That is, x86 ASM can't be run on an x64 or ARM platform. Still, even with all the limitations of ASM, it's still useful for the most performance-critical code. However, the Gallium IR (what does that mean?) seems to come before hardware-specific trackers, which implies that it is hardware-independent. I think it would have a wider user base than ASM.

                        Comment


                        • #13
                          Originally posted by loonyphoenix View Post
                          It seems like a lower-level OpenGL or something. Is there a state tracker to talk to that language directly?
                          Yes, it's really another 3D API. There is the "graw" state tracker (Gallium RAW) but nobody seems to use it. Even I don't know how to use it. There's also the python state tracker which exposes the Gallium API in Python, which I used to use for testing, but that's bitrotting too. Pylladium to the rescue? Who knows.

                          Originally posted by loonyphoenix View Post
                          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?
                          Let's call that internal interface Gallium (it's not really IR, it's an API, like OpenGL). If we exposed Gallium to userspace, we'd have to keep the ABI stable. Having it internal allows us to change it whenever we want, which is damn important as we're playing a catch-up. If Lightspark developers use Gallium directly, they will have to merge it into the Mesa tree and release it as part of the Mesa project, or merge a subset of Lightspark and define their own public API (which is much better than using GL, because GL is really awkward and the path from GL to Gallium is quite long).

                          Comment


                          • #14
                            Originally posted by marek View Post
                            Yes, it's really another 3D API. There is the "graw" state tracker (Gallium RAW) but nobody seems to use it.
                            Seeing as the API is constantly changing, that's not surprising.

                            Let's call that internal interface Gallium (it's not really IR, it's an API, like OpenGL). If we exposed Gallium to userspace, we'd have to keep the ABI stable. Having it internal allows us to change it whenever we want, which is damn important as we're playing a catch-up. If Lightspark developers use Gallium directly, they will have to merge it into the Mesa tree and release it as part of the Mesa project, or merge a subset of Lightspark and define their own public API (which is much better than using GL, because GL is really awkward and the path from GL to Gallium is quite long).
                            Thank you for the clarification. That was enlightening.

                            Do you see the API/ABI becoming stable in the future? Or is it a permanent situation, like the drivers inside the kernel?

                            Comment


                            • #15
                              Unlikely, but you can make another state tracker that is just a copy of the Gallium API, and if Gallium changes, you will need to wrap any changed function with a function that translates the parameters from the old function to the new one.

                              Comment

                              Working...
                              X