On Sam, 2003-02-08 at 04:37, David Dawes wrote: > On Sat, Feb 08, 2003 at 04:10:58AM +0100, Michel D�nzer wrote: > >On Sam, 2003-02-08 at 03:40, David Dawes wrote: > >> On Fri, Feb 07, 2003 at 09:24:21PM -0500, David Dawes wrote: > >> >On Fri, Feb 07, 2003 at 05:33:09PM -0800, Michael Cardenas wrote: > >> >> > >> >>I'm implementing a resolution test in our display control panel, which > >> >>basically starts a second X server on another terminal with the > >> >>desired resolution. > >> >> > >> >>This seems to work with some cards, but on the intel i810, I get the > >> >>following error: > >> > > >> >What hardare are you using? I just checked and noticed that the > >> >agpgart isn't being released when switching away for the 830M and > >> >later. Adding that allows a second X server to be started. If > >> >DRI is enabled, I notice some contention there when starting the > >> >second server, so that's something else to watch out for. > >> > > >> >If you're using an 830M or later, try this patch. The code for the > >> >810/815 already has this. > >> > >> I had another look, and for the 810/815 it doesn't do this when > >> DRI is enabled. I'm not sure why not. Nothing should be referencing > >> those mappings when the X server is switched away, so it should be safe > >> to unbind them. > > > >If a DRI client is running while you switch away, it will use these > >mappings (if the i8xx drivers are anything like the radeon drivers). > > Hmm, I haven't seen any problems with the 830M/845G, etc, which do unbind > when switching away, and I have tested with DRI clients running. > > I'm not so familiar with the radeon drivers, but the Intel chips are > the only ones I'm aware of where the user-land code interacts directly > with the agpgart module. Physical system memory is allocated when the > server starts up. It's then bound into the video memory aperture. It's > this binding that's undone when VT switching. The memory allocations > are kept until the X server exits (and re-bound into the aperture when > VT switching back). The mappings of the various parts of the apertures > that the DRI clients see aren't changed. > > The X server holds the DRI lock while switched away, so that should prevent > the clients from attempting to access the hardware, shouldn't it?
Yes. Actually, now that you've spelt it out, I wonder if the same thing couldn't be done in the other drivers. > I think it'd be good to make the reinit work you did more general (work > for all drivers), That would be nice in the long term, but I only have Radeon hardware to test and it's very little code in the radeon driver which could easily be split off later on. > as well as make it possible for the DRI to adapt to changes in video memory > usage on the fly. That could prove to be quite a challenge. :/ > Is your reinit patch in the DRI trunk yet? No, it was rejected. -- Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
