Software > Operating Systems and Porting

FreeBSD - Unfortunately not very TALOS-focused

(1/4) > >>

Raion:
I've been talking with the FreeBSD PowerPC devs, and they're unfortunately making a mistake, in my humble opinion, regarding their support for the Talos. They are not interested in either a separate little endian version, or to consider migrating their ppc64 port to little endian. It's unfortunate, as the litany of evidence that I've read on POWER is that little endian POWER will probably be the future due to big-endian.

But then again, FreeBSD has made some dumb decisions in the past. Hopefully NetBSD or OpenBSD will step up.

I've considered once I get a POWER board on doing a fork of FreeBSD for POWER64el, but another consideration has been just doing that for illumos or something.

Probably going to just end up running Debian, in all likelihood until a BSD or illumos is available that is little-endian.

Jubadub:
I'm all for a little-endian variant of FreeBSD. However, I believe there are more accurate ways to describe the decision made by the FreeBSD devs.

In general, I believe there is no "mistake" in going for either endianness. But there are certainly advantages and disadvantages over picking one over the other:

- In the POWER and PowerPC world, big-endian is universal, meaning every processor is big-endian, but only POWER8 and later are capable of little-endian (though many were able to switch endianness during runtime, with the most notable exception being the PowerPC 970 subfamily, AKA "G5", which is strictly big-endian, but also 64-bit); +1 Big-Endian
- GNU/Linux and BSD have historically always been big-endian on PowerPC; +1 Big-Endian
- Porting of certain x86 software is easier to little-endian POWER than big-endian, as endianness becomes one less thing to worry about; +1 Little-Endian

Because we still live in an x86 world, and still will for a long time to come, little-endian has been a popular choice by many GNU/Linux distros and BSD flavors in making their move back to PowerPC, but not all. FreeBSD, in particular, never abandoned the PowerPC world (unlike nearly ALL the little-endian PPC systems popping up now), and are just sticking to the foundation they kept stable. On top of that, because every other PPC computer is big-endian since inception, this means they can be used as a "testing ground" of sorts for Talos II family owners, and especially future owners that don't quite have one yet. PowerMac G5 owners, in particular.

Regardless, it's great to see a great architecture having so many great system choices, and that too in both endiannesses. As a 970MP G5 Quad owner, I'll strictly stick to big-endian whenever I can, and because that's the foundation we have as inheritors of the POWER ;), but I also won't be so close-minded that I will refuse anything little-endian if it comes my way. In the end, it really doesn't matter, other than having the very choice of picking one or the other.

q66:
Jubadub, this is not accurate. While I'm all for having a big endian variant of things, the lack of a little endian variant seriously hampers usability of the system on modern hardware; modern graphics cards will not work and the ones that do work are limited to OpenGL 3.2 (even if the hardware supports 4.5) because of missing features in Mesa (like rgb10 and fp64), and even if stuff gets implemented it will always be slower/less efficient and I suspect things like SDMA will be mostly impossible, because of the GPU hardware being little endian. Additionally, having LE supports lets you assume that POWER8 is the baseline, which allows the system compiler to employ a more modern instruction set by default; runtime checks will only work for checking stuff like AltiVec/VSX presence and not everything implements them and they don't always work well.

I understand that not everybody cares about these things, but forcing your choice on users is IMO not wise.

Jubadub:
Those are all excellent points. However, I must ask: what part of my post was inaccurate, exactly? Could you quote it for me?

When you say "forcing your choice on users is IMO not wise", do you mean the FreeBSD devs? Because as far as I go, I stated that "having the very choice of picking one or the other" is what really matters, regarding endianness, meaning I'm entirely with you there.

Anyway, I don't think all those points, which seem to sum up to "better GPU support" and "more compiler assumptions", invalidate any of the previous points. The GPU situation, in fact, goes hand in hand with my earlier statement, "we still live in an x86 world", and is definitely a very good argument pro-little-endian.

But I must say that although it doesn't concern earlier PPC hardware, because they can't use modern GPUs due to being stuck to earlier revisions of PCIe (and many still-great big-endian GPUs are available for them), it certainly concerns Raptor computers with their amazing PCIe 4.0 interface, and that's a point I hadn't realized before (modern GPU endianness), so I thank you for bringing that up. Of course, nothing prevents all of it to work just as well with big-endian (flipping byte order aside, unless if new BE GPUs are made), but as you pointed out, new work would be required, and who would volunteer to do it? With this, the thread title finally sort of makes sense in at least one point (which otherwise doesn't, as either big or little-endian are equally Talos-focused).

Also, just to make sure I understand you correctly, when you say "and even if stuff gets implemented it will always be slower/less efficient", you exclusively mean the byte-order flipping from little to big-endian in modern GPUs, right?

Regarding compiler assumptions, on the other hand, I don't think that is much of a point, because you can always compile assuming CPUs of a specific "range" or "category" are being used regardless of endianess. For example, you can always compile and assume POWER8 and later is being used, with AltiVec, VSX and all the latest POWER ISA, and still choose big-endian, no runtime checks required. There's absolutely nothing stopping the developer there, as far as endianness is concerned. In fact, that's what Fedora ended up doing, around version 24 or so: they offered the system for big-endian PPC systems, but they weren't, say, fully G5-compatible anymore, even though it has AltiVec and so on; Only later CPUs were officially supported.

q66:
Yes, I mean systems that do that, not you.

It'll be slower/necessary because of the requirement for staging buffers and copying along the way, and that's assuming somebody will implement this stuff at all. Endian flips by themselves are actually pretty much free on POWER, it's more of an API boundary causing extra copying where not necessary, which however also means this will probably never be ideal. And that's also why I say the earlier points are not accurate; if there are reasons why this will never be ideal, it means big endian *is* a practical usability problem, and it's not a simple matter of choosing one or the other, there are actual considerations you have to keep in mind.

You can totally use any GPU you wish on earlier PPC hardware like the PCIe G5. I have an R5 235 in my G5, which was never supported by Apple, as it was released many years after the deprecation of the G5, PCIe is backwards compatible. Similarly, I also have an NVMe SSD in mine, it works alright.

Yes, you can compile for newer hardware, nothing is preventing you from doing that; however, distributions won't do it for you, unless you use specifically a source distro, and once you need to compile your own stuff, you're kinda on your own.

Navigation

[0] Message Index

[#] Next page