Re: [sugar] rendering test
Michel Dänzer wrote: As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? ShmPutImage is still accelerated though (also, that commit is only in 1.5, not 1.4). What kind of cleanup do you have in mind? Remove the unused PutImage hook from the ShmFuncs structure. Also maybe move the whole structure definition in the xserver as it doesn't seem like something that belongs to the public xextproto interface. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
Michel Dänzer wrote: On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. I was remembering the code. As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option ShadowFB off, at least assuming the amd driver provides other desirable features the fbdev driver can't provide. Riccardo, could you try that? -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
On Tue, 2008-09-30 at 21:30 +0200, Bernie Innocenti wrote: Michel Dänzer wrote: On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. I was remembering the code. As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option ShadowFB off, at least assuming the amd driver provides other desirable features the fbdev driver can't provide. Riccardo, could you try that? weird, testing with the ShadowFb option off slightly speeds up the test ;P avg time on 5 tries: ~57.5s (it was 62.83s) riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. excessive migration of pixmaps to the framebuffer, and so on. Migration overhead is indeed often the cause of EXA performance issues. Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option ShadowFB off, at least assuming the amd driver provides other desirable features the fbdev driver can't provide. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rendering test
On 28/09/08 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: Ooops. cc'ing to some other people/list in the hope someone more knowledgeable than me will comment. Thanks. Please Cc me on posts like these to make sure I don't miss them. No, it doesn't bother me to receive 0.001% more mail. I've also Cc'd the Xorg list in case someone can give us more insight. On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? Was fbdev running with EXA or XAA? (does fbdev even support EXA?) My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), excessive migration of pixmaps to the framebuffer, and so on. X 1.5 was supposed to have a much better EXA, at least judging from the stream of patches landed on the tree. Indeed - migration is probably what is hurting us the most here. We would probably have to do a more in-depth analysis of what is actually happening in the engine, but the general rule of thumb is that it is very very very very very bad to read from the video memory. Jordan (Did I mention it was bad?) -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
On Mon, 2008-09-29 at 09:08 -0600, Jordan Crouse wrote: On 28/09/08 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: Ooops. cc'ing to some other people/list in the hope someone more knowledgeable than me will comment. Thanks. Please Cc me on posts like these to make sure I don't miss them. No, it doesn't bother me to receive 0.001% more mail. I've also Cc'd the Xorg list in case someone can give us more insight. On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? Was fbdev running with EXA or XAA? (does fbdev even support EXA?) My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), excessive migration of pixmaps to the framebuffer, and so on. X 1.5 was supposed to have a much better EXA, at least judging from the stream of patches landed on the tree. Indeed - migration is probably what is hurting us the most here. We would probably have to do a more in-depth analysis of what is actually happening in the engine, but the general rule of thumb is that it is very very very very very bad to read from the video memory. Timings with X 1.5 (I picked up the most recent package I could find on koji for fc9) don't change at all. riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
Ooops. cc'ing to some other people/list in the hope someone more knowledgeable than me will comment. Thanks, Tomeu On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
Tomeu Vizoso wrote: Ooops. cc'ing to some other people/list in the hope someone more knowledgeable than me will comment. Thanks. Please Cc me on posts like these to make sure I don't miss them. No, it doesn't bother me to receive 0.001% more mail. I've also Cc'd the Xorg list in case someone can give us more insight. On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? Was fbdev running with EXA or XAA? (does fbdev even support EXA?) My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), excessive migration of pixmaps to the framebuffer, and so on. X 1.5 was supposed to have a much better EXA, at least judging from the stream of patches landed on the tree. I'd be very interested in seeing the output of oprofile while running your benchmark on X 1.4 and X 1.5. Please, remember to install the debuginfo packages for the X server, libcairo, and the geode driver. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? Was fbdev running with EXA or XAA? (does fbdev even support EXA?) http://www.x.org/wiki/ExaStatus lists fbdev in the `Probably unsuitable for EXA support' section; so, I guess XAA. My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), excessive migration of pixmaps to the framebuffer, and so on. X 1.5 was supposed to have a much better EXA, at least judging from the stream of patches landed on the tree. I'd be very interested in seeing the output of oprofile while running your benchmark on X 1.4 and X 1.5. Please, remember to install the debuginfo packages for the X server, libcairo, and the geode driver. I haven't tried to run oprofile on the xo yet (it is on my todo list). If I remember well, ExaDoMoveOutPixmap (or a function with a similar name) and memcpy were always on top of sysprof profiles in rendering tests. riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
Riccardo Lucchese wrote: Was fbdev running with EXA or XAA? (does fbdev even support EXA?) http://www.x.org/wiki/ExaStatus lists fbdev in the `Probably unsuitable for EXA support' section; so, I guess XAA. Confirmed: there's absolutely no EXA code in xf86-video-fbdev. Too bad, it would have been perfect to measure the relative overhead of going through the EXA fallbacks. My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), excessive migration of pixmaps to the framebuffer, and so on. X 1.5 was supposed to have a much better EXA, at least judging from the stream of patches landed on the tree. I'd be very interested in seeing the output of oprofile while running your benchmark on X 1.4 and X 1.5. Please, remember to install the debuginfo packages for the X server, libcairo, and the geode driver. I haven't tried to run oprofile on the xo yet (it is on my todo list). Be careful, there's a catch with jffs2: it does not support the writable shared mmap that oprofiled needs. This leads to a confusing situation where you get an empty report file without any error given. Refer to this (possibly outdated) documentation for an easy workaround: http://wiki.laptop.org/go/Oprofile_setup If I remember well, ExaDoMoveOutPixmap (or a function with a similar name) and memcpy were always on top of sysprof profiles in rendering tests. One advantage of repeating the profile now would be comparing the absolute times between different X servers and Fedora runtimes. Also, leaf functions tell us very little. memcpy() might be called from many different places to do different things. oprofile also supports stack traces, but for some reason I could never get them to work on the XO. One clue is that oprofile cannot use the NMI interrupt on the XO and falls back to using a software timer instead. Perhaps the stack tracing code doesn't like that. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
On Sun, Sep 28, 2008 at 8:57 PM, Bernie Innocenti [EMAIL PROTECTED] wrote: Riccardo Lucchese wrote: I haven't tried to run oprofile on the xo yet (it is on my todo list). Be careful, there's a catch with jffs2: it does not support the writable shared mmap that oprofiled needs. This leads to a confusing situation where you get an empty report file without any error given. Refer to this (possibly outdated) documentation for an easy workaround: http://wiki.laptop.org/go/Oprofile_setup If I remember well, ExaDoMoveOutPixmap (or a function with a similar name) and memcpy were always on top of sysprof profiles in rendering tests. One advantage of repeating the profile now would be comparing the absolute times between different X servers and Fedora runtimes. Also, leaf functions tell us very little. memcpy() might be called from many different places to do different things. oprofile also supports stack traces, but for some reason I could never get them to work on the XO. One clue is that oprofile cannot use the NMI interrupt on the XO and falls back to using a software timer instead. Perhaps the stack tracing code doesn't like that. In that case, maybe sysprof is just enough (and much easier to set up). Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
