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=3D1, ~625fps without=20
> >> on.
> should I be concerned that these fps are too low? others seem to be=20
> 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=20
glxgears with enabled DRM debugging (even less if I also enable debug=20
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=20
> >> blit
> > The swap buffer blit is just a copy - for example a copy from back=20
> > front buffer. Since the engine timed out before swap buffer blit it=20
> > that the commands before it were at fault. Which is puzzling as you=20
> > that everything works in 640x480.
> Just to elaborate: 640x480 runs fine. at 800x600 windowed, it plays=20
> fine, but if a scene gets more complicated i see some jerkyness.. i.e.,=20
> the scene freezes for a second or two and then jumps ahead, and i get a=20
> 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=20
> 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=20
> 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=20
> 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=20
generating so many drawing commands that the card is simply too slow to=20
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=20
initiates a reset sequence.
This is actually an interesting problem. Here are some issues to think=20
1) The SWAP ioctl should really report an error to userspace when the engin=
has timed out.
2) I agree that it would make sense to monitor the ring buffer somehow.=20
Perhaps a wait_for_ringbuffer that is called at the top of wait_for_fifo?=20
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=20
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=20
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=20
the graphics card. To get an idea of what I'm talking about, launch a=20
terminal emulator and glxgears side by side. Then run "yes" in the terminal=
emulator. glxgears will essentially "lock up".