2009/7/28 Michel Dänzer <daen...@debian.org>: > On Tue, 2009-07-28 at 02:49 +0200, Michal Suchanek wrote: >> On 28/07/2009, Michel Dänzer <daen...@debian.org> wrote: >> > On Tue, 2009-07-28 at 00:16 +0200, Michal Suchanek wrote: >> > > On 27/07/2009, Michel Dänzer <daen...@debian.org> wrote: >> > > > On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: >> > > > > 2009/7/27 Michel Dänzer <daen...@debian.org>: >> > > > > >> > > > > > >> > > > > > Please provide the full output of >> > > > > > >> > > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 >> > > > > > >> > > > > > for both cases. >> > > > > > >> > > > > > For now assuming it's a 3D driver issue, reassigning. >> > > > > > >> > > > > >> > > > > Attaching output of glxinfo. >> > > > >> > > > >> > > > Thanks. I don't see anything wrong. How do the framerate and CPU usage >> > > > compare when running >> > > > >> > > > /usr/lib/xscreensaver/hypertorus -delay 0 -fps >> > > > >> > > > ? >> > > >> > > With DRI fps is pretty much constant around 8.0 >> > >> > >> > Hmm, that's pretty low, I'm getting around 40 fps on an RV350. >> >> It's no wonder it is slow. Even rendering by a Celeron CPU is at times >> faster than what my GPU shows. > > That's weird though, your GPU should be at least about as fast as mine. > > >> > > > BTW, you can force the swrast driver by setting the environment >> > variable >> > > > LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. >> > > > >> > > >> > > With this option fps ranges from 7.5 to 12 depending on object view >> > angle. >> > > >> > > These are values in fullscreen and no delay. Both cause 100% system >> > > load but the DRI one causes system load and the software one causes >> > > user load. >> > >> > >> > It might be interesting to find out where the CPU time is spent with >> > hardware acceleration. >> > >> >> It might be another unrelated DRI problem because in >> xscreeensaver-demo the CPU is almost unused and the animation is still >> slow. It's actually quite interesting, though. Turning on the fps >> display makes the system time go almost 100% even in the demo. > > That may be because the 3D driver doesn't accelerate glBitmap(), so the > FPS text is rendered in software. > >> I wonder how I could find where the time is spent. If it is system >> time it is spent in kernel, right? > > E.g. oprofile can profile the kernel as well if it has access to the > uncompressed vmlinux binary.
Which is not packaged by Debian nor is there a tool for extracting it from the compressed one. The majority of time is spent in: (with -fps) 181333 53.6798 radeon.ko radeon.ko radeon_do_wait_for_idle (without -fps) 287349 59.3526 radeon.ko radeon.ko radeon_freelist_get Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org