Jens Owen wrote:
> Greg Hughes wrote:
> > Jens,
> > >
> > > Have you looked at the dynamic driver loading interface in Mesa? It's
> > > very similar, and it utilizes the ARB extension for resolving driver
> > > extensions.
> > Do you mean the Device Driver (DD) interface defined in src/dd.h, or is there
> > another interface you're referring to?
> A different interface. Brian has developed a libGL wrapper that can
> supports OpenGL core rendering routines regardless of their
> architectural origin. Brian, can you give us a pointer to where this
> interface lives in the source tree?
To be pedantic, the code is in GLX/DRI, not Mesa.
Look in xc/lib/GL/dri/dri_glx.c. Basically, we make a DRI call to find
the name of the GL driver (like "tdfx" or "mga") and then use dlopen()
to load the actual driver ("tdfx_dri.so" or "mga_dri.so"). The driver we
open is dependant on the screen number in order to support heterogeneous
After we've opened the driver we'll use the driver's __driCreateScreen
function to bootstrap the driver.
The GLX_ARB_get_proc_address extension adds a little complication.
Each GL driver should also export a function named __driRegisterExtensions.
We call this function early in the GLX initialization for each screen's
driver. This lets GL drivers export new GL extension functions without
requiring the libGL.so library to know anything about them. This lets
vendors (such as VA) release new *_dri.so GL drivers with new extensions
without requiring a libGL.so upgrade.