> I don't think a comparison with Windows is that technically relevant,
> since the graphic cards drivers are completly different.
Well, I am using NVIDIA's OpenGL drivers... And as far as I know, the
codebase is the same for Windows and Linux drivers. So performance
should be comparable betwenn Windows and Linux.
> > 1) instead of generating C code for the conversion (as in
> > opengl_norm.c), generate some ASM in-line to do it as fast as
> > possible. The problem with this is how to get the address of the
> > 'destination' function to put in the ASM...
>
> I'm not sure exacly what you mean by how to get the address of the
> destination function, since you have "static" thunks,
> but I think I have solved that problem for the Solaris C
> thunking that is dynamic.
What I meant is that these 'thunks' would call libGL functions. So
that the function address I need to call is only known at link time.
For 'dynamic' thunks, the function address is known, but I do not know
how to get it in the ASM code for 'to be linked in' functions.
> Thread safety is a problem, however I think I have solved that.
> What I did was to reshuffle the stack and allocate space _before_
> the arguments. Not that efficient, but it is optimized assembler and
> likely more efficent than what GNU C does.
>
> I have attached some code that might intrest you.
I will look at it. Anyway, I would like to hack something quickly
(even not thread safe) just to see how many FPS I can gain to see if I
even need to bother trying to optimize this :-)
As for thread safety, for most of OpenGL apps that people will use
with Wine (i.e. games :-) ), there should be no need to have it... So
having a non-thread safe but fast solution that could be compiled in
at configure time could be nice (and as I can detect easily when an
app is doing multi-threaded OpenGL calls, I can even warn the user by
a ERR that he should recompile Wine).
--
Lionel Ulmer - [EMAIL PROTECTED]
