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: > >> > >> 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? 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? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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!" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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!" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 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. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
On Sun, 2008-09-28 at 15:03 +0200, Marco Pesenti Gritti wrote: > > - joyride regressed sensibly at rendering with cairo since 703 > > I have cairo 1.8 rpms compiled for joyride for some other reason. > Perhaps the regression is in X, but still I think it might be worth to > give them a try: > > http://dev.laptop.org/~marco/cairo-1.8.0-1.fc9.i386.rpm > http://dev.laptop.org/~marco/pixman-0.12.0-1.fc9.i386.rpm > same timings with the newer packages :/ Sysprof profile: - pixbuf http://dev.laptop.org/~rlucchese/test_rendering/pixbuf.sysprof http://dev.laptop.org/~rlucchese/test_rendering/pixbuf.sysprof.00.png http://dev.laptop.org/~rlucchese/test_rendering/pixbuf.sysprof.01.png - image surface http://dev.laptop.org/~rlucchese/test_rendering/imagesurface.sysprof - xlib surface http://dev.laptop.org/~rlucchese/test_rendering/xlibsurface.sysprof cpu usage during the tests shown by top: (build 2489, amd driver) - pixbuf: cpu: ~80% X, ~16% test_gtkimage - cairo image surface: cpu: ~52% test_gtkimage, ~45% X - cairo xlib surface: cpu: ~84% test_gtkimage, ~12% X I'll rewrite the test in C, I'm curious to see what would be the new timings. riccardo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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!" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
On Sun, 2008-09-28 at 15:33 +0200, Benjamin Berg wrote: > Hello, > > On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: > > Besides this, I think the icon caching mechanism should be reworked: > > right now every icon has its own surfaces-cache and its svgloader. So > > that, if I'm not wrong, two icons showing the same svg (with same size, > > colors etc..) cache two distinct but identical surfaces in their > > _iconbuffer and cache two times the raw svg file contents in their > > svgloader. > > The cached surface is shared between different icons (the icon buffer is > not shared). _surface_cache is a class variable, so that only one LRU > list for the surfaces is created. mm yeah, sorry, totally misread the code :/ riccardo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
Benjamin Berg wrote: >> Oh, why can't we just use the gtk icon cache with the rendered pixmaps? > > The thing is that the GTK+ icon cache are just prerendered icons > (created with a standalone application). In Sugar however, we need a > more complicated mechanism as the colour of the icons is changed on the > fly. One would probably need to implement a custom icon cache, that > prerenders the most often needed colour combinations. I wonder if we could extend gtk-update-icon-cache to pre-render also our svg icons, keyed by the stroke/fill color pair, or maybe just limited to the neutral (gray) icons. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
On Sun, 2008-09-28 at 18:35 +0200, Bernie Innocenti wrote: > Benjamin Berg wrote: > > A shared cache would be great. One way to do it would be to share a > > mmap'able file similar to the GTK+ icon cache file. But to create this > > file, one will need to know the icon colors that should be prerendered. > > > > More complicated would be to create a small service that uploads > > rendered icons to the X server, and hands back the pixmap ID. That way > > all applications could use one shared server side cache. > > (The pixmap based sapwood GTK+ engine, used on the Nokia 770/8x0 > > devices, does this to save memory.) > > We discussed this approach in Brno. I'm glad to hear it's feasible. > > Oh, why can't we just use the gtk icon cache with the rendered pixmaps? The thing is that the GTK+ icon cache are just prerendered icons (created with a standalone application). In Sugar however, we need a more complicated mechanism as the colour of the icons is changed on the fly. One would probably need to implement a custom icon cache, that prerenders the most often needed colour combinations. Benjamin signature.asc Description: This is a digitally signed message part ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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!" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
Benjamin Berg wrote: > On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: >> Besides this, I think the icon caching mechanism should be reworked: >> right now every icon has its own surfaces-cache and its svgloader. So >> that, if I'm not wrong, two icons showing the same svg (with same size, >> colors etc..) cache two distinct but identical surfaces in their >> _iconbuffer and cache two times the raw svg file contents in their >> svgloader. > > The cached surface is shared between different icons (the icon buffer is > not shared). _surface_cache is a class variable, so that only one LRU > list for the surfaces is created. That was my impression too. On the train from Brno to Prague, me and Tomeu made some quick & dirty performance measurements on that code. IIRC, on startup we render something like 30 svg icons, and blit them to screen around 60 times after the home view is fully rendered. Switching views does not cause too much rendering too. While I might have a fuzzy memory for the exact numbers, I'm damn sure my conclusion was that there wasn't much to be gained by optimizing icon rendering. There were, however, a couple of icons with too many vertexes. These would take 10x the time of other average icons to render. One of these was the Tortoise icon, perhaps Tomeu remembers the other one. >> I guess best would be switching to have only one global cache (or >> not ? ;); perhaps a global cache clashes with using server side >> surfaces ? (see benzea's patches) > > A shared cache would be great. One way to do it would be to share a > mmap'able file similar to the GTK+ icon cache file. But to create this > file, one will need to know the icon colors that should be prerendered. > > More complicated would be to create a small service that uploads > rendered icons to the X server, and hands back the pixmap ID. That way > all applications could use one shared server side cache. > (The pixmap based sapwood GTK+ engine, used on the Nokia 770/8x0 > devices, does this to save memory.) We discussed this approach in Brno. I'm glad to hear it's feasible. Oh, why can't we just use the gtk icon cache with the rendered pixmaps? -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
Hello, On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: > Besides this, I think the icon caching mechanism should be reworked: > right now every icon has its own surfaces-cache and its svgloader. So > that, if I'm not wrong, two icons showing the same svg (with same size, > colors etc..) cache two distinct but identical surfaces in their > _iconbuffer and cache two times the raw svg file contents in their > svgloader. The cached surface is shared between different icons (the icon buffer is not shared). _surface_cache is a class variable, so that only one LRU list for the surfaces is created. > I guess best would be switching to have only one global cache (or > not ? ;); perhaps a global cache clashes with using server side > surfaces ? (see benzea's patches) A shared cache would be great. One way to do it would be to share a mmap'able file similar to the GTK+ icon cache file. But to create this file, one will need to know the icon colors that should be prerendered. More complicated would be to create a small service that uploads rendered icons to the X server, and hands back the pixmap ID. That way all applications could use one shared server side cache. (The pixmap based sapwood GTK+ engine, used on the Nokia 770/8x0 devices, does this to save memory.) Benjamin signature.asc Description: This is a digitally signed message part ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
Hi Riccardo, this is awesome, thanks a lot for taking the time to do it. > - joyride regressed sensibly at rendering with cairo since 703 I have cairo 1.8 rpms compiled for joyride for some other reason. Perhaps the regression is in X, but still I think it might be worth to give them a try: http://dev.laptop.org/~marco/cairo-1.8.0-1.fc9.i386.rpm http://dev.laptop.org/~marco/pixman-0.12.0-1.fc9.i386.rpm > - rendering pixbufs is extremely slow on the xo We are not using pixbufs a lot in Sugar I think (right?). Perhaps better to focus on cairo surfaces. > - server side surfaces are awesome ;) > > > Besides this, I think the icon caching mechanism should be reworked: > right now every icon has its own surfaces-cache and its svgloader. So > that, if I'm not wrong, two icons showing the same svg (with same size, > colors etc..) cache two distinct but identical surfaces in their > _iconbuffer and cache two times the raw svg file contents in their > svgloader. > > I guess best would be switching to have only one global cache (or > not ? ;); perhaps a global cache clashes with using server side > surfaces ? (see benzea's patches) Are you able to make sugar meeting this week? We could start discussing a new design for the cache there. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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 > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
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 Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] rendering test
Hi, I'm working on icon rendering perf (well, since yesterday as I had no free time the latest weeks) and have some interesting results inspired by benzea's suggestion of using server side surfaces for cairo. (see http://dev.laptop.org/attachment/ticket/8000/serverside-pixmap.patch http://dev.laptop.org/attachment/ticket/8000/serverside-pixmap.2.patch) The following results are timings for a simple python script drawing lots of GtkImage widget's on a full-screen window on the xo. (like in http://dev.laptop.org/~rlucchese/test_rendering/test_gtkimage.png) * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s - cairo image surface: 49.68s 48.87s 48.79s 49.83s 49.41s - cairo xlib surface: 18.46s 18.05s 17.84s 17.84s 18.15s * 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 - cairo image surface: 62.40s 61.56s 61.15s 61.71s 61.55s - cairo xlib surface: 20.02s 20.30s 19.92s 20.79s 20.05s * 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 ;) Besides this, I think the icon caching mechanism should be reworked: right now every icon has its own surfaces-cache and its svgloader. So that, if I'm not wrong, two icons showing the same svg (with same size, colors etc..) cache two distinct but identical surfaces in their _iconbuffer and cache two times the raw svg file contents in their svgloader. I guess best would be switching to have only one global cache (or not ? ;); perhaps a global cache clashes with using server side surfaces ? (see benzea's patches) riccardo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
