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 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
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: Introduction to `picker' and git link
On Wed, Jul 9, 2008 at 11:05 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Wed, Jul 9, 2008 at 12:07 AM, Michael Stone <[EMAIL PROTECTED]> wrote: >> >> Perhaps you could modify the display so that each track is prominently >> labeled with the full arguments to the process? > > Yes, I'm curious to see the same graph with the process name as well > as the full command. I pushed the fixes to the git tree. In fact cmdline texts already had to be there but I wasn't accounting for the bogus format of /proc/x/cmdline. Here is a new example boot trace (I lost the .picker file I used yesterday): wget http://www.bodhidharma.info/out.grapher.svg This was obtained with $ picker -t120 -f10 (again from sshd's init script) $ grapher -p80 I'm going to rearrange cmdline texts to make them easier to read ;) Thanks, riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Introduction to `picker' and git link
Hi, as part of my intern work on profiling sugar, I've written a little application for gathering system and per process statistic from /proc called. It may reveal itself useful in catching interferences between processes or when profiling cpu/mem usage of long running processes. In fact there are two executables, picker and grapher. For my purposes picker is run on the xo and grapher on a pc to output pretty figures from the statistics blob generated by the first. An example figure can be found at: (it's quite big; better not to open it in a browser) wget http://www.bodhidharma.info/out.grapher.svg This figure shows the xo boot (starting from start() in sshd's init script) and lasts for 120sec (the sampling rate is 10Hz); the figure was generated by only showing the processes with higher cpu-time and that took up to 75% of the total cpu-time taken by all processes running on the xo for the `picking' time. In the future grapher may be extended to show more info, and maybe integrate timed sugar debug logs. Git tree is at: git+ssh://[EMAIL PROTECTED]/git/activities/picker Both executables take the -h option. Questions, hints, requests or bug reports .. I appreciate them all ;) Thanks, riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Project name: Picker is set up
Hi, There was a mistake on assigning the project. Thanks, riccardo On Tue, Jul 8, 2008 at 5:32 PM, Henry Edward Hardy <[EMAIL PROTECTED]> wrote: > Tue, 8 Jul 2008 13:13:42 +0200, "Riccardo Lucchese" > <[EMAIL PROTECTED]> wrote: > > 1. Project name: Picker > > Done. Your tree is here: > git+ssh://[EMAIL PROTECTED]/git/activities/picker > > Please follow instructions here for importing your project: > http://wiki.laptop.org/go/Importing_your_project > > Let us know if you have any problems with your tree. Happy hacking. > > Cheers, > > -- > Henry Edward Hardy > [EMAIL PROTECTED] > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[project account request]
1. Project name :Picker
2. Existing website, if any :
3. One-line description :Lightweight system and processes
statistics (cpu/mem/io) gatherer.
4. Longer description :Gathers system and processes statistics from /proc
:and graphs them to pretty figures.
:
:It is useful to catch interactions
between processes and study
: cpu/mem/io usage of long running processes
5. URLs of similar projects :http://www.bootchart.org/
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URLE-mail
- --
#1 riccardo Riccardo Lucchese
riccardo.lucchese gmail.com
#2
#3
...
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
7. Preferred development model
[ ] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar to
CVS and Subversion users, and that tends to work well for most projects.
[X] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
"main" tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a "discussion" tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the list
we chose to create above
[ ] A separate mailing list, -git, should be created for commit
notifications
[X] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
I'd like being able to create personal git trees
11. Translation
[X] Set up the laptop.org Pootle server to allow translation
commits to be made
[ ] Translation arrangements have already been made at ___
12. Notes/comments:
This project is part of my work as an intern at OLPC.
Thanks,
riccardo
id_rsa.pub
Description: Binary data
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: intern project on profiling sugar
On Fri, Jul 4, 2008 at 11:04 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > On Fri, Jul 04, 2008 at 08:56:34AM +0200, Riccardo Lucchese wrote: >> Hi >> >> I'm riccardo lucchese (rl) and will be an intern at olpc for the >> next ten weeks. My initial proposal for the internship was working >> on profiling sugar. i.e. why is activities startup so long ? ;) > > [...] > >> I was told that some of you have already specifically worked on this; >> that would be great if you could share your gotchas ;) > > http://dev.laptop.org/ticket/5228 > http://dev.laptop.org/ticket/5452 > http://dev.laptop.org/ticket/4349 > http://dev.laptop.org/ticket/7212 yeah, exactly ;) > > Martin > Thanks ! riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
intern project on profiling sugar
Hi I'm riccardo lucchese (rl) and will be an intern at olpc for the next ten weeks. My initial proposal for the internship was working on profiling sugar. i.e. why is activities startup so long ? ;) Right now I'm working on a tool for gathering cpu/mem/io statistics on the xo that produces pretty figures like bootchart does (http://www.bootchart.org/images/bootchart.png); the problem with bootchart was that it is quite heavyweight at decent sampling frequencies. This tool will be used for profiling activities startup and other actions suffering of long delaying. It is almost finished. With the same goal I'm writing a script that extracts perfs timings from data logged by sugar components so that it will be possible to run automated `regression' tests in the future. These tools will be used with other common profiling tools like the embedded python profiler, sysprof and oprofile. I was told that some of you have already specifically worked on this; that would be great if you could share your gotchas ;) I appreciate any hints on features those tools should have and any comments on this work! Thanks ! riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
