| Wizzup | freemangordon: there's another one with -Os and -ftree-vectorize, seems similar in size too | 00:50 |
|---|---|---|
| uvos | -O2 with thumb makes no sese iiuc | 00:54 |
| uvos | since thumb trades performance (register pressure) for code size | 00:54 |
| Wizzup | uvos: you mean -Os makes more sense yeah? | 00:55 |
| uvos | sure altho imo we should be benchmarking this | 00:56 |
| Wizzup | sure | 00:56 |
| uvos | decreased code size may only make sense on n900 | 00:56 |
| uvos | googeling around also makes it look like the real code size improvements come from compileing for thumb1 | 00:59 |
| uvos | not thumb2 (ie mixed mode) | 00:59 |
| uvos | as in mixed mode gcc's optimizer mostly thinks using thumb isent worth the performance cost | 00:59 |
| uvos | while in thumb1 mode it has to | 01:00 |
| Wizzup | how is this set? | 01:00 |
| uvos | Note that there is no “thumb2” option. If the target processor is new enough, Thumb-2 will be used automatically. | 01:01 |
| uvos | hmm | 01:01 |
| uvos | so -march | 01:02 |
| uvos | something | 01:02 |
| uvos | not sure what | 01:02 |
| uvos | some thumb1 only proc i gues | 01:02 |
| Wizzup | sounds like we probably don't want to do that though | 01:03 |
| uvos | yeah | 01:03 |
| Wizzup | so one other problem I am trying to tackle is that gcc complains about some builds on the CI only | 01:04 |
| Wizzup | because the underlying cpu reports armv8 | 01:04 |
| Wizzup | even though the instruction set is armv7 | 01:04 |
| Wizzup | but I can't make it armv7 in qemu without losing KVM | 01:04 |
| Wizzup | (repor armv7) | 01:04 |
| Wizzup | so passing -march=armv7-a+neon-fp16 (or something) for armhf might solve that | 01:04 |
| uvos | why would that make gcc complain? | 01:04 |
| Wizzup | neon code | 01:05 |
| Wizzup | it detects armv8 cpu and decides that this code won't work there | 01:05 |
| Wizzup | even though we want it to build for armv7 | 01:05 |
| Wizzup | it seems like at least from my search | 01:05 |
| uvos | ok | 01:05 |
| Wizzup | iirc n900 doesn't have vfpv4 | 01:05 |
| Wizzup | in any case, we have an easy test bed to toy with this in -experimental for now | 01:06 |
| uvos | dosent armv8 have neon? | 01:06 |
| Wizzup | sure | 01:06 |
| Wizzup | but slightly different I guess | 01:06 |
| uvos | not sure why it would complain | 01:06 |
| uvos | ok | 01:06 |
| uvos | yeah no idea | 01:06 |
| Wizzup | ok, so CONFIG += plugin in qmake disables making .la files | 01:23 |
| Wizzup | *sigh* | 01:23 |
| Wizzup | uvos: is this a problem? | 02:04 |
| Wizzup | sphone: contacts-evolution: can currently only fill contacts of ofono calls | 02:04 |
| Wizzup | that is followed by: | 02:04 |
| Wizzup | sphone: sphone-mce: dbus call to mce faied with GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "req_vibrator_pattern_deactivate" with signature "s" on interface "com.nokia.mce.request" doesn't exist | 02:04 |
| Wizzup | oh, hum: | 02:05 |
| Wizzup | sphone: No backend for gui_dialer_show | 02:05 |
| Wizzup | ah: | 02:07 |
| Wizzup | sphone: Failed to load module ui-dialer-gtk: /home/user/sphone/build/src/modules/libui-dialer-gtk.so: cannot open shared object file: No such file or directory; skipping | 02:07 |
| Wizzup | ah it doesn't look in the gui/gtk2 path | 02:08 |
| Wizzup | well I guess the dialer launched | 02:09 |
| Wizzup | but my vm screen is now black | 02:09 |
| Wizzup | :D | 02:09 |
| Wizzup | (rotation) | 02:10 |
| Wizzup | well I can get sphone to show when I call through tp and hang up | 02:19 |
| Wizzup | enough for tonight :) | 02:19 |
| freemangordon | uvos__: there is absolutely no difference in registry pressure ARM vs thumb2 | 08:38 |
| freemangordon | the only thing that differs is instructions size (32 ARM vs 16 thumb2 bits) and slightly higher thumb2 decoding time | 08:39 |
| freemangordon | which is compensated by better code cache usage | 08:40 |
| freemangordon | as with thumb2 you have twice as much instructions per I cache line | 08:41 |
| freemangordon | in theory that is ofc :) | 08:41 |
| freemangordon | and yes, we want thumb2, not thumb1 | 08:41 |
| freemangordon | Wizzup: hmm, 3986 vs 4022 | 08:43 |
| freemangordon | something is wrong here | 08:43 |
| freemangordon | we should have ~ 30% down | 08:44 |
| freemangordon | and yes, we want -O2, not -Os | 08:44 |
| freemangordon | lemme install and compare binary sizes | 08:48 |
| freemangordon | Wizzup: I think I know what happens - because build VM does not support thumb2, gcc has no option but to use thumb1, otherwise it won;t be able to run the tests | 09:02 |
| freemangordon | It might be even ignoring -mthumb at all and the slight difference in sizes comes from -mfpu=neon | 09:04 |
| freemangordon | ok, libglib .so has exactly the same size | 09:04 |
| freemangordon | hmm | 09:06 |
| freemangordon | this does not make sense to me https://pastebin.com/JtAmSTLs | 09:06 |
| freemangordon | is it possible we are already on thumb? | 09:06 |
| freemangordon | omg | 09:07 |
| freemangordon | seems like yes, we are | 09:07 |
| freemangordon | Tag_FP_arch: VFPv3 | 09:11 |
| freemangordon | Tag_Advanced_SIMD_arch: NEONv1 | 09:11 |
| freemangordon | vs | 09:11 |
| freemangordon | Tag_FP_arch: VFPv3-D16 | 09:11 |
| freemangordon | this is the only difference between experimental and stable in terms of readelf :( | 09:11 |
| freemangordon | Wizzup: sorry for wasting your time, I am really surprised debian is using thumb2 by default | 09:14 |
| freemangordon | /lib/arm-linux-gnueabihf/libc.so.6 is even compiled with NEON | 09:16 |
| freemangordon | Tag_Advanced_SIMD_arch: NEONv1 | 09:16 |
| freemangordon | unfortunately those low-hanging fruits were already picked-up :) | 09:17 |
| freemangordon | yep, everything is already thumb | 09:25 |
| freemangordon | and most of it is Tag_Advanced_SIMD_arch: NEONv1 | 09:27 |
| freemangordon | sicelo: will it be ok to provide you with icd ofono module with more traces for you to provide new log? | 09:31 |
| freemangordon | actually I will do that for -devel anyway | 09:48 |
| sicelo | most definitely, yes I can test | 09:53 |
| freemangordon | ok, I need maybe 10 minutes to push to devel | 09:53 |
| sicelo | nc | 09:53 |
| freemangordon | The following NEW packages will be installed: | 10:40 |
| freemangordon | elogind libpam-elogind policykit-1 policykit-1-gnome | 10:40 |
| freemangordon | Wizzup: is that ok ^^^? | 10:40 |
| freemangordon | sicelo: please install libicd-network-ofono | 10:40 |
| freemangordon | oh, wait | 10:41 |
| freemangordon | are you one beowylf or chimaera? | 10:41 |
| freemangordon | *beowulf | 10:41 |
| Wizzup | hi | 10:42 |
| freemangordon | Wizzup: is it safe to upgrade chimaera to -devel? | 10:43 |
| Wizzup | there is nothing in chimaera-devel so yes | 10:43 |
| Wizzup | freemangordon: so we were already on neon? | 10:43 |
| freemangordon | there is | 10:43 |
| Wizzup | err, I mena thumb | 10:43 |
| freemangordon | see ^^^ | 10:43 |
| freemangordon | yes, so it seems | 10:43 |
| Wizzup | freemangordon: you can imo just pus to main chimaera, but fine for chimaera-devel or chimaera-testing | 10:44 |
| Wizzup | I just push to chimaera main sine we didn't 'release' it yet | 10:44 |
| freemangordon | https://pastebin.com/j5DU5u7Z | 10:44 |
| Wizzup | so there's no expectation of stablity | 10:44 |
| freemangordon | where those came from then? | 10:44 |
| Wizzup | oh right | 10:44 |
| Wizzup | no I did that | 10:44 |
| Wizzup | yea don't upgrade to it | 10:44 |
| Wizzup | sorry waking up | 10:44 |
| freemangordon | :) | 10:44 |
| freemangordon | ok | 10:44 |
| Wizzup | this is me setting up an env for me and uvos to do the elogind porting | 10:44 |
| freemangordon | sicelo: so, are you on chimaera or baowulf? | 10:45 |
| freemangordon | Wizzup: I think this is -experimental matter | 10:45 |
| freemangordon | but yeah | 10:45 |
| freemangordon | ok, will push to chimaera and beowulf-devel then | 10:45 |
| Wizzup | freemangordon: so we don't need -fpu=neon either? | 10:45 |
| freemangordon | seems we need it | 10:46 |
| Wizzup | freemangordon: btw jfyi the build vm "technically" is armv8 | 10:46 |
| freemangordon | as glib is compiled without it | 10:46 |
| Wizzup | which does not support thumb | 10:46 |
| Wizzup | so if your theory is that it does runtime detection, then that's wrong | 10:46 |
| freemangordon | but, I doubt it makes that much of a difference | 10:46 |
| freemangordon | as long as we don;t use tree-vectorize | 10:47 |
| Wizzup | right | 10:47 |
| freemangordon | which I think is not a good idea to use anyways | 10:47 |
| Wizzup | the last gtk build I set -ftree-vectorize | 10:47 |
| Wizzup | well how else will it use neon? | 10:47 |
| freemangordon | intrinstics | 10:47 |
| freemangordon | like, you may have compile-time checks | 10:47 |
| Wizzup | freemangordon: do you want me to build gtk in experimental with thumb explicitly disabled? | 10:47 |
| Wizzup | just to make sure your theory is correct? | 10:47 |
| freemangordon | yes, please do | 10:48 |
| Wizzup | what flag is that | 10:48 |
| freemangordon | umm... | 10:48 |
| * freemangordon checks | 10:48 | |
| Wizzup | atm I have: | 10:48 |
| Wizzup | DEB_CFLAGS_APPEND="-mfpu=neon -mthumb -Os -ftree-vectorize" | 10:48 |
| Wizzup | DEB_CXXFLAGS_APPEND="-mfpu=neon -mthumb -Os -ftree-vectorize" | 10:48 |
| Wizzup | export DEB_CFLAGS_APPEND | 10:48 |
| Wizzup | export DEB_CXXFLAGS_APPEND | 10:48 |
| Wizzup | we can set that to whatever we want | 10:48 |
| Wizzup | as in, we can add -march= too | 10:49 |
| freemangordon | "-marm" | 10:49 |
| Wizzup | what does this do? | 10:50 |
| Wizzup | ah | 10:50 |
| freemangordon | disables thumb | 10:50 |
| Wizzup | no thumb | 10:50 |
| Wizzup | freemangordon: so thi? | 10:51 |
| Wizzup | DEB_CFLAGS_APPEND="-mfpu=neon -marm -O2" | 10:51 |
| Wizzup | DEB_CXXFLAGS_APPEND="-mfpu=neon -marm -O2" | 10:51 |
| freemangordon | yes | 10:51 |
| Wizzup | ok | 10:51 |
| freemangordon | Wizzup: BTW I loaded mesa big driver in IDA | 10:51 |
| freemangordon | and indeed ISA is thumb2 | 10:51 |
| Wizzup | ok | 10:51 |
| Wizzup | well, building now | 10:51 |
| Wizzup | I do want to test if we should set -march=armv7-a | 10:52 |
| freemangordon | but yeah, it costs nothing to do one more build | 10:52 |
| uvos | https://www2.cs.arizona.edu/~arvind/papers/lctes02.pdf | 10:52 |
| Wizzup | freemangordon: just some power at my home ;p | 10:52 |
| uvos | suposedly thumb can be up to 30% smaller at 5-30% perf cost | 10:52 |
| uvos | and gcc emmits almost no thumb instructions anyways | 10:52 |
| freemangordon | not really | 10:53 |
| uvos | document is fairly old i admit, but modern arm has no thumb anyhow | 10:53 |
| uvos | (ecept in 32bit mode) | 10:53 |
| freemangordon | lemme show you some instructions from mesa big driver .so | 10:53 |
| uvos | i am sure you will find some | 10:54 |
| uvos | thats not the point | 10:54 |
| uvos | the point is it dosent use it for hot paths | 10:54 |
| Wizzup | what do you base this on, just wondering | 10:54 |
| freemangordon | it does | 10:54 |
| uvos | suposedly anyhow, havent done tests myself | 10:54 |
| freemangordon | a random function https://pastebin.com/3UmefPLM | 10:55 |
| uvos | sure i see | 10:56 |
| freemangordon | most of the instructions are thumb | 10:56 |
| freemangordon | the only ARM one I see is VPUSH | 10:56 |
| Wizzup | is this pvr or our mesa | 10:57 |
| freemangordon | pvr_dri.so | 10:57 |
| freemangordon | so our mesa | 10:57 |
| freemangordon | didn't check blobs, but it does not matter | 10:57 |
| Wizzup | sure | 10:59 |
| Wizzup | ok, sounds like we do thumb for sure then | 10:59 |
| freemangordon | mhm | 11:00 |
| freemangordon | which is actually bad news :) | 11:00 |
| Wizzup | btw, how did you confirm that debian also does thumb | 11:00 |
| freemangordon | libc.6 ;) | 11:00 |
| Wizzup | that might be a special case, but probably | 11:00 |
| freemangordon | well, just do readelf -a on a random vanilla binary | 11:01 |
| freemangordon | s/binary/lib | 11:01 |
| Wizzup | ok | 11:01 |
| Wizzup | so what about -march=marmv7-a ? | 11:01 |
| freemangordon | how would that help? | 11:01 |
| Wizzup | so the cpu part of /proc/cpuinfo gives away that our build vm is armv8 | 11:02 |
| Wizzup | even though the 'model name' say it's v7 | 11:02 |
| freemangordon | if we want to help n900, then we better use cortex-a8 | 11:03 |
| Wizzup | this is about build systems thinking we have a v8 cpu | 11:03 |
| Wizzup | when we really don't | 11:03 |
| Wizzup | model name: ARMv7 Processor rev 3 (v7l) | 11:03 |
| Wizzup | CPU part: 0xd08 | 11:03 |
| Wizzup | but | 11:03 |
| Wizzup | 0xd08 = cortex-a72 = armv8-a+crc | 11:03 |
| Wizzup | and I think this might also be why gcc gives some weird errors in some cases | 11:03 |
| freemangordon | ok | 11:04 |
| Wizzup | https://phoenix.maemo.org/job/marian-lite-binaries/architecture=armhf,label=armhf/16/consoleText | 11:04 |
| Wizzup | /usr/lib/gcc/arm-linux-gnueabihf/10/include/arm_neon.h: In function 'int32x4_t vcvtnq_s32_f32(float32x4_t)': | 11:04 |
| Wizzup | /usr/lib/gcc/arm-linux-gnueabihf/10/include/arm_neon.h:1762:10: error: this builtin is not supported for this target 1762 | return (float32x4_t)__builtin_neon_vrintnv4sf (__a); | 11:04 |
| Wizzup | that in particular | 11:04 |
| Wizzup | anyway, that was just a guess | 11:04 |
| Wizzup | I will need to try it to be sure | 11:04 |
| freemangordon | and maybe add -mtune=cortex-a8 | 11:04 |
| Wizzup | but basically marian-lite builds fine on d4 | 11:04 |
| Wizzup | but not on ci | 11:05 |
| freemangordon | I see | 11:05 |
| freemangordon | yeah, test it | 11:05 |
| dsc_ | < Wizzup> this is about build systems thinking we have a v8 cpu <== build systems think this because of gcc's compiler definitions | 11:05 |
| Wizzup | but those come from -march= no? | 11:05 |
| dsc_ | unsure | 11:05 |
| freemangordon | you have built-in defaults | 11:05 |
| freemangordon | afaik | 11:05 |
| dsc_ | yep | 11:05 |
| freemangordon | so maybe we want -march=marmv7-a -mtune=cortex-a8 | 11:06 |
| freemangordon | -march=marmv7-a -mtune=cortex-a8 -mfpu=neon | 11:06 |
| freemangordon | that should help n900 a bit | 11:07 |
| freemangordon | for the other I doubt it matters that much for daily usage | 11:07 |
| freemangordon | if you dig crypto currencies maybe yes :) | 11:07 |
| Wizzup | I think really the hope was/is that it would either help with size or make things magically faster, i.e. scrolling in gtk2 or something, if it had some fast path :p | 11:09 |
| Wizzup | btw looks like the gtk is done | 11:10 |
| Wizzup | still hardly a size difference. | 11:10 |
| freemangordon | seems -marm is ignored then | 11:10 |
| dsc_ | Wizzup: `echo | gcc -dM -E - | grep -i arm` | 11:11 |
| freemangordon | umm... | 11:11 |
| dsc_ | on armhf VM build machine that should yield `#define __ARM_ARCH 7` somewhere | 11:12 |
| dsc_ | but I'm guessing it will say `#define __ARM_ARCH 8` | 11:12 |
| freemangordon | Wizzup: I see no -marm passed to gcc | 11:12 |
| Wizzup | freemangordon: oh! | 11:12 |
| Wizzup | freemangordon: waking up part #2 | 11:12 |
| Wizzup | I forgot to scp the debian_glue fil | 11:13 |
| Wizzup | e | 11:13 |
| freemangordon | :) | 11:13 |
| Wizzup | dsc_: on build vm : http://dpaste.com/CSVE3SQWF | 11:13 |
| Wizzup | looks like it's the same on the d4 | 11:15 |
| Wizzup | like, identical | 11:15 |
| Wizzup | a bit surprised perhaps that ARMEL is defined | 11:15 |
| Wizzup | and indeed with -mfpu=neon we get neon enabled | 11:15 |
| Wizzup | freemangordon: btw this gcc statement also helps check that indeed thumb is probably already on | 11:16 |
| freemangordon | mhm | 11:16 |
| Wizzup | or not :) | 11:16 |
| Wizzup | yes it does: | 11:16 |
| freemangordon | it is, otherwise we wouldn;t have thumb2-compiled pvr_dri.so | 11:16 |
| Wizzup | echo | gcc -mfpu=neon -mthumb -dM -E - | grep -i thumb | 11:16 |
| Wizzup | vs | 11:16 |
| Wizzup | echo | gcc -mfpu=neon -marm -dM -E - | grep -i thumb | 11:16 |
| Wizzup | sure | 11:16 |
| freemangordon | but at least now we will know what -mthumb saves for us :) | 11:17 |
| Wizzup | freemangordon: does n900 have vfp3 ? | 11:17 |
| freemangordon | cortex-a8 | 11:18 |
| freemangordon | I think yes | 11:18 |
| Wizzup | but iirc not vfpv4 | 11:18 |
| freemangordon | right | 11:18 |
| Wizzup | maybe -march=armv7-a+neon-fp16 is slightly better then | 11:19 |
| freemangordon | "The VFP coprocessor is a nonpipelined floating-point execution engine that can execute any VFPv3 data-processing instruction" | 11:19 |
| freemangordon | Wizzup: maybe, I lack the details here | 11:19 |
| freemangordon | https://developer.arm.com/documentation/ddi0344/k/ch16s07s01 | 11:20 |
| freemangordon | sicelo: so, please, install libicd-network-ofono from either chimaera or beowulf-devel (depending on what your device is on), gather new traces and provide that | 11:21 |
| freemangordon | please, also, capture dbus-monitor (if possible bothe session and system bus) logs as well that match those icd2 logs | 11:22 |
| freemangordon | SuperMarioSF: you may do as well ^^^ | 11:22 |
| dsc_ | https://github.com/maemo-leste-extras/ruy/blob/732693c7056f6671ea5606fa00404e02de1c119c/cmake/armFlags.py#L12 | 11:26 |
| dsc_ | for reference :p | 11:26 |
| dsc_ | note that list is half-arsed and does not claim to be complete :P | 11:26 |
| Wizzup | right, but just for everyone wondering, we don't use this anymore | 11:28 |
| Wizzup | no runtime detection | 11:28 |
| Wizzup | at least afaik | 11:28 |
| dsc_ | yes, for Maemo Translate (and its dependencies) we just set `-mfpu=neon` | 11:29 |
| dsc_ | but, only on arm 32bit (armv7) | 11:29 |
| dsc_ | because AARCH64 implies NEON | 11:30 |
| Wizzup | right | 11:31 |
| freemangordon | so, to conclude and move on: do we agree on "-march=marmv7-a -mtune=cortex-a8 -mfpu=neon"? | 11:31 |
| dsc_ | for the build machine? | 11:31 |
| freemangordon | yes | 11:31 |
| freemangordon | for 32bits arm | 11:31 |
| dsc_ | looks good | 11:31 |
| freemangordon | that way we'll squeeze as much as possible from N900 | 11:32 |
| freemangordon | with close to optimal for other devices | 11:32 |
| freemangordon | Wizzup: if you are fine with ^^^, please set-up that on chimaera (not experimental) and maybe rebuild a couple of packages | 11:33 |
| dsc_ | im a bit surprised that only now the build machine has these specific flags for 32bit, this means compilations previously may not have been using neon optimally or whatever | 11:33 |
| freemangordon | we didn't check how it is on beowulf | 11:33 |
| freemangordon | but I would bet it is the same | 11:33 |
| Wizzup | freemangordon: ok, I'm waiting for the gtk test with -marm to finish | 11:35 |
| Wizzup | just for completion | 11:35 |
| freemangordon | ok | 11:35 |
| Wizzup | dsc_: for sure it wasn't using neon before, yes | 11:35 |
| Wizzup | this is probably also true for all debian pkgs | 11:36 |
| freemangordon | but only 'our' builds | 11:36 |
| dsc_ | right, the ones from devuan were built with god knows what | 11:36 |
| freemangordon | no, I would guess vanilla deian packages are compiled with neon | 11:36 |
| freemangordon | *debian | 11:36 |
| Wizzup | freemangordon: then it won't work on some other devices | 11:37 |
| Wizzup | https://wiki.debian.org/ArmHardFloatPort | 11:37 |
| Wizzup | Programs usually take advantage of NEON thanks to hand-crafted assembly routines. GCC can automatically vectorize code and generate NEON instructions, however this tends to have limited success. It would seem sensible NOT to require NEON in a new port since some modern Armv7 ?SoCs such as Marvell Dove and NVidia Tegra2 don't implement it. | 11:37 |
| Wizzup | so no, probably not ;) | 11:37 |
| freemangordon | on chimaera it is requirement | 11:37 |
| freemangordon | I see why would beowul be different | 11:37 |
| Wizzup | https://wiki.debian.org/ArmHardFloatPort#GCC_floating-point_options | 11:38 |
| freemangordon | despite the docs aboe | 11:38 |
| Wizzup | freemangordon: what makes you think that | 11:38 |
| Wizzup | it's not enabled by default | 11:39 |
| Wizzup | and dpkg-buildflags doesn't show it | 11:39 |
| Wizzup | so I am not sure why you'd think neon is used by defaul | 11:39 |
| freemangordon | readelf -A /lib/arm-linux-gnueabihf/libc.so.6 | 11:39 |
| freemangordon | on chimaera this shows Tag_Advanced_SIMD_arch: NEONv1 | 11:40 |
| freemangordon | please someone on beowulf, execute ^^^ | 11:40 |
| freemangordon | and report if there is Tag_Advanced_SIMD_arch: | 11:40 |
| Wizzup | it's the same | 11:40 |
| freemangordon | ok, so it uses NEON | 11:41 |
| Wizzup | I don't know what these attributes really mean though | 11:41 |
| Wizzup | I'm not convinced yet | 11:41 |
| dsc_ | < Wizzup> and dpkg-buildflags doesn't show it <== buildflags of what? individual packages? | 11:41 |
| Wizzup | /bin/ls is not NEON for example | 11:41 |
| freemangordon | or at least is compiled with -fpu=neon | 11:41 |
| Wizzup | dsc_: dpkg-buildflags is a debian tool to show the default system wide build flags | 11:41 |
| Wizzup | freemangordon: sure maybe glibc has some special paths when it detects neon at runtime | 11:41 |
| Wizzup | which is why I think glibc is not a good candidate | 11:42 |
| freemangordon | this does not show the defaults of gcc being used | 11:42 |
| Wizzup | Tag_THUMB_ISA_use: Thumb-2 | 11:42 |
| Wizzup | Tag_FP_arch: VFPv3-D16 | 11:42 |
| dsc_ | whether something gets compiled with NEON or not is (often) via #ifdef's with defs provided by gcc | 11:42 |
| Wizzup | is /bin/bash | 11:42 |
| Wizzup | no mention of neon at all | 11:42 |
| freemangordon | ok | 11:42 |
| dsc_ | you wont see them in dpkg stuff | 11:42 |
| Wizzup | same on beowulf | 11:42 |
| Wizzup | dsc_: yes, I know, but since it's not the default, that matters | 11:42 |
| Wizzup | dsc_: what I was saying is that -mfpu=neon is not in dpkg-buildflags so it's unlikely that $random pkg uses neon | 11:42 |
| freemangordon | maybe all libs has detection logic | 11:43 |
| Wizzup | glibc being an exception | 11:43 |
| Wizzup | since they have fast paths for all kinds of simd | 11:43 |
| freemangordon | *have | 11:43 |
| dsc_ | thats what I'm saying, some libs just automatically start using NEON when GCC signals that it has that ability | 11:43 |
| freemangordon | I know for sure pixman and gtk have | 11:43 |
| Wizzup | dsc_: but we don't signal it(!) | 11:43 |
| Wizzup | currently | 11:43 |
| Wizzup | and neither does debian | 11:43 |
| Wizzup | per dpkg-buildflags | 11:43 |
| freemangordon | Wizzup: and this is an issue for gkt | 11:43 |
| freemangordon | *gtk | 11:43 |
| Wizzup | freemangordon: -marm https://maedevu.maemo.org/pkgweb/chimaera-experimental/main/binary-armhf/libgtk2.0-0.html | 11:44 |
| Wizzup | freemangordon: -mthumb https://maedevu.maemo.org/pkgweb/chimaera/main/binary-armhf/libgtk2.0-0.html | 11:44 |
| freemangordon | yeah | 11:44 |
| freemangordon | Installed-Size: 5090 | 11:44 |
| Wizzup | looks like 20% | 11:44 |
| freemangordon | vs 4020 | 11:44 |
| Wizzup | yup | 11:44 |
| dsc_ | Wizzup: what do you mean 'we dont signal it' | 11:44 |
| dsc_ | gcc signals that its armv7 | 11:44 |
| dsc_ | and some header files act on that | 11:44 |
| dsc_ | see also `echo | gcc -dM -E - | grep -i arm` | 11:45 |
| Wizzup | what I am saying is that the current debian build system, and ours, do not signal neon support | 11:45 |
| Wizzup | so if somehing is compiled with neon it's because their build system does something special, e.g. compile both neon and non-neon paths and switch at runtime | 11:45 |
| Wizzup | which is probably what glibc does | 11:45 |
| freemangordon | wtf? where are gtk neon patches? | 11:46 |
| Wizzup | freemangordon: that was the next question :D | 11:46 |
| * freemangordon scratches head | 11:46 | |
| freemangordon | on my device only :D | 11:48 |
| freemangordon | as a patch | 11:48 |
| freemangordon | ok, will push to master/chimaera | 11:49 |
| freemangordon | the patch needs __ARM_ARCH_7A__ | 11:52 |
| Wizzup | freemangordon: heh | 11:55 |
| Wizzup | freemangordon: we define that currently | 11:55 |
| freemangordon | good | 11:55 |
| Wizzup | $ echo | gcc -dM -E - | grep -i __ARM_ARCH_7A__ | 11:55 |
| Wizzup | #define __ARM_ARCH_7A__ 1 | 11:55 |
| Wizzup | and of course: | 11:56 |
| Wizzup | $ echo | gcc -mfpu=neon -march=armv7-a+neon-fp16 -mtune=cortex-a8 -dM -E - | grep -i __ARM_ARCH_7A__ | 11:56 |
| Wizzup | #define __ARM_ARCH_7A__ 1 | 11:56 |
| freemangordon | how is neon-fp16 better? | 11:56 |
| freemangordon | what is it? | 11:56 |
| dsc_ | probably only useful for crypto(graphy) yakshaving | 11:56 |
| Wizzup | gcc manual covers it | 11:57 |
| freemangordon | ah, "half-precision floating-point" | 11:58 |
| freemangordon | ok | 11:59 |
| freemangordon | makes sense | 11:59 |
| freemangordon | Wizzup: ok, we have a deal | 12:00 |
| Wizzup | ok, will set it up in a bit | 12:00 |
| freemangordon | ok, please wait until I push gtk optimizations before build | 12:01 |
| Wizzup | don't worry I'm trying to solve some dumb wordpress error ;) | 12:02 |
| freemangordon | :) | 12:02 |
| Wizzup | freemangordon: this might help with modest scrolling too | 12:05 |
| Wizzup | (I hope) :P | 12:05 |
| freemangordon | mhm | 12:05 |
| freemangordon | Wizzup: how to make a release? | 12:10 |
| freemangordon | just re-tag and force-push? | 12:10 |
| freemangordon | or? | 12:10 |
| sicelo | freemangordon: I'm still on beowulf | 12:10 |
| freemangordon | sicelo: ok, then install libicd-network-ofono from beowulf-devel | 12:11 |
| freemangordon | oh, I am stupid, it uses debian/patches | 12:17 |
| sicelo | will do. just a bit busy with something for a bit though | 12:17 |
| freemangordon | sure | 12:17 |
| freemangordon | Wizzup: please LMK when chimaera build machine is ready | 12:19 |
| freemangordon | so I can rebuild gtk with https://github.com/maemo-leste/gtk/commit/ee6731e3074f408dd09f959af3f91f09a400db9a | 12:20 |
| Wizzup | freemangordon: experimental first? or just standard? | 12:36 |
| freemangordon | standard | 12:40 |
| Wizzup | ok, that will need a bit more time | 12:54 |
| Wizzup | will do in 30 mins or so | 12:54 |
| Wizzup | freemangordon: it's running now, pls if you can monitor it in ~5 mins nad see if it looks ok | 12:55 |
| Wizzup | freemangordon: I would make a new tag with new patches, but ymmv | 12:56 |
| Wizzup | it's running now anyway | 12:56 |
| Wizzup | so we want to: (1) check for right build flags (2) check if patches are in there | 12:56 |
| freemangordon | we don;t need new tag as contents of /debian does not depend on it | 12:56 |
| Wizzup | ok then | 12:57 |
| Wizzup | bbiab | 12:57 |
| freemangordon | seems like build flags are ok | 13:03 |
| freemangordon | done, lets see :D | 13:11 |
| freemangordon | I wonder how to benchmark that | 13:14 |
| freemangordon | at least device booted after the upgrade | 13:20 |
| freemangordon | *the device | 13:20 |
| Wizzup | how about: modest d4 scrolls faster or comparable to n900 fremantle modest | 13:20 |
| Wizzup | :D | 13:20 |
| Wizzup | d4 modest for scrolls at like 2fps | 13:20 |
| freemangordon | no | 13:20 |
| Wizzup | for me* | 13:20 |
| freemangordon | that's weitd | 13:20 |
| freemangordon | *weird | 13:20 |
| freemangordon | it is way faster here | 13:20 |
| Wizzup | re: bench, there is some gtkbench right | 13:20 |
| Wizzup | gtkperf? | 13:20 |
| freemangordon | yes, but it is highly dependable on gpu rendering | 13:21 |
| freemangordon | because of h-d compositong | 13:21 |
| Wizzup | ok | 13:21 |
| freemangordon | maybe without h-d | 13:21 |
| freemangordon | ok, lemme stop h-s and run gtkperf | 13:21 |
| freemangordon | please do the same on your device | 13:21 |
| freemangordon | *before* upgrade | 13:21 |
| freemangordon | gtkperf -a | 13:23 |
| Wizzup | kill hildon-home too? | 13:23 |
| Wizzup | or doesn't matter? | 13:23 |
| freemangordon | should not | 13:23 |
| freemangordon | /usr/sbin/dsmetool -k /usr/bin/hildon-desktop | 13:24 |
| Wizzup | yup did already | 13:24 |
| Wizzup | it's running | 13:24 |
| freemangordon | Total time: 72.44 | 13:24 |
| Wizzup | keeping screen on btw | 13:24 |
| Wizzup | to make sure mce doesn't tur noff one of the cpus | 13:24 |
| freemangordon | yeah | 13:24 |
| freemangordon | mhm | 13:24 |
| freemangordon | same here | 13:24 |
| freemangordon | it seems that lines is using most of those 72s | 13:25 |
| Wizzup | what about circles | 13:25 |
| Wizzup | are you on new gtk already? | 13:25 |
| freemangordon | yes | 13:25 |
| Wizzup | aha. | 13:25 |
| freemangordon | Circles - time: 3.39 | 13:25 |
| Wizzup | my bench is -way- slower fwiw | 13:25 |
| Wizzup | but we'll have to see after reboot | 13:26 |
| freemangordon | please, do not upgrade yet | 13:26 |
| Wizzup | sure thing | 13:26 |
| Wizzup | circles is over a minute now for sure | 13:26 |
| Wizzup | but it's xorg that uses most cpu by far | 13:26 |
| Wizzup | how large was your drawing area? | 13:27 |
| Wizzup | mine fills most of the width in landscape, and only half the height | 13:27 |
| freemangordon | same here | 13:27 |
| Wizzup | circles is hitting 4-5 mins now I think | 13:28 |
| freemangordon | please run 1000 times pixpufs test | 13:28 |
| freemangordon | weird | 13:28 |
| freemangordon | the above runs 14.45s | 13:28 |
| freemangordon | here | 13:28 |
| Wizzup | now it's getting annoying to keep the screen on :D | 13:29 |
| freemangordon | stop that | 13:29 |
| Wizzup | hm? | 13:29 |
| freemangordon | just run pixpufs test | 13:29 |
| freemangordon | *pixbufs | 13:29 |
| Wizzup | ok | 13:29 |
| freemangordon | 100 times initially | 13:29 |
| freemangordon | then 1000 | 13:29 |
| Wizzup | how do I run it? | 13:29 |
| freemangordon | if it makes sense | 13:29 |
| freemangordon | from the ui | 13:29 |
| Wizzup | huh? | 13:29 |
| freemangordon | just start gtkperf and then select pixbufs | 13:29 |
| Wizzup | oh | 13:29 |
| Wizzup | ok | 13:30 |
| Wizzup | GtkDrawingArea - Pixbufs - time: 1,49 --- | 13:30 |
| Wizzup | Total time: 1,49 | 13:30 |
| Wizzup | 1000 is | 13:30 |
| Wizzup | GtkPerf 0.40 - Starting testing: Sat Jan 21 13:29:45 2023 | 13:30 |
| Wizzup | GtkDrawingArea - Pixbufs - time: 1,53 --- | 13:30 |
| Wizzup | Total time: 1,53 | 13:30 |
| freemangordon | no way | 13:30 |
| freemangordon | make sure it is really 1000 | 13:31 |
| freemangordon | you cannot type there | 13:31 |
| freemangordon | you have to increase with up arrow | 13:31 |
| Wizzup | I typed 0 | 13:31 |
| Wizzup | but ok | 13:31 |
| Wizzup | lol | 13:31 |
| Wizzup | yeah typing doesn't work | 13:31 |
| Wizzup | that's dumb | 13:31 |
| freemangordon | hmm, now circles takes ages here | 13:31 |
| Wizzup | GtkPerf 0.40 - Starting testing: Sat Jan 21 13:30:46 2023 | 13:31 |
| Wizzup | GtkDrawingArea - Pixbufs - time: 13,51 --- | 13:31 |
| Wizzup | Total time: 13,51 | 13:31 |
| freemangordon | weird | 13:31 |
| Wizzup | so I will leave device unupdated, but I have to go out for a bit soon | 13:32 |
| freemangordon | ok, so maybe neon is slower :D | 13:32 |
| freemangordon | ok | 13:32 |
| Wizzup | I could also be the -mtune= | 13:32 |
| freemangordon | will continue later on, I have other things to do as well | 13:32 |
| Wizzup | probably not but still ;) | 13:32 |
| Wizzup | I am not sure if we should have the mtune | 13:32 |
| * Wizzup afk | 13:32 | |
| dsc_ | is the build machine updated with flags related to armv7? | 13:36 |
| dsc_ | id like to compile my thingies | 13:37 |
| freemangordon | ok, this is crazy, first time circles took less that 4 seconds, now it takes minuts | 13:37 |
| freemangordon | whatever is slowing it down is in xorg | 13:45 |
| Wizzup | dsc_: yes, now it is, but I should probably hide it behind chimaera only | 13:58 |
| Wizzup | dsc_: that's done now, assuming I didn't make a sh mistake | 14:00 |
| dsc_ | Wizzup: alright | 14:03 |
| dsc_ | Wizzup: could you fire off some builds? | 14:11 |
| dsc_ | ruy, sentencepiece, marian, kotki, maemo-translate | 14:11 |
| dsc_ | :P | 14:11 |
| Wizzup | in that order? | 14:11 |
| Wizzup | started ruy | 14:11 |
| dsc_ | sure | 14:11 |
| dsc_ | ty | 14:11 |
| Wizzup | started sentencepiece-browsermt | 14:14 |
| Wizzup | dsc_: I think my debian glue change didn't work | 14:24 |
| Wizzup | I have to rebuild | 14:24 |
| norayr | folks why this maemo5 section doesn't get picked up: https://github.com/norayr/quickflickr/blob/427a98808c04aa2ef0d2d30f4cf2529688e30694/src/quickflickr.pri#L17 | 18:52 |
| dsc_ | forgot how qmake works, sorry ^^ | 18:53 |
| Wizzup | norayr: do you specify -spec maemo ? | 18:55 |
| norayr | what is that? how do i specify? where? | 18:56 |
| norayr | when? | 18:56 |
| Wizzup | qmake -spec maemo foo.pro | 18:56 |
| Wizzup | https://github.com/maemo-leste-extras/dorian/blob/master/debian/rules#L7 | 18:56 |
| norayr | let me see | 18:57 |
| Wizzup | norayr: also it's 'maemo' not 'maemo5' | 18:57 |
| Wizzup | https://github.com/maemo-leste-extras/dorian/blob/master/dorian.pro#L133 | 18:57 |
| Wizzup | nope sorry | 18:57 |
| Wizzup | it is maemo5 | 18:57 |
| Wizzup | https://github.com/maemo-leste-extras/dorian/blob/master/dorian.pro#L162 | 18:57 |
| norayr | understand | 18:58 |
| norayr | qmake should have a maemo spec right? | 19:05 |
| norayr | whatever dorian.pro has, it is not going to be picked up without debian/rules right? | 19:06 |
| norayr | ah no. | 19:06 |
| norayr | those are different things. rules has maemo qt something, probably, and my problem is how to make those maemo5 sections in .pro or .pri to be picked up. | 19:07 |
| norayr | they aren't. i have to move let's say 'opengl' to the regular QT += section for it to be picked up. | 19:07 |
| Wizzup | norayr: hence the -spec maemo | 19:09 |
| Wizzup | there is the maemo spec, which defines maemo5, and then you can do QT += maemo5 | 19:10 |
| Wizzup | iirc | 19:10 |
| norayr | yeah, i just tried using your rules file, which is for debhelper, i guess, and now i have the errors that maemo orientation functions don't work. this is good probably. | 19:10 |
| norayr | and probably that is why in easylist my replacement functions didn't work. | 19:10 |
| Wizzup | which functions? | 19:11 |
| freemangordon | Wizzup: no need to pass anything to qmake | 19:12 |
| freemangordon | QT += maemo5 should be enough | 19:12 |
| freemangordon | along with build-dep | 19:12 |
| Wizzup | freemangordon: sure but -spec maemo is required to have maemo5 be defined in case you want to make maemo optional | 19:16 |
| freemangordon | what means 'optional' in this context? | 19:18 |
| freemangordon | BTW, shall I pick voicecall, in terms we discussed? | 19:19 |
| freemangordon | are you happy with it already? | 19:19 |
| Wizzup | freemangordon: I'm hoping to finish a proof of concept sphone module tonight, latest tomorrow | 19:19 |
| Wizzup | then it might make sense to send that in | 19:19 |
| freemangordon | ok | 19:20 |
| Wizzup | for us it won't matter at that point, of coures it's nice if they accept is | 19:20 |
| norayr | /usr/lib/x86_64-linux-gnu/qt5/mkspecs/maemo/qmake.conf contains QMAKE_PLATFORM += maemo5 | 19:20 |
| freemangordon | BTW, what is the case with video calls? | 19:20 |
| Wizzup | something farstream, not sure. | 19:20 |
| freemangordon | like, do nemo guys already have something? | 19:20 |
| Wizzup | norayr: exactly, that's why 'maemo5 {}' works | 19:20 |
| Wizzup | with -spec maemo | 19:20 |
| norayr | but i guess it works with your rules file, but not with default old debian/rules | 19:21 |
| norayr | and now i changed rules to your file, i get | 19:22 |
| norayr | class QApplication’ has no member named ‘setGraphicsSystem | 19:22 |
| norayr | because there is this line: app.setGraphicsSystem("raster"); | 19:23 |
| norayr | plus rotation functions started to not be recognized. | 19:23 |
| Wizzup | I have no idea what this does | 19:23 |
| norayr | but before it was building ok. | 19:23 |
| norayr | qmlloader.cpp:55:22: error: ‘WA_Maemo5PortraitOrientation’ is not a member of ‘Qt’; did you mean ‘InvertedPortraitOrientation’? | 19:23 |
| norayr | error: ‘setAttribute’ was not declared in this scope | 19:24 |
| norayr | i can replace those setAttribute calls with | 19:24 |
| norayr | setProperty("X-Maemo-Orientation", 0); like lines. | 19:24 |
| norayr | but not sure, if i need to include something for those to work. | 19:25 |
| Wizzup | no need to include anything | 19:25 |
| norayr | this is setGraphicSystem: https://doc.qt.io/archives/qt-4.8/qapplication.html#setGraphicsSystem | 19:28 |
| norayr | i guess i just can comment this line: https://forum.qt.io/topic/25263/raster-and-qt5 | 19:31 |
| Wizzup | sounds plausible | 19:32 |
| norayr | it starts but just shows white screen | 19:42 |
| norayr | do you think i can/should change 'import Qt 4.8' with 'import QtQuick 2.3' in qml files? | 19:43 |
| Wizzup | sorry, I don't know how to fix qml | 19:47 |
| Wizzup | if you can fix it, you will also know how to fix openmediaplayer | 19:47 |
| norayr | good, before it was saying 'module Qt is not installed'. now it is saying different errors. | 19:57 |
| norayr | qrc:/qml/qflickr/QuickFlickrMain.qml:35:5: Type MainMenu unavailable | 19:58 |
| norayr | it is at runtime. | 19:58 |
| norayr | maybe i am not even asking, i am recording for public. | 19:59 |
| Wizzup | what module did you install to get rid of that error | 20:00 |
| Wizzup | and where did you see the error | 20:00 |
| Wizzup | uvos: I got organicmaps to build on maemo | 21:16 |
| Wizzup | apart from qt style issues, it looks quite nice | 21:34 |
| Wizzup | I just downloaded an offline map, 50 MB | 21:34 |
| Wizzup | and it knows all the spots | 21:34 |
| Wizzup | uvos: when does sphone actually detect that call is active? | 23:33 |
| Wizzup | uvos: I deal with the answer trigger the same as ofono, but it doesn't seem to pick it up | 23:33 |
| Wizzup | uvos: does the call->state need to be updated in the same function call? | 23:33 |
| Wizzup | it's nice to be able to use conversations for sms, with telepathy-ring going through sphone | 23:42 |
| Wizzup | :) | 23:42 |
| Wizzup | hopefully tomorrow night I have something stable-ish | 23:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!