On Mon, May 31, 2010 at 09:47:17AM +0200, Michel Dänzer wrote: > On Mon, 2010-05-31 at 09:43 +0200, Michel Dänzer wrote: > > reassign 583653 linux-2.6 2.6.32-13 > > kthxbye > > > > On Sam, 2010-05-29 at 17:33 +0200, Sylvain Beucler wrote: > > > On Sat, May 29, 2010 at 04:21:46PM +0200, Michel Dänzer wrote: > > > > On Sam, 2010-05-29 at 15:02 +0200, Sylvain Beucler wrote: > > > > > On Sat, May 29, 2010 at 01:05:36PM +0200, Michel Dänzer wrote: > > > > > > On Sam, 2010-05-29 at 10:21 +0200, Sylvain Beucler wrote: > > > > > > > > > > > > > > The attached simple test runs at 17FPS in KMS mode on my computer, > > > > > > > against 300FPS in non-KMS mode. > > > > > > > > > > > > Forgot to mention: sysprof or oprofile profiles of slow and fast > > > > > > runs > > > > > > might be interesting, at least if the CPU is pegged during the runs. > > > > > > > > > > Here are 2 sysprof runs: > > > > > - UMS / fast: > > > > > - kernel 11.25% > > > > > - X 77.20% > > > > > - KMS / slow: > > > > > - kernel 90.28% > > > > > - X 5.79% > > > > > > > > Unfortunately, there's no information about where in the kernel the > > > > cycles are burnt. This information should be available with sysprof > > > > 1.1.x and a kernel with the performance counter/event framework. > > > > > > Quite a nice tool: > > > > > > __libc_start_main 0,00% > > > 93,67% > > > _start 0,02% > > > 87,66% > > > In file /usr/bin/Xorg 0,13% > > > 87,64% > > > In file /usr/lib/xorg/modules/libexa.so 0,04% > > > 86,60% > > > In file /usr/lib/xorg/modules/drivers/radeon_drv.so 0,08% > > > 86,48% > > > radeon_bo_open 0,00% > > > 79,87% > > > In file /usr/lib/libdrm_radeon.so.1.0.0 0,00% > > > 79,87% > > > drmCommandWriteRead 0,00% > > > 79,86% > > > __kernel_vsyscall 0,00% > > > 79,86% > > > - - kernel - - 0,00% > > > 79,86% > > > on_each_cpu 36,81% > > > 36,81% > > > __purge_vmap_area_lazy 20,31% > > > 20,31% > > > flush_all_zero_pkmaps 7,84% > > > 7,84% > > > vm_unmap_aliases 1,65% > > > 1,65% > > > > > > What do you think that means? > > > > I think it could confirm my suspicion below, reassigning to the kernel. > > Would be great if you could try if it's better with a 2.6.33 or 2.6.34 > > kernel. > > > > > > > > Anyway, this probably means it's an issue in the kernel, not the X > > > > driver. May be solved already in newer kernels, there have been some AGP > > > > performance improvements which I'm not sure have made it into Debian's > > > > 2.6.32 DRM backport. > > BTW, does booting the kernel with radeon.agpmode=-1 work around the > problem? It'll make things slower in general but it looks like it should > help for this problem, which would further confirm the above.
The test runs at 65FPS with radeon.agpmode=-1 (~3-4x faster than without this option, but ~4-5x slower than without KMS). -- Sylvain -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100606203354.ga2...@perso.beuc.net
