Jon Taylor wrote:
| ... If the new generic interface can be implemented using a
| dynamic library based system, it would not necessarily have to be
| Mesa-specific. It could be implemented directly or as a wrapper layer
| around the GLX/WGL/etc interfaces, whether those interfaces are
| themselves implemented by Mesa or another OpenGL-type library/driver.
| ...
| If GLX were to be implemented as a wrapper layer around the generic
| interface (reverse of the above), People could use GLX directly or by
| wrapping it around another interface (generic or otherwise).
| ...
| This generic interface idea is a godsend, IMO. I see no reason why
| this generic interface should not immediately be written. ...
As an historical note, many of us have been down this path before --
sometimes more than once. I call it the ``endless regression of the
lowest layer'' problem. If we were to borrow from Richard Feynman, I
guess we would say ``there's still plenty of room at the bottom.'' :-)
Technically, the issue is that layering isn't a sufficiently-powerful
abstraction mechanism to handle the engineering problems you're trying
to solve. Each strictly-defined layer represents a barrier to
optimization and a rough edge along which semantic gaps grow. You can
be supremely careful about keeping your new low-level API as simple
and general as possible, but in the long run the inherent complexity
of real-world problems will force you to add more and more
functionality to the API until it becomes as large as the APIs you
were trying to replace. (This is true even if the API is dynamically
extensible.) Then a new generation of engineers grows disgusted with
the implementation and maintenance costs and repeats the process.
As a practical matter, I suggest that the best solutions are those
which create as few new peer APIs as possible, and actively avoid new
API layers. In the case of drivers (for the purposes of this
dicussion, I'm including device-specific portions of GLX in this
category), this means using vertical modularization rather than
layering. In principle, vertical modularization allows a command to
flow directly from the API entry point to the hardware with *no*
intervening driver interface layers. Systems using such techniques
have been built and are commercially successful. The most important
question to keep in mind for such a design is ``What is the smallest
set of access control constraints I must enforce in order to support
multiple APIs, or multiple implementations of the same API?'' Then, as
a *separate* project, you tackle ``How do I minimize the amount of
work needed to make a given API implementation robust and
high-performance?'' The SGI OpenGL sample implementation has a good
deal of code that's useful in this regard, and I've been trying to
convince SGI to release some of it to Mesa.
So my suggestion is: If you believe there's a good case for a new
``window system'' interface, e.g. for embedded systems that don't
have X11, then by all means go ahead and design it. But don't attempt
to encourage its use as an implementation layer for GLX; keep it
tightly focused on a particular application, or it'll rapidly become
just as large as GLX, and the layered implementation of GLX will be
slower than the native one. Lose-lose situation for everyone.
Allen
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
