On 08-Jun-99 Holger Waechtler wrote:
>> > I would be happy, if we could do something similiar with the FX/NV/G200
>> > driver - Mesa would become a generic super-driver similiar to the SVGA
>> > X-Server, which decides at runtime, which hardware driver it will use.
>> I think that'd be a very bad idea.
>> Let's try to avoid monolithic designs and select drivers via configure
>> options or, even better, make Mesa modular (a nice alliteration :) !
>> I could add portable dlopen support to Mesa, if you like.
> Who says, that our super driver is not able to load it's subdrivers
> dynamically ??
Well, that was my interpretation. libggi or XFree 4.0 would
be a better example, IMHO.
> (could you explain, how dlopen() is used ??
dlopen could be used to load a dynamic library (driver)
that has a standardized interface, e.g., the functions init_drv()
and get_visual(). You can get the addresses of these functions
using dlsym (e.g. dlsym("init_drv")).
First off, we'd need a unified driver API for Mesa.
Why has each driver its own API? This is bad.
There should be single interface for applications
so that they don't need to know the underlying driver.
Such an abstract interface is required for dynamic
loading of drivers since many platforms don't allow
unresolved symbols when linking against a library.
My proposal:
typedef struct mesa_visual *MesaVisual;
typedef struct mesa_buffer *MesaBuffer;
typedef struct mesa_context *MesaContext;
extern MesaVisual MesaCreateVisual(char *driver, ...);
extern void MesaDestroyVisual( MesaVisual visual );
extern MesaBuffer MesaCreateBuffer(MesaVisual visual,
void *your_window_id);
extern void MesaDestroyBuffer( MesaBuffer buffer );
extern MesaContext MesaCreateContext( MesaVisual visual,
MesaContext sharelist );
extern void MesaDestroyContext( MesaContext context );
extern void MesaMakeCurrent( MesaContext context, MesaBuffer buffer );
extern void MesaSwapBuffers( MesaBuffer buffer );
Driver-specific flags should be accessible via
glEnable/Disable/Hint & co
extern int MesaGetCapabilities(MesaVisual visual);
could return information about the features of the driver,
for example, does it support multiple windows, video modes,
can you disable hw-acceleration ... ?
We could define abstract, driver independent functions for
these features.
> - works it on non-Unix
> platforms (MacOS, Dos, Windows) ??
I've written a portable dlopen wrapper for libtool called libltdl.
It supports:
dlopen (Solaris, Linux, *BSD), shl_load (HP-UX), LoadLibrary (Win32),
load_add_on (BeOS), GNU DLD (emulates dynamic linking for static libraries)
libtool's dlpreopen (works on all platforms, modules are statically
linked to the program)
> -- if not, we could put some #ifdef's
> around it and link at unsupported platforms all subdrivers in the
> library.)
Certainly.
Thomas Tanner -----------------------------------------
email: tanner@(ffii.org|gnu.org|ggi-project.org|gmx.de)
web: http://home.pages.de/~tanner
GGI/Picasso: http://picasso.ffii.org
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
