On Monday 21 February 2005 17:40, John Clemens wrote: > > On Mon, 21 Feb 2005, John Clemens wrote: > > > >> give it a go on my fanless 9600se (RV350 AP). > > > > How much memory do you have ? What kind of CPU and motherboard ? > > Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g. > Gentoo. The card has 128Mb ram. > > >> - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) > >> - glxgears gives me about 250fps with drm debug=1, ~625fps without debug > >> on. > > should I be concerned that these fps are too low? others seem to be > reporting around 1000..
Well, I'm not sure about the value with debug off, it does seem rather low, but perhaps reasonable if you are using immediate mode (which is still the default in CVS, I believe - check r300_run_render in r300_render.c). Your debug FPS is rather high, actually - I only get around 50fps in glxgears with enabled DRM debugging (even less if I also enable debug messages from the userspace driver). > >> - tuxracer runs ok at 640x480 fullscreen > >> - ice textures look psychadelicly blue > >> - at 1280x1024, (and somewhat at 800x600 windowed), i get these > >> errors: > >> [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer > >> blit > > ... > > > The swap buffer blit is just a copy - for example a copy from back buffer to > > front buffer. Since the engine timed out before swap buffer blit it means > > that the commands before it were at fault. Which is puzzling as you point out > > that everything works in 640x480. > > Just to elaborate: 640x480 runs fine. at 800x600 windowed, it plays > fine, but if a scene gets more complicated i see some jerkyness.. i.e., > the scene freezes for a second or two and then jumps ahead, and i get a > few messages in the log. At 1280x1024, this happens all the time, so it > appears the game is locked, and I get a stream of those messages in the > log file. alt-F switching to the console works, and switching back i get > about 2 seconds more of movement, and then soft-lock again (persumably > because the card re-inits on VC switch). I can switch to the VC and kill > it and all's fine. Judging from what you're saying, the card isn't > locked, it just isn't able to draw a full scene before it times out. Well, this is certainly interesting, and it does sound like userspace is generating so many drawing commands that the card is simply too slow to process them all. My guess is that the one-two second freezes are causes by the X server when it, too, thinks that the engine has timed out and initiates a reset sequence. This is actually an interesting problem. Here are some issues to think about: 1) The SWAP ioctl should really report an error to userspace when the engine has timed out. 2) I agree that it would make sense to monitor the ring buffer somehow. Perhaps a wait_for_ringbuffer that is called at the top of wait_for_fifo? In the "fast path", this costs an additional I/O read operation, otherwise it should be essentially be no different performance-wise. 3) Come to think of it, couldn't the card just issue an IRQ when it's done? 4) If a drawing command takes very long, can we identify the userspace process that is responsible for sending the command buffer that caused the delay, and can we deal with this process somehow? Perhaps we could insert an age marker before and after the processing in the command buffer ioctl. The last point actually touches on a bigger subject: scheduling access to the graphics card. To get an idea of what I'm talking about, launch a terminal emulator and glxgears side by side. Then run "yes" in the terminal emulator. glxgears will essentially "lock up". cu, Nicolai
pgpRFAJMWkcWT.pgp
Description: PGP signature
