Yea, but I think that is a response to google not allowing / strongly encouraging android kernel patches into mainline. This is a huge difference than the previous model where there were forked versions of the system tied to a kernel version.
This talk is a great overview of where things are going...
Distro? I dunno probably not without at least some tweaking at least to the DT.
Stock android? Yes, perhaps. Some functionality from devices is provided via closed firmware blobs that you'll need too. I'm thinking of the modem or other DSPs at least. However I suppose that projects like LineageOS just harvest those from working phones?
I know one developer at Qualcomm who uses Linux on their Snapdragon laptop.
The firmware blobs will be what people are objecting to, if they're specific to a kernel version. What you really want out of this is to be able to install updated kernels on the device without needing a corresponding firmware blob nobody has released.
The firmware blobs execute on the peripherals that happen to be software programmable - not on the CPU (or "apps" CPU). And therefore they're not bound to a particular kernel.
IMO the blobs aren't very objectionable while still not ideal. Would I prefer to have the source to software running on all the peripherals? Sure, I would. But once you're programming on the peripherals it narrows significantly the audience who's interested and capable at changing behavior or making fixes.
I could be wrong but I think this is actually somewhat common.
Cynical but fair points. I'm a total ignoramus when it comes to this level of tech, but it does feel like Apple has been showing how important power efficiency is right now, and the de-bloating that risc-v offers, or potentially offers, seems very appealing in that regard. Of course, it could totally be overshadowed by simple bad developer habits even at the OS level. Like I said, im very ignorant in this area.
What is crazy is how Apple was able to steal the thunder from all, intel, amd, qualcomm, etc. I really wish the PC (non-apple) world steps up, because I don't like macOS at all, and I don't like to pay the Apple prices either.
Qualcomm essentially bought the team that created those designs, so it's possible that Qualcomm catches up or exceeds them (although I'm not holding my breath).
That's probably why ARM is suing them, they potentially could create designs that make ARM's designs obsolete and are likely to take ARM's market (unlike Apple).
That is the case at all. If ARM were given the same die size budget as Apple's CPU I doubt the difference would be what they are today. Worth pointing out (again) all the ARM Cortex-X design are nearly half the die size as Apple's Performance Core.
ARM suing them was simply because they are using a contract tailored for Server market and using it in Smartphone.
Anyone can post, and there are a lot of fanbois of all stripes here. I think there are plenty of non-apple fans here, they just (largely) don't dogpile on things they don't like. Or at least that's how I read the posting guidelines.
In other words, if like me, you roll your eyes every time apple announces some "innovative" new feature other platforms have had for years, just let the fans have their moment.
I would bet a significantly larger percentage of posters here use Apple devices than does the general population. A lot of the population just buys the cheapest thing that claims to do what they want.
I think it comes from a place of frustration. Apple makes this amazing hardware with great software that just oozes with great UX design, but they arbitrarily limit what you can do with them.
I really admire the M1/M2 and the quality that Apple puts into everything they do, that said:
* I think metal is a horrible material for laptops (I rather have plastic/carbon as in ThinkPads),
* non-mate screens really suck (they only look good in pictures),
* and I barely tolerate macOS when I have to use it.
But for me, the worst part is the non-choice. In the PC world, you can choose 10000 different PCs.
Again, I really admire the M1/M2, and the quality of apple products. But I returned an M1 on my previous job because of what I said above, and went to a ThinkPad X1 Carbon.
I think choice is a double edged sword, especially when it comes to building your own PC. Yes, you can choose between many many components, but you also have to choose between them.
You're talking about best laptops. Parent said physically best. I don't think the answer is subjective - Apple most definitely makes far better laptops physically.
The M2 Air is astonishingly light, while being made of metal, as opposed to the ThinkPad's (cheap imo, but subject to debate) plastic. Don't see what the argument is.
It depends on your definition of "physically best". Which is better, a Ferrari Daytona or a Ford F-150? Macs are sleek and elegant, but they're built with absolutely no regard for long-term serviceability. Thinkpads are big ugly slabs of black plastic, but they're easy to open, they have a sensible internal layout and Lenovo provide service manuals and spare parts.
It would be more clear-cut for me if Apple used their engineering prowess to expose an M.2 slot or make it easier to fix a display without buying a $600 topcase assembly. The physical build of their products is fragile at best and consumer-hostile at worst, in my opinion.
My experience with airs is if you try to compile anything with them, the CPU cores peg, the fans go crazy, cpu throttles. (This was with an intel-based air.)
My point isn't that Airs are bad, but that they're not ideal for some tasks and saying any machine is "the best" without mentioning what you're using it for is less useful of a statement than you might think it is.
The Apple Silicon Mac Book Airs are a totally different beast. The Intel ones were unbearably slow for heavy computing tasks. The new architecture is really fast and doesn’t get very hot while being really fast.
I had a Lenovo think pad in 2013 for school. Carried it all over campus for 1 year. So unless their build quality is entirely different nowadays, I’ll never go near another thinkpad
It started literally falling apart in 6 months. One of the usb ports stopped working, the disc tray was stuck, the bottom left of the trackpad was sunken in, and the whole laptop felt cheap and was plastic. A ton of flex in the whole thing.
The worst experience I had with an aluminum mac was dropping it while open and having the screen shatter.
I don't know what ThinkPad you had, but I have had ThinkPads for more than 12 years, working daily, had let them fall on the ground (had to change screen twice), and they still work. There are companies that buy ThinkPads from banks, big companies, after 4 years of use, and they re-sell them and they work for another 10 or more years. Your experience is very weird.
I've had a ThinkPad 13 2G for about 6 years and it's still working fine, but it most likely didn't get the same level of use/wear that yours did.
It's a shame that IBM sold its PC business to Lenovo. Maybe it's just the model I have, but Lenovo's ThinkPads feel so much worse in quality than IBM's ThinkPads. I probably won't get another one when the time comes to replace mine.
That said, I'll consider a Framework or Starbook next time because even T series Thinkpads are getting thinner and bendier and the keyboards lower and worse.
This is the problem with ThinkPad, there are several models with varying price and durability values. Macs are great for people who don't want to think about their requirements.
Not insurmountably, though. Performance-per-watt wise, their GPUs seem to be a full generation behind Nvidia's options. A laptop-spec 3080 regularly beats the M2 Ultra at the same wattage, which is a bit of a head-scratcher considering the node disparity.
It looks like Apple's biggest lead is the TSMC node advantage and their ARM license. And they're not the only ones with access to TSMC fabs and ARM specifications...
Apple Silicon made a big splash because they were the first on TSMC 5nm and got compared to AMD on TSMC 7nm. Now that we've seen 5nm Ryzen it's basically the same, AMD uses a somewhat higher max TDP and correspondingly gets higher multi-thread performance.
Not really sure what’s the advantage of switching from whatever you have today (ARM?), to a qualcomm IP. Qualcomm is historycally a quite shitty partner to have.
Nobody is going to give the secret sauce for free. Also these AI/ML use cases are just some marketing bs, not really grounded by anything really.
There are plenty of ISAs you can find freely available today (Open sparc anyone?). The problem is fragmentation…
RISC-V is not tied to Qualcomm, so you can either choose a different partner or do it all yourself if you've got the necessary skills and resources.
> This open ISA provides designers and developers with greater control over their computing environments, allowing them to fine-tune their systems without relying on third parties or incurring additional license fees associated with proprietary architectures.
> RISC-V is not tied to Qualcomm, so you can either choose a different partner or do it all yourself if you've got the necessary skills and resources.
ISA is the least important part in CPU. The hard part is having all drivers for the peripherals given chip has and knowing most of the chinese vendors it's straight to landfill after few years unless something becomes so popular community RE it.
In fairness using Qualcomm for purposes other than mobile modem integration is a niche pursuit for ARM windows machines and Meta Quest VR. Their CPU implementations never recovered from the 64 bit transition that wrong footed them completely.
As the parent alluded to, if there is a problem in the Android ecosystem you will almost certainly find either Qualcomm or Google in the middle of it.
It's entirely the point of the RISC-V custom extension space that Qualcomm are allowed to do this. It's certainly a risk that software could get locked in to using these custom extensions, but it's also very easy to tell if software is using those extensions from simple examination of the opcodes. For those interested, check the bottom byte[*] of each instruction for:
[*] Where "bottom byte" is actually the first byte since instructions are always stored little endian.
Edit: To be clear and avoid confusion, RISC-V has two sorts of extensions, the custom vendor-specific extension space that I'm talking about here, and the RVI standard extensions which I'm not talking about.
> software could get locked in to using these custom extensions
the question arises: can such extensions be patented?
we've seen already that APIs cannot get patented (see the Oracle vs Google litigation).
If Qualcomm was to develop a set of extension, but other players in the risc-v space could implement some equivalent that's ISA/binary compatible... I wouldn't see any issue with that.
IANAL, but yes, ISA extensions can be patented. For example, the x86-64 extension ("Long Mode") was created by AMD, and Intel had to pay to license it.[0] Those patents expired a few years ago, allowing Microsoft and Apple to write x86-64 to ARM translators freely.
RISC-V has two sorts of extensions. The custom extensions I mentioned in my post above are vendor-specific and they can do what they want, patent them, keep them secret, whatever. However the standard extensions which go through ratification by RISC-V International and are meant to be implemented by anyone must have a royalty-free patent grant (see: https://riscv.org/wp-content/uploads/2022/03/RISC-V-Amended-...)
The cool thing is that there are already extensions in the work to make custom vendor extension compatible with each other and vendors have a general incentive in not keeping their extensions private, because this will hinder software support. as most FOSS software/toolchains will target the extension profiles, which won't include any closed extensions.
If you've gone to the trouble of migrating to RISC-V then you allow that, it's on you.
But even then working around custom extensions is a lot easier than a whole ISA. Short of patents you can always reimplement them. No one can copyright instruction code numbers.
Agreed, especially given their position in ARM, a ubiquitous and easy to license IP. The lock in will come from the GPU, accelerator/coprocessor, and other IPs that will lead to Qualcomm/other large vendor lock in.
I believe SiFive's CPUs and chip designs are not open source generally, although they do open source a lot of related things such as software, specifications, tools. I looked at their GitHub and didn't find any CPUs in there, though there are a lot of repos.
Here's an interesting take on what someone thinks "open source" means in this context: gjsman-1000 wrote: Open source refers solely to the software side of things in these groups and types of projects. Thus, all of the drivers and software you need to use the SiFive is open source and thus you can say it is an open source design. However, it is not an "open hardware" design in that the IP used to design the chip is not released.https://news.ycombinator.com/item?id=25762114
I personally don't think of closed chip designs with open software and specifications as open source chips. That would be like saying Intel and AMD x86s are open source. Though to be fair to those companies, their CPU programming models are much more open than their FPGA programming models, which requires proprietary software and secret specifications to program them at all.
If ARM are going to attack Qualcomm, who else will they go for? Particularly since they now need to justify their very high stock price. With RISC-V you have a clear license (BSD) which lets you do what you want, now and in the future.
Qualcomm took the first step in this case by trying to sell Nuvia derived designs under their own license agreement. Whoever wins it’s not really Arm going on the ‘attack’ if there is a reasonable case that the license has been breached.
We have no visibility into either contract at the center of this case. I’m holding off judgement until we understand Qualcomm’s architecture license, and the assignment clause in Nuvia's. I will only say that suing a 10% customer is, generally speaking, a terrible idea.
Well you’re not really holding off judgment then! It’s also a terrible idea to let big customers breach their contracts but as you say we haven’t seen the contracts concerned.
And I stand by that. Leave aside who is right, because we don’t know. We do know that Qualcomm sent them ~$270m last fiscal year and ARM is pushing them away. The case is over “tens of millions” in Qualcomm’s telling, so it’s not even that much money ARM is seeking, and it is risky. They have a huge mess with the ARM China joint venture that is not done unfolding IMO, and they have chosen that same moment to sue their second biggest customer, who is about to bring ARM chips to Windows PCs in a real way. ARM “winning” this case looks like losing to me.
In any event, I think they settle before it gets to trial next year, because the potential for embarrassment in discovery for both parties is too great, the sum in question is too small, and both companies should want to see those ARM Windows PCs.
> Qualcomm sent them ~$270m last fiscal year
> ARM is pushing them away
> “tens of millions” in Qualcomm’s telling
> ARM “winning” this case looks like losing to me.
I'm sorry, this is once again a very one sided portrayal of this case. Qualcomm is utterly reliant on Arm's technology and if - as you admit is a possibility - Qualcomm has materially breached its licenses in a way that is detrimental to Arm's interests, Arm is supposed to say 'fine, please go ahead'? Of course not!
>> There are plenty of ISAs you can find freely available today (Open sparc anyone?). The problem is fragmentation…
If by "fragmentation" you mean lack of industry-wide support, then you've answered your own question as to why RISC-V. Most Debian packages can run on it. There is even an Android port to RISC-V. Outside x86 and ARM, the next best supported ISA is RISC-V.
Unrelated: why do they call the instruction set an architecture or ISA?
> Unrelated: why do they call the instruction set an architecture or ISA?
In the early days of all of mainframes, minicomputers, and microprocessors companies slapped some hardware design together and then made un an instruction set for it. When the same company made a better, faster, shinier computer a few years later the hardware was completely different and the instruction set was completely different and everyone had to rewrite their software.
One of the best-known examples is the Intel 4004, 8008, 8080, 8086 and so on. None of them can run software for either later or earlier chips. Intel was reasonably good at making it not too hard to rewrite old software, but it still had to be done.
An Instruction Set ARCHITECTURE is an instruction set that is designed from the outset to be independent of any particular hardware implementation of it, and it is intended to make and sell machines over a long period of time that can all run the same software.
Not only that, but with, for example, the IBM System/360 introduced in 1964 they announced six different machines (Models 30, 40, 50, 60, 62, and 70) on the same day, with about a 20:1 "commercial" performance ratio (90:1 for "scientific" use) and a similar range of monthly rental costs (IBM didn't sell them outright).
RISC-V is similarly deliberately an Instruction Set Architecture, that works well with a very wide range of implementation techniques and cost/size, all of which can run exactly the same software (at least if it sticks to RV32I / RV64I).
Strictly speaking an instruction set doesn’t include things like the memory model which you need to know to be able to port code. For example, Apple had to add an extension to their ARM chips which makes stronger guarantees about the order in which memory is written because x86 Mac apps might have dependencies on that which their developers hadn’t been aware of.
Oh, apologies if it sounded like I was trying to say RISC-V doesn't - I was only trying to explain why we use the term “instruction set architecture” as opposed to just “instruction set”.
ARM is no saint either. The problem is that when you have total control over the key IP at some point you become prone to extracting more money out of your customers through various forms of coercion.
The advantage of moving to RISC-V is that no one owns it and you can always leave your IP vendor for another one. Because RISC-V is an attractive ISA it's having an anti-fragmentation effect, creating a popular standard and an industry around it.
It still has an Arm license, but the outcome of the lawsuit against Qualcomm last year was that Qualcomm could not use the Nuvia design, which used Arm technology, on the idea that Qualcomm did not get the same rights as Nuvia had to use Arm’s designs from their takeover of Nuvia.
aren’t all instruction sets slightly different ways of achieving the same thing at a low level?
8, 16, 32, 64 bit mov + add + sub + load + store. and/or/not/xor, blah blah blah
obviously it gets way more complex.
just curious “unlocking its potential”
i thought the primary benefit of risc-v is how easy it is to implement since it never gets into the more complex messiness that’s modern x86_64 and all of its extensions
For whatever reason we've decided to allow companies to copyright and patent instruction sets, which means in practice it's completely forbidden to make your own x86-compatible processor, and for ARM you'd better negotiate a license fee up front.
RISC-V is permissionless, you just grab the specs and start implementing (or more likely, grab a free core off Github and start modifying it). So that's the difference here.
For extensions, RISC-V supports those in a somewhat more structured way. There's both an open process for ratifying standard extensions, and a reserved space for your own custom extensions.
Patents covering the earliest x86 cpus have long expired.
Copyrights cover documentation, and may cover the names of instructions. But creating something that's interoperable with x86, and doesn't violate those copyrights, should be considered fair use. In the same line of copyrighted APIs vs. competing implementations of said APIs. Basically: make cpu that eats binary code of >20y old x86 cpu, use new names for instructions, and write your own documentation.
But of course recent, high performance x86 cpus are still covered by many patents.
So what's legal are competing implementations of x86 cpus released ~20y ago, not using performance enhancing technology covered by still-valid patents. To do what? No market for those.
Not to mention Intel & AMD have legal teams that could make the going tough for anyone trying to do so. Even if legally allowed.
A big advantage for RISC-V is being a clean slate ISA, meaning its design takes into account many issues that were bolted on ad-hoc in other ISAs (32/64 bit, extensions, virtualization, compact instructions, etc).
And being a modular design, you don't pay the power/area cost if you just need a simple core.
A really good introduction to RISC-V is designed, and why it is the way it is, by the original authors.
It left me with a very positive view of RISC-V, as well as reasonable knowledge of the ISA and ABI, which has since proven useful while writing/debugging assembly on the architecture.
I mean on a core level all computers are all equivalent, since they're all just Turing-complete Von Neumann machines. Anything and everything that can be done on one computer can be transformed to achieve the same on a different architecture.
The potential here doesn't just mean different instructions though, it means getting out of ARMs vendor lock-in and for the CPU manufacturers not being forced to pay the licencing fees for the instruction set.
Well there's a difference between the instruction set and the specific implementation in silicon. The Instruction set really doesn't cover how an operating system is booted, how energy efficient a specific chip is, how to interact with devices and drivers, how caching and out of order execution are achieved etc. Qualcomm has undeniable experience in all of this, regardless weather you like their implementation or not and there isn't a single riscv chip out there that can compete with ARM on the performance level yet.
I think the argument will be that even if it can't compete on performance it can compete at the business level by being more flexible, unencumbered by licensing and IP restrictions, etc.
Whether it's a universal good for the consumer or not is unclear. We could end up with significant fragmentation. But the compelling aspect of RISC-V is that companies can spin up their own cores to do all sorts of things without a lot of hassle with licensing. Either by writing one's own core or using an existing off the shelf one, and then tacking on whatever extensions or customizations that make sense for them
And thinking here far beyond what most people think of when they think of in regards to processors (phones, computers) but the fact that ARM cores are in practically everything these days from the MCU to the MPU level. Everything from light bulbs and ceiling fans to COVID tests to garage door openers to christmas lights or toys to drive and memory controllers to laptops and phones.
Think of all that diversity, and now consider what advantages a manufacturer can get by being able to roll up whatever they want, but still be able to use a common standard compiler suite, verification tools, skill set, etc.
RISC-V is the future, or at least a future. No doubt ARM and x86 will exist alongside basically forever, but RISC-V I think has crossed the point where it was a "maybe will be something" to a "it's happening" moment.
What instructions you have and how they are structured does have direct relation to how easy/hard is to produce performant code with it, but yeah, in modern big processors they pretty much always go thru transformation to uOps (sort of micro-instructions) that are cpu vendor specific.
But yeah modern IP laws are clown cart of idiocy that try to kill competing on good product alone at every possible corner
I believe most of the value in the ISA being open source would be captured by hyperscalars and companies like Qualcomm.
With companies like Qualcomm involved, I am afraid they are going to do the whole embrace, extend and extinguish strategy.
Coz we don't want to pay for licensing
> and what’s in it for you
The fun of porting and/or testing everything! Aren't you happy ?
Oh, and we will not upstream our drivers as usual so your devices will be landfill after 4 years as usual