Sarvatt | pixman in maverick is muuch faster on arm, I merged that as soon as I could :) | 00:54 |
---|---|---|
=== robclark1 is now known as robclark | ||
kai | hi folks | 08:01 |
=== hrw|gone is now known as hrw | ||
hrw | morning | 08:13 |
kai | is there much of a difference in assembler code between armv5 and the newer systems like the cortex (apart from the stuff the newer systems add)? | 08:16 |
kai | one of my co-workers is fiddling around with low-level kernel calls to get async file io going, and I'm wondering if I should get him an account on a shevaplug (faster, more ram) or on a beagle (newer cpu arch) | 08:17 |
lool | kai: Depends whether he's optimizing for v6 or v7? | 09:00 |
lool | kai: beagle's speed is decent, but I never tried the JTAG; sheeva is really great to JTAG-debug, so it might be relevant for him | 09:01 |
Lutin | lool: if it's a matter of getting things /going/ , v6 vs. v7 shouldn't matter much though | 09:01 |
lool | Lutin: the question is sheeva versus beagle, I agree with you that the described work is likely not architecture specific, but apparently it's about writing some assembler, so it could make a difference | 09:02 |
hrw | Lutin: v5 vs. v7 | 09:03 |
lool | if you want to ship a v7 based product and you dont care that your code works on v5, you might be able to use some v6 or v7 assembly to speed things up | 09:03 |
hrw | sheeva has armv5 | 09:03 |
kai | lool: I don't actually know what's involved | 09:05 |
kai | lool: this is about some really low-level IO stuff in the linux kernel, that's about the point where the explanation turned into chinese | 09:06 |
hrw | kai: sheeva + jtag access then would be easier and faster | 09:06 |
kai | hrw: ok, thanks :) | 09:08 |
hrw | sheeva cpu if much faster in integer then beagleboard | 09:08 |
hrw | and in kernel you can not use vfp or neon so no big speed up would be archived on bb | 09:09 |
hrw | shit. dpkg hang on my dekstop | 09:12 |
amitk | ogra_cmpc: what is the equivalent of qemu-arm-static in debian? | 12:37 |
lool | amitk: qemu-user-static | 12:49 |
amitk | lool: thanks | 12:52 |
lool | mpoirier: Heya | 14:23 |
mpoirier | good day. | 14:23 |
lool | mpoirier: linux-image-omap depends on linux-image-2.6.33-500-omap in maverick | 14:23 |
mpoirier | ? | 14:24 |
lool | mpoirier: Currently, linux outputs linux-image-2.6.35-4-omap | 14:24 |
lool | mpoirier: There are two set of omap kernels in maverick | 14:24 |
lool | mpoirier: One built from linux, and one built from linux-ti-omap | 14:24 |
mpoirier | humm.... | 14:24 |
=== kmargar is now known as markos_ | ||
lool | apt-get install linux-omap or linux-image-omap should do something useful, but is broken right now | 14:24 |
mpoirier | Humm.... | 14:25 |
lool | mpoirier: It's not clear to me whether you'll switch to a separate branch + source package for omap4 support, or whether it will still be linux source package? | 14:25 |
mpoirier | it is still undecided. | 14:25 |
lool | Humm.... | 14:26 |
mpoirier | according to the trail of email in my inbox over the last couple of days | 14:26 |
lool | mpoirier: Is there any benefit for OMAP3 in running the OMAP branch from TI? | 14:26 |
lool | If you get a single binary kernel to work on OMAP3 + OMAP4 from the TI branch and it's strictly better than the mainline one, then I think the path is clear | 14:27 |
mpoirier | indeed. | 14:27 |
mpoirier | mainline should follow quickly though... | 14:28 |
amitk | lool: omap4 support will come out of separate source tree (it resides as a branch in the maverick kernel) | 14:29 |
amitk | tim added it yesterday | 14:29 |
lool | amitk: Yes, understood this bit; was it decided to use a single kernel for OMAP4 and OMAP3? and is there any regression for OMAP3 from mainline to the TI branch? | 14:31 |
amitk | lool: there is not benefit is running omap3 with TI's code since TI's code is not upstream and hence will get refactored quite a bit before it all makes it to upstream. | 14:31 |
amitk | also, last I looked, TI's tree breaks OMAP3 | 14:31 |
lool | Ok | 14:31 |
ogra | lool, bug 595949 | 14:52 |
ubot2 | Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) (and 1 other project) "linux-meta-ti-omap depends on the wrong binary kernel in maverick (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/595949 | 14:52 |
lool | ogra: Thanks; I didn't know whether linux-meta was also concerned or not | 15:00 |
hrw | http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ - new structure, new versions | 15:34 |
=== bjf[afk] is now known as bjf | ||
=== hrw is now known as hrw|gone | ||
sebjan | ogra: I just filed the bug 596004 regarding the UNE UI issue on Maverick | 17:32 |
ubot2 | Launchpad bug 596004 in netbook-meta (Ubuntu) "with 2D UI (une-efl) selected, the gnome desktop toolbar is also visible and seems to be running (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/596004 | 17:32 |
ogra_cmpc | sebjan, great, thanks, i'll take care of it | 17:38 |
lool | Wow, my beagle has a /dev/ramzswap0 for some reason | 17:42 |
lool | is compcache enabled on installed system as well? i thought it was an install only thing | 17:42 |
markos_ | lool: hi, I have some initial results on the hardfp/softfp performance | 17:47 |
markos_ | tested on the iMX515 with karmic (ubuntu original vs my compiled with hardfp) | 17:47 |
markos_ | I tested glxgears to see how it would affect fp performance (using fbdev X, no 2d/3D accel) | 17:48 |
markos_ | so softfp gave me ~120 fps, while hardfp gives me 146 fps | 17:48 |
markos_ | I know glxgears is not a proper 3D benchmark, but I'm not interested in 3D, rather fpu performance | 17:49 |
markos_ | so... | 17:49 |
markos_ | that's ~21% speed increase, dunno if it can be more, but it looks logical | 17:49 |
markos_ | I'll post this asap with more info | 17:50 |
lool | markos_: markos_ That's interesting, thanks | 18:03 |
lool | markos_: what about the archive, did you manage to setup a source one? | 18:03 |
markos_ | yeah it includes sources in the same url | 18:04 |
markos_ | most of them at least | 18:04 |
markos_ | I probably forgot to include sources for packages I built manually -not needing patching, just cyclic dependency probs,e tc | 18:05 |
lool | markos_: http://freevec.org/repository/dists/karmic/main/ has no source index? | 18:09 |
=== sbambrough is now known as sbambrough-lunch | ||
markos_ | strange, I did reprepro includedsc | 18:12 |
markos_ | lol | 18:12 |
markos_ | that was on my local server, I have to rsync it | 18:12 |
markos_ | sorry bout that :) | 18:12 |
markos_ | I'll let you know when the rsync is over | 18:13 |
lool | markos_: thanks a lot | 18:16 |
lool | markos_: I'm away next week though, so I'll probably mirror the week afterwards | 18:17 |
markos_ | i don't think it's going anywhere | 18:18 |
markos_ | I mean I have no plans to move or remove it | 18:18 |
markos_ | so... | 18:18 |
lool | Ok thanks | 18:19 |
markos_ | the past days I've been working on setting up wanna-build... | 18:23 |
markos_ | I have to say the documentation is *crap* | 18:23 |
markos_ | I still haven't managed to even setup the db | 18:23 |
markos_ | anyway, dinner time, later | 18:23 |
=== sbambrough-lunch is now known as sbambrough | ||
=== JaMae is now known as JaMa | ||
GrueMaster | ogra: ping. Do you know when jasper will be in the repo? | 19:40 |
lool | markos_: An alternate wanna-build is being developed IIRC | 21:05 |
lool | markos_: pkern was doing a python rewrite as a gsoc I thnk | 21:05 |
lool | markos_: The documentation for the current version is the source I'm afraid | 21:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!