On November 20, 2003 07:17 pm, Alexandre Julliard wrote:
Get rid of a bunch of TSX functions.
Yay! Getting rid of the TSX functions seems to be within our reach now. I hope this is the plan, right? :)
"Dimitrie O. Paun" dpaun@rogers.com writes:
Yay! Getting rid of the TSX functions seems to be within our reach now. I hope this is the plan, right? :)
Yes, and ultimately not only to get rid of the TSX functions but of all the explicit X11 locking too. These days I think it's reasonable to assume that the X libraries are thread safe.
Yes, and ultimately not only to get rid of the TSX functions but of all the explicit X11 locking too. These days I think it's reasonable to assume that the X libraries are thread safe.
This means that I will have to change the usage of the X11 critical section in the D3D code by one of our own (basically, we 'misuse' a bit this crit. section to prevent two threads doing GL calls at the same time - something that games like DungeonSiege love to do :-) ).
Lionel
Lionel Ulmer lionel.ulmer@free.fr writes:
This means that I will have to change the usage of the X11 critical section in the D3D code by one of our own (basically, we 'misuse' a bit this crit. section to prevent two threads doing GL calls at the same time - something that games like DungeonSiege love to do :-) ).
Do you really need to lock all GL calls, or is it just to protect access to d3d internal structures? The GL libraries themselves should be thread safe right?
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
On November 20, 2003 08:45 pm, Alexandre Julliard wrote:
Yes, and ultimately not only to get rid of the TSX functions but of all the explicit X11 locking too.
<much_joy>It would be nice to finish this before WineConf, this way the circle is complete, we've been bouncing this idea last conference, in San Diego :) </much_joy>
Speaking of which, I noticed you're hard at work at it, do you need a hand? If so, we need to coordinate a bit, it's just too easy to step on each other's toes.
Also, is it worth opening a Janitorial item? If we're going to just get it over with, it may be done before the new item will even appear on WineHQ...
"Dimitrie O. Paun" dpaun@rogers.com writes:
Speaking of which, I noticed you're hard at work at it, do you need a hand? If so, we need to coordinate a bit, it's just too easy to step on each other's toes.
Probably not worth the trouble, there aren't many calls remaining.
Also, is it worth opening a Janitorial item? If we're going to just get it over with, it may be done before the new item will even appear on WineHQ...
For the TSX issue it's not worth it; we may want one for getting rid of the wine_tsx11_lock calls later on, though this will require some thought in cases where the X11 lock is used to protect something else, so maybe it's not really janitorial.
-
Alexandre Julliard -
Dimitrie O. Paun -
Lionel Ulmer