Do you really need to lock all GL calls, or is it just to protect access to d3d internal structures?
I do not lock at the individual GL call level but rather at the 'internal API' level (for example, to draw some primitives, I do not lock on each glVertex call, but at the API function level which does the drawing).
And, yeah, it also serves to protect internal structures (why add a new lock when you already have one that you needed to call).
The GL libraries themselves should be thread safe right?
Well, this is a point that I never really investigated (especially when two threads are sharing the same GL context). For example, in Wine, we never actually set the current GL context for all threads, only for the one creating the D3D object... And still, multi-threaded games like DungeonSiege work like a charm (this is maybe due to the second thread 'inheriting' the GL context as long as one does not call glXMakeCurrent on a new context).
But the real issue is that they share the same context and that we need to change GL states to emulate some of D3D's quirks. So some game (like DungeonSiege) which does 3D rendering in one thread and 2D in another thread would have the lock / unlock thread break the GL rendering states ... and would lead to utter mess on the screen (as I saw for myself when I started debugging this game when some locks were missing :-) ).
I have no idea when I will have time to replace the X11 lock usage by a special D3D lock (I was planning to hack on more fun stuff this week-end :-) ).
Note that the GL locks can be removed from the OpenGL code (I just need to re-generate the thunks).
Lionel