Did you have a 2D accelerated server running on another vt? The DDX saves and restores its register state on mode switches, so it could be a problem with the FIFO depth or pattern registers being changed. Try testing without another X server running if you haven't already. Also, does anything show up in the system log?
On Sat, 18 May 2002, Felix Kühling wrote: > Hi, > > I updated my DRI tree and recompiled everything. With glxgears, and > quake1 things work fine and the framerate has increased again. glxgears > went from 190 to 240 :). With quake2 and quake3 the Xserver locks up > before anything is drawn. I can kill the X-server with the secure access > sysrq key so the kernel is still responding. I get the following > messages in my kernel log: > > May 18 14:40:43 viking kernel: [drm] Setting FIFO size to 128 entries > May 18 14:40:43 viking kernel: [drm] Creating pci pool > May 18 14:40:43 viking kernel: [drm] Allocating descriptor table memory > May 18 14:40:43 viking kernel: [drm] descriptor table: cpu addr: 0xc06ac000, bus >addr: 0x006ac000 > May 18 14:40:43 viking kernel: [drm] Starting DMA test... > May 18 14:40:43 viking kernel: [drm] starting DMA transfer... > May 18 14:40:43 viking kernel: [drm] waiting for idle... > May 18 14:40:43 viking kernel: [drm] waiting for idle...done > May 18 14:40:43 viking kernel: [drm] DMA test succeeded, using asynchronous DMA mode > May 18 14:41:47 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:47 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:48 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:48 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:49 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:49 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:50 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:50 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:51 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:51 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:52 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:52 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:53 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:53 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:54 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:54 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:55 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:55 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:56 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:56 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:57 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:57 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > May 18 14:41:57 viking kernel: SysRq : SAK > May 18 14:41:57 viking last message repeated 9 times > May 18 14:41:57 viking kernel: [drm] mach64_do_wait_for_idle failed! >GUI_STAT=0x02000001 > May 18 14:41:57 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle >failed > > Both quake2 and quake3 switch the video mode. Before this used to work > even though switching the mode with Ctrl+Alt+"+/-" locked up the > X-server. I tried quake2 without fullscreen and it worked. Maybe this > behaviour changed with asynchronous DMA? > > For this test I compiled everything with gcc-2.95.4. I had a different > problem after compiling with gcc-3.0. I have to try that again and check > for compile errors. The problem was that the X server segfaulted on > startup. I'll report more details later. > > Regards, > Felix > > On Sat, 18 May 2002 05:33:40 -0400 (EDT) > Leif Delgass <[EMAIL PROTECTED]> wrote: > > > OK, I finally committed my changes thus far as a checkpoint. I'm reading > > BM_GUI_TABLE in the dispatch routine to see when we hit the hardware > > pointer and wait once we reach it. So the dispatch is treating the > > descriptor table as a ring, and it helps. There's still lots of places to > > optimize and probably a fair amount of cruft and bugs lurking, but I > > wanted to get this into cvs while things are working. :) One of the main > > problems is context switches with the X server. Right now I have a wait > > for idle followed by saving the pattern registers (used for buffer aging) > > in EnterServer (atidri.c). I'm only restoring the registers if the X > > server changes them, but the engine must be idle before they can be > > stored. We really need to figure out how to do this better, because > > things slow down whenever you move the mouse now. This might be a good > > time to look into getting sync working with 2D accel as well, since we'll > > need to verify that the solution will work with XAA. > > > > AGP texturing is working, but the algorithm needs work. The trick is that > > for multitexturing, both textures need to be in either card local or AGP > > memory. > > > > I can go into more detail about these changes at Monday's meeting, but > > I'll be away for a couple of days and I wanted to get this checked in and > > post a quick message for now... > > > > -- > > Leif Delgass > > http://www.retinalburn.net > > > > > > _______________________________________________________________ > > Hundreds of nodes, one monster rendering program. > > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > > > _______________________________________________ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > __\|/__ ___ ___ ___ > __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ > _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ > [EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time! > > _______________________________________________________________ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
