https://lwn.net/SubscriberLink/884876/ba79f0b75e086321/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Distributions + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account Thoughts on software-defined silicon [LWN subscriber-only content] Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! By Jonathan Corbet February 18, 2022 People are attracted to free software for a number of reasons, including price, overall quality, community support, and available features. But, for many of us, the value of free software is to be found in its ability to allow us to actually own and maintain control over our systems. Antifeatures in free software tend not to last long, and free drivers can often unlock capabilities of the hardware that its vendors may not have seen fit to make available. Intel's upcoming "software defined silicon" (SDSi) mechanism may reduce that control, though, by taking away access to hardware features from anybody who has not paid the requisite fees. SDSi is a "feature" that is expected to make an appearance in upcoming Intel processors. Its purpose is to disable access to specific processor capabilities in the absence of a certificate from Intel saying otherwise. As the enabling patch set from David Box makes clear, the interface to the mechanism itself is relatively simple. It appears as a device on the bus that offers a couple of operations: install an "authentication key certificate" or a "capability activation payload". The certificate is used to authenticate any requests to enable features, while the payload contains the requests themselves. Unless this device has been used to store an acceptable certificate and payload, the features that it governs will be unavailable to software running on that CPU. The SDSi hardware also maintains a couple of counters that track the number of unsuccessful attempts that have been made to load a certificate or enable a feature. Should either counter exceed a threshold, the mechanism will be disabled entirely; the only way to get it back will be to power-cycle the processor. Presumably, the intent here is to thwart attempted brute-force attacks against the SDSi gatekeeper. Intel is clear enough about the purpose behind this new mechanism. SDSi will enable shipping CPUs with features that may be of interest to users, but which are unavailable unless additional payments are made. The restricted capabilities will be present on all shipped CPUs, but the customers, who might have thought that they own their expensive processors, will not be able to use their systems to their fullest capability without add-on (and perhaps recurring) payments to the vendor. The benefits to Intel are clear. The company can do price differentiation among its customers in an attempt to extract the maximum revenue from each while simultaneously reducing the number of different hardware products it must carry in its catalog. The revenue stream from a processor will not necessarily stop once the CPU is purchased, and might continue indefinitely. The benefit for customers is not quite so clear. In theory, customers with minimal needs can avoid paying for expensive features they don't use and can "upgrade" their hardware without downtime if their needs change. Also unclear is which features Intel intends to control in this manner. One can imagine all kinds of things, including the ability to access larger amounts of memory, higher clock rates, additional CPUs, specialized instructions, or accelerators for workloads like machine learning. Taken to its extreme (which the company would presumably not do, though one never knows anymore), an off-the-shelf processor might be unable to run anything more demanding than "hello world" until additional licenses have been purchased. There was a time when a floating-point processor was an add-on unit; perhaps we will find ourselves there again. This business model is not new, of course; stories abound regarding early mainframes that could be "upgraded" by altering a single jumper. Tesla automobiles include a number of features, including basic capabilities like use of the full capacity of the battery, that only work if an extra payment is made; there is no shortage of reports that the company will disable those features when one of its cars is resold. Car manufacturers evidently want to extend this idea to, for example, requiring subscription payments to enable heated seats. The heating elements exist in the seats regardless, and the manufacturer sold them to the buyer, but the buyer still does not really own them. Rent-based business models have been spreading through the technology industry for some time. Many of us no longer purchase and run our own servers; we rent them from a cloud provider (and, to the tell the truth, are often better off for it). Companies that are still in the proprietary software business are finding the monthly subscription model more appealing than simply selling software licenses. And, of course, there are dodgy web sites out there demanding payments for access to their content. But the problem seems worse for hardware that has been purchased, and which the customer, on the theory that they own said hardware, may believe they can rightly use to its fullest capability. Our free software, which is supposed to enable that use, finds itself relegated to asking the hardware for permission to use the available features. It is a loss of control over our systems, yet another set of secrets hidden away inside our computing hardware and protected by anti-circumvention laws; if this approach is commercially successful, we will surely see much more of it. It is hard to see a way out of this situation that doesn't involve making hardware free in the same way that we have done with software. Maybe someday it will be possible to order the fabrication of processors from free designs and at least be able to hope that the result will be lacking in deliberate antifeatures. But that is not the world we live in now, and it's not clear that we will get there anytime soon. Meanwhile, SDSi is definitely coming to Linux; maintainer Hans de Goede has indicated that this work is on track to be merged for 5.18. There are not a whole lot of arguments that can be made against the acceptance of the SDSi driver; it simply enables another piece of functionality packaged with upcoming CPUs. The kernel community has not made a practice of judging whether it likes the "features" provided by a specific peripheral before accepting driver support, and it would be hard to justify starting now. So the Linux kernel will play along with SDSi-enabled CPUs just fine; it will be up to customers to decide whether they want to be as agreeable. [Send a free link] ----------------------------------------- (Log in to post comments) Thoughts on software-defined silicon Posted Feb 18, 2022 17:53 UTC (Fri) by jebba ( supporter , #4439) [ Link] If Red Hat (or whoever) didn't add it to the Linux kernel, wouldn't it be much more difficult for Intel to do this? If so, then why add it? [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 18:29 UTC (Fri) by MatejLach (subscriber, #84942) [Link] I agree with your sentiment but Intel has their own Linux engineers too. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 18:32 UTC (Fri) by jebba ( supporter , #4439) [ Link] Ya, I just mentioned Red Hat since they were in the link. Regardless of who writes it, the Linux developers can certainly reject it. They are under no obligation to add it. If they do, it seems it would do a lot to undercut Intel's attack. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 18:52 UTC (Fri) by tshow (subscriber, #6411) [ Link] I suspect what will kill this is AMD and ARM _not_ doing it, combined with users not bothering to rent whatever Intel is trying to hive off. This has the smell of something that is going to wind up in the tech news in a couple of years when Intel end-of-lifes it because it shows no prospect of paying for itself. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 19:24 UTC (Fri) by atnot (subscriber, #124910) [ Link] Indeed, Intel has already tried this once: https://en.wikipedia.org/ wiki/Intel_Upgrade_Service However, I think it's much more likely to work these days, especially in the enterprise space. Processors there are already highly segmented, with dozens of SKUs that only differ in what fuses are blown in them in the factory. In that sense, this can be a real benefit for enterprise customers, as they would presumably need to order and stock fewer CPU variants. Of course the catch is that longer term, while there is an upper limit to the amount of segmented SKUs are feasible to produce, there is no such limit for feature toggles. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 19:35 UTC (Fri) by developer122 (subscriber, # 152928) [Link] I already avoid intel chips because they paywall ECC. My NAS runs on one of the cheapest (and most power efficient) CPUs AMD ever made, but it's fully stacked with ECC RAM for my ZFS ARC. [Reply to this comment] AMD efficient ECC Posted Feb 19, 2022 9:20 UTC (Sat) by sdalley (subscriber, #18550) [ Link] That sounds really interesting. Any details on which processor/ mainboard you used? [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 3:35 UTC (Sat) by k8to (subscriber, #15413) [Link ] Maybe? I'd more expect amd and some arm vendors to do the same. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 10:16 UTC (Sat) by pbonzini ( supporter , # 60935) [Link] The optimist in me thinks that this might be targeted only to cloud vendors, who rent a subset of a machine at a time and also might rent the same machine for slightly different instance types. Many instruction set extensions can be hidden from CPUID but would still be present in the processor. Different instance types then could use SDSi to have a different set of features enabled for real, and not just in CPUID. The pessimist in me thinks that this is just wishful thinking, though. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 13:37 UTC (Sat) by nim-nim (subscriber, #34454) [ Link] No chance of Red Hat refusing to do it now they belong to IBM, who already practices this. And even if everyone in the community refused to add it Intel would just add the patch to its own kernel and require use of this kernel. Like Nvidia does for its own hardware. Free software means adding antifeatures to a fork is cheap (especially if they are self-contained). [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 22:52 UTC (Sat) by jebba ( supporter , #4439) [ Link] But then they'd be left having to maintain their own fork for that CPU series. There's a lot of overhead there. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 18:46 UTC (Fri) by tshow (subscriber, #6411) [ Link] According to my father, the IBM mainframe upgrade (at least on the mainframe his company had) involved a physical (door lock style) key that operated a rotary switch. Apparently there was a lot of Blues Brothers style pomp & circumstance (briefcase handcuffed to one of the IBM techs, many IBM people in the upgrade party and so forth) involved in the upgrade. His understanding was that they made a big deal of it for legal reasons. Between it requiring a key and all the ceremony, there was no way a customer could claim they didn't realize they couldn't just close a jumper for free. I could kind of see the justification for this if it was running the hardware harder and making it more likely to fail within the warranty period, if (for example) they charged to let you dangerously overclock but would still honor the warranty. But this does look like another "The money people are asking where else can we extract rent?" situation. Now, if you could pay them to get root access to the IME so you could properly secure the machine, that would be another thing entirely. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 18:59 UTC (Fri) by jebba ( supporter , #4439) [ Link] > Now, if you could pay them to get root access to the IME so you could properly secure the machine, that would be another thing entirely. This is available to some customers, but not the general public. Some folks have done a lot of work to try to neutralize it: https://puri.sm/learn/intel-me/ [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 12:48 UTC (Sat) by hazeii (guest, #82286) [Link] On mainframes they were often call 'slugs', in that they essentially slowed the machine down - thus there were extra payments to deslug the machines (even on a short-term basis). [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 20:20 UTC (Fri) by tux3 (subscriber, #101245) [ Link] Maybe this 'feature' is a preparation for the last few deathrattles of Moore's Law. If we can't keep selling meaningful upgrades, phasing in a subscription model early seems optimal. If improvements keep slowing down, it will eventually be cheaper for you to software-upgrade your i3 into an i5 than buy the 5% better and newer i3s that come out every year or two. This'd be great for Intel, who is now in the business of selling people upgrades while saving the cost of an entire chip. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 21:00 UTC (Fri) by atnot (subscriber, #124910) [ Link] That would be pretty poor timing on their part considering AMD has taken significant market share and forced Intel to start delivering double digit performance improvements every year again. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 20:40 UTC (Fri) by flussence (subscriber, #85566) [Link] Nothing new to worry about. Intel's been famous for crippling CPUs and chipsets via firmware and microcode lockouts ever since they introduced HyperThreading. The only thing they're doing differently here is dumping the implementation burden on the OS and using the existing ucode cryptography circuitry to remove the right to repair entirely. Maybe they're feeling threatened by coreboot? The other thing they're doing - unintentionally - is admitting that their chips are barely worth what the base model sells for and everything else is pure scalping. That too is public knowledge but it's nice to see it straight from the horse's mouth. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 22:56 UTC (Fri) by NYKevin (subscriber, #129325) [Link] While I can't say that I *approve* of Intel's business model, I also can't say that this is an accurate assertion: > The other thing they're doing - unintentionally - is admitting that their chips are barely worth what the base model sells for and everything else is pure scalping. It is possible (I haven't run the numbers) that they are running an "airfare-style" business model, where: 1. The cheap seats barely break even on a seat-mile basis, and may even lose money when non-operating expenses are included. 2. The business class seats are the main profit center, because you can sell a fair number of them to business travelers at a healthy markup, and make a decent profit in doing so. 3. The first class seats are essentially "bonus profit" for customers willing to pay extra for premium services. Some airlines don't even do first class, or merge it with business class. If the airline had the option to do so, they would fill the entire plane with business class seats. But they can't sell quite enough business class seats, at business class prices, for this to make sense, unless they use smaller planes, which have poorer economies of scale, driving the price further up, etc. The purpose of the economy seats, then, is to lose as little money as possible, and *maybe* make a small profit if the economics allow for it. The people sitting in business class are the folks who are actually paying for the plane ride, despite the fact that their seats are only marginally more costly to the airline in terms of operating expenses.* The question is whether the economies of scale inherent in the silicon market end up working out the same way as they do in the aviation market. I would be very interested in seeing hard data on that point. * In a properly-run business, opportunity costs should usually be low or negative. Positive opportunity costs indicate misallocation of resources. So if you want to quantify the "cost" of a good or service to the supplier, you probably mean the accounting cost, not the opportunity cost. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 23:48 UTC (Fri) by Cyberax ( supporter , # 52523) [Link] The thing is, the larger die is supposed to be more expensive. So the fact that you can just sell the fully-loaded die as an "economy" SKU means that you don't have competitors that would just undercut you on price or features. This was very much the case up to about 5 years ago in case of Intel on servers. These days? It just seems stupid. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 2:00 UTC (Sat) by khim (subscriber, #9252) [Link] > So the fact that you can just sell the fully-loaded die as an "economy" SKU means that you don't have competitors that would just undercut you on price or features. Nope. You are forgetting an elephant in the room: price of set of photolithography masks and design cost for these masks. To make one set of masks you have to spend millions of dollars (singular millions). But to develop completely new set price can go to $100 million for relatively small chips and I wouldn't be surprised to know that with monsters like AMD/nVidia/Intel are producing they can go to $1 billion or more. When non-recurring costs are so high it may make sense to produce transistors which are destined to be disabled and it would still be cheaper than to produce many physically different SKUs. > These days? It just seems stupid. Nope. As price of development grows higher and higher and relative cost of unused silicone lower and lower more and more companies would want to do that. That's simple math. I don't know under what kind of rock you were sitting, but just recall that endless disable/enable AVX512 saga: apparently it's cheaper for Intel to go with already prepared masks and just disable AVX512 in firmware rather then redo the production process! [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 8:47 UTC (Sat) by Wol (subscriber, #4433) [Link] I had a 3-core AMD a while back (just scrapped it), and I understood that a lot of these chips were actually 4-cores with a core disabled. Especially with a new design, if these things can be disabled by blowing a fuse, surely it makes sense to just disable stuff that fails QA and sell the resulting chip at a lower price point. Cheers, Wol [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 11:41 UTC (Sat) by smurf (subscriber, #17840) [ Link] That makes economic sense when the silicon is broken, and already routinely used with clock speeds or (in the embedded realm) on-die Flash memory. Selling perfectly working CPUs at a bargain and then charge for the "upgrade" is a slightly different kettle of fish, and frankly I can't contribute much to that discussion beyond "don't like it and will go to some pains not to use CPUs with this kind of anti-feature". The non-turnoff-able IME is bad enough. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 12:15 UTC (Sat) by khim (subscriber, #9252) [Link ] > That makes economic sense when the silicon is broken, and already routinely used with clock speeds or (in the embedded realm) on-die Flash memory. Except it wasn't broken. The majority of sold chips had perfectly functional additional cores you can enable (back when all it took to enable them was a pencil). And I'm sure the majority of Ryzen 5 5600X sold today actually have 8 working cores, too. They have fully functional 32MB cache designed for all 4 cores and if your approach was the reason for their existence then we would have had some version of Ryzen with reduced cache and all 8 cores enabled. There are nothing like that because it doesn't make any economic sense: you couldn't fit these between Ryzen 5 5600X and Ryzen 7 5800X. They would be weird side-cousin to Ryzen 5 5600X which would just make buyers confused. > Selling perfectly working CPUs at a bargain and then charge for the "upgrade" is a slightly different kettle of fish. It's exactly the same only now you couldn't sell small percent of chips which are actually defective. But have less SKUs to manage. I'm not sure if it would work or not, but it makes perfect economic sense. > don't like it and will go to some pains not to use CPUs with this kind of anti-feature Yeah, that's what stops these incentives. PR backlash. But as R&D prices for CPUs go up and prices of unused silicone goes down the incentive to switch to that model becomes more and more acute. Actually the problems with Dark silicon almost guarantee that said model would become the norm eventually. When you couldn't power all the transistors on the chip simultaneously for thermal reason the ability to pick between features A, B, and C (either of which can be enabled but not all simultaneously) make such scheme pretty attractive. You couldn't do that with millions of SKUs but can easily achieve with million of [potential] licenses. And in that case the ability to enable features without license would become actively harmful: enabling all features simultaneously would just fry the chip and it would be pretty hard to prove in warranty service that this happened because of customer irresponsibility, not because of customer's misuse. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 12:58 UTC (Sat) by Wol (subscriber, #4433) [Link] Going back many years, to microcode running on processors with speeds in KHz arena ... 50-series Pr1mes actually came with a microcode update if you were running INFORMATION (aka Pick) on them, it added a whole bunch of instructions specially optimised for handling strings, to make the database more efficient. THAT would be an interesting feature on modern silicon :-) Cheers, Wol [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 15:06 UTC (Sat) by mfuzzey (subscriber, #57966) [ Link] >enable features without license would become actively harmful: enabling all features simultaneously would just fry the chip and it would be pretty hard to prove in warranty service that this happened because of customer irresponsibility, not because of customer's misuse. Surely this case could be handled in hardware by only accepting configurations enabling at most any 2 of features A, B, C (or whatever other thermal / power constraints exist). I don't see why this would require a license based system to be safe [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 15:10 UTC (Sat) by khim (subscriber, #9252) [Link ] This would only work if you can, somehow, determine which combinations are actually safe and which may do harm based solely on some simple calculations. If you need to do any kind of testing, then license would be perfect way to ensure that everything works perfectly. That's minor issue, ultimately. Economic need to differentiate markets drives the effort to a much larger degree than technical needs. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 9:12 UTC (Sat) by Cyberax ( supporter , #52523) [Link] > Nope. You are forgetting an elephant in the room: price of set of photolithography masks and design cost for these masks. Sure. But this works only if you don't have competition. Because it's easy to undercut others on features otherwise. After all, it doesn't cost you anything extra to enable a feature that your competitor doesn't have. We're already seeing this with AMD, it's steadily eating into Intel's server marketshare that had been unassailable up until ~3 years ago: https://www.tomshardware.com/news/intel-amd-4q-2021-2022-... [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 11:57 UTC (Sat) by khim (subscriber, #9252) [Link ] > But this works only if you don't have competition. If you have competition then it becomes even more important. > After all, it doesn't cost you anything extra to enable a feature that your competitor doesn't have. It would cost you a lot. If you would stop selling $299 Ryzen 5 5600X (which is, essentially, $449 Ryzen 7 5800X with two cores disabled) and would start selling Ryzen 7 5800X for $399 instead of having these two... you would lose both on people who were ready to spend $449 and on ones who were ready to buy something for $299. I took example from AMD book, not Intel book to show that as competition grows more acute the need to disable features and sell crippled product grows, not diminishes. Market segmentation is powerful tool. When AMD had no ability to make powerful CPUs (for many years AMD's CPU before Ryzen were awful) -- because it was hard to sell even CPUs with even all features enabled (and it was losing money as the result). When AMD made something for the top tier -- it started marked segmentation games (and immediately become profitable). > We're already seeing this with AMD, it's steadily eating into Intel's server marketshare that had been unassailable up until ~3 years ago And this has nothing to do with the fact that AMD presented 7nm EPYC Rome two years ago while Intel still couldn't make 10nm Xeons (10nm of Intel is more-or-less the same as 7nm of TSMC), but everything to do with the fact that EPYCs are less segmented? Dream on. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 15:11 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] It isn't just an issue of competition in the market. Fab capacity of each company and the overall market is a factor. Currently, the entire world is maxed out on wafer starts. So while it probably saves on masks, validation, etc. to cripple a perfectly functional 16core die to be sold as an 8core die, that means there is an 8core die area of silicon that is now lost. In a situation where every cpu produce can be sold, that lost real estate represents a potential 100% increase in gross margin. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 15:19 UTC (Sat) by khim (subscriber, #9252) [Link ] If we have lived in a world where every CPU can be sold then we would have seen similar craziness to GPU market where prices are 2x-3x recommended price. And GPU makers don't, actually, embrace that craziness, they fear it because they know what comes next: governments would say that cryptocurrency mining is a criminal activity, GPU sales would drop through the floor and they would be selling them at loss for some time. Fab capacity is strained not because it's impossible to build mode fabs, but because it's impossible to do that profitably: build cycles are many years, investment are measured in billions and unused fabs are not aging well. Thus no, your reasoning doesn't make sense long-term. And CPU/GPU manufacturing is long-term process, it takes many years to develop CPU from scratch and year or two just to do minor alterations. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 16:10 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] I was just quoted a 26+ week lead time on any zen3 epyc cpu with >= 32cores from a major manufacturer. I ended up accepting zen2 cores in order to cut the estimated lead time in half. However, the price will start to float at the market rate 90days from the date the quote was issued. I won't even know the final cost until I'm invoiced for the shipment. If this isn't a CPU shortage, I don't know what one would look like. The GPU and CPU makers are all bidding on the same fab capacity. When AMD reserves wafers at TSMC, that's capacity that is denied to Apple/ Nvidia/Intel/etc. and vice versa. The ability to build new fabs is not unlimited. Bleeding edge fabs need equipment from ASML who reports that they and their supply chain are already maxed out. The world is essentially already building new fab capacity at the maximum rate they can get lithography equipment. The rumors are that TSMC is booked out *years* in advance at the 5, 4, and 3nm nodes. Are you arguing that AMD is going to produce 128core zen4s and then cripple perfect dies down to 16c core parts instead of taping out multiple designs that use the exact same logical blocks, when all that lost real estate could have instead been used for GPUs or ~5-7 additional CPUs? [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 17:12 UTC (Sat) by khim (subscriber, #9252) [Link ] > I was just quoted a 26+ week lead time on any zen3 epyc cpu with >= 32cores from a major manufacturer. I ended up accepting zen2 cores in order to cut the estimated lead time in half. That's nice piece of data. Let's try to decipher it, shell we? 1. You asked for latest-and-greatest cores and got promise to receive them when they would be made (you may not know that, but half-year or more is not atypical if we are talking about manufacturing of complex 7nm chip: they require almost hundred masks and application of one mask takes full day or more, depending on how much load fab experiences right now). The exact same thing happened with surprisingly good R300 back when it was hot -- yet somehow back then noone was bawling their eyes out and complained about shortage of fabs. Everyone accepted that it was simple management miscalculation. 2. When you asked for less "hot" chips made by the exact same manufacturer in the exact same lab by the exact same producer you got shorter times because, apparently because there are surplus of these in production. 3. Yet it's very easy to buy consumer-grade chips with Zen3 core. The full nomenclature from lowly Ryzen 5 5600X (which my friend bought in India two days ago) to Ryzen 9 5950X (which I bought at the same time). Prices are less than what recommended prices are. Many of these are artificially crippled. Doesn't look like shortage of CPUs to me, sorry. > If this isn't a CPU shortage, I don't know what one would look like. Indeed, you don't know that. When you need to pay 10x or 100x price to receive 250nm chip (like some automotive chips are selling for right now) and situation stays that way for years -- then you can say there are shortage of chips. Till then it's normal reaction of market on changes in demand and supply for something that takes years to produce coupled with customers who, naively, expect to buy the same thing with lead times measured in weeks. JIT-manufacturing, both good and bad sides of it. > The rumors are that TSMC is booked out *years* in advance at the 5, 4, and 3nm nodes. Why do you say these are rumors? That's the reality. Latest nodes are always booked years in advance. Because fabs are extremely expensive yet they can only ask for extra-premium prices for latest nodes for a few years... nobody builds spares. You don't even need rumors to confirm something that was always true. > The GPU and CPU makers are all bidding on the same fab capacity. Nope. That's not true because of, as you have said yourself: fab capacities are booked years in advance. Essentially they are booked when labs are built or maybe a bit later. If they are already booked then there are no competition between customers. > When AMD reserves wafers at TSMC, that's capacity that is denied to Apple/Nvidia/Intel/etc. and vice versa. No, they just build more fabs. > Are you arguing that AMD is going to produce 128core zen4s and then cripple perfect dies down to 16c core parts instead of taping out multiple designs that use the exact same logical blocks, when all that lost real estate could have instead been used for GPUs or ~5-7 additional CPUs? No, I'm saying that if you don't want shortages you don't disrupt markets by printing trillions of unbacked money and using all tricks you can imagine to avoid 40-50% inflation... mechanism where you have to calculate number of chips you need to order five years in advance but where buyers expect lead times measured in weeks works if you can predict number of buyers, but if you break that mechanism... it stops working. This is completely unrelated to selling crippling CPUs. Ryzen 5 5600X and Ryzen 9 5900 are still being produced and sold despite the fact that you can sell the exact same chips as Ryzen 7 5800X and Ryzen 9 5990X. Turning 128 core chip into 16 core chip wouldn't make any sense because AMD embraces chiplets architecture thus you can just use more or less chiplets. But if you want to shave off 2 cores or 4 cores... AMD does that and is happy to sell these at discount prices. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 19:07 UTC (Sat) by Cyberax ( supporter , # 52523) [Link] > It would cost you a lot. If you would stop selling $299 Ryzen 5 5600X (which is, essentially, $449 Ryzen 7 5800X with two cores disabled) and would start selling Ryzen 7 5800X for $399 instead of having these two... you would lose both on people who were ready to spend $449 and on ones who were ready to buy something for $299. Except that you can undercut Intel and sell Ryzen 7 5800X for $299 and immediately crush Intel. Otherwise Intel will just push you out with cheaper and faster CPUs. In reality, cores are usually locked because they fail internal QA - this is indeed a perfectly valid strategy. > I took example from AMD book, not Intel book to show that as competition grows more acute the need to disable features and sell crippled product grows, not diminishes. Market segmentation is powerful tool. Not following. Once the competition starts biting, there's a pressure to unlock more and more features on the low-end of the spectrum. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 8:24 UTC (Sat) by zdzichu (subscriber, #17118) [ Link] Is it different, really? It sounds exactly like unlockable Pentium G6951 from 2010 (mentioned in comments here), but with Linux driver this time. [Reply to this comment] the name of this "feature" is appalling Posted Feb 18, 2022 20:50 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] If there is no FPGA, CPLD, or microcode involved than the name of this "feature" is badly inaccurate, even by the usual marketing standards. This is nothing more than MSRs to turn on and off features baked into the die. I am skeptical that even "enterprise", let alone "hyperscaler", customers are enthusiastic about having to deal with per socket license entitlement. AMD is going to finally start shipping avx512 support. It seems like adding avx512 to "e-cores" for a consistent desktop/server fp abi would have been a much more productive use of engineering time. [Reply to this comment] the name of this "feature" is appalling Posted Feb 18, 2022 21:12 UTC (Fri) by developer122 (subscriber, # 152928) [Link] Can you imagine if we still had to pay per-CPU software licences for operating systems? https://megatokyo.com/strip/549 [Reply to this comment] the name of this "feature" is appalling Posted Feb 19, 2022 1:58 UTC (Sat) by flussence (subscriber, #85566) [Link] This is the first I've heard of AMD having plans for AVX512. I thought they didn't see it going anywhere? [Reply to this comment] the name of this "feature" is appalling Posted Feb 19, 2022 9:36 UTC (Sat) by developer122 (subscriber, # 152928) [Link] I'm surprised. Intel is killing it off with Alder (lava) Lake. [Reply to this comment] the name of this "feature" is appalling Posted Feb 19, 2022 11:32 UTC (Sat) by pbonzini ( supporter , # 60935) [Link] It's still there on server parts, and with growing functionality. [Reply to this comment] the name of this "feature" is appalling Posted Feb 19, 2022 13:29 UTC (Sat) by khim (subscriber, #9252) [Link ] Intel overestimated the speed of changes in the software realm. Alder Lake have some cores which support AVX512 and some that don't support it yet. I guess the optimistic thinking was that software would adopt, somehow. But software was barely able to adopt cores with different speed, neither Linux nor Windows is ready to deal with cores with different instructions sets! Thus it was easier for Intel to disable it rather then try to create some buggy driver which would do something with that mess. [Reply to this comment] the name of this "feature" is appalling Posted Feb 19, 2022 15:33 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] It has been widely reported that zen4 will finally add avx512, including leaked screen shots of an AMD manual. AFAIK there has been no public confirmation from AMD. There are probably enough engineering samples floating around at this point that we will know one way or the other soon. Avx512 complicates the decision as to whether or not to use a gpu for fp intensive code. It is a lot easier to change some compiler flags/add some code annotations than committing to debugging a cuda pipeline. Without fancy SIMD instructions, the choice of cpu is less relevant as the system will probably have one or more Nvidia gpus installed anyways. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 21:06 UTC (Fri) by wittenberg (subscriber, #4473) [Link] Amdahl made this a feature. You paid for a small machine, and could upgrade it (via software) whenever you needed the faster machine. Since you were renting the machine anyway, this placed a small administrative burden on everyone. In essence, this is the elasticity that we now praise in cloud computing. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 22:45 UTC (Fri) by ejr (subscriber, #51652) [Link ] This. Doubling down, this is about ensuring cloud providers negotiate appropriate fees. Unless competitors undercut these fees. So it's a temporary thing. Intel won by nuking these constraints once upon a time. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 21:48 UTC (Fri) by MattBBaker (subscriber, # 28651) [Link] IBM has tried this before in the server market. Racks of fully populated machines, and then you would install a license in the BIOS to unlock capabilities. Rumor is that the target of this was Amazon, which needed a way to run their website over Christmas, but not over buy on compute for the rest of the year. Instead, Amazon started AWS and rented out their excess capability. It seems unlikely Intel is eyeballing "Matt's desktop". It feels like this will be DOA because anyone that Intel would eye up for this would instead go to ARM for custom chips. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 21:59 UTC (Fri) by kunitz (subscriber, #3965) [ Link] There are a number of details that will be interesting to understand. Those certificates must be specific for a CPU; you don't want customers to run a whole fleet with a single feature certificate. What will be the lifetime for the root certificate? Can it be exchanged? If not this is an interesting mechanism for implementing planned obsolescence. I can understand why Intel is doing it. Right now they have to blow off fuses to generate different SKUs. In the future they have one SKU but can still do price segmentation. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 18, 2022 22:59 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] Intel will still have to have a huge number of SKUs to make use of the chips with defects in cores, L2, L3, etc. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 13:45 UTC (Sat) by atnot (subscriber, #124910) [ Link] This is what chip manufacturers always point to, however from people in the industry the reality is that especially as the process matures, most dies are able to hit high bins without issues. There isn't really a technical need for more than two or three SKUs per design. As e.g. AMD has shown by only releasing three real desktop SKUs in the 5000 series. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 15:36 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] I know next to nothing about ICU manufacturing but couldn't that also be a sign as to the differences in TSMC vs Intel defect rates? [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 3:40 UTC (Sat) by k8to (subscriber, #15413) [Link ] I feel like the natural consequence of "let's put software in everything" is that everything will be full of bugs and security problems. I'm not really a fan of rentier models, but I think the technical problems that will come are enough to make this a bad idea. Sure there are examples of doing this in the mainframe era, but mainframes were not living in our modern world of security attacks. Additionally, the pricetags and dev cycles of those systems meant that a lot more attention was given to the implementations at least in an attention / complexity ratio sense. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 6:51 UTC (Sat) by pabs (subscriber, #43278) [Link ] This reminds me of when HDCP support was added to Linux/etc: https://drewdevault.com/2019/10/07/HDCP-in-Weston.html [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 7:26 UTC (Sat) by mcon147 (subscriber, #56569) [ Link] Linux isn't required to take anyone's patches, accepting them is a deliberate choice. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 8:14 UTC (Sat) by gioele (subscriber, #61675) [ Link] Just for historical context: somewhat similarly to Intel Upgrade Service, Raspberry Pis until version 4 used to come with disabled MPEG-2 and VC-1 hardware acceleration blocks. To enable them you needed to buy a key [1,2]. The firmware took care of uploading the key to the right HW register. [1] https://codecs.raspberrypi.com/mpeg-2-license-key/ [2] https://codecs.raspberrypi.com/vc-1-license-key/ [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 18:01 UTC (Sat) by ermo (subscriber, #86690) [ Link] Out of curiosity, why was this handled like this? Was it because the IP for the hardware blocks in question was owned by someone else than the SoC supplier (MPEG LA vs. Broadcom) in this instance and that, due to wanting to keep the BoM as low as possible to hit the intended RPi price point, this was necessary for the RPi foundation? Or am I getting it all backwards? [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 18:24 UTC (Sat) by excors (subscriber, #95769) [ Link] Because of the MPEG LA patent licensing fees. From https:// www.raspberrypi.com/news/new-video-features/ : > One of the things that we had to regretfully dismiss as an option was an MPEG-2 decode licence for every unit. Providing that licence would have raised the price of every Raspberry Pi by roughly 10% > We've spent some months working out how on earth to square this particular circle. A blanket licence for everybody would cost the Foundation money it simply doesn't have, and not everybody with a Raspberry Pi would use that licence; an individual licence for an individual user to download and use with an individual machine is a surprisingly finickity thing to engineer. [...] But that's what we've done (They already paid a blanket licence fee for H.264 decode/encode, so that was enabled by default.) I don't believe the individual licence key is used by the hardware blocks in any way; it's merely verified by the Pi's proprietary firmware before enabling the APIs that make the hardware accessible from Linux. Some naughty people hacked the firmware so the verification function would always return true - it's not particularly secure, but it was apparently good enough to keep the MPEG LA happy. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 13:53 UTC (Sat) by b3nt0box (subscriber, #98698) [Link] IBM has been doing this with mainframes for a long time. I think that is the area where this is intended to play. Large systems installations where the hardware is never actually "owned" but leased. [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 14:50 UTC (Sat) by jeffreypmcateer (subscriber, # 140200) [Link] I'm surprised at the number of people completely ignoring the very real possibility that the lockout implementation will be heavily flawed; Intel CPUs haven't exactly been faithful to their ISA plans in recent years. I fully expect within 3-5 years an exploit to surface giving everyone access to all of their CPU features, after which point Intel will lawyer up and play the DRM game. In this scenario private cloud gets a huge advantage; they can move illegal CPUs behind legal nginx servers, while public cloud has to pay the full cost of licensing each CPU. Private consumers don't even come close to mattering, nobody has the legal capacity to just "sue all our customers" (besides, you lose a lot of customers who were on the fence but still buying). [Reply to this comment] Thoughts on software-defined silicon Posted Feb 19, 2022 16:04 UTC (Sat) by felixfix (subscriber, #242) [ Link] Is the key unique to each chip, or the same for them all? Seems likely to leak sooner rather than later. [Reply to this comment] Copyright (c) 2022, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds