On Wed, 2002-07-03 at 15:43, Jens Owen wrote: > Michel D�nzer wrote: > > > On Tue, 2002-07-02 at 18:38, Keith Whitwell wrote: > > > >>Chris Howells wrote: > >> > >>>-----BEGIN PGP SIGNED MESSAGE----- > >>>Hash: SHA1 > >>> > >>>Hi, > >>> > >>>Is there any real need these days for DRI to be limited to only working on one > >>>X session? > >>> > >>>I spoke to the maintainer of kdm, and he wants to implement a feature to allow > >>>multiple people to use kdm to login easily, by using multiple X sessions to > >>>switch between different users. Unfortunately this means that DRI will only > >>>work on one of the sessions. > >>> > >>>gdm can apparently do this already so would also suffer from the lack of > >>>acceleration on all sessions as well. > >>> > >>>NVidia'd propreitary drivers can apparently offer acceleration in multiple > >>>sessions so it's a real shame that DRI can't :( > >>> > >>>Is support for acceleration on multiple sessions likely to appear in the > >>>future? > >>> > >>Nobody's really talked about this as a desired feature previously. I'm not > >>even sure that it *doesn't* work -- it shouldn't be too hard to get working if > >>not. > >> > > > > How would it work with a single hardware lock? I've been thinking about > > making the lock per-screen to achieve this, but I'm probably just > > missing something. > > If you had a lock per screen, and the server held the lock, but assumed > the hardware was accessed when VT switched away, then I belive you could > get this scheme to work.
Exactly what I've been thinking of, just extending the current scheme to a per-screen lock (and probably more per-screen resources). > Other things to consider: My thoughts about them, please correct me if I'm missing something or simply wrong. :) > 1) Holding the lock will effectively lock out the 3D driver from > rendering. Over an extended period of time this might cause problems if > the application is allocating many buffers in anticipation of the lock, > and other X sessions are needing those same buffers. This is only a problem given 2) though AFAICS. > 2) The AGP resources from the AGP GART module are not a per screen > resource. Their may be assumptions in our drivers where we are assuming > a 1:1 mapping between the AGP resources and a single X session. Right, hadn't thought about that before. I assume we'd only have to make the areas used for DMA (rings, indirect buffers, ...) per-screen, things like textures could simply be invalidated when switching away. For the DMA stuff, we might get away with saving it to 'normal' RAM or a temporary file when switching away and restoring it when switching back, if only for a proof of concept. In the long run there could be a sophisticated solution with virtual memory magic. That might be overkill though, seeing as VT switching is a relatively rare operation. > I'll be curious to hear what issues you find if you choose to persue > this functionality. Let us know. It sure looks like a fun project, unfortunately I don't know if I can find the time to actually play with it in the near future. Maybe at Cologne? :) -- Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek We have stuff for geeks like you. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
