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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100606203354.GA2641@perso.beuc.net">http://lists.debian.org/20100606203354.GA2641@perso.beuc.net

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.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).

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100613092917.GA3533@perso.beuc.net">http://lists.debian.org/20100613092917.GA3533@perso.beuc.net

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111123130558.GA6497@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111123130558.GA6497@elie.hsd1.il.comcast.net

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120316233425.GA32485@burratino">http://lists.debian.org/20120316233425.GA32485@burratino