RISK-V is just ISA.
You will have open source RISK-V microarchitectures for processes that are few generations old. You can use the same design long time when the performance is not so important.
You will not get open source optimized high performance microarchitectures for the latest process and large volumes. These cost $100s of millions to design and the work is repeated every few years for a new process. Every design is closely optimized for the latest fab technology. They have patents.
Intel, AMD, Nvidia, ARM, all have to design new microarchitectures every few years. It's not just doing some VHDL design. It involves research, pathfinding, large scale design, simulation, verification and working closely with fab business. The software alone costs millions and part of it is redesigned. Timelines are tight or the design becomes outdated over time.
Why wouldn't we get a logic netlist which could perform reasonably well when placed on silicon by people who know what they are doing? (Yeah, lots of handwave.) I'm asking this out of curiosity. Not an expert in the field by any means.
Foundries actually have an interest in helping to optimize an open core for their process as a selling point since it can be reused by multiple customers.
The best ARM core is Apple’s Lightning, which has an IPC rate about 4X that of the A72. [0]: https://carrv.github.io/2020/papers/CARRV2020_paper_15_Zhao....
At the same time, Nvidia may be trying to hedge its future as its other competitors (Intel, AMD, even Apple) all have their own CPU and GPU designs. The animosity with Apple has shown the power dynamics and the high stakes.
A thought I've been kicking about, though I fully understand it to be incredibly unlikely would be if NVIDIA would simply terminate any license Apple has to use ARM at all. The move would arguably be done out of pure spite. "payback" for the GeForce 8600M issues that cost them 200~ million and $3 billion in market cap in part due to Apple pushing for a recall.
Apple also seemingly pushed Nvidia utterly out the door, going as far as to completely block NVIDIA from providing drivers for users to use their products even in "eGPU" external enclosures on newer versions of MacOS. Even if only a minority of Apple users ever bought Nvidia cards, being completely banned from an OEM's entire lineup would likely ruffle feathers
If Nvidia bought ARM and decided to find some legal way to terminate the contract with Apple out of spite, Apple would have to find another ISA for their "Apple Silicon".
(Or, of course, Apple are making a huge mistake. But seems a bit less likely to me.)
One big point that came up in the congressional hearing the other day was how Google, when buying DoubleClick, said (under oath to congress) that not only would they not merge data but that they legally couldn't if they wanted to - and then years later did just that.
Is there any way to acquire in such a way that Apple would own ARM but there'd be a complete firewall between them, with ARM having a separate board, CEO, etc. and nothing between them except the technical ownership (and any contracts between the two companies)?
I hope not, as I'm in favour of breaking up huge companies myself... but if legal firms can have a system in place for firewall of information between clients I don't see why a similar legal situation could be feasible for allowing Apple to buy on the condition that they can't have any say over operations, with selling ARM being their only way of influencing them in any way?
Of course, owning a company where you have no control at all isn't great, but in this case it might be worth it if Apple trusts ARM to keep doing well without Apple's help, and if it would prevent someone like NVIDIA from shutting Apple out.
And would there be any antitrust issues if Apple bought a 500 year license to freely (or at a pre-set calculation of pricing) use any and all current and future ARM designs?
ARM has previously shut down open source software emulation of parts of the ARM ISA.
For a while QEMU could not implement ARMv7 I think, until changed their mind and started permitting it. There was an open source processor design on opencores.org that got pulled too.
The reasoning was something like "to implement these instructions you must have read the ARM documentation, which is only available under a license which prohibits certain things in exchange for reading it".
Third parties have been able to get IOS running in an emulator for security research and Android(!) has even been ported to the IOS devices that contain the "Checkrain" Boot ROM exploit (though with things like GPU, Wi-Fi etc in varying states of completion)
(The silicon implementation of an isa is referred to as the microarchitecture btw)
Do you really think NVidia is going to substantially overpay for ARM to then nuke it’s remaining value by going to war on it’s licensees?
umm... what? what does that even mean? lol
I could kind of maybe begin understand your argument from the Graphics side, as users mostly interact with it at an API level, however keep in mind that shaders are languages the same way "cpu languages" work. It's all still compiled to assembly, and there's no reason that you couldn't make an open instruction set for a GPU the same as a CPU. This is especially obvious when it comes to Compute workloads, as you're probably just writing "regular code".
Now, that said, would it be a good idea? I don't really see the benefit. A barebones GPU ISA would be too stripped back to do anything at all, and one with the specific accelerations needed to be useful will always want to be kept under wraps.
It's technically possible but the economics isn't there (was my point). The cost of making a new GPU generally includes writing drivers and shader compilers anyway, so there's not much of a motivation to bother complying with a standard. It would be different if we did expose them at a lower level (i.e. if CPU were programmed with a jitted bytecode then we wouldn't see as much focus on ISA as long as the higher level semantics were preserved)
I'm reminded of the argument over low-level graphics APIs almost a decade ago. AMD had worked together with DICE to write a new API for their graphics cards called Mantle, while Nvidia was pushing "AZDO" techniques about how to get the best performance out of existing OpenGL 4. Low-level APIs were supposed to be too complicated for graphics programmers for too little benefit. Nvidia's idea was that we just needed to get developers onto the OpenGL happy path and then all the CPU overhead of the API would melt away.
Of course, AMD's idea won, and pretty much every modern graphics API (DX12, Metal, WebGPU) provides low-level abstractions similar to how the hardware actually works. Hell, SPIR-V is already halfway to being a GPU ISA. The reason why OpenGL became such a high-overhead API was specifically because of this idea of "oh no, we can't tell you how the magic works". Actually getting all the performance out of the hardware became harder and harder because you were programming for a device model that was obsolete 10 years ago. Hell, things like explicit multi-GPU were just flat-out impossible. "Here's the tools to be high performance on our hardware" will always beat out "stay on our magic compiler's happy path" any day of the week.
By that logic anything emulates its ISA because that is the definition of an ISA. An ISA is just the public interface of a processor. You are wrong about what x86 processors run internally. Several micro ops can be fused into a single complex one which is something that cannot be described with a term from the 60s. Come on, let the RISC corpse rot in peace. It's long overdue.
90%+ of the core logic area (stuff that is not i/o, power, memory, or clock distribution) on the GPU are very basic matrix multipliers.
They are in essence linear algebra accelerator. Not much space for sophistication there.
All best possible arithmetic circuits, multipliers, dividers, etc. are public knowledge.
There might be faster algos for super long integers, or minute implementation differences that add/subtract few kilogates.
Big integer calculations are the bread and butter of GPUs now?
https://01.org/sites/default/files/documentation/intel-gfx-p...
That's almost 1000 pages, and one of 16 volumes, it just happens to be the one most relevant for programmers. If this is your idea of "simple," I'd really like to see your idea of a complex chip.
That's not true at all. I'd recommend reading up on current architectures, or avoid making such wild assumptions.
Conversely, there is a lot of logic on a modern CPU to extract parallelism from a single thread, stuff like register renaming, scoreboards for out of order execution, and highly sophisticated branch prediction units. I get the feeling this is the main stuff you're talking about. But this source of complexity does not dramatically outweigh the GPU-specific complexity I cited above.
One way to get an empirical handle on this question is to write a rasterization pipeline entirely in software and run it in GPU compute. The classic Laine and Karras paper does exactly that:
https://research.nvidia.com/publication/high-performance-sof...
An intriguing thought experiment is to imagine a stripped-down, highly simplified GPU that is much more of a highly parallel CPU than a traditional graphics architecture. This is, to some extent, what Tim Sweeney was talking about (11 years ago now!) in his provocative talk "The end of the GPU roadmap". My personal sense is that such a thing would indeed be possible but would be a performance regression on the order of 2x, which would not fly in today's competitive world. But if one were trying to spin up a GPU effort from scratch (say, motivated by national independence more than cost/performance competitiveness), it would be an interesting place to start.
If you don't have insider's knowledge of how these things are made, I suggest using less certain language.
Just because a big part of the chip are the shading units it doesn't mean it's simple or there's no space for sophistication. Have even you been following the recent advancements in recent GPUs?
There is a lot of space for absolutely everything to improve. Especially now that Ray Tracing is a possibility and it uses the GPU in a very different way compared to old rasterization. Expect to see a whole lot of new instructions in the next years.
Combine these 2 statements and most GPUs would have roughly identical performance characteristics (performance/Watt, performance/mm2, etc)
And yet, you see that both AMD and Nvidia GPUs (but especially the latter) have seen massive changes in architecture and performance.
As for the 90% number itself: look at any modern GPU die shot and you'll see that 40% is dedicated just to moving data in and out of the chip. Memory controllers, L2 caches, raster functions, geometry handling, crossbars, ...
And within the remaining 60%, there are large amounts of caches, texture units, instruction decoders etc.
The pure math portions, the ALUs, are but a small part of the whole thing.
I don't know enough about the very low level details of CPUs and GPUs to judge which ones are more complex, but in claiming that there's no space for sophistication, I can at least confidently say that I know much more than you.
Funny you say that. I've never heard a CPU architect coming to the GPU world and say "Gosh, how simple is this!".
I invite you to look at a GPU ISA and see for yourself, and that is only the visible programming interface.
So, what do you think is the most complex thing on an Nvidia GPU?
That's why third party open shader compilers like ACO could be made:
https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/a...
If you want to look at some historical examples where this wasn't quite the case, look at the old 3DFX VooDoo series. They did add features but they kept compatibility to the point where even up to a VooDoo 5 would work with software that only supported the VooDoo 1. (n.b. This is based on my memory of the era, i could be wrong). They had other business problems, but it meant that adding completely new features and changes in Glide (their API) was more difficult.
It is driven largely by academics who lack a pragmatic drive in areas of time-to-market, and it is being explored by companies for profit motives only. NXP, NVIDIA, Western Digital see it as a way to cut costs due to Arm license fees.
RISC-V smells like Transmeta. I lived through that hype machine.
I think one of the major points for RISC-V was to avoid the possibility of patent encumbrance of the ISA so that it can be freely used for educational purposes. My computer architecture courses 5-6 years ago used MIPS I heavily. MIPS was not open at the time, but any patents for the MIPS-I ISA had long since expired.
POWER is actually open, but it is tremendously more complicated. RISC-V by comparison feels like it borrows heavily from the early MIPS ISAs, just with a relaxation of the fixed sized instructions and no architectural delay slots and a commitment to an extensible ISA (MIPS had the coprocessor interface, but I digress).
The following is my own experience - while obviously high performance CPU cores are the product of intelligent multi-person teams and many resources, I believe RISC-V is simple enough that a college student or two could implement a compliant RV32I core in an HDL course if they knew anything about computer architecture. It wouldn't be a peak performance design by any measure (if it was they should be hired by a CPU company), but I think that's actually a point of RISC-V as an educational platform AND a platform for production CPU cores.
unsurprising given that Wave Computing shut down the project almost a year ago and subsequently declared bankruptcy.
The advantages of those two (and of ARM) is that there actual Implementations with decades of development behind them, Yes, some technical debt but also many painfully-learned good decisions.
RISC V, which I’m really excited about, you can think of as a PRD (customer’s perspective product requirements document). That’s what an ISA is. Each team builds to meet that using their own iomplemetation, none of which is more than a few years old yet. But the teams incorporate decades of learning , and have largely a blank sheet to start with. I think it will be great....but isn’t yet.
POWER has technically only been "open" for a little under a year. OpenPOWER was always a thing, but this used to mean that companies could participate in the ISA development process and then pay license fees to build a chip. This changed last year when POWER went royalty-free (like RISC-V).
The real defniition of "open" is can you answer the following questions in the negative:
- Do I need to pay someone for a license to implement the ISA?
- Is the ISA patent-unencumbered?
[^1]: https://www.hackster.io/news/wave-computing-closes-its-mips-...