Messages

1

Operating Systems and Porting / Re: FreeBSD - Unfortunately not very TALOS-focused

« on: November 29, 2019, 08:51:12 am »

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, I'm aware, sorry for not making my point clear earlier. What I meant was that PCIe 2.0+ GPUs will be limited to PCIe 1.0's bandwidth and not be able to show their true potential. (I, too, have an unsupported GPU in my G5, though it's flashed with modified firmware to still be usable under Mac OS X, and is still just a PCIe 1.0 card, namely an ATI X1950XT 256MB VRAM.)

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. [...] it's more of an API boundary causing extra copying where not necessary, which however also means this will probably never be ideal.

That doesn't seem to be an inherent big-endian issue, but just the API not being updated for it. That is indeed a "practical usability problem" (though I'd be wary of overemphasizing that argument, because people could try to justify using x86/ARM over anything else for that same reason, and that's something we don't want to happen). However, that doesn't mean any of it "will always be slower/less eficient" nor that "this will never be ideal", nor does it make the earlier points inaccurate. But now I understand better where you are coming from, so thanks for taking the time to explain your thoughts to me.

[...] it's not a simple matter of choosing one or the other, there are actual considerations you have to keep in mind.

Oh, absolutely. That is why I stated earlier that "there are certainly advantages and disadvantages over picking one over the other". (Some low-level assembly techniques also exploit each endianness differently, so each has its superior use cases.)

What I meant by saying "either is fine" is that, although each has its own advantages, they both work great, and will be desirable in different situations. Bottom-line is that I do agree FreeBSD, although already 100% Talos-focused, could still additionally offer more builds, in particular little-endian. Of course, the same issue applies to all those other distros like Fedora and Debian and their lack of big-endian options (as tier 1, at least).

2

User Zone / Re: Void Linux thread

« on: November 29, 2019, 07:54:25 am »

Obviously, as all GPUs require firmware, and specifically anything using amdgpu needs *loadable* firmware (i.e. it's not onboard anymore) in form of signed firmware blobs. The driver may not be proprietary, but the firmware always is.

Actually, what is obvious is that what you said is not obvious (and is technically even wrong in the end when you said "the firmware always is [proprietary]"), for 2 simple, factual reasons:

- Just like drivers, firmware source code exists for various devices, and GPU firmware is no different (whether they are already out there or not is another matter). In fact, even the Talos computers contain firmware you can recompile at will;

- The purchase page marks the NVidia GPUs as "proprietary", which, for people not familiar with the availability or lack thereof of libre GPU firmware, can easily and reasonably be interpreted it refers to the firmware. (The driver situation being proprietary or not is OS-dependant, not Talos-dependant, and the purchase page is for Talos alone).

There's also the fact it has been previously discussed on Raptor's Twitter (not sure if by them or a 3rd party) that ALL firmware has been "liberated" (as in, made libre) for the RaptorCS computers (or something along those lines), except one: HDD / SSD firmware. But whether that is true or not, I don't know. But people checking out Raptor's two Twitter accounts can easily come across the statement.

We mark anything requiring kernel/userspace binaries as Proprietary.  Card side firmware we don't explicitly call out, since it's IOMMU isolated.  If we see any libre GPU options start showing up, we'll start calling out cards that require vendor firmware somehow, but for now there's no real point considering the state of the GPU market.

Now this clears it up, many thanks.

3

User Zone / Re: Void Linux thread

« on: November 28, 2019, 06:42:22 am »

Interesting, I didn't know that. But would blobs be required even for the AMD Radeon Pro WX7100 and AMD Vega 64? On the official purchase page, unlike the other 4 GPUs listed there (all NVidia), those 2 AMD ones aren't marked as "proprietary".

4

User Zone / Re: Void Linux thread

« on: November 27, 2019, 09:02:54 pm »

Agreed on selecting the "User Zone" section, it does seem more appropriate, according to their descriptions. And this is an excellent idea! I had considered something like this, but I had zero drive to actually get it done, let alone with this level of superb quality. Nice job! This certainly serves as a perfect entry point.

If I may make a suggestion, what about an extra line in the summary to state whether or not the distro/flavor contains binary blobs, and its FSF status? This will be an important point for some, especially now that the Talos line has been officially certified with FSF's RYF. Libre software enthusiasts are certainly a considerable end-user demographic for RaptorCS. Afterall, we are talking about the most powerful computer lines of all time among those which FULLY give control back to the user.

5

Operating Systems and Porting / Re: FreeBSD - Unfortunately not very TALOS-focused

« on: November 27, 2019, 08:32:22 pm »

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.

6

Operating Systems and Porting / Re: FreeBSD - Unfortunately not very TALOS-focused

« on: November 26, 2019, 05:43:20 pm »

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.

7

General OpenPOWER Discussion / Re: Ahoy shipmates!

« on: November 26, 2019, 05:04:58 pm »

The absolute best systems of all time finally got a home.