Also, with the price difference between the two it would be a more interesting hardware using this difference to acquire more RAM.
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.
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.
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.
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.
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.)
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.
> 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.
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.
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.
I'm less familiar with laptops: Do Intel and AMD CPUs even share a common socket?
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.
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.
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.
Afaik newer generations have Intel beat on performance/watt, particularly in HT heavy applications and at least 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...
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.
You're bold. :)
Security isn't even the only good reason to disable HT.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-EPYC...
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.
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/...
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!
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.
Or do you mean the modern AGESA binary that has zero support whatsoever in coreboot right now?