Ian Romanick wrote:
Linus Torvalds wrote:
You _really_ want to use futex'es for any user-space locking. It's
back-ported to 2.4.x, and it gets these cases _right_. There are fair
user-space locks based on futexes as part of modern glibc sources, and
they are _fast_, since all non-contention (common case) is done entirely
in user space, and they do the right thing (*) when there is contention.
You're right. We do _really_ want to use futex'es. However, I don't
think they're available on *BSD or Solaris. I don't know if there's
anyone working on DRI right now that knows enough about Linux and *BSD
to be able to determine what the effort would be to make futex'es or a
futex-like wrapper for those systems. I honestly believe that is the
only reason we haven't already started using futex'es.
We also have the problem of having to support old kernels with new
user-mode drivers.
Hmmm...I'll have to look in to futex'es more...
As promised, I have finally looked into the mystical futex. The short
version is that it should be dead simple to convert the existing DRI
drivers to use either the existing locking method or a futex. And now
for the rest of the story...
A futex is actually very similar to the existing DRI lock. This is the
main thing that will make transitioning the to futex interface so
simple. Basically, a futex is just a variable in shared memory. When a
thread wants to acquire the futex it decrements the variable. If it's
non-negative, the thread happily continues on. If the value is
negative, the thread calls into the kernel to block. At this point, the
futex is virtually identical to the existing DRI lock.
The real difference comes at the unlock. When a thread wants to release
the futex, it increments the variable. If the value is greater than
zero, the thread happily continues on. If the value is zero or
negative, the thread calls into the kernel to wake-up the next waiting
thread. It is this last part that differentiates the futex from the
existing DRI lock. It is also this last part that gives the behavior we
were trying to achieve by calling sched_yield after releasing the DRI lock.
There are 5 steps that we need to take to transition to the futex
interface. Some of the changes are in device independent code and some
are in device dependent code.
1. Create a set of wrapper functions in lib/GL/mesa/src/drv/common.
These functions will wrap the existing DRI lock functions. These
functions are currently implemented as virtually identical macros in
each driver's *_lock.h file. Basically, we need to convert these macros
to functions and move them to the common directory. All of these macros
call a device specific *GetLock routine on lock contention. The
function verion of the macros would need to take a pointer to this
function as a parameter.
2. Create a set of wrapper functions in lib/GL/mesa/src/drv/common, with
the same functional interface as those in step #1, to wrap the interface
to the futex.
3. In each driver, add a pointer-to-function called acquireLock and one
called releaseLock. These pointers will be used to call one of the sets
of wrapper functions.
4. In the create context call of each driver, detect which interface
(i.e., classic DRI lock or futex) to use and initialize the acquireLock
& releaseLock pointers. The code that actually detects which interface
to use could probably also live in the common directory. That dependes
on whether or not the detection is as simple as detecting that the
kernel supports the futex ioctl.
5. Modify the macros in *_lock.h to call acquireLock & releaseLock with
the correct, device specifice parameters.
I believe that will be the path of least resistance. It should also
make it a bit easier to add support for "special" interfaces for other
systems. The nice thing about the futex, and the part that makes it so
easy, is the data representation of a futex and the data representation
of the classic DRI lock is identical. That means that we don't need to
make any changes / additions to the SAREA. That's a big plus in my book. :)
The one catch that I see is that I don't see support for the futex ioctl
in any 2.4 kernel. I did a 'grep -ri futex include/' in the source for
2.4.21-ac2 and for 2.5.69. The 2.4 kernel didn't have any hits, but the
2.5 kernel did. Of course, this doesn't mean that support isn't there,
it just means that it might be more challenging to build a driver on a
box with only 2.4 kernel sources installed.
The other interesting possability is to make the "classic" DRI lock
behave like a futex (i.e., add a "release contended lock" ioctl) to
systems that don't support the "real" futex interface. This would
include older linux kernels and, more importantly, the various BSDs.
That's a bridge better left uncrossed until another day. :)
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
