On 2002.06.13 05:18 Leif Delgass wrote: > Well, I had a "Eureka!" moment and figured out the problem with 2D accel, > which was also the cause of the signal 11 on server shutdown. "Hidden" > in > atiaccel.c there is a second initialization of the framebuffer manager > that was causing XAA to use the entire offscreen area (including our > back, > depth and texture areas) for the pixmap cache and offscreen pixmaps. > What confused me was there was a _third_ intialization in atiscreen.c if > direct rendering is disabled. I discovered that Gareth had added that > and > probably missed the one in atiaccel.c. So I removed the third init and > bypassed the one in atiaccel.c for the direct rendering path. Between > that and restoring the registers used by 3D driver in the XAA sync to the > what the Xserver expected, I got 2D accel working. VT and mode switches > also work now without locking up. >
That's great news, Leif! > I've also implemented the functions to init and move the back and depth > buffers (with the exception of depth moves), based on the Rage128 and > Radeon versions respectively. This makes moving windows much smoother. > We've still got some problems with the scissors not being updated > properly, which can be seen when moving windows. I've also had lockups > with the texenv Mesa demo in single-buffered mode, which could be because > of the scissors or the fact that we don't do cliprects for vertex buffers > yet. I'm not sure what the cause is yet. If it's reproducible don't forget to cat /proc/kmsg to see the ring dump. I'll also try to look at that as soon as I finish what've been doing and merge your changes. > > OK, now for the bad news: the driver currently allocates only 128 > scanlines for the XAA pixmap cache and offscreen pixmaps. This is what > the calculations for the size of the local texture area have been based > on. To get good 2D performance, we should probably allocate a full > viewport's worth of offscreen mem for XAA. This will put an even bigger > crunch on cards with less than 8MB of framebuffer mem. I think we'll > need > to figure out a good tradeoff here, and then include a config option so > people can decide if 2D or 3D is more important to them. Dynamic > allocation of back and depth buffers would help here and would allow > using higher resolutions on cards with low mem. > ... IIRC one of the features being planned for the next XFree86 version would be the ability the really change screen size (not just the display size) while running. I hope that this still holds because that changes in XFree86 will facilite the dynamic allocation of the back and depth buffer. And only when we are able to do that while the X server is running is that we'll really solve the low memory card problem, otherwise even if the user switches to lower screeen resolution for playing a game, it will remain on AGP memory so the preformance will be low. José Fonseca _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
