Messages in this thread | | | Date | Wed, 15 Dec 1999 15:48:04 -0500 | From | Rik Faith <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
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/
| |