[HN Gopher] Intel updates mysterious 'software-defined silicon' ...
___________________________________________________________________
Intel updates mysterious 'software-defined silicon' code in the
Linux kernel
Author : flipbrad
Score : 123 points
Date : 2021-12-08 11:49 UTC (11 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| luma wrote:
| > The code outlined a process for enabling new features by
| verifying cryptographically signed licences
|
| This smells a lot like laying the groundwork for locking
| processor features behind a license key. Get ready for a monthly
| CPU license plan...
| kllrnohj wrote:
| Intel's been doing this for 5 years already:
| https://www.intel.com/content/www/us/en/support/articles/000...
|
| You have to buy some stupid dongle to enable "Intel(r) Virtual
| RAID on CPU" feature, and it's like $100 or something silly.
| johnchristopher wrote:
| Ahem https://codecs.raspberrypi.com/mpeg-2-license-key/
| reasonabl_human wrote:
| Hadn't seen this before.. and this license key operates at
| the hardware level, not the OS level? One can't expect mpeg
| hw decide to function with arch or nix installed on a
| raspberry pi instead?
| pjc50 wrote:
| Hardware level. It's a compromise imposed on the chip
| builders because the MPEG decoder or part thereof that
| they're using is subject to patent licensing. So in order
| to not pay the patent license, it's shipped locked-out.
| When you pay them a chunk goes back to the licensor
| (presumably MPEG-LA).
| colejohnson66 wrote:
| Although the later models have fast enough CPUs to not
| need the hardware decoding
| ksec wrote:
| >(presumably MPEG-LA).
|
| MPEG 2 has been patent free since 2018 in US and 2020
| worldwide. Along with AAC-LC. They are charging for
| license key for the usage of that specific decoder block
| only. i.e The IP of the actual HW decoder, not the codec
| itself.
|
| MPEG 2 and VC1 is so low in complexity you are software
| decode it with minimal CPU resource on RPi 4.
| duskwuff wrote:
| > MPEG 2 has been patent free since 2018 in US and 2020
| worldwide.
|
| The patents were still active, and the technology was
| still useful, when the Pi Foundation started selling the
| license keys in 2012. Nowadays... yeah, they're
| irrelevant.
| buran77 wrote:
| The devil's in the details but if the price is right then this
| isn't fundamentally worse than any CPU with factory disabled
| cores. The difference being that you could now pay to unlock
| the feature instead of buying a whole new CPU.
|
| On the other hand if I have no guarantee the license is valid
| forever and I _own_ it, or that I can use it in any conditions
| not just with internet connectivity, or it 's tied to the rest
| of the machine, or only until I want to sell my hardware, then
| it does become fundamentally worse.
|
| This might be a new way to enable more flexibility for cloud
| providers so they can customize each offering without having
| different sets of hardware, just a license management
| component. I also see this as something OEMs may be interested
| in, tiering otherwise identical products could be just a FW
| switch away, greatly simplifying logistics and manufacturing.
| OEMs could customize the CPUs they receive while Intel would
| shrink the number of SKUs. Being Intel though means none of the
| savings will ever reach the consumer.
| wtallis wrote:
| Cores that are permanently disabled from the factory help
| improve yields. Features that can be turned back on later
| don't, because they still need to pass QA.
| smachiz wrote:
| They can also improve monetary yields. On mature processes,
| the yields are probably higher than demand - cores are
| being disabled because they have more buyers for a 32 core
| than a 48 core chip.
|
| If they can sell another 16 cores at no incremental cost
| post sale, that's attractive. As long as it doesn't prevent
| that customer from buying a whole new 48 core chip from
| them, anyway.
| wtallis wrote:
| When Intel starts disabling cores that are fully
| functional, then the practice shifts over into the bad
| column of _artificial_ product segmentation. It may be
| good for _Intel_ , but it's a problem for consumers.
| Likewise, features that ship to every customer but can
| only be turned on by eg. Amazon are worrying for obvious
| reasons.
|
| The only reason why we tolerate such clear signs of
| market failure is because in the larger picture, Intel
| _et al._ need to keep their margins high and consistent
| to keep Moore 's Law alive(ish). Maintaining such a fast
| pace of progress is probably better for customers in the
| long run, even if it means getting ripped off in the
| short term. But _without_ such a benefit to make the
| tradeoff worthwhile, customers and economic policymakers
| would be right to be incensed when Intel uses wasteful
| tactics like disabling defect-free silicon in order to
| insulate their price sheet from the true supply and
| demand dynamics of their market.
| buran77 wrote:
| > The only reason why we tolerate such clear signs of
| market failure is because in the larger picture, Intel et
| al
|
| Let's not forget our history here. I'm not a big fan of
| Intel but any techie will remember we successfully
| "tolerated" such practices decades ago when the Celeron
| 300A ran at double frequency, the Radeon X800 series got
| 50-100% more pixel shaders, or the Phenom X3s got 33%
| more cores for free. If anything customers were
| rejoicing.
|
| The market was always artificially segmented. The only
| reason we don't know today whether disabled blocks are
| good or not is that manufacturers have gotten better at
| keeping them disabled.
|
| You'd be hard pressed to tell me the actual real life
| difference _for you_ between a $300 4-core CPU with 2
| cores fused off, and a $300 4-core CPU with 2 cores
| licensed off.
|
| > Intel uses wasteful tactics
|
| Intel fashion dictates the user will see little benefit
| but differentiating SKUs in software is certainly less
| wasteful from the manufacturer's and OEM's perspective.
| The logistics alone might be worth it.
|
| Software manufacturers ship full installers with features
| disabled in licensing. Streaming services store all
| content but serve you a lower quality one based on your
| particular "license". Car manufacturers sell essentially
| the same engine with different power outputs.
|
| As I said, there are no bad products, just bad prices.
| wtallis wrote:
| You seem to be ignoring that the hypothetical alternative
| would be a market with prices with downward flexibility,
| such that rather than gambling on unsupported hacks, you
| could instead get more cores for your money just by
| waiting for later in the product cycle. A 4-core chip
| with two fuzed off at $300 and a 4-core chip with two
| licensed off at $300 are _definitely_ not equivalent
| options to be comparing, because in a market with no
| artificial product crippling Intel 's price sheet would
| have to change.
|
| The fact that artificially crippling chips is not new
| does not mean it's a good thing. Having accepted a
| tradeoff doesn't erase its downsides.
| buran77 wrote:
| The distinction is purely academic and it explains the
| "why" but doesn't change the "what". For all intents and
| purposes the components have some features inaccessible for
| [reasons]. Similar to how features licensed in software are
| still usually present in the shipped libraries. What makes
| the difference are the price and the licensing terms for
| unlocking that feature.
|
| Chips have been known to have perfectly functioning blocks
| disabled, or frequency limited not for improved yields but
| simply because the demand for a lower end SKUs was so high.
| Unlocking them was a matter of penciling some fuses,
| flashing a firmware, or simply changing a setting in the
| BIOS.
|
| If anything this kind of licensing opens the door to
| "hardware piracy" where under the correct conditions you
| may be able to hack older, or unsupported hardware to gain
| the full functionality.
| BizarroLand wrote:
| It makes sense for unlockable cores on server grade
| hardware, it would allow bootstrapping companies to buy
| in low and then upgrade on demand, but it's pretty safe
| to say that this is going to overflow into the user
| space, where you can buy a 16 core processor for your max
| budget and then find out there are another 16 cores that
| software prevented you from accessing and that would
| require a monthly fee to unlock, which is ridiculous.
| mrcode007 wrote:
| It's been going on for years. Almost every Intel CPU has a
| cryptographic key embedded in it. If you get a special license
| from Intel you get a full unlock which allows you to "get root"
| on the CPU and have full debug capabilities. This is how UEFI
| and other low level software get debugged during CPU bring-up
| for example.
| dirtyv wrote:
| Sounds like Intel plans on doing the same thing with their chips
| that Tesla does with its batteries.
| gentleman11 wrote:
| Is amd the same about adding secret blobs to their hardware?
| my123 wrote:
| Yeah, the PSP with its opaque firmware even handles DRAM
| initialisation on Zen processors, so that you cannot run
| without it at all.
| mrcode007 wrote:
| A lot of DDR initialization code is heavily patented and
| often considered a "trade secret" which is why it's rarely
| released and publicized. It's not that complicated if you
| know hardware and work with the official internal data sheet.
| I've seen those as part of partnership between CPU vendors
| and my workplace. You get to read them on a special Remote
| Desktop so you don't copy them. Same for ME. Once you know
| what's actually in the code the conspiracy theories do seem
| funny :)
| not1ofU wrote:
| This guy now works for intel: DEF CON 26 - Christopher
| Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted
| x86
|
| https://www.youtube.com/watch?v=jmTwlEh8L7g This is one of
| many amazing videos this guy did before they hired him.
| floatboth wrote:
| Marvell has their DDR3+4 initialization straight on GitHub:
| https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell
| (even this includes a Synopsys blob for the PHY, but only
| on some platforms -- no blobs on A70x0/A80x0 thankfully)
|
| It's really stupid that other vendors can't just do the
| same.
| my123 wrote:
| The code involved isn't even that long... but mistakes can
| result in very annoying behavior. Debugging issues with
| that code is a pain.
| mrcode007 wrote:
| Yes, it's a huge pain to the point where you don't want
| to be stuck fielding support calls from enthusiasts
| tweaking things on their own. Huge pain in debugging this
| code
| coldacid wrote:
| The conspiracy theories are funny, but the bullshit
| situation of being locked out of things you yourself OWN
| isn't. I think that's what most of us hate about things
| like ME or PSP.
| floatboth wrote:
| ME/PSP isn't that offensive in terms of "locking you
| out", it's just a coprocessor that's _there_. Intel Boot
| Guard on the other hand can actually prevent custom
| firmware from running.
| my123 wrote:
| Being a TPM is one of the Intel ME and PSP's
| functionalities. Making a TPM that'd be secure against
| custom firmware is possible, but isn't very implemented
| across the industry.
|
| It'd need measuring the hash of the loaded firmware
| itself to hardware managed PCRs that affect the hardware
| crypto engines. Something that's done on the Secure
| Enclave for Apple A13 onwards AFAIK.
|
| (also... managing DRM systems, they'll have to be put on
| a coprocessor somewhere.)
| smolder wrote:
| It's not a wild conspiracy theory that there's an
| unlabelled "High Assurance Platform" bit on Intel platforms
| to disable the Management Engine. The same sources that
| identify the bit as "HAP" control claim it was requested by
| three letter agencies. I set it, and it does
| disable/debilitate the ME, so that much is true. That the
| option exists at least suggests that the ME is an attack
| surface worth worrying about for someone, i.e. state level
| actors, even if it's not known to be exploitable.
|
| I assume you meant to be a help by assuring people their
| computers aren't backdoored, but I don't think you have the
| certainty to claim ME is sound and secure. It just reminds
| me of how well-meaning people insisted the USG wasn't
| interested in capturing everyone's communications, back
| before it was accepted fact, pre-Snowden.
| StillBored wrote:
| Its commendable, but if you look closely
| https://github.com/MarvellEmbeddedProcessors/mv-ddr-
| marvell/... its not all "open". I think there is a fair
| amount of discussion about whether poking a bunch of random
| values into random registers is "open".
| seanhunter wrote:
| This reminds me of a story told to me by a work colleague who
| began his career on Mainframes in the late 70s. One work place he
| was at paid several million for a major upgrade to their IBM
| mainframe. A guy in a white lab coat showed up, took the side
| panel off the mainframe, _removed_ a circuit board and gave them
| a piece of paper to sign saying the job was complete.
| acchow wrote:
| What did that circuit board do?
| outworlder wrote:
| Hardware-based sleep()? :)
| Taniwha wrote:
| We had a Burroughs 6700, at some point (late 70s) we agreed to
| pay for what was called the "$50,000 screwdriver" which upped
| the clock speed - we wrote a contract where we would run a
| benchmark before and after and if it wasn't X% faster we
| wouldn't have to pay. We ran the before benchmark, the field
| engineer went into the cabinets to up the speed, came back
| looking sheepish, seems he'd regularly been turning the clock
| speed up during preventative maintenance sessions to make sure
| the machine was performing OK and at some point had forgotten
| to turn it back .... we didn't have to pay
| Taniwha wrote:
| Also I designed a Mac graphics accelerator gate array back in
| the late 80s, we were worried that the promised VRAM
| performance would not be fast enough so I designed in the
| ability to add extra clocks to RAS and CAS timings - it ran
| at full speed which was great, but marketing wanted a lower
| price-point version of the graphics card so we sold one with
| a ROM that turned on those extra RAS/CAS clocks
| PeterisP wrote:
| It's not an ancient practice, I recall a case in the early
| 2000s where we got an expensive CPU upgrade to a mainframe
| which was not implemented by "a guy in a white lab coat" but as
| a one-line script (with a cryptographic key) to unlock more
| CPUs which were already installed on the system when it was
| first shipped.
| squarefoot wrote:
| It's a very common practice, not just in computers. Many
| digital oscilloscopes (and probably other instruments too) can
| be hacked by just editing a file or flashing a new firmware.
| The purpose in scopes is making them behave as more expensive
| models with much higher bandwidth, which means that faster ADCs
| and circuitry is already there, but not used to its full
| potential so that the device can be placed in a lower market
| segment and sold cheaply.
|
| https://nyctomachia.wordpress.com/2018/09/02/riglol-unlock-e...
|
| https://www.makermatrix.com/blog/hacking-the-siglent-1104x-e...
|
| ..etc.
| ts4z wrote:
| Tesla sold 75kWh cars to people who bought 60kWh cars. Then,
| during the wildfires here in California, they remotely unlocked
| the extra 15 for people trying to get out of town. If you
| wanted to get access to what you had legal title to, well,
| that's an upcharge.
| wiedehopf wrote:
| With batteries it's a bit more complicated as LiIon degrades
| faster at higher charge levels / voltages. So you're trading
| longevity for extra capacity in that case.
| amelius wrote:
| Business practices should have their own book of law, which
| says what is and what isn't acceptable.
| OldManAndTheCpp wrote:
| Isn't that just contract law?
| amelius wrote:
| The problem is that the law is too abstract and not
| sufficiently exhaustive to address all the disingenuous
| schemes used by businesses.
| ethbr0 wrote:
| Isn't this the same as SaaS thinking, albeit in the hardware
| era?
|
| For the more common story of IBM enabling present but disabled
| memory, they couldn't magically teleport a new memory board
| into your mainframe. But they could ship your mainframe with
| extra, verified but disabled memory.
|
| Customer UX for memory upgrades then changes from "Wait for it
| to ship, etc" to "We'll have it done tonight."
| seanhunter wrote:
| Yes indeed. These kind of things afflict enterprise IT all
| the time.
|
| I used to run b2c teams which dealt with big banks. One
| bank's IT department used to bill internally for data center
| costs using RAM as a proxy for energy usage. A big spark
| cluster was purchased for the project I worked on and the
| minimum RAM for the spec of machine that was "standard" was
| 128MB, so to "save costs" they had the data center guy take
| out half the memory in every machine before racking it up.
| :-(
| literallyaduck wrote:
| Binary blobs are a security threat, a right to repairs threat, an
| ownership threat.
| coldacid wrote:
| Whatever happened to having chips that didn't have all this
| secretive scummy nonsense behind it? I feel like we should just
| roll back to the 68k era at this point.
| tenebrisalietum wrote:
| ACPI is to blame because it specifically enabled laptop
| manufacturers to hide platform hardware details behind a shitty
| firmware interface instead of providing OS drivers/hardware
| details to driver developers, and it was around that time that
| SMI became a thing on Intel CPUs and platform firmware started
| to use that for fan control, instead of depending on the OS to
| do that.
| StillBored wrote:
| ACPI is a huge part of the reason that linux works at all on
| x86, and in many cases is as popular as it is. If it acted
| more like arm boards where pretty much nothing works right,
| no one would use it for general purpose computing. There are
| literally hundreds and hundreds of drivers for PMICs, clock
| dividers, GPIO pin muxing/etc for the hundred or so boards
| that sorta work, and each one needs customization that takes
| months/years every time something gets tweaked on the
| board/etc.
|
| ACPI allows random x86 board vendors to literally have
| hundreds of products themselves that not only boot linux, but
| a pile of other OS's because they aren't wasting their time
| writing drivers for every single board and voltage regulator.
|
| So, call it shitty, but understand that its the reason you
| can boot a single linux image on everything from an atomicPi,
| to HP superdome flex, and the thousands of desktops/etc being
| customized by people in their bedrooms.
|
| Its also largely the reason why linux works on 20 year old
| PC's that no one is actually testing on anymore.
|
| The alternative is a monoculture where the HW is basically
| provided by a single vendor that doesn't change much and
| provides a half dozen supported configurations. I would point
| to the zseries here because that is effectively how it works,
| but it also has a huge hw/firmware abstract machine that
| allows IBM to change the underlying HW details without having
| to rewrite all this low value garbage.
| tenebrisalietum wrote:
| > There are literally hundreds and hundreds of drivers for
| PMICs and voltage dividors, GPIO pin muxing/etc for the
| hundred or so boards that sorta work, and each one needs
| customization that takes months/years everytime something
| gets tweaked on the board/etc.
|
| There's literally tens of thousands of devices for the PC
| platform and Linux has no problem supporting them if the
| hardware can be documented. Why can't the vendor document
| that instead of hiding this stuff behind opaque binary
| blobs that can have security vulnerabilities? Whether this
| is ARM or x86 doesn't matter.
|
| > ACPI OTOH allows random x86 board vendors to literally
| have hundreds of products themselves that not only boot
| linux, but a pile of other OS's because they aren't wasting
| their time writing drivers for every single board and
| voltage regulator.
|
| I'm parsing this as "ACPI OTOH allows random x86 board
| vendors to develop shitty hardware, cut corners on
| documenting it, and not care as long as Microsoft OS's boot
| on it."
|
| > they aren't wasting their time writing drivers for every
| single board and voltage regulator.
|
| Document the damn registers and hardware interfaces and
| then someone out there will write it for them.
|
| > Its also largely the reason why linux works on 20 year
| old PC's that no one is actually testing on anymore.
|
| Well Linux still supports hardware that predates ACPI, like
| floppy drives, so this is making a connection where there
| is none.
|
| > The alternative is a monoculture where the HW is
| basically provided by a single vendor that doesn't change
| much and provides a half dozen supported configurations.
|
| Wrong. Before ACPI, for example, there were many chipset
| vendors--Opti, VIA, etc. ACPI didn't kill these off but
| there wasn't a monoculture before ACPI.
|
| > I would point to the zseries here
|
| So ... do we want an IBM-mainframe like monoculture where
| you have to depend on IBM when the hardware changes?
|
| > allows IBM to change the underlying HW details
|
| The job of abstracting the hardware details is the
| operating system and operating system drivers. Literally
| that's 50% of the reason why you have an OS in the first
| place is to abstract I/O into things like open(), read(),
| write() or other interfaces that are portable because of
| underlying drivers. If the hardware is so different that
| existing I/O calls can't handle it, you need to develop new
| ones - that's what happened with Berkely sockets - NICs are
| not block or character devices.
|
| If the drivers are open source then they are bug-
| correctable and useable even well after the hardware
| manufacturer goes away. Embedding that in closed-source
| platform-firmware makes you dependent on that platform
| manufacturer. A strong contributor to the Wintel monopoly.
| StillBored wrote:
| Wrong. Before ACPI, for example, there were many chipset
| vendors--Opti, VIA, etc. ACPI didn't kill these off but
| there wasn't a monoculture before ACPI.
|
| That is where your wrong, x86 PC's had BIOS and APM which
| also provided minimal platform abstractions. But there
| was a monoculture, you either provided PC/AT HW and BIOS
| compatibility or your x86 didn't work. There were HW
| "standards" for everything, be that CGA/EGA/VGA, or IDE
| controllers. Yes, you might make your own video card, but
| its absolutely supported those standards. Similarly with
| chipsets, there were closed source early boot firmware,
| but by the time the MBR was being loaded it looked like a
| 1980's PC/AT.
|
| As far as there being enough driver developers to further
| fill the kernel with all these drivers belies a
| fundamental misunderstanding of how complex even those
| arm machines are behind the scenes, even the ones that
| work likely have huge stacks of binary code running
| places that aren't visible to linux/DT. You need only
| look at some of the open or reverse engineered arm boards
| to see that. the RK3399 specs were published, what 4
| years ago at this point, and there are still rk3399 fixes
| landing. Should it take 5+ years from the release of a
| piece of hardware before linux can boot and work reliably
| on it?
|
| edit: See https://en.wikipedia.org/wiki/Option_ROM for
| where all that binary code used to hide in the 1990's
| when you plugged in random "vga" boards and storage
| controllers.
| mijoharas wrote:
| > We were sceptical of that assertion because making the effort
| to add code to the Linux kernel without planning for it to be
| used is thoroughly counter-intuitive
|
| I mean... this seems like a very good point, but from the rest of
| the article, and the previous one, it sounds like the patch was
| approved?
|
| Why was this allowed into the kernel? looks like
| drivers/platform/x86/intel/* mostly. Does intel just "own" that
| section of code? who accepts these patches?
|
| I'm not particularly familiar with this stuff so would appreciate
| someone filling me in on this.
| zamadatix wrote:
| > I mean... this seems like a very good point, but from the
| rest of the article, and the previous one, it sounds like the
| patch was approved?
|
| Intel actually said, in a short snippet where The Register
| refers to them as "Chipzilla", "If we plan to implement these
| updates in future products we will provide a deeper explanation
| of how they are implemented at that time.". One interpretation
| could be they are saying they haven't figured out if they are
| going to implement this in anything so they just added it for
| fun... I'd call that the "makes a good article" interpretation.
| The other interpretation is they plan to use the feature but
| have not yet finished planning which products will use it to
| unlock what and will talk about it in more detailed once
| planned, I'd call that the "corporatespeak decoded version". If
| you were a literal interpretation bot I would still say the
| corporatespeak version fits better than the article filler
| version hence why the extrapolations with that version don't
| match up to what is happening.
|
| > Why was this allowed into the kernel? looks like
| drivers/platform/x86/intel/* mostly. Does intel just "own" that
| section of code? who accepts these patches?
|
| I didn't look if it was actually accepted yet or just a
| proposed patchset but generally Intel will be the maintainers
| for Intel code (but not always) and they are one of the larger
| contributors to the kernel overall. You can see more details
| about maintainers and reviewers (as well as maintainers for
| sections of code) here https://www.kernel.org/doc/linux/MAINTAI
| NERS#:~:text=One%20j....
| sgnnseven wrote:
| I don't think that this is really new for Intel so they are
| very likely to use this functionality. They've done something
| similar to Pentiums about 11 years ago:
| https://www.engadget.com/2010-09-18-intel-wants-to-charge-50...
| Brybry wrote:
| I'm not an expert but: you can look at the log for any given
| file and see who authored what commit, who reviewed, who
| actually committed. For example, a different change by the same
| author [1]
|
| And you can search the mailing list[2] by commit hash/author
| name/etc and look at relevant discussion trees to see lively
| patch discussion and criticism/final pull requests/etc.
|
| I don't believe the changes in question have been merged.
|
| [1]
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
|
| [2] https://lore.kernel.org/lkml/?q=David+E.+Box
| anamax wrote:
| There was at least one IBM machine that had a similar "feature".
|
| It could run in slow-mode or fast-mode. Always-on fast-mode cost
| more per month than slow-mode. (Yes, these machines were leased,
| not sold.) However, you could get "fast-mode" on an as-
| needed/hourly-basis, for a "small" fee of course.
| [deleted]
| thedougd wrote:
| Related: https://news.ycombinator.com/item?id=29302045
|
| Intel Software Defined Silicon: additional CPU features after
| license activation
| TedShiller wrote:
| DRM?
| mdp2021 wrote:
| What will this practice mean on airgapped machines? Probably that
| their hardware will only work at a fraction of the capabilities.
| But not necessarily only that: unlocking hardware features my
| mean, depending on implementation, that at some point in time a
| network connection is assumed.
| wmf wrote:
| You should install the license the same way you install other
| software.
| jiggawatts wrote:
| I was just thinking this morning that Intel segments their market
| by the _class of person_ that is their customer.
|
| "You're a consumer, you don't _need_ error correcting memory!
| Only the upper class, I mean... your superiors... err.. sorry,
| _enterprise_ customers need that feature. It 's reserved for
| _them_ , it is not for the likes of you."
|
| Meanwhile AMD basically sells silicon by unit area. It's like
| buying gelato at the ice cream shop. You can ask for one scoop,
| two scoops, or three. You get to decide how hungry you are,
| that's it. There isn't a flavour with broken glass in it[1]
| served only to the working class stiffs, and with the glass-free
| gelato reserved only for the gentry.
|
| [1] This is pretty much what a CPU without ECC is. It randomly
| crashes and corrupts your data. Look. Not _every_ bite of ice
| cream has glass in it! There 's _very little glass_ in the ice
| cream. It 's super rare, and Intel Pty Ltd tells you that this is
| an acceptable amount of risk for you to take, because you aren't
| as important as other people.
| my123 wrote:
| > and Intel Pty Ltd tells you that this is an acceptable amount
| of risk for you to take
|
| AMD does the same thing too. Ryzen APUs don't have (even
| unofficial) ECC support, except if you pony up for a Ryzen Pro
| one.
|
| (and so do many other SoC providers...)
| StillBored wrote:
| Official support, doesn't mean it doesn't work. Although your
| right AMD does a bit of product segmentation here/there. The
| laptop space while considerably simpler is not only segmented
| by core count, but threading, and TDP.
|
| I've been expecting them to just simplify to a core
| count/memory channel/socket matrix for a while because they
| are so close. There really isn't any reason these days to
| segment by frequency beyond maybe a couple golden parts where
| all the cores run at the peak frequency.
| my123 wrote:
| > Official support, doesn't mean it doesn't work
|
| For Ryzen CPUs (ones without an iGPU), they don't fuse it
| off, and as such it can unofficially work.
|
| For Ryzen APUs (parts with an iGPU), they fuse it off, and
| as such it will never work there.
| kllrnohj wrote:
| Slightly different in the AMD case as the Ryzen Pro are the
| same socket and not really much more expensive (eg,
| https://www.amazon.com/Ryzen-4750G-Processor-3-6Ghz-
| Threads/... ). So as a consumer you can make a fairly
| straightforward value prop tradeoff there. Well, you could
| except AMD throws in the complication that they no longer
| sell APUs directly to consumers, not officially anyway. These
| are all technically "OEM only" parts.
| Dasateam wrote:
| 5600G and 5700G are sold directly to consumers, the Pro
| variants aren't. Only the 4000G series was completely OEM-
| only for some reason.
| charcircuit wrote:
| >It randomly crashes and corrupts your data
|
| My PC doesn't have ECC memory and it isn't crashing and
| corrupting my data. I think you are vastly over exaggerating.
| PragmaticPulp wrote:
| > This is pretty much what a CPU without ECC is. It randomly
| crashes and corrupts your data.
|
| I use ECC RAM in systems with error counters.
|
| Error correction is an extremely rare event, if it happens at
| all. This idea that non-ECC computers are crashing all the time
| due to memory errors isn't true.
|
| You can run something like memtest86 for days on end. You
| shouldn't see any errors at all, unless your memory is bad.
|
| The reality is that the average consumer doesn't really want to
| pay the extra amount for ECC RAM. As you said, ECC has been
| available on AMD consumer platforms for a long time and there's
| barely any uptake outside of people building servers and
| workstations with consumer-grade AMD CPUs.
|
| The AMD (Consumer) ECC story isn't perfect, either. It's not
| officially supported so there's a lot of debate around whether
| or not it's actually working on certain consumer motherboards.
| It's definitely not equivalent to the official ECC support of
| their higher-end parts.
|
| Intel, on the other hand, actually did roll out a lot of i3
| processors with full, official ECC support. These are (or were)
| a favorite for low-cost servers for this reason. It worked well
| and the support was great.
| woah wrote:
| Intel's cost is designing the circuits and the means to etch
| them, not buying the sand.
| defaultname wrote:
| "I was just thinking this morning that Intel segments their
| market by the class of person that is their customer."
|
| Just about every company in the world that sells things
| (including AMD) engages in market segmentation.
|
| A classic - https://www.joelonsoftware.com/2004/12/15/camels-
| and-rubber-...
|
| It has nothing to do with the "class of person" -- that whole
| notion seems pejorative in this context -- but maximizing how
| much you can extract in the aggregate.
|
| In the case of Intel, for years (decades?) they were their own
| primary competitor. They wanted to be sure that for a given
| customer they could extract the maximum amount possible, and
| they did this by gating some features (ECC, AVX, etc) to try to
| avoid business customers deciding to get by on "lesser"
| processors. And the simple truth is that the overwhelming bulk
| of consumer products will never, ever have an ECC relevant
| error event, which is how businesses managed to get by without
| it.
| charcircuit wrote:
| I think it would be cool to just be able to instantly get
| improvements to my machine without having to go through the
| hassle of dealing with ordering and installing physical hardware.
| vsskanth wrote:
| can someone kindly ELI5 what exactly is software defined silicon
| ? is it another term for FPGA ? or is it something more capable
| than that
| michaelt wrote:
| Back in the 1990s you could buy a big IBM mainframe with 8
| CPUs, and they'd ship you one with 16 CPUs and if you decided
| to upgrade later, they just sent a guy to flip a secret switch.
|
| This was never popular with the Free Software crowd, who
| believe in the principle that the owner of the hardware has the
| right to do whatever they like with it. They would say you have
| the right to flip the secret switch yourself.
|
| This is the same idea, but updated for the 21st century. My
| laptop came with hardware support for virtual machines - In a
| few years time, perhaps features like hardware-accelerated
| virtual machine support will be separately licensed premium
| features, instead of being stock features.
|
| Some companies already do this - for example, some Teslas have
| autopilot and long range batteries, but they're disabled in
| software. And if you buy a Tesla with those features second-
| hand, Tesla can disable them until you pay them.
| RHSeeger wrote:
| > And if you buy a Tesla with those features second-hand,
| Tesla can disable them until you pay them.
|
| Everything I've seen says this is not the case. As I
| understand it, the story in the news about "something like
| this" was misleading. The car went through a dealer and was
| sold certified pre-owned; and it was sold as not having those
| features. It turns out they forgot the disable those
| features. I you buy one from a third party that already paid
| for the feature, it stays with the car.
|
| At least, that's the understanding I was left with.
| DebtDeflation wrote:
| > The car went through a dealer and was sold certified pre-
| owned; and it was sold as not having those features.
|
| Was the car sold to its original owner with those features
| enabled? If so, it's effectively the same as the original
| story reported, meaning that Tesla expected to be paid
| twice for the feature.
| bee_rider wrote:
| So, free upgrades in a couple years when this inevitably gets
| broken in to?
| monocasa wrote:
| I don't think it's inevitable that this'll be broken into.
| Public/private crypto in high end process nodes has a
| pretty good track record.
| nikanj wrote:
| Modern Nvidia cards detect you're trying to mine for cryptos,
| and artificially limit the performance of the silicon.
|
| It's the opposite of being capable - it's silicon that refuses
| to play to it's full capacity lest you buy an additional
| license.
| quaintdev wrote:
| That's just nuts. Sell me at what price you will but after I
| buy it, you should not control a single bit on my hardware.
|
| It's like we are going backward in progress.
| paulmd wrote:
| This has been the norm for a long time - the AMD Hawaii GPU
| was sold as the 290X to gamers with FP64 artificially
| crippled to run much more slowly than normal, and then sold
| at a much higher price to other richer customers who use
| them to make money as the Radeon Pro series (in the case of
| Hawaii - it was the FirePro S9150 and S9100). Traditionally
| it has been FP64 performance, as well as things like
| looking at the OpenGL calls and artificially limiting
| performance when something looks like a CAD workload (see:
| the big increase when NVIDIA removed the limitations on
| Titan X professional workloads after Vega FE came out).
|
| Somehow nobody shed a tear for the poor enterprise
| customers until miners came along. But that's what it is,
| miners are enterprise customers, they use them to make a
| profit.
|
| Similarly, almost all R5 consumer processors are made by
| artificially disabling fully functional cores on R7
| chiplets. AMD already had nearly 80% of the chips coming
| off the line with 8 functional cores at Zen2 launch, and
| numbers have only gotten better since there. Yeah, maybe a
| few fail clock bins or other things, but those bins are
| chosen very loosely such that they're not throwing away any
| significant amount of chips anyway. The overwhelming
| majority of R5s are perfectly good chips being gimped and
| sold as lower chips, because the availability and demand
| are exactly opposite of each other - they have the highest
| availability of 8-core chiplets and the highest demand for
| 4- and 6-core chiplets. How do you square the two? Not by
| lowering prices of your high-margin products - you keep
| those high to extract the maximum price from price-
| insensitive consumers, and you artificially gimp a bunch of
| them for the rest of the market to protect your profits in
| the higher segment.
|
| https://en.wikipedia.org/wiki/Price_discrimination
|
| The thing to remember is that home users are almost always
| the _beneficiary_ of market segmentation, because we are
| the most price sensitive. The alternative to Core-vs-Xeon-E
| segmentation isn 't that everyone gets Xeons at i5 pricing,
| it's that the i5 now costs almost as much as a Xeon. The
| R&D has to be paid back one way or another, or else R&D
| will be significantly reduced (most likely meaning much
| longer product generations and slower moves to new nodes,
| etc). Price discrimination means enterprise customers pay
| _more than their share_ and home customers pay _less than
| their share_ , so if market segmentation goes away and
| those equalize then home customers will have to bear more
| of their fair share of the product cost.
|
| Again, who wants to race to pay more for their gaming
| graphics card so that Boeing and cryptominers can pay less?
| It would be great if everything were free, or priced at its
| true cost, but in the real world R&D needs to be paid for
| _somehow._
|
| Oh, and the other thing is Enterprise customers actually
| love this, it's called Capacity on Demand and I'm sure the
| reason Intel is doing this is because their customers keep
| asking for it. Sun, Oracle, Fujitsu, IBM - all the big
| enteprise vendors will sell you a machine with a bunch of
| cpu and memory that _you 're not allowed to use or touch!_
| But if your workload scales up, instead of having to shut
| down your mainframe to upgrade it, you can just pay money
| and turn the cores on! And sure, it would be nice if all
| software were just microservices that you could re-
| instantiate onto another machine, but some stuff (like
| databases) can't be trivially scaled and partitioning
| (read: stale data reads) can't be tolerated. The only
| _surefire_ answer to CAP is One Big Machine, and that 's
| what some situations need, and they love this.
| mperham wrote:
| Who's "we"? You are going backward. NVIDIA's profits are
| going forward.
| coldacid wrote:
| We are.
| jrootabega wrote:
| Are they doing it to get a bigger cut of miners' funds? Or
| to try to find a way to keep the pipeline for designing,
| building, and coding for gaming GPUs flowing?
| ethbr0 wrote:
| I think on the whole, Nvidia isn't thrilled about crypto
| mining.
|
| It made them a lot of money, but they (rightly so) look
| at it as margin that could evaporate tomorrow. And in the
| mean time pisses their core users off (through volume
| availability issues) and makes an already difficult
| production -> retail supply chain even more bursty.
|
| So how do you deal with that? Well, a not-terrible way is
| artificially segmenting your market. Crypto folks, over
| here in this pool with huge waves. Everyone else, back to
| business as usual.
| kllrnohj wrote:
| Nvidia isn't thrilled about crypto mining because it
| creates too many second-hand cards, that's it. They just
| want to kill the second-hand market boom that happened as
| crypto mining has high hardware turnover, and gaming
| doesn't. So gamers just pick up second-hand previous
| generation high end cards instead of buying current gen
| mid-range cards.
|
| It's not a coincidence the software lockout landed right
| as Nvidia released an unlocked mining card without a
| display output ( https://www.nvidia.com/en-us/cmp/ ). And
| since it doesn't have a display output, all those used
| mining cards become ewaste instead of something that cuts
| into nvidia's revenue.
| acchow wrote:
| Exactly. If Nvidia removed the crypto crippling, almost
| all of their GPUs would be bought up for crypto mining
| leaving their gaming market empty. A new entrant would
| come in and take up their gaming market. Meanwhile,
| Nvidia's production (and capital expenditure with it)
| could ramp up dramatically to meet crypto demand, until
| it too collapses. Then they are left with nothing but
| debt.
| Eelongate wrote:
| > _A new entrant would come in and take up their gaming
| market._
|
| Miners would probably find a way to use that new
| entrant's GPUs for mining too.
|
| I think the real threat is that mining could chill the
| gaming industry as a whole. Either by pricing tons of
| people out of gaming so they find new hobbies and maybe
| never come back, or by influencing the direction of game
| development away from advanced graphics. If most gamers
| can't afford top-end GPUs anymore, then the perceived
| value of [Latest Game] having the most photorealistic
| graphics yet could be flipped into the negative by a
| change in gamer culture.
| DennisP wrote:
| They sell another GPU specifically for mining, at twice
| the price.
|
| https://www.pcgamesn.com/nvidia/CMP-170HX-price-double-
| RTX-3...
| htrp wrote:
| We had the same thing in software and in media content.
| 1cvmask wrote:
| Intel seems to be on a mission to slide into historical
| irrelevance. Rome didn't die in a day and neither will Intel. I
| think this gives new meaning to planned obsolescence.
| ethbr0 wrote:
| Intel and AMD don't build features no one asks for.
|
| TPM and SecureBoot came directly from large customers
| requesting exactly that.
|
| HN (and more broadly, PC users) aren't all of the market for
| CPUs.
| mike_d wrote:
| The "TPM" you know today started life as Microsoft Palladium,
| an attempt by Microsoft to create a hardware DRM
| implementation for "content producers" that could tell the OS
| what was allowed and not allowed on your computer. The
| assumed goal at the time was that once the frog was
| sufficiently boiled it would be used to enforce Windows
| licensing as well. After much backlash they diverted their
| efforts into a cabal with Compaq, HP, IBM, and Intel to make
| it more general purpose and actually allow the end user to
| store keys.
|
| Secure boot was mostly just a toy until Google implemented it
| in Chromebooks and the large customers you speak of pointed
| and said "I want that!"
| temac wrote:
| You seem to imply customers demand bridled CPUs. Thinking
| about it, there is one scenario for which their "sw-defined
| silicon" (hello newspeak) would both make sense and not be
| too much of a fuckery: instead of their regular process that
| now consists of shipping unvalidated HW and waiting for
| complaints about bugs for triggering chicken bits in the next
| microcode, they could ship processor with only the properly
| validated parts enabled at first, and make people pay for
| extra perf or features when the remaining validation is
| actually completed and if it passes.
|
| I do not really believe this is their intent thought: people
| are way too much continuing to act like mean 5% better perf
| on arbitrary benchmarks has any significance (even regardless
| of power consumption). So Intel will likely continue to ship
| broken but allegedly fast processors, and will continue to
| kill the perfs to remove the bugs once they sold enough.
|
| Plus, in a competitive market, it would be an equilibrium
| hard to achieve if competitors are not making pay for their
| own deferred enablement.
| PeterisP wrote:
| There definitely are major customers (for example, cloud
| providers) which explicitly demanded "bridled CPUs" like
| TPM and SecureBoot. It's not not something imposed by
| Intel, those features are required by an important part of
| the market, ignored by another important part of the market
| (unsophisticated consumers), and opposed by an small part
| of the market which is highly represented among tech and
| privacy enthusiasts here on HN, but is not really
| significant in size.
| rodgerd wrote:
| Yep. Being able to buy processors that don't trigger
| Oracle's core-count licensing (for example) but be able
| to vary cores on and repurpose them in the general VM
| farm is a thing that I have been very keen on in a past
| life.
|
| It's a relatively niche interest, but it exists.
| mike_d wrote:
| > cloud providers) which explicitly demanded "bridled
| CPUs" like TPM and SecureBoot
|
| You seem to be terribly confused. End customers demand
| features, they do not demand limitations.
|
| AWS and GCP don't want to spend money acquiring or
| powering chips with dead areas of silicon.
| ethbr0 wrote:
| End customers demand features for a price.
|
| If there's unused silicon in a chip, but it costs the
| same or cheaper and has the features they want, I think
| you'd be hard pressed to find a customer who's going to
| complain.
| zozbot234 wrote:
| "Dark Silicon" is actually ubiquitous in modern chips.
| They can't possibly run 100% of the chip while staying
| within power and thermal constraints - and this gets
| _worse_ , not better as process technology improves. So,
| even if some of that dark silicon is "software defined"
| it just doesn't matter all that much.
| klelatti wrote:
| > Intel and AMD don't build features no one asks for.
|
| Hmmm. Intel has built whole ISAs that no one asked for and
| didn't want.
| ethbr0 wrote:
| If you're referring to IA-64, then what information
| available in 1994 would have made you believe that VLIW /
| EPIC wasn't a viable path to provide >1 IPC at competitive
| clock speeds? Something very many customers were asking for
| and wanted.
|
| Some good ideas work. Some good ideas don't. Doesn't mean
| they were bad ideas, only that unknown at the time factors
| or future developments made them bad ideas.
| klelatti wrote:
| I wasn't thinking of IA-64 actually.
|
| Not sure how the rest of your comment relates to my point
| though. Customers may want better performance. Doesn't
| mean they want your new architecture. They certainly
| didn't want IA-64. That's just a statement of fact.
| ethbr0 wrote:
| Which ISA were you talking about?
|
| And as for the link between architecture and performance,
| I'll turn the common quip: "You can have performance or
| architecture changes, pick two."
|
| The debate between runtime parallelism vs compiler
| parallelism, and which would result in greater
| performance on real world workloads, was an open question
| at the time.
|
| As it turned out, the market preferred answer was "Screw
| it, we'll push superscalar and add more cores." But
| that's non-obvious in foresight. See: the famous
| P68/NetBurst/Pentium 4 vs P6+/Pentium M struggles.
| klelatti wrote:
| I broadly agree that it was non obvious and don't really
| blame Intel for trying IA-64.
|
| I was really (semi humorously) trying to push back
| against the parent comment saying that everything these
| firms have done has arisen directly from customer demand.
| Obviously firms must think that there is demand for new
| products or features but sometimes they just
| misunderstand the market.
|
| To give another example was there really any demand from
| customers for x86 cores in smartphones or was it Intel
| just trying to establish a market presence?
|
| To answer your question iAPX432.
___________________________________________________________________
(page generated 2021-12-08 23:01 UTC)