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?
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
