Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page)
Rik Faith (faith@precisioninsight.com)
Wed, 15 Dec 1999 15:48:04 -0500
In article <199912151109.DAA09556@pizda.ninka.net>,
you write:
|> 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:
[nice example removed]
|> 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.
I'd like to point out that the DRI was designed with SGI (and other
non-Intel) hardware in mind, and that the design can support implicit
locking mechanisms using page faulting.
We have implemented the current version of the DRI with an explicit
cooperative lock because that is required on today's PC-class hardware.
However, if a page-fault mechanism is found to be desirable on some
hardware, the currently implemented DRI can still provide a very
significant part of the overall infrastructure needed to support direct
rendering -- the changes required would involve the kernel driver, and the
removal of the explicit locking code from the X server and the
direct-rendering client.
Selecting and implementing a synchronization mechanism is only one small
part of the direct-rendering infrastructure provided by the DRI -- more
information is available on http://precisioninsight.com/piinsights.html.
--
Rik Faith <faith@precisioninsight.com>
Precision Insight, Inc.
-
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/