Bug#583653: xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations
Jonathan Nieder wrote: Sylvain Beucler wrote: On Sun, Jun 06, 2010 at 10:33:54PM +0200, Sylvain Beucler wrote: The test runs at 65FPS with radeon.agpmode=-1 (~3-4x faster than without this option, but ~4-5x slower than without KMS). On 2.6.34-1-686 (from experimental) the test runs at 150 FPS. It's better though still 2x slower. Hm, how do 3.1.y kernels do? Ping? If you don't have access to this hardware or no longer are interested in pursuing this, that's fine, but please do let us know so we can plan accordingly. Thanks, Jonathan -- 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/20120316233425.GA32485@burratino
Bug#583653: xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations
Sylvain Beucler wrote: On Sun, Jun 06, 2010 at 10:33:54PM +0200, Sylvain Beucler wrote: The test runs at 65FPS with radeon.agpmode=-1 (~3-4x faster than without this option, but ~4-5x slower than without KMS). On 2.6.34-1-686 (from experimental) the test runs at 150 FPS. It's better though still 2x slower. Hm, how do 3.1.y kernels do? If the speed regression persists, we should take this upstream (http://bugs.freedesktop.org). -- 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/2023130558.ga6...@elie.hsd1.il.comcast.net
Bug#583653: xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations
On Sun, Jun 06, 2010 at 10:33:54PM +0200, Sylvain Beucler wrote: 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.so0,08% 86,48% radeon_bo_open 0,00% 79,87% In file /usr/lib/libdrm_radeon.so.1.0.00,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_lazy20,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). On 2.6.34-1-686 (from experimental) the test runs at 150 FPS. It's better though still 2x slower. -- 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/20100613092917.ga3...@perso.beuc.net
Bug#583653: xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations
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.so0,08% 86,48% radeon_bo_open 0,00% 79,87% In file /usr/lib/libdrm_radeon.so.1.0.00,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_lazy20,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
Processed: Re: Bug#583653: xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations
Processing commands for cont...@bugs.debian.org: reassign 583653 linux-2.6 2.6.32-13 Bug #583653 [xserver-xorg-video-radeon] xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations Bug reassigned from package 'xserver-xorg-video-radeon' to 'linux-2.6'. Bug No longer marked as found in versions xserver-xorg-video-ati/1:6.13.0-2. Bug #583653 [linux-2.6] xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations There is no source info for the package 'linux-2.6' at version '2.6.32-13' with architecture '' Unable to make a source version for version '2.6.32-13' Bug Marked as found in versions 2.6.32-13. kthxbye Stopping processing here. Please contact me if you need assistance. -- 583653: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583653 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.127530750718890.transcr...@bugs.debian.org
