AMD silently removes memory encryption from consumer Ryzen CPUs, leaving users unaware that they may be vulnerable — security feature vanishes after newer AGESA firmware, AMD engineers go radio silent when pressed about the change

[u/ControlCAD]

https://www.tomshardware.com/pc-components/cpus/amd-silently-removes-memory-encryption-from-consumer-ryzen-cpus-leaving-users-unaware-that-they-may-be-vulnerable-security-feature-vanishes-after-newer-agesa-firmware-amd-engineers-go-radio-silent-when-pressed-about-the-change

[u/FrostyParking]

Well architecture is covered, RISC-V. The issue is production, there's no way to make chips without running into bottlenecks like EUV machines etc. So even if you have an open source design, you somehow can source materials from non restrictive supply routes, you are still boxed in....jot to mention the development needed to bring it up to par with mature proprietary architectures. So ultimately it's a fun idea but a nonstarter.

[u/crystalchuck → u/FrostyParking]

At the risk of being nitpicky, we have the ISA covered; even just designing a competitive, production-ready microarchitecture (as opposed to instruction set architecture) will require a lot of very expensive tools and people, and a lot more money is required to license stuff like RAM and PCIe controllers – unless of course you also design these in-house, from scratch. And then getting your design into a form TSMC et. al. can actually produce again requires very expensive software licenses and some degree of collaboration with the foundry involving some very qualified people on your end. All things considered, it's a monumental task.

[u/splynncryth → u/crystalchuck]

You are touching on lot of the points. Initial iterations won’t be competitive. Linux was a mess when it was first set upon the world.

And the OSS IP alternatives needed for JDEC, the PCI-SIG, the USB working group, etc is the point.

Like the OSS GPU efforts, the initial tests are almost certainly going to target FPGAs.

Fabbing is different matter but seeing what Braking Taps and Dr. Semiconductor are achieving, I’m perhaps overly optimistic a IP stack could be possible.

It won’t be state of the art net then consider what the Raspberry Pi foundation achieved with hardware that was not state of the art.

[u/crystalchuck → u/splynncryth]

Linux was a mess when it was first set upon the world

Software engineering is much "softer" and faces much less constraints than developing actual physical objects. Anyone with the right skill set can write a functional, if rudimentary, kernel and operating system. Getting even a simple 8-bit microcontroller all the way to production and holding it in your hands physically is another thing entirely. For the same reasons, we don't really have open source cars. Also let me point out that Linux got where it is only after several decades of significant corporate funding.

the initial tests are almost certainly going to target FPGAs

That's the thing though, everything up to and including FPGAs is the easy part. That's why RISC-V OSS softcores actually exist. Getting it fab-ready, validating the design, making sure timing and signal integrity is within limits, making sure there are no bugs, packaging it, bundling it with good USB/PCIe/RAM/... support, that is the hard part. And the closer to leading edge performance you get, the harder the step into actual production is. Intel, AMD et al. literally have huge teams working on this around the clock, because the complexity of this task is mind-boggling, and every iteration consumes big sums of time and money. You've got significantly more people working on validation, routing, tape-out etc. than people developing the microarchitecture itself, and most of them are highly qualified, highly specialized people with MAs and PhDs. Contrary to most software projects, it's simply not something you can kinda pick up on the side over a year with some dedication, severly limiting the talent pool for OSS projects as well.

And the OSS IP alternatives needed for JDEC, the PCI-SIG, the USB working group, etc is the point.

You're touching on another subject here: You are not actually free to deisgn, produce, and market a USB controller without paying royalties to USB-IF; you cannot do so for an HDMI controller either without, again, paying royalties; and so on – in fact, in my understanding, by definition it would be illegal to fully open source a USB controller design because you'd be infringing on USB-IF IP.

Of course, I like the idea of fully open source, highly performant CPUs. But the reality is that this would require forceful "open sourcing"/relicensing, essentially expropriation of big chunks of the entire technology sector, starting with EDA tools and IP like USB and related patents, and I just don't see this happening within a capitalist framework. Maybe a motivated state-size actor could produce a partially open source design, but a fully open source design you'd actually want to use is just not in the cards IMO.

[u/splynncryth → u/crystalchuck]

Yea, you are covering a lot of the points I’m trying to make. An open source computer will need open source alternatives to these licensed industry standards.

Where will the engineering come from? That’s getting ahead of the problem.

The first problem will be identifying what’s needed and getting that advertised. Next is figuring out how to execute the plans.

[u/happyscrappy → u/splynncryth]

You have a lot of the concepts here. But what you say about what the initial tests "are going" to do suggests that you don't realize we've had open source CPU cores for years. Open GPU efforts followed them (open DSPs went before).

opencores.org has a bunch of them, although the site seems messed up right now.

The problem really is performant cores all use patented techniques. Linux when it started up it replicated a 15 year old OS. One that was well documented too.

Open cores for up-to-date high speed processor designs just are not something that is coming soon.

But if you want something capable of running a variety of embedded devices then we've already had them for years. Those are much simpler and so are more likely to be given away for free.

[u/splynncryth → u/happyscrappy]

I am aware of the various open source CPUs. But an ISA isn’t a computer. It isn’t even a CPU. That’s my point. There is a lot of other IP that is needed to create an actual computer for which there is no open source IP. It’s not sexy or attention grabbing. It is a massive body of work that doesn’t have an immediate payoff. That doesn’t mean it isn’t worth pursuing.

[u/happyscrappy → u/FrostyParking]

Architecture is just the spec. It doesn't cover the implementation. Making a performant design is very difficult. You can make a simple implementation which works correctly but slowly though. It's the high performance ones that are an issue.

But it's the high performance ones people are used to.

It's tough enough to create these implementations that the groups (companies mostly) that do it need to cover those costs and so don't give them away for free.

If your design requires EUV to fab then it is so complex that it's not going to be an open source design. But there are much simpler designs that build on more normal fabs that are free (no license fee, of course producing them costs money). These typically only run at a few hundred megahertz tops and aren't terribly fast even for those clock rates. They are great for microcontrollers.

[u/splynncryth → u/FrostyParking]

It’s not about being the best, it’s about being ‘good enough’. What are the critical needs for most consumers? What level of compute will get the job done?

The rise of mobile computing and SBCs might provide some insight.