>My main concern is not what the front end interface looks like and
>whether dlopen() is it. What I care about is that where dlopen() or
>some similar facility is available, it is what is used. The API to
>load modules from within' mesa can look however you like, I care about
>implementation details at the bottom.
>
Ditto.
>Actually my original asm re-design suggested a method by which modules
>were not necessary. If we don't really need them, why bother?
the reasoning behind them is that you can develop contained litttle
modules which are easily optimized and tested for various cpus
etc, for me it means i can send a small test suite and source code
to one of the cpu oems and they can optimize it, without needing
the whole source tree/build system etc. Obviouslly with mesa its
not needed because the source is freely available.
Also it means the end user can have a core mesa.lib/dll and can
download say a new math module for their cpu without any rebuilds.
Also it cuts down the memory footprint as only the needed modules
are loaded.
Its another level of abstraction I suppose, an API within an API.
If we can standardize it , hopefully others can benefit from it too.
Wouldn`t it be great if you could just have a set of shared libs
that could be written by anyone that were optimized for specific
cards/cpus etc. They could be black boxes so that oem`s
that were cagey about driver specs could do them without
complex nda's, pinch me i`m dreaming.
They`d contain standard common routines, just like the C dll/libs etc.
I`m still in the planning stage with it.. I hope it doesn`t sound too crazy
8-)
charlie
