Messages in this thread | | | Date | Wed, 15 Dec 1999 03:09:20 -0800 | From | "David S. Miller" <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
Date: Tue, 14 Dec 1999 20:16:06 -0800 (PST) From: Linus Torvalds <torvalds@transmeta.com>
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/
| |