On Mon, 2009-11-09 at 04:02 -0800, Joakim Sindholt wrote: > I've heard a little talk here and there and glisse pointed out I should > take it to the ML. > > The basic idea is that instead of binding 1 winsys, 1 state tracker and > a couple of pipes into every single library we churn out, we define some > sort of API between winsys and state_tracker so that we can split the > library into 1 x (winsys + n pipes) and compile state trackers > separately and just load our "Gallium3D library" at runtime. > The way I see it we have a couple of options: > > * Generic API > This is probably impossible but never-the-less the prettiest > solution. It implies we can define a single, simple API that > satisfies all state trackers > * Superset > We could do this, which is closely related to a generic API > approach, but it would probably be a horrible mess > * Modular > Here's the best thing I could think of, which still has the > potential for horrible mess-ness. Basically it would entail > writing a loader that asks the winsys/pipe part to deliver a > struct that satisfies a specific interface. The interface would > be on a per-state tracker basis but many state trackers will > probably use the same very simple interface anyway. Furthermore, > we can siphon out functions all winsys' will provide anyway and > provide a generic interface for state trackers with no specific > needs > > The last implementation discussed could potentially give a simple > generic API + whatever-you-want without making a horrid mess of things > and still keeping code relatively clean. > > What do the higherups think, and do you already have a way better idea > than mine?
Joakim, This is definitely a direction we're interested in. Jakob is preparing an interface so that we can have multiple statetrackers for the Khronos APIs loaded simultaneously and talking to each others, as EGL establishes. And I've playing with the idea of having a generic driver interface that would allows to plug together state tracker + pipe + winsys dynamically in runtime ( http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg07818.html ). I believe this is more or less what you describe as the "Modular" option. I agree with your assessment -- trying to impose a generic API for everything would be bound to fail eventually. And a superset of all interfaces would imply to implement a large combination interfaces, continuously growing. We should cater for the most common things in the pipe_screen if we can, but we must leave room for extension. I don't have an ETA for this. I hope that we can tackle this after 7.7. I'll start a branch to prototype this when I find some time. Your feedback would be most welcome of course. Jose ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
