Josh Vanderhoof wrote:
>
> Brian Paul <[EMAIL PROTECTED]> writes:
>
> > I was browsing the latest code to see where assembly language
> > optimizations will hook into the transformation code. It wasn't
> > obvious to me where this would happen.
> >
> > Someone from Intel wrote me today that they've been testing PIII
> > instructions in Mesa and would like to get them into the distribution.
> >
> > We've got to clarify how/where to do this.
> >
> > Ideally Mesa should test at runtime if the CPU supports 3DNow! or
> > PIII instructions. A compile time option would be OK for the time
> > being though.
> >
> > Have you given any thought to this? In the original Mesa 3.1 beta
> > there was a simple framework for hooking in optimized FP code.
>
> I have the assembly language working with the newest Mesa. I just
> added a new file, x86.c, which defines gl_init_x86_asm_transforms(),
> which replaces the entries in gl_transform_tab and gl_clip_tab that
> have assembly language equivalents with pointers to the asm functions.
> It still has some bugs to fix before I commit it.
>
> One new thing about the assembly code that may be bad is that it now
> uses m4 macros. As long as a pre-expanded version is included, is
> that OK?
I don't have any problems with this (I don't know how Brian feels,
though).
I am actually keen to see a lot of this repetitive code moved to a
higher level, and using automatic means to generate a lot of it. What
I've done with the xyz_tmp.h files is motivated by this desire, but I
think it could be more cleanly done with a couple of perl scripts and
some sort of template mechanism.
If you look at the GLX code for example, it is clear that most of it is
untouched by human hands.
I'll be keen to see what you've been able to acheive.
Keith
