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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to