Re: [r300] Radeon 9600se mostly working..

[Nicolai H. <pre...@gm...>]

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 ?
>=20
> Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g.=
=20
> Gentoo.  The card has 128Mb ram.
>=20
> >> - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL)
> >> - glxgears gives me about 250fps with drm debug=3D1, ~625fps without=20
debug
> >>  on.
>=20
> 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,=
=20
but perhaps reasonable if you are using immediate mode (which is still the=
=20
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
buffer=20
> >> blit
>=20
> ...
>=20
> > The swap buffer blit is just a copy - for example a copy from back=20
buffer to=20
> > front buffer. Since the engine timed out before swap buffer blit it=20
means=20
> > that the commands before it were at fault. Which is puzzling as you=20
point out=20
> > that everything works in 640x480.
>=20
> 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=
=20
> 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=
=20
> 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=
=20
> 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=
=20
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
about:
1) The SWAP ioctl should really report an error to userspace when the engin=
e=20
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=
=20
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=
=20
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=
=20
emulator. glxgears will essentially "lock up".

cu,
Nicolai