Brian Paul wrote:
>
> Keith W,
>
> 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've copied the key function below. In 3.1beta1 there were a lot of
assignments in this function and some ifdefs. The assignments populated
arrays of function pointers from which it was easy to select the
appropriate transformation code. The arrays still exist, byt the
assignments have been moved into functions which are generated in a
fairly crude manner using the C preprocessor.
void gl_init_transformation( void )
{
gl_transform_tab[0] = raw_transform_tab;
gl_transform_tab[1] = cull_transform_tab;
init_c_transformations_raw();
init_c_transformations_masked();
init_c_norm_transform_raw();
init_c_norm_transform_masked();
init_c_cliptest_raw();
init_copy_raw();
init_copy_masked();
init_dotprod_raw();
init_dotprod_masked();
#ifdef USE_X86_ASM
gl_init_x86_asm_transforms();
#endif
}
The function gl_init_x86_asm_transforms() should simply overwrite those
arrays with pointers to whatever optimized functions have been written.
For the meantime I would say that 'gl_init_x86_asm_transforms()' should
be reserved for Josh's code, and that PIII would be best accomodated by
adding this code to the tail of the function:
#ifdef HAVE_PIII_ASSEMBLY
gl_init_piii_asm_transformations();
#endif
That function would also be resposible for checking that there really
was a PIII installed.
In the longer term I am in broad agreement with Dave Millar's posting
regarding the rationalization of asm and introduction of an arch/
directory. I would like to see all of the #ifdef _some_architecture_
code moved into those directories.
In particular, I would like to see some architecture-specific header
files containing things like the FLOAT_COLOR_TO_UBYTE_COLOR macro and
all the other little bits and pieces we are accumulating.
I would never support runtime linking for this problem - this is massive
overkill for such a simple task and would introduce unnecessary
complications to configuration and installation.
I'm very surprised to hear that XFree have implemented their own runtime
linker. But if that sort of thing is common over there, the delays with
XF4.0 start to make sense...
Keith
