charlie wallace wrote:
>
> i`ve been working on something similar, the
> solution we`re looking at is to use a run time linker
> that links in the correct module for the cpu/renderer
> in use. kind of like shared libs on unix, that way all
> the routines are pointers or table lookups. It doesn`t
> help much with asm thats inlined with top level stuff
> of course, but it does help with other longer routines.
>
> It`d be really cool if you had a run time loadable module
> that could be specific to say k6,katmai,mips etc that
> just could be loaded by mesa,.
>
> there would be a `c` version for easy porting as
> there is now, ..
>
> That was theres no ugly ifdefs or such its all
> handled at runtime. Means users can just get
> say the vector/matrix/math lib/dll/bin whatever
> for their system, mesa detects and loads it instead
I wasn't imagining any sort of dynamic loader for the assembly
code modules. The basic goal, I think, is to compile/assemble
the Mesa code with x86, 3DNow, MMX, _and_ PIII instructions all
into the same library. Then at runtime, detect if the CPU has
those instruction set extensions and use them, otherwise simply
never execute the special code.
This would allow Red Hat, for example, to make a single Mesa
x86 library RPM which could be used on any x86 system. Furthermore,
an OpenGL application could be shipped with a single X86 Mesa
library file which would take advantage of any Intel-like CPU it
might run on.
This is a sort of a cross-compile/assemble situation. It should be
possible to assemble (but not execute) 3DNOw, MMX, PIII code on any
x86 (or other) architecture system.
-Brian
----------------------------------------------------------------------
Brian Paul Avid Technology / Softimage [EMAIL PROTECTED]
