| 00:00.57 | *** join/#maemo atk (~Arch-TK@ircpuzzles/staff/Arch-TK) |
| 00:47.54 | *** join/#maemo Natch (~Natch@h-155-122.A444.priv.bahnhof.se) |
| 01:04.50 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 06:10.07 | *** join/#maemo FalconSpy (~falconspy@ip72-208-230-47.ph.ph.cox.net) |
| 06:10.07 | *** join/#maemo FalconSpy (~falconspy@unaffiliated/falconspy) |
| 07:09.10 | *** join/#maemo spiiroin (~spiiroin@2001:998:2a:dead:dd6d:d8b5:9c46:1744) |
| 07:13.54 | *** join/#maemo Marshall_Banana (~Marshall_@dslb-178-010-082-024.178.010.pools.vodafone-ip.de) |
| 07:20.25 | *** join/#maemo herekun (~herekun@164.132.132.199) |
| 07:31.27 | drathir | DocScrutinizer05: if i may ask n900 what type of simlock have? |
| 07:44.14 | *** join/#maemo Kabouik (~kabouik@236.34.200.37.customer.cdi.no) |
| 07:54.59 | bencoh | it usually comes sim-unlocked |
| 07:56.42 | KotCzarny | and since it has bb5 modem, all rules apply |
| 08:04.59 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 08:38.37 | *** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-vxgicvpsoxpdzgxb) |
| 08:41.28 | *** join/#maemo Smily (~SmilzOrg@ip5f5bf6e4.dynamic.kabel-deutschland.de) |
| 09:04.19 | *** join/#maemo ketas (~ketas@0011-0000-0000-0000-35dc-8408-07d0-2001.dyn.estpak.ee) |
| 09:08.05 | *** join/#maemo jskarvad (~jskarvad@ip4-83-240-32-61.cust.nbox.cz) |
| 09:08.06 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 09:21.24 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 09:39.04 | *** join/#maemo eijk_ (~eijk@p200300454A12D90085A3F8EA5B0DB802.dip0.t-ipconnect.de) |
| 09:40.09 | *** join/#maemo Kilroo (~Kilroo@cpe-71-71-97-50.triad.res.rr.com) |
| 09:48.49 | *** join/#maemo cyteen (~cyteen@230.178.93.209.dyn.plus.net) |
| 10:14.03 | *** join/#maemo cyteen (~cyteen@230.178.93.209.dyn.plus.net) |
| 10:28.37 | *** join/#maemo eMHa (~mh@p54B0F9BC.dip0.t-ipconnect.de) |
| 10:36.07 | *** join/#maemo pigeon (~pigeon@124.171.55.143) |
| 10:44.06 | *** join/#maemo cyteen (~cyteen@230.178.93.209.dyn.plus.net) |
| 10:53.26 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 11:21.01 | *** join/#maemo Wikiwide (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 11:22.31 | Wikiwide | Why does my N900 have camera's videos mixed with all other films in Media Player, and not placed into category of "Recorded by device camera"? |
| 11:39.15 | *** join/#maemo eMHa (~mh@81.26.162.98) |
| 12:00.49 | *** part/#maemo Wikiwide (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 12:52.12 | *** join/#maemo pigeon (~pigeon@ppp121-44-93-71.bras1.syd7.internode.on.net) |
| 12:52.30 | *** join/#maemo eijk (~eijk@p200300454A12D900384E0EE1BB59482A.dip0.t-ipconnect.de) |
| 13:03.02 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 13:19.50 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 13:31.07 | DocScrutinizer05 | I think because it doesn't filter subgroups out form "all" group |
| 13:31.45 | DocScrutinizer05 | beauty of fracker err tracker |
| 13:32.14 | DocScrutinizer05 | the tracker concept is broken by design, in my book |
| 13:46.39 | *** join/#maemo geaaru (~geaaru@host107-223-dynamic.250-95-r.retail.telecomitalia.it) |
| 13:53.32 | *** join/#maemo mkz (~mkz@i.try.to.use.offensive.vhosts.and.that.is.not.allowed.org) |
| 13:54.41 | mkz | is it ok if I mirror http://repository.maemo.org/ ? |
| 13:54.46 | mkz | that is, recursive wget or rsync |
| 13:55.04 | mkz | don't want to be that guy which hogs bandwidth without permission |
| 13:56.57 | bencoh | if anything, you should probably use apt-mirror |
| 13:57.03 | bencoh | (or something close to it) |
| 13:58.10 | bencoh | first sync will take ages, but then on it should be fine |
| 14:01.18 | DocScrutinizer05 | generally it's ok to mirror repos and whatever you like |
| 14:01.34 | DocScrutinizer05 | but listen to advice regarding best way to do so |
| 14:13.26 | *** join/#maemo ketas- (~ketas@73-212-191-90.dyn.estpak.ee) |
| 14:16.53 | *** join/#maemo spiiroin (~spiiroin@178-55-119-17.bb.dnainternet.fi) |
| 14:18.10 | Wizzup | new cssu in cssu testing it seems, cool. can't upgrade to it due some conflict with curl though (on cssu thumb) |
| 14:54.15 | enyc | Wizzup: hrrm somebody else whad some crazy dependency mess too |
| 14:54.35 | enyc | 15:23 * DocScrutinizer05 feels massive headache http://paste.opensuse.org/86359988 - prolly getting too old for such shit |
| 14:55.54 | enyc | ok maye that wasn't the rpoblem |
| 15:04.50 | Wizzup | enyc: I think there needs to be a new curl build for thumb |
| 15:04.55 | Wizzup | so it might just take a bit more time |
| 15:14.16 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 15:22.33 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 15:34.43 | *** join/#maemo vectis3 (~user@88-145-67-14.host.pobb.as13285.net) |
| 15:45.30 | *** join/#maemo auenf (~David@120.154.64.171) |
| 15:48.33 | *** join/#maemo Kabouik (~kabouik@236.34.200.37.customer.cdi.no) |
| 15:53.37 | *** join/#maemo KotCzarny (ariel@31.135.195.151) |
| 16:35.29 | *** join/#maemo Vajb (~Vajb@85-76-163-6-nat.elisa-mobile.fi) |
| 16:36.33 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:04.23 | *** join/#maemo herekun (~herekun@kibergod.static.corbina.ru) |
| 17:08.51 | *** join/#maemo ketar (~herekun@164.132.132.199) |
| 17:10.49 | *** join/#maemo ketar (~herekun@164.132.132.199) |
| 17:15.54 | *** join/#maemo pagurus (~user@i59F7A742.versanet.de) |
| 17:32.02 | *** join/#maemo herekun (~herekun@164.132.132.199) |
| 17:54.57 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 19:13.11 | *** join/#maemo pigeon (~pigeon@ppp121-44-93-71.bras1.syd7.internode.on.net) |
| 19:22.27 | *** join/#maemo freemangordon (~ivo@46.249.74.23) |
| 19:28.03 | *** join/#maemo eMHa (~mh@p54B0F467.dip0.t-ipconnect.de) |
| 19:43.42 | *** join/#maemo Natch (~Natch@h-155-122.A444.priv.bahnhof.se) |
| 19:48.21 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 20:05.58 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 20:17.39 | *** join/#maemo Kabouik_ (~kabouik@ks3100825.kimsufi.com) |
| 20:49.02 | *** join/#maemo Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 21:02.38 | CatButts | hey DocScrutinizer05 |
| 21:03.10 | CatButts | you mentioned softfloat is not 'that' much slower than hardfloat |
| 21:03.33 | CatButts | how would it hold against something like DSP |
| 21:04.34 | CatButts | say, a multichannel softsynth |
| 21:04.58 | DocScrutinizer05 | CatButts: softFP uses whatever available, DSP or arithmetic coprocessor or even software implementation of float math |
| 21:05.37 | DocScrutinizer05 | softfp is hardfp wrapped into a library call ABI |
| 21:05.52 | DocScrutinizer05 | if the platform has a hw accel for FP |
| 21:06.13 | DocScrutinizer05 | so your question doesn't make much sense to me |
| 21:06.18 | CatButts | so it still ends up in hardware, but there is a capability check at runtime? |
| 21:06.32 | DocScrutinizer05 | not at runtime, at compile time |
| 21:07.38 | DocScrutinizer05 | at least for maemo, that's not done at runtime afaik |
| 21:08.08 | CatButts | so on the n900, I still benefit from hardware floats? |
| 21:08.15 | DocScrutinizer05 | softfp is a library, the implementation of that library may differ with target platform, the API stays the same |
| 21:08.23 | CatButts | ah, I see meow |
| 21:08.24 | DocScrutinizer05 | yes |
| 21:09.01 | DocScrutinizer05 | hardfp directly calls the float hw from your code, without any library in between |
| 21:09.25 | DocScrutinizer05 | (simplified picture) |
| 21:09.57 | CatButts | I initially thought that softfp meant software emulated float calculations |
| 21:10.01 | CatButts | strictly |
| 21:10.02 | DocScrutinizer05 | the overhead of softfp over hardfp is basically the library wrapper code, for maemo |
| 21:10.05 | CatButts | not a lib call |
| 21:10.15 | DocScrutinizer05 | afaik |
| 21:10.47 | CatButts | now it's clear in my head |
| 21:11.15 | DocScrutinizer05 | or let me put it that way: your maemo osftfp library is built using hardfp code |
| 21:11.28 | DocScrutinizer05 | softfp* |
| 21:12.56 | freemangordon | guys, it is not like that |
| 21:13.04 | freemangordon | it is about the calling convention |
| 21:13.30 | freemangordon | softfp means float args are passed through int registers |
| 21:13.52 | freemangordon | hardfp means float args are passed through FP registers |
| 21:13.55 | DocScrutinizer05 | yes, you call a copoc directly with parameters in coproc registers, for hardfp. You call a library with parameters on stack or whatever, for softfp |
| 21:14.38 | freemangordon | no, you call a library (or a local function) both ways |
| 21:15.16 | DocScrutinizer05 | https://wiki.debian.org/ArmHardFloatPort/VfpComparison |
| 21:15.20 | freemangordon | just that function parameters are put in CPU for softfp or FPU for hardfp registers |
| 21:15.55 | freemangordon | with softfp you can emulate FP in software |
| 21:16.12 | freemangordon | but you can use HW FPU if it is available as well |
| 21:16.22 | DocScrutinizer05 | "soft" vs "softfp" vs "hard" |
| 21:16.49 | freemangordon | DocScrutinizer05: remember how was 8087 emulated? |
| 21:16.54 | freemangordon | back then |
| 21:17.25 | DocScrutinizer05 | wasn't that softirq |
| 21:17.40 | DocScrutinizer05 | software interrupt |
| 21:18.27 | freemangordon | no, it was generatin "illegal instruction" interrupt, whatever it was called :) |
| 21:18.49 | freemangordon | that irq was handled by FPU emulation lib |
| 21:18.51 | DocScrutinizer05 | hmm, pretty much a sowtware interrupt |
| 21:19.21 | DocScrutinizer05 | an instruction causing an interupt |
| 21:20.01 | freemangordon | however, soft(fp) vs hardfp in terms of cortex a8 is just about where FP parameters are passed |
| 21:20.13 | DocScrutinizer05 | :-) |
| 21:20.35 | DocScrutinizer05 | so not as huge a difference as the uneduicated user might expect |
| 21:20.43 | freemangordon | well, it was a prefix at a start of every FPU instruction, 0x0F or somesuch |
| 21:21.08 | freemangordon | there is a huge diff for FPU intense function calls |
| 21:21.24 | freemangordon | some 20% iirc |
| 21:21.35 | freemangordon | but no difference for most of the system |
| 21:21.47 | DocScrutinizer05 | yeah, probably you need 30 instead 8 instructions for a complete FP op |
| 21:22.30 | DocScrutinizer05 | no 1000 instructions though |
| 21:22.44 | DocScrutinizer05 | like you'd need for software emulation |
| 21:22.50 | freemangordon | it is not the instructions themselves, but the memory access |
| 21:22.59 | DocScrutinizer05 | :nod: |
| 21:24.29 | freemangordon | I am not sure you can copy from integer reg to FPU reg directly, without going through memory, however, even if it is possible, it takes time |
| 21:24.38 | freemangordon | and leads to pipeline stalls |
| 21:25.48 | DocScrutinizer05 | I'd give ballpark estimations of "soft":1000; "softfp":1000 or 30 (depending if hw accel available);"hard" (only when available): 8 |
| 21:25.49 | freemangordon | CatButts: the last ~20 lines is a kind of an answer to your question |
| 21:25.54 | DocScrutinizer05 | whatever time unit |
| 21:26.32 | DocScrutinizer05 | according to you it's rather "soft":1000; "softfp":1000 or 12 (depending if hw accel available);"hard" (only when available): 10 |
| 21:26.35 | freemangordon | DocScrutinizer05: well, keep in mind that for bug FP functions penalty is relatively small comapred to function execution time |
| 21:26.43 | freemangordon | *big |
| 21:26.48 | CatButts | so it's a tad bit slowe, but no tragedy |
| 21:26.51 | CatButts | r |
| 21:26.56 | freemangordon | yes |
| 21:27.09 | CatButts | even with intensive float calculations? |
| 21:27.37 | freemangordon | float calculations themselves are not affected |
| 21:27.43 | DocScrutinizer05 | that's *only* looking at the float instructions |
| 21:27.46 | freemangordon | just the function calls |
| 21:28.11 | DocScrutinizer05 | the rest of the system doesn't care what your float does |
| 21:28.39 | DocScrutinizer05 | a program that doesn't use floats will not run any fatser on a hardfp system, |
| 21:28.46 | freemangordon | correct |
| 21:29.28 | DocScrutinizer05 | CatButts: so yes, *only* "with intensive float calculations" (100% intensity) |
| 21:32.19 | DocScrutinizer05 | idly wonders if you could wrap the softfp functions with an IRQ-lock and save all FP registers and restore them before leavinbg the softfp function, so hardfp and softfp code could coexist |
| 21:33.07 | DocScrutinizer05 | sucks big time, but would make coexistence possible |
| 21:33.55 | CatButts | plays with cubic interpolation and manages to turn it into ear-raping noise |
| 21:34.41 | DocScrutinizer05 | wait, wouldn't an IRQ either not touch FP registers at all, or (in case it's the schedukler) save the FP registers as well and restore them for the newly scheduled process? |
| 21:35.57 | DocScrutinizer05 | so except for shared libs, is there *anything* that comflicts between softfp-processes and hard(fp)-processes? |
| 21:37.03 | DocScrutinizer05 | and even for shared libs, would the ABI change for soft/hard? |
| 21:37.51 | DocScrutinizer05 | freemangordon: ^^^ |
| 21:38.40 | *** join/#maemo eijk (~eijk@p200300454A12D9001DD24081B271A143.dip0.t-ipconnect.de) |
| 21:38.53 | freemangordon | there is nothing that conflicts |
| 21:38.57 | DocScrutinizer05 | HAHAH >>FPU instructions could be emulated by the kernel so that FPU-less systems could run with this ABI but as far as we know this does not exist<< |
| 21:39.23 | freemangordon | not exactly true iirc, there are "some" instructions emulated in the kernel |
| 21:39.42 | DocScrutinizer05 | ooh, this direction of "not true" :-D |
| 21:40.18 | DocScrutinizer05 | oooh, "pipeline stalls" |
| 21:40.20 | DocScrutinizer05 | hmmm |
| 21:40.26 | freemangordon | iirc, some vfpv3 instructions are emulated if hw is vfpv2 |
| 21:41.00 | freemangordon | but don;t quote me on that one, it was a while I looked at kernel FP support code |
| 21:41.54 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 21:50.01 | DocScrutinizer05 | CatButts: (at runtime) I stand corrected: >>The GCC -mfloat-abi=softfp flag allows use of VFP while remaining compatible with soft-float code. This allows selection of appropriate routines at runtime based on the availability of VFP hardware.<< |
| 21:51.39 | DocScrutinizer05 | >>The runtime linker, ld.so, supports a mechanism for selecting runtime libraries based on features reported by the kernel. For instance, it's possible to provide two versions of libm, one in /lib and another one in /lib/vfp, and ld.so will select the /lib/vfp one on systems with VFP.<< |
| 21:53.19 | DocScrutinizer05 | BUT... >>...the ARM EABI and ELF specification has no way to tell which of soft, softfp, hard is used to build it<< |
| 21:56.42 | DocScrutinizer05 | HMMPH >>This needs to be looked into.. is it only a part of the version 5 EABI and not implemented? Could there possibly be scope for a GNU EABI extension for this, or a fix for the linker?<< |
| 22:00.01 | *** join/#maemo thuttu77 (~thuttu77@82-181-37-124.bb.dnainternet.fi) |
| 22:08.53 | DocScrutinizer05 | ((<freemangordon> there is nothing that conflicts)) so you could run softfp programs on a hardfp platform/system, provided there are all necessary "softfp" lib.so available? |
| 22:10.09 | DocScrutinizer05 | s/programs/binaries/ |
| 22:13.40 | DocScrutinizer05 | hmm, isn't that already answered by >>...but dynamic linking of an executable to a library will not know that it is a bad idea to link a softfp libc or libm to a hardfp executable and vice-versa.<< |
| 22:42.30 | *** join/#maemo NotKit (~nekit@87-119-227-190.saransk.ru) |
| 23:15.51 | *** join/#maemo TheKit (~nekit@178.45.148.38) |