Author Topic: Void Linux thread  (Read 1841 times)

madscientist159

  • Raptor Staff
  • *****
  • Posts: 43
  • Karma: +9/-0
    • View Profile
Re: Void Linux thread
« Reply #15 on: December 10, 2019, 06:22:45 pm »
Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.

I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).

What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #16 on: December 10, 2019, 07:47:50 pm »
Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.

I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).

What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?

If you mean performance loss with 64-bit ldbl vs 128-bit IEEE754, 64-bit should be faster, because Void is compiled for POWER8 like other distros and therefore can't use POWER9 isns (other than in glibc math functions, which can be chosen at runtime). The actual difference, don't know, I haven't benchmarked it (and won't, as that would mean compiling a set of packages for that).

I kind of don't want to use the 128-bit stuff for long double type in principle, as the hard VSX requirement is there either way (gcc will not compile it without -mcpu set to at least power7) and I'd kind of like the little endian and big endian targets differ mostly in just endianness and baseline -mcpu setting.

I never liked the long double type anyway, as the guarantees you get with it are zero (it's only required to be at least as big/precise as double and that's it). So going with a 64-bit baseline that's covered well in hardware everywhere seems like the sane choice (plus musl won't be adopting 128bit IEEE754 as it would require introduction of a new subarch because musl doesn't version symbols - so that would make glibc little endian the *only* outlier).

People who want 128-bit IEEE754 floating point can easily use the __float128 type in gcc. That is a much better option as it has guaranteed properties (similarly, it works on modern x86 with at least 128-bit wide SIMD as well). People who want the IBM 128bit floating point can also use the __ibm128 type in gcc in a similar manner.

Adopting 64-bit long double in glibc is actually pretty easy right now - because it used to use it in the past (before IBM made them change the default to the silly 128-bit double-double). Therefore, all the compatibility symbols as well as redirects for when you use -mlong-double-64 are set up in glibc, and all it takes is recompiling libraries and programs that use 128-bit IBM long double. You can easily tell which do - they will be tagged like Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double in the ELF attributes. This tag is only introduced when long doubles are used in the binary and it was compiled with those set to 128-bit IBM format.

So, I just went and checked every package containing ELF files for the tag, and compiled a list. It's a relatively small number, only about 330 packages out of 8000+. The rest of them can be left alone.
« Last Edit: December 10, 2019, 07:54:54 pm by q66 »

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #17 on: December 12, 2019, 12:50:00 pm »
After some experimentation, I came to the conclusion that it is currently not practical to switch, as while things will mostly work, using compat symbols ultimately means that some configurations will break; in this case, things that manually declare stuff like math symbol prototypes (which is allowed) for long double math funcs will still use the ibm128 symbols and silently have wrong results... while this is rare, it is a concern.

I searched for potential workarounds but they mostly just introduced new issues elsewhere...

I'll wait until glibc has ironed out its IEEE754 128-bit support and some other distros have switched to it (i know Fedora is planning that) and then I'll reevaluate my options (e.g. possibly see if I could get in a 64-bit ldbl ABI *without* falling back to compat symbols, which would generally solve everything, besides compatibility with ibm128 and glibc is going to need to handle that for the ieee754 transition anyway). Since transition has proved to be less of a problem than expected by itself, it should be relatively easily doable later on.

So, sticking with what I have for now.

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #18 on: December 16, 2019, 03:51:14 am »
New packages batch; bringing out-of-box support for the Navi GPUs in the 5.4 kernel, further BE expansion, and other cool stuff 8)

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #19 on: January 03, 2020, 11:07:10 am »
We're now complete (as in the whole repo is built and everything not buildable is properly marked as such) on ppc64le and ppc64le-musl \o/

ClassicHasClass

  • Full Member
  • ***
  • Posts: 146
  • Karma: +9/-0
  • Talospace Earth Orbit
    • View Profile
    • Floodgap
Re: Void Linux thread
« Reply #20 on: January 04, 2020, 06:28:13 pm »
Excellent!!

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #21 on: January 15, 2020, 02:08:50 am »
The repos are now complete on big endian/32 bit targets as well. Final coverage as usual at https://repo.voidlinux-ppc.org/stats.html. Currently at ~100k packages, amounting to just under 450GB total.
« Last Edit: January 15, 2020, 02:18:57 am by q66 »

xilinder

  • Newbie
  • *
  • Posts: 33
  • Karma: +2/-0
    • View Profile
Re: Void Linux thread
« Reply #22 on: January 18, 2020, 10:08:04 am »
I installed Void Linux as a base system only and added 'mc''links' and 'gpm'.
I'm not getting a mouse. How do I start it?
Talos II 2x8, 32GB RAM, onboard Microsemi RAID,  AMD WX7100, J.Micron SATA/PATA PCIe adapter. Debian with Mate.

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #23 on: January 18, 2020, 10:12:10 am »
presumably you need to enable the appropriate service...

something like


ln -s /etc/sv/gpm /var/service/

xilinder

  • Newbie
  • *
  • Posts: 33
  • Karma: +2/-0
    • View Profile
Re: Void Linux thread
« Reply #24 on: January 18, 2020, 10:47:17 am »
Yup! That did it. Thanks
Talos II 2x8, 32GB RAM, onboard Microsemi RAID,  AMD WX7100, J.Micron SATA/PATA PCIe adapter. Debian with Mate.

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #25 on: April 11, 2020, 11:34:24 am »
Fresh installation/live media now available: https://voidlinux-ppc.org/news/2020/04/new-images.html

q66

  • Jr. Member
  • **
  • Posts: 51
  • Karma: +13/-0
  • Void Linux for ppc maintainer
    • View Profile
    • Void Linux for PowerPC
Re: Void Linux thread
« Reply #26 on: May 01, 2020, 09:19:02 pm »
Latest packages now fix Navi GPUs on kernel 5.6 (5.5 and 5.4 had it working all along). Once again we're the first to have it, but necessary patch was submitted upstream as well and in the meantime made it into drm-next, and will trickle down to other distros later.