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-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
