System76 To Release A "New Open-Source Computer"

[starshipeleven]

Why is AMD their best best when we have RISC-V?

Because they probably want to have a physical product to sell to consumers before 2020, and RISC-V can't do that at performance and price points required for consumer market, while AMD can.

[torsionbar28]

Wrong, AMD requires a binary blob also for hardware bringup phase, just like Intel has FSP AMD has AGESA.

The management engine is another thing added.

This is true, but to be clear, the "binary blob" that intel and AMD chips require consists of two parts:

One is the microcode that operates the processor (and memory controller for the newer products), and this has existed now for 2+ decades, ever since original Pentium in the 90's. While we all wish this part was open source, it is proprietary for a reason. This is where the magic happens, translating the x86 CISC ISA into instructions for the underlying RISC core(s). There is significant IP in this, hence the reason it is closed. This is a uniquely x86 problem, due to the legacy CISC ISA. This problem does not exist with native RISC ISA's like POWER, RISC-V, MIPS, SPARC, or the defunct Alpha and PA-RISC, where the microcode does not contain any magical instruction translation IP. On native RISC platforms, all the performance optimization magic happens in software, in the compiler (which is why GCC makes much slower binaries on those platforms than the proprietary compilers from the respective vendors do).

Two is the ME/PSP that contains the management and security "features".

[starshipeleven]

This is true, but to be clear, the "binary blob" that intel and AMD chips require consists of two parts:

FSP and AGESA aren't CPU microcode, it's firmware loaded at cold boot to do the hardware initialization, RAM controller training, and other low-level stuff.

Intel's FSP is also overengineered enough that it can basically just pull up a secondary bootloader like u-boot from the flash chip, and this u-boot is just going to find and load an OS (i.e. does no other initialization on its own).
FSP basically replaces whole what Coreboot project does.

Which is one of the reasons Intel made their own BSD-licensed shim-bootloader to actually do this step without u-boot so companies don't have to touch scary GPL-licensed code and can protect their precious IP properly.

I'm ignoring microcode as "blob" because I treat it as part of the hardware, the CPU has a ROM with microcode in it already, you can update it on runtime.

Otherwise we would have three blobs, microcode, FSP/AGESA and ME/PSP firmware blobs.

[DrYak]

FSP/AGESA and ME/PSP firmware blobs.

I haven't been following the latest development of these engine. I was under the impression that these are just mission creep on the same "always on" extra core+firmware.


But to go back to my initial statement : this bring-up/management part is the only (two-part) blob on an AMD APU.
The GPU will be able to run on entirely opensource graphical stack, written by paid-for devs, including some on AMD's payroll.

As opposed to nearly all ARM SoC which rely on binary drivers for nearly everything. (with a few exception here and there where the GPU got reverse engineered).

[DrYak]

Why is AMD their best best when we have RISC-V?

RISC-V isn't an actual chip.
RISC-V is just an instruction set. That isn't covered by any patent, and thus can be implemented by anyone.
With currently only a partially open physicial chip available (That still use some restricted stuff for the RAM controller part).

But in theory, yes, a hardware company could step in and design and produce a CPU that "speaks" the RISC-V isa and is 100% opensource friendly.
It just happens that there's no such chip currently being produced, as of now (or maybe there is, but Michael hasn't reported about it yet).

AMD is company that makes CPUs that you can buy now at your shop. Compared to any putative chip running RISC-V instructions, it has the following disadvantages.

- it's patent covered, mostly by Intel (anything covering the x86 core and some of the vector extensions) and by AMD (mostly the 64bits extensions), with these two company having patent agreements (they can use each other tech), but no other company capable to legally make a x86-compatible chip without licensing deals.
- nowadays they need a blob (well, actually 2 distinct blobs as pointed out by starshipeleven) in order to operate.

[torsionbar28]

FSP and AGESA aren't CPU microcode, it's firmware loaded at cold boot to do the hardware initialization, RAM controller training, and other low-level stuff.

Ah, got it, thanks for the explanation, I didn't realize that was a separate "blob" from the microcode.

[starshipeleven]

I haven't been following the latest development of these engine. I was under the impression that these are just mission creep on the same "always on" extra core+firmware.

No it's actually hardware bringup firmware, may be loaded by the ME/PSP or something else (I don't know the details) but it's doing its own job and is not related to the "security functionality" provided by the ME/PSP.

But to go back to my initial statement : this bring-up/management part is the only (two-part) blob on an AMD APU.

The same applies on an Intel system I guess? What is different on Intel?

[DrYak]

The same applies on an Intel system I guess? What is different on Intel?

CPU-wise : they are the same.
GPU-wise : the absence of a GPU that isn't a joke ?

(I was thinking in terms of AMD's *APU*s vs. ARM *Soc*, so including the whole "there are maybe a few Adreno supported by Freedreno and that's about it")

Well, okay, I'm a bit though on Intel. But you have to admit that a *big* proportion of laptop tend to couple Intel CPUs with Nvidia GPUs, which would be a big no-go for an opensource project (or a costly one if they need to drop the necessary ressources on nouveau devs).

[starshipeleven]

CPU-wise : they are the same.
GPU-wise : the absence of a GPU that isn't a joke ?

(I was thinking in terms of AMD's *APU*s vs. ARM *Soc*, so including the whole "there are maybe a few Adreno supported by Freedreno and that's about it")

Well, okay, I'm a bit though on Intel. But you have to admit that a *big* proportion of laptop tend to couple Intel CPUs with Nvidia GPUs, which would be a big no-go for an opensource project (or a costly one if they need to drop the necessary ressources on nouveau devs).

I can get behind that, yeah.

So far their best effort in graphics was teaming up with AMD to add an AMD GPU on the same CPU/SoC package (with a separate die), but so far not even AppleBooks have started using used that.

Afaik Freedreno isn't that bad, especially after Qualcomm started code-dropping stuff for new Adrenos regularly. The issue is the rest of the SoC, and the overall cost-performance ratio for anything that wants to compete with a PC.

[jacob]

Wouldn’t ARM be required for an open desktop? Even ARM though suffers from the issues around GPU drivers.

Given al of that I’d be happy to see an AMD APU in the desktop. Very reasonable performance for a low to midrange desktop. With today’s chip tech a decent desktop can fit in a very small case.

Given that ARM is easily the most proprietary and closed ISA currently in use, not to mention a paradise of firmware blobs and nonstandard bootstrap procedures, I would say that an open source desktop requires first and foremost STEERING CLEAR from ARM.

But then again, Intel with their IME is not exactly a panacea either, AMD is no better and RiscV is not really credible as a desktop platform (at least for now) and it seems that a desktop RiscV chip with competitive performance is, at the very least, still many years away. POWER is thus still the only option for a truly open source desktop.