2025-11-01 01:01:53 <huajingyun> Ariadne: Thanks for the merge
2025-11-03 12:36:56 <mps> how we patch pkg with multiple source dirs in apkbuild? dovecot in that case
2025-11-03 12:38:28 <mps> manually in prepare()?
2025-11-03 12:49:44 <mps> ah, I see something git log history
2025-11-04 14:28:26 <mps> noticed that on upgrade to edge apk installs all firmware pkgs
2025-11-04 14:28:39 <mps> imo this is bug
2025-11-04 14:29:29 <mps> I solved it temporary by `apk add linux-firmware-none`
2025-11-04 21:34:05 <omni> there is indeed something odd with the linux-firmware aport
2025-11-04 22:06:56 <mps> this happens in last 2 months, earlier it worked fine
2025-11-04 22:08:24 <mps> is there bootable image to flash on usb stick for loongarch64. alpine istall downloaded from site doesn't work
2025-11-04 22:11:07 <mps> could maybe this work https://dl-cdn.alpinelinux.org/alpine/edge/releases/loongarch64/alpine-minirootfs-20251016-loongarch64.tar.gz
2025-11-04 22:12:27 <mps> going to sleep, will read answers tomorrow after wake up. gn and thanks
2025-11-05 00:43:59 <adrian> heya, I opened an MR for changing the GCC default ISA to make Alpine compatible with Loongson-2 CPUs: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92630
2025-11-05 00:51:33 <Ariadne> adrian: loongarch64 is intended to use LSX/LASX
2025-11-05 00:52:14 <Ariadne> if we want to support embedded CPUs, it should be a different arch
2025-11-05 00:53:38 <adrian> why is LASX currently disabled then and why would embedded be a different arch
2025-11-05 00:54:04 <Ariadne> i am just telling you what the intention is
2025-11-05 00:54:22 <Ariadne> if you want to support loongson pi, a new port is needed
2025-11-05 00:55:15 <adrian> this seems silly though, having two different ports for vector extensions vs no vector extensions has no precedent in alpine
2025-11-05 00:55:32 <adrian> they're the same architecture that aside
2025-11-05 00:56:04 <Ariadne> the vector extensions are crucial for performance
2025-11-05 00:56:06 <ikke> for x86 we decided to drop support for CPUs that do not support SSE2
2025-11-05 00:57:01 <Ariadne> yes, which means i586 or lower will need to be a new port :)
2025-11-05 00:57:20 <Ariadne> same here
2025-11-05 00:57:39 <ikke> yes, we technically could, but we don't see value (or rather, not have the resources) to support it
2025-11-05 00:57:55 <Ariadne> i have no objection to a loongarch-without-vectors port, but LSX/LASX provide significant performance improvements
2025-11-05 00:58:11 <Ariadne> and personally, as one of the people using and maintaining this port, that is important to me
2025-11-05 00:58:54 <adrian> i'm down to maintain a loongarch-without-vectors port if that's what this ends up at
2025-11-05 00:59:17 <adrian> it's a real bummer that the embedded CPUs can't run Alpine at the moment
2025-11-05 00:59:22 <Ariadne> i'm down to help, but imo loongson embedded SoCs should run loongarch32 anyway
2025-11-05 00:59:29 <adrian> no, they aren't 32-bit capable
2025-11-05 00:59:37 <adrian> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92630#note_556193
2025-11-05 00:59:47 <adrian> at least if this is to be believed
2025-11-05 01:00:18 <Ariadne> what?
2025-11-05 01:00:34 <Ariadne> it says Loongson-64bit because you are running in 64bit mode
2025-11-05 01:00:56 <adrian> CPU op-modes should list 32-bit if supported
2025-11-05 01:01:00 <adrian> but maybe that's my kernel config
2025-11-05 01:01:20 <adrian> anyways, i see no point in running a 32-bit kernel/userspace on a 64-bit capable cpu
2025-11-05 01:01:38 <Ariadne> 
ACTION shrugs

2025-11-05 01:02:32 <Ariadne> all of the loongson embedded SoCs are on boards with <4GiB RAM
2025-11-05 01:02:42 <adrian> well that might change
2025-11-05 01:03:59 <adrian> but yeah 32-bit is a mandatory subset of loongarch64
2025-11-05 01:11:21 <Ariadne> none the less, a GCC MR to change the desired microarchitectural baseline for a given port is not appropriate
2025-11-05 01:11:48 <Ariadne> speaking with my GCC maintainer hat on, you can ask the TSC if they would like to adjust the baseline to include embedded SoCs
2025-11-05 01:11:59 <Ariadne> ergo, !92630 is rejected
2025-11-05 01:40:38 <Ariadne> to be clear, if loongarch64 becomes unusable for desktop use due to lack of vector support, i intend to quit working on the port
2025-11-05 02:22:11 <huajingyun> Good morning
2025-11-05 02:22:35 <huajingyun> Thank you for your attention to this
2025-11-05 02:25:54 <huajingyun> we cannot sacrifice performance to accommodate all CPUs. I previously submitted an MR to enable 128-bit vectors (LSX) for loongarch64, and I still maintain my position at !74062
2025-11-05 02:26:25 <huajingyun> Of course, for long-term considerations and to meet the needs of embedded CPUs, as Ariadne and ikke mentioned, it is worth considering porting loongarch-without-vectors separately if necessary
2025-11-05 02:27:39 <ikke> huajingyun: mind adding that to https://gitlab.alpinelinux.org/alpine/tsc/-/issues/101
2025-11-05 02:27:46 <Ariadne> i mean, that's my point basically.  it's not that i am against loongarch-without-vectors (or perhaps building some specialized loongarch-with-vectors packages), but the reason why loongarch port is in better shape than most is because there are people daily driving it
2025-11-05 02:28:31 <Ariadne> firefox built without vector support is really buggy, and importantly, much slower (0.8 score on speedometer2 benchmark vs 3.4), making it unusable for daily use
2025-11-05 02:30:28 <Ariadne> and to be clear, speedometer2 benchmark of 3.4 is still not good.  but it is at least usable.
2025-11-05 02:32:49 <huajingyun> ikke: ok
2025-11-05 02:46:00 <ikke> huajingyun: thanks
2025-11-05 02:51:23 <Ariadne> my position, personally, is that LSX/LASX codepaths should only be used in situations where LSX/LASX are marked as present in AT_HWCAP when launching a binary
2025-11-05 02:51:53 <Ariadne> but i do not want to lose the GCC autovectorization
2025-11-05 02:52:17 <Ariadne> because right now, loongarch just is not as well-optimized as x86/arm
2025-11-05 02:52:48 <Ariadne> so giving up optimizations for embedded SoC is counterproductive to having a high quality port
2025-11-05 02:53:47 <Ariadne> i have no objection to downgrading the baseline in GCC, as long as we still get autovectorized code that is used when LSX/LASX are present
2025-11-05 03:05:03 <Ariadne> another option is to allow the base system (e.g. non-desktop packages) to support LS2 chips, while building desktop packages with vectorization
2025-11-05 03:05:19 <Ariadne> regardless, it will have to wait for 3.24
2025-11-05 04:50:29 <celest> build-3-22-loongarch64 is using edge distfiles, could that be changed to v3.23? Thanks.
2025-11-05 04:51:27 <celest> I also think it may be stuck on py3-anyio again.
2025-11-05 05:02:16 <celest> Sorry, build-3-23-loongarch64, not 3-22 which was fixed last month from what i remember, so could 3-23 get the fix before it is released? Thanks again.
2025-11-05 06:54:19 <Ariadne> for what it’s worth, GCC 16 improves loongarch code generation quality significantly, to the point where losing autovectorization might not be too bad 
2025-11-05 06:58:01 <Ariadne> notably the inliner has been hooked up
2025-11-05 06:59:17 <xen0n> Ariadne: also LoongArch FMV support might end up included in GCC 16, currently it's the 2nd revision on the gcc-patches list
2025-11-05 06:59:19 <xen0n> https://gcc.gnu.org/pipermail/gcc-patches/2025-October/698068.html
2025-11-05 07:00:41 <xen0n> with FMV and target_clones support in place we could finally lower the baseline without losing the performance
2025-11-05 07:00:55 <Ariadne> yep ^^
2025-11-05 07:01:01 <Ariadne> in fact we should gain
2025-11-05 07:01:25 <Ariadne> they fixed a really ugly bug in the bstrpick splitter
2025-11-05 07:01:42 <xen0n> yeah I've seen that in the commit message
2025-11-05 07:01:45 <Ariadne> which results in really bad codegen
2025-11-05 07:01:49 <xen0n> but also LA664 new features
2025-11-05 07:02:25 <Ariadne> LA664 silicon is competitive, it’s just the codegen that is not
2025-11-05 07:02:40 <xen0n> it could easily be a decade before the baseline could be raised to -march=la64v1.1 so having FMV is really important for leveraging those new instructions
2025-11-05 07:02:42 <Ariadne> for the longest time autovectorization is basically the only optimization we had :=
2025-11-05 07:02:51 <Ariadne> :p*
2025-11-05 07:02:57 <xen0n> agreed
2025-11-05 07:03:18 <xen0n> SIMD optimization polishes are something the Loongson team has been working on daily
2025-11-05 07:03:43 <Ariadne> i wonder if we can back port these
2025-11-05 07:03:46 <xen0n> I see the PRs pop up on the LLVM project every week
2025-11-05 07:04:02 <Ariadne> if so, i would be in support of lowering baseline to allow LS2 chips
2025-11-05 07:04:49 <xen0n> regarding lowering baselines, we could do some experiments first, with GCC 16 to verify it's actually working
2025-11-05 07:05:08 <Ariadne> on gentoo, right?
2025-11-05 07:05:10 <xen0n> I could do so with Gentoo where it's trivial to tinker with baselines
2025-11-05 07:05:14 <Ariadne> yep
2025-11-05 07:05:15 <xen0n> yeah exactly ;-)
2025-11-05 07:05:48 <Ariadne> i’m waiting for general availability of LA864 skus, but trump has fucked everything re: tarriffs
2025-11-05 07:05:49 <xen0n> then we can figure out the backports, I think if everything's confirmed working the Loongson team could step up and help us
2025-11-05 07:06:09 <Ariadne> i might just go to japan and buy a machine locally
2025-11-05 07:06:30 <Ariadne> though 3a6000 isn’t bad
2025-11-05 07:06:37 <xen0n> ah :-/ but I think the LA864's should be out no earlier than Q2 or Q3 next year?
2025-11-05 07:06:44 <Ariadne> yeah
2025-11-05 07:06:54 <Ariadne> i’m patiently waiting :)
2025-11-05 07:07:03 <xen0n> I just talked with one of the designers at the China Linux Kernel summit a few days ago
2025-11-05 07:07:07 <xen0n> it wouldn't be so quick
2025-11-05 07:07:18 <xen0n> ah, fine then ;-)
2025-11-05 07:07:44 <Ariadne> i just need to figure out how to avoid the 800% tariff
2025-11-05 07:07:48 <Ariadne> or whatever it is now
2025-11-05 07:07:49 <Ariadne> hahaha
2025-11-05 07:09:03 <xen0n> I haven't checked the US tariff policy in detail but we always brought boards into and out of China (for demoing at various events) just in our suitcases
2025-11-05 07:09:12 <xen0n> if it's personal use then it should be okay...
2025-11-05 07:09:21 <xen0n> it's working for us but IANAL
2025-11-05 07:09:32 <Ariadne> yeah china doesn’t care
2025-11-05 07:10:43 <Ariadne> but the GCC 16 optimizer changes are encouraging
2025-11-05 07:12:47 <mps> I'm trying to arrange right now 'in suitcase delivery from China' riscv64 laptop :)
2025-11-05 07:31:55 <huajingyun> does anyone know how many scenarios Alpine Linux is used in the embedded field, or roughly what percentage?
2025-11-05 07:32:14 <huajingyun> Personally, I've always used it in Docker images and on desktop/server
2025-11-05 07:33:49 <Ariadne> it’s definitely present in IoT world
2025-11-05 07:34:15 <Ariadne> in fact i am on a trolley right now where the info signs run alpine (i’ve seen them reboot :D)
2025-11-05 07:42:59 <huajingyun> Ah, I can picture it in my mind, haha
2025-11-05 07:51:56 <mps> huajingyun: what you count as embedded field
2025-11-05 07:53:07 <mps> some ready made products or end users setup in small devices
2025-11-05 08:10:52 <huajingyun> I'm not sure,I haven't encountered some products that use Alpine linux (it exists, but I haven't found it yet)
2025-11-05 08:10:58 <huajingyun> Perhaps it's used in some routers and similar devices
2025-11-05 08:11:17 <Ariadne> with GCC 16 and -march=loongarch64 -mtune=la664, autovec is disabled but unixbench scores are looking better than on GCC 15
2025-11-05 08:11:40 <Ariadne> i am rebuilding firefox now and will run speedometer2
2025-11-05 08:14:56 <Ariadne> adrian: assuming firefox benches well, i have no objection to dropping baseline after backporting the codegen improvements
2025-11-05 08:16:25 <huajingyun> Ariadne: Looking forward to your results,thanks
2025-11-05 08:19:22 <Ariadne> (with that said, dropping baseline must still go through the system change process)
2025-11-05 08:20:57 <Ariadne> huajingyun: i suspect the speedometer2 result will be still around 3.4, but that’s because the JIT in firefox needs to be optimized
2025-11-05 08:37:44 <Ariadne> okay… firefox on speedometer benchmark is reporting 5.7 +/-1.3
2025-11-05 08:38:18 <Ariadne> so IMO the overall codegen improvements offset the loss of autovectorization
2025-11-05 08:38:32 <Ariadne> more than offset
2025-11-05 08:43:34 <huajingyun> the results do appear to show an improvement
2025-11-05 08:44:26 <huajingyun> As things stand, I'm reserving my opinion for now. I might need to take some time to research and evaluate these things further (it's uncertain, things might change)
2025-11-05 08:44:43 <huajingyun> In any case, I think we agree on one thing: we both want a solution that guarantees good performance while also being able to run on embedded systems
2025-11-05 08:48:21 <Ariadne> yes, ports with active daily use by developers are healthier
2025-11-05 08:51:31 <Ariadne> i will look into backporting these codegen fixes
2025-11-05 09:03:30 <Ariadne> so my thoughts are: drop the baseline with GCC 16, build some packages (firefox mainly) with autovectorization enabled as a sub-architecture (apk3 feature!)
2025-11-05 09:04:08 <Ariadne> i will update the TSC ticket in the morning, but i think that is a good path for 3.24/25 iterations
2025-11-05 09:05:01 <Ermine> i'm out of the loop, but have you migrated to apk3?
2025-11-05 09:06:27 <celest> Yes, main/apk-tools is now version 3
2025-11-05 11:27:19 <ikke> Ermine: but the index and package format is still v2
2025-11-05 12:34:22 <mps> trying to build rescue image for loongarch64 and usr_merge_nag.sh break chroot install
2025-11-05 12:34:51 <mps> how can it be disabled on install
2025-11-05 12:35:18 <mps> and why it is used in fresh install
2025-11-05 12:35:19 <ikke> apk add '!usr-merge-nag`
2025-11-05 12:35:48 <mps> thanks, will try
2025-11-05 12:43:57 <mps> also dbus is 'bad' on install https://tpaste.us/YqkM
2025-11-05 12:47:12 <mps> looks like it not time to make rescue now
2025-11-05 12:49:19 <mps> nearly same script used for asahi installer and it worked fine 2 months ago