I'd think coding in the gallium IR would be just like x86 asm.
Thank you for the clarification. That was enlightening.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).
Do you see the API/ABI becoming stable in the future? Or is it a permanent situation, like the drivers inside the kernel?
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.
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.
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).
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.
I was going to say hopefully that gives them the flexibility to deal with API breakage with a certain amount of grace.