[Openchrome-users] new dri options

[Boris Dušek]

On Tuesday 03 October 2006 14:32, you wrote:
> Boris Du?ek wrote:
> ...
> > On Tuesday 03 October 2006 13:06, you wrote:
> > #ifdef HAVE_SSE and now is by driQuery...). But then I discovered
> > that somewhere in the code that I enabled by commenting out the
> > "#ifdef 0", there were hardcoded references to memcpy_sse.
>
> Ah, I see, you mean this part:

yes, that's it.

>
>   #if defined( USE_SSE_ASM )
>   #define COPY_DWORDS(vb, vertsize, v)
>       [[ via_sse_memcpy(vb, v, vertsize * 4); ]]
>   #else
>   #if defined( USE_X86_ASM )
>   #define COPY_DWORDS(vb, vertsize, v)
>       [[ "rep ; movsl" ]]
>   #else
>   #define COPY_DWORDS(vb, vertsize, v)
>       [[ for (j = 0; j < vertsize; j++) ]]
>   #endif
>   #endif
>
> It doesn't look like this is configurable after compile time.  It
> would have to be programmed quite differently for that to become
> possible, and that is beyond me.

same for me, that's why I could not finish it myself.

>
> So for now it seems best to leave the whole SSE stuff out of the
> patch and just add the page flipping and the extra mipmap level
> options.  It makes the patch smaller too: more easily accepted.
> What do you think?

My opinion is: definitely put back the "#if 0" for this part again. Because we 
simply can't handle it with our skills at the moment.

The question is whether SSE can make the performance difference in the rest of 
the code, i.e. where vmesa->memcpy is invoked. If the difference is 
negligible, then best would be to simply forget about SSE at all and make 
things simpler.

If there is a difference, then there is no problem for enabling 
driconf-configurability of the vmesa->memcpy routine.

I personally would prefer the second option, but not sure about it. Since I 
don't have the development driver with my patch (how unusual, I don't use my 
own patch :), could you (or someone else with the patch) please test glxgears 
with SSE off and on? (and with the "#if 0" included in both cases)?

Btw. this reminds me of a problem I had - is it somehow possible to develop 
the mesa 3D DRI drivers (e.g. unichrome driver) with only mesa system headers 
and libraries installed? I mean do I really have to install the whole source 
code for mesa, or is there a cleaner way, some "3D driver SDK", or something 
else that would make use of the already install MESA libraries and headers on 
my system? Just would make life easier. I use mesa 6.5.1.

Boris
>
> Benno