No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

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


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


      • #18

        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.


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