Relatedly: why no AMD GPUs? AMD's much more cooperative with Linux than Nvidia is or probably ever will be at this rate, and performance is great even with the FOSS drivers (as I've observed on both my Dell Precision 7510 and the Threadripper + Radeon rig I built about a year ago).

Like, it's kinda maddening that "the" household name in Linux laptops (if there is such a thing) has zero laptops with an AMD GPU as an option.

AMD GPUs require AtomBIOS which contains bytecode (that is: blobs) to initialize the GPU. If you look at the Linux drivers, they come with an AtomBIOS bytecode interpreter for that purpose.

There was some confrontation over that 10 years ago or so (see radeon vs. radeonhd drivers, one point of view is described at https://libv.livejournal.com/27799.html) and the people in charge of Linux GPU drivers decided to go with AtomBIOS.

> AMD GPUs require AtomBIOS which contains bytecode (that is: blobs) to initialize the GPU. If you look at the Linux drivers, they come with an AtomBIOS bytecode interpreter for that purpose.

I'm failing to see how this is any worse than the current situation with Nvidia drivers, especially if System76 is preinstalling them. You'll need blobs either way. You'll arguably need far more of them for an Nvidia GPU than an AMD GPU.

ACPI also works this way, no?

Right, but ACPI has a standard (even if using the standard has onerous restrictions) and so firmware projects like coreboot can (and do) implement their own.

For AtomBIOS, you have a single vendor virtual machine environment (bytecode + semantics) describing whatever they need in a custom form. There's no other documentation for the things out there than AtomBIOS speciment, making reimplementation rather complex.

Seems to just be that System76 laptops to date are all based on Clevo designs and Clevo does not make any laptops with AMD chips.

Are the mobile AMD GPU options all that great? The RX 5500M that's coming out soon looks interesting.

The reasons for going with Nvidia are:

  * Nvidia is more power efficient. This is really critical for mobile devices
  * Nvidia has CUDA, which is important for (among other things) folks that use machine learning frameworks
  * System76 has put in work to make using Nvidia GPUs more seamless on Linux (pre-installing the drivers, etc.)

Zen 2 really gave AMD the power-efficiency over Intel. Intel's 10nm is still largely absent from the market, and even then I'm not sure how much more efficient the 10nm process is.

I don't think the same can be said for Navi vs. Nvidia's architecture. Also, Nvidia is working on their own 7nm based GPUs.

Fair points all around.

> Are the mobile AMD GPU options all that great?

I haven't had issues with them, even with high-performance stuff like gaming and CAD (can't speak much to machine learning, though).

> Nvidia has CUDA, which is important for (among other things) folks that use machine learning frameworks

What's stopping them from using OpenCL? Whether by using an ML library that actually supports OpenCL outright (e.g. Caffe, PlaidML) or using something like Hipify to convert from CUDA to OpenCL, that shouldn't be a limiting factor.

We initially went with OpenCL to maximize optionality, e.g., back then, GPUs were just getting into the cloud, and we were thinking of eventually getting Graphistry running on FPGAs as well. However, we had to bring a bunch of stuff to the JS world, and ultimately, we wasted a ton of time & money here and with minuscule eco-system support. Intel & AMD's SW arms are very narrow in what they actually support, so if you aren't doing some precise deep learning thing or legacy fortran whatever, sorry.

Back then, the case was unclear because so little stuff existed outside of the MPI & graphics worlds. Today, for most engineering leaders today, the CUDA ecosystem, and emerging productivity layers like RAPIDS is quite rich. They make OpenCL a niche & risky call. The goal should be writing ~100X more code than the OpenCL ecosystem is giving you, it's just surface level.

> I haven't had issues with them, even with high-performance stuff like gaming and CAD (can't speak much to machine learning, though).

Good to know. I have a laptop with the Ryzen 3500U and the Vega 8 integrated graphics. I love it for what I use it for (light gaming) but I'm not familiar with the higher-end mobile GPUs.

> What's stopping them from using OpenCL? Whether by using an ML library that actually supports OpenCL outright (e.g. Caffe, PlaidML) or using something like Hipify to convert from CUDA to OpenCL, that shouldn't be a limiting factor.

I assume just familiarity? That's just what the ML people that I know use.

I would really like to see OpenCL take a dominant position in the GPU compute space, regardless of the GPU manufacturer that has best support for it.

I think we're still a little ways off from a tipping point towards OpenCL. I think it will be accelerated with Intel's launch of the Xe discrete graphics.

Basically AI mainly use cuda. Yes there are libraries. But for the moment for most of us ... I still have to stay in high Sierra for that in my old Mac Pro. Other platform ... open CL for machine learning and AI, not sure anyone doing this. Leela zero do havr some success.

I suspect it's because AMD's resurgence is so recent and these things need long lead times for procurement, development, and validation.

I'm less familiar with laptops: Do Intel and AMD CPUs even share a common socket?

Intel and AMD CPUs do not share a common socket (or chipset) on server, desktop, or mobile platforms. I think the last shared socket was Socket 7 [0], released back in 1995.

0: https://en.wikipedia.org/wiki/Socket_7

I didn't realize that. I guess it shows that I talk to more people building desktops than I have myself.

AMD and Intel do not share a socket.

Not only do Intel and AMD processors not share the same socket, processors change socket from generation to generation.

Socket? Ha! Slot 2 forever! Muahahahaha! >:-D

Can't speak for System76, but I got the AMD Thinkpad (A485), and I'm honestly disappointed as hell and now I understand why you don't see the Ryzens on laptops too much.

The power management is an absolute joke (the thing has two batteries and barely lasts 2 hours total), suspend works maybe 20% of the time, and the OS actually freezes on it every now and then leaving no trace in syslog. I'd much rather get an Intel now if I had a choice.

The A485 was their first attempt with the first mobile Ryzen release. The T495s (latest mobile release) should be way better.

For reference, I had a Ryzen 1800x and it had the same OS freeze issue. The latest Ryzen CPU hasn’t had any issue with 0% down time for months.

I have an E495 (would have gotten the T495 if it didn't have soldered RAM and/or if it still offered a second battery), and it does okay. I think I get 3-5 hours battery (haven't measured it), and I'm considering getting an external battery pack before I need the extra battery life.

The E495 uses a newer rev of their chips and is completely usable (not as good as Intel) despite still not being on 7nm. I expect the next gen to be very competitive with Intel.

That being said, I'm really disappointed at the direction Lenovo is going by trying to make everything thin. I want a powerful laptop (compiling, light gaming) and I'm fine with some extra thickness, but I want don't want anything bigger than 14". If I want thin, I can go for the X models or the T...s models, but for some reason, the regular T line is getting thinner as well, and losing a lot of the reasons I have for getting them. I ended up with the E series because I don't want soldered RAM and I'm not paying a premium for a laptop that has much of what I want removed.

If System76 can deliver a decent Ryzen laptop (want those cores) with a good keyboard and open firmware, I'll pay. I'm happy with it being thick, provided it's not too wide (needs to fit in my bag). But all I see from System76 is mediocre laptops with open source bits, and that's just not my cup of tea.

What distro? I have a T495s and I haven't had any issues with it running Arch.

Yea, something seems fishy. My E485 (one 3-cell battery) gets 3-4 hours on Arch

You poor bastard. I’m running arch on an X1 6th and getting 8 hours+

I mean, they're very different laptops and anyway, if this is a competition, I get ~10-11 hours with a 9 cell in my x220 on arch.

What Ryzen are you specifically referring to?

Afaik newer generations have Intel beat on performance/watt, particularly in HT heavy applications and at least on desktop.

Being able to put out more FLOPs at max pinned wattage, doesn’t imply that you’ll take in fewer watts at idle. Power consumption isn’t linear.

I'm not talking about "more FLOPs at max pinned wattage", that would be Intel. I'm talking about efficiency as in performance delivered per watt used and on that metric Ryzen has Intel beat on desktop.

So it stands to reason those new Ryzen chips would also perform very well in laptops.

[0] https://www.tomshardware.com/reviews/amd-ryzen-9_3900x-vs-in...

No, you’re misreading what I said. My point was that the metric AMD has Intel beat in is “performance per watt under load”. With Ryzen, each watt you spend will get you more FLOPs than the same marginal watt will get you on an Intel chip. It’s like Ryzen is a car with more torque, that can turn each cc of gasoline burned into more force, and so get you further down the road. But that doesn’t mean that Ryzen idles as low as an Intel chip; i.e. that the Ryzen car would end up burning less gasoline over an hour of city driving.

Ryzen can be more power-efficient in e.g. a server (constant near-100% load profile) while also being less power-efficient in a laptop (constant near-idle load profile.) People who talk about the Ryzen power efficiency numbers are only talking about how it performs in the server-like test context (or, often, a gaming context, where the measurement they’re using is just “what sort of PSU do you need to power this thing at max load.”) As is evidenced by sibling posts in this thread, Ryzen doesn’t fare so well in the laptop-like test context in practice.

Leaving HT enabled in 2019.

You're bold. :)

Not a single one of those exploits has ever been seen in the wild.

We don't have to lock our doors, this is a safe community.

Security isn't even the only good reason to disable HT.

I have a similar experience with the A285. Battery life is disappointing with Windows 10, and significantly more so with Ubuntu and variants.

Probably because AGESA is a blob. Once AMD will return to supporting coreboot, it would be a better option. There was recently some indication, that they are interested.

https://www.phoronix.com/scan.php?page=news_item&px=AMD-EPYC...

Intel is equally blobby (FSP, ME).

Works with coreboot though somehow. AGESA prevents it as far as I know, since it does some stuff that coreboot has to be doing. I'm not that familiar with details, may be some coreboot experts can comment.

coreboot on modern Intel requires (some amount of) ME firmware (without which the x86 core wouldn't even turn on) + some parts of the Intel FSP binaries.

coreboot on modern AMD requires (some amount of) PSP firmware (without which the x86 core wouldn't even turn on) + some parts of AGESA which were most recently shipped as "BinaryPI".

The situation is comparable, just that Intel has ~7 years of dealing with coreboot through Chromebooks now, while AMD dropped the ball after a great start and only picked it up again recently. If AMD sticks to the current trajectory, Intel and AMD would be similarly well supported in coreboot (with a similar amount of blobs required) at some point in the near future.

If you're aiming for fully blob-free operations, look for chips not newer than the early 90s. If you can live with not having loadable blobs (while boot ROMs on the CPU die are acceptable), that extends into the late 2000's, but requires some care when selecting your gear.

I wouldn't put any hopes on RISC-V when it comes to avoiding blobs because all higher performance variants will use the same "strings attached" high performance memory and bus controller function blocks whose developers will mandate a certain level of blobbiness.

> requires some care when selecting your gear

Doesn't that mostly boil down to "avoid anything newer than Ivy Bridge/Bulldozer"?

> high performance memory […] controller function blocks

There are DDR4 controllers with FOSS training code out there :) https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/...

Here's POWER's training code for DDR4:

https://git.raptorcs.com/git/talos-hostboot/tree/src/import/...

pgeorgi has a valid point in that if you go for the cheapest off the shelf building block type DDR4 solution for your silicon design (won't name names here, but it's a widely known vendor in the silicon block space), those controllers come with mandated binary-only firmware. IBM (and apparently Marvell?) both didn't use that cheap off the shelf solution and also decided to release their training code. Kudos to both companies for bucking the trend here!

That cheapest COTS block also has the advantage of being battle tested by the big customer base.

Since you presumably have pretty good contacts into IBM: ever asked if they'd consider pooling resources with other vendors around their interconnects in an open forum?

Not sure if DDR4 (or USB, or even PCIe 4.0) silicon is a huge differentiator for them, and those protocols all thrive on interoperability: no need for IBM (or Marvell, for example) to figure out all the issues with real world peripherals on their own.

The general answer is yes and yes. That's why OMI / OpenCAPI are being released as standards, with RTL / HDL. I think at this point there would be more appetite for a next gen interface like DDR5 vs. DDR4 to be released, but I'm just speaking personally from general knowledge here.

Coreboot integrates plenty of blobs via its blobs repository, so "Coreboot builds" does not imply "blob-free".

Then AGESA must be posing some problem for it.

The ancient AGESA open sourced well over a decade ago, then closed down a few years later right about when the PSP started to appear on AMD platforms?

Or do you mean the modern AGESA binary that has zero support whatsoever in coreboot right now?

I mean AGESA that's used for new AMD CPUs.

OK, that makes sense. And yes, it causes problems for coreboot -- AIUI there are no modern AMD systems supported, because AMD has not allowed use of the AGESA blob in that way.

You might be mistaking coreboot for libreboot, the coreboot fork that rejects all proprietary blobs.

Maybe because they don't have mobile versions of their new Zen 2 based chips yet. I'm planning on nursing my current laptop until those are out and make it into laptops. But I figure that is at least a year out as they haven't even announce any mobile Zen 2 chips yet.

How do you avoid the Intel chips in networking? Intel has often-used Ethernet and WiFi chips.