Note that you really should look at what DRI did with the 3dfx
driver, that does all of this =and= tries to keep much of the
context locking in user space (so that only on clashes does it go
to the kernel to fix things up).
The kernel side is in the standard 2.3.x kernel these days, the X
server side is in the unofficial 3dfx X server.
Please keep in mind that what the SGI folks are complaining about here
and how the 3dfx has to do are radically different issues.
Most commodity 3D graphics hardware these days cannot be interrupted
mid-operation, have it's state fully saved, have another renderer's
state fully restored, and let the latter continue where he left off.
You must complete the full operation you are currently in the middle
of before you can let someone else have the card.
Whereas most SGI, Sun, and other vendor's higher end cards allows you
to arbitrarily stop a renderer mid-place, save the card state, and
restore the card state another thread has. This can happen at nearly
arbitrary locations, so the following works:
Thread 1 Thread 2
OP = RECTANGLE
X = 0
Y = 0
OP = LINE
(takes fault, thread1's graphics card
state is saved, thread2's is restored
and mappings are removed from thread1's
space)
X1 = 5
Y1 = 10
X2 = 10
Y2 = 10 (draws the line)
W = 50
(takes fault, graphics
state restored, thread2's
state saved and his mappings
removed)
H = 50 (draws the rectangle)
Commodity PCI/AGI 3D graphics cards cannot do this, which is why
the userland locking solution exists at all. However for cards that
can do the above, this is what people want.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/