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.
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. 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. For people using Jose's binary packages from the DRI website: this should appear in the next build (will be named mach64-20020614..., I think), if you want to try it out. -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
