> > > 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.
Yes, but that is the problem of the linker. It is the same problem
whether you write in assembler or C and regardless if you make
the call directly or indirectly through function pointer.
OK, in assembler you need to have special PIC code, as I'm my
attempt to an implementation in the most recent mail.
> 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.
You use the word static and dynamic differently that me.
When I say dynamic I mean that the number of arguments
or other specific data is not know at compile or link time.
> > 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 :-)
Try the patch in my most recent mail.
> 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).
My patch (the latest one) is designed for a worst case scenario where
1. There might be calls from multiple thread
2. There might be a reentrancy in the same thread.
I'm not sure 2 is even possible for OpenGL functions.
Are there OpenGL functions that takes callbacks?
And if so are these callbacks are allowed to call
OpenGL functions. If not the thunking might be done
faster.
