Announcement

Collapse
No announcement yet.

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

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

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


            • #16
              Yeah, it's just a matter of abstraction. The internal API reflects the internal structure of the Gallium architecture, but that isn't interesting to app developers. Actually making those drivers do stuff is interesting. Nothing's stopping anyone from making a new modern graphics API. Gallium isn't that API; it just makes it easier to develop, as it gives you an existing working chunk of hardware drivers that your API will instantly work with once you write the glue/state-tracker for it.

              I'm really interested in seeing such an API, especially if efforts are made to document it, DESIGN it (versus just write it, and then constantly change it because it wasn't thought out first), and publish it.

              Honestly, though, there's not much to graphics APIs these days. Almost all of the interesting work goes on in the shader compilers/optimizers. The graphics APIs are mostly just a collection of methods for pushing data to the GPU and then telling it which chunks of data to pass off to shaders for rendering, with some state management tossed in for the bits of the pipeline that are still fixed-function.

              Comment


              • #17
                Originally posted by elanthis View Post
                DESIGN it (versus just write it, and then constantly change it because it wasn't thought out first)
                There is no "designing it perfectly". No matter how much you try, you always realize after some time that you got the first design all wrong. Usually at least several API re-specifications are required for a good design. So the argument that something should be very carefully designed and thought out and be the best from the beginning is wishful thinking and never works in practice. Iterative subtle refining the API as time goes by is the only key to success. This rule applies to every project (especially large projects).

                If someone wants a new modern graphics API on Linux, Gallium is currently the best choice, far better than OpenGL (except that Gallium has no high-level shader language, there's just the TGSI assembly language as the shader code representation).

                Comment


                • #18
                  @Marek

                  Lightsmark's architecture is highly layered from what I understand. They should be able to maintain their gallium to lightsmark adaptor code more or less independent of the vm portion of their project.

                  Comment


                  • #19
                    I was going to say hopefully that gives them the flexibility to deal with API breakage with a certain amount of grace.

                    Comment

                    Working...
                    X