I'd think coding in the gallium IR would be just like x86 asm.
Announcement
Collapse
No announcement yet.
Galium3d, mesa, mesa 3d, state trackers and drivers... help!
Collapse
X
-
Originally posted by curaga View PostI'd think coding in the gallium IR would be just like x86 asm.
Comment
-
Originally posted by loonyphoenix View PostIt seems like a lower-level OpenGL or something. Is there a state tracker to talk to that language directly?
Originally posted by loonyphoenix View PostIt 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
-
Originally posted by marek View PostYes, it's really another 3D API. There is the "graw" state tracker (Gallium RAW) but nobody seems to use it.
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?
Comment
-
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
-
Originally posted by elanthis View PostDESIGN it (versus just write it, and then constantly change it because it wasn't thought out first)
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
Comment