Intel to start licensing x86 cores…

x86 is the 32 bit stuff, AMD owns the X64 stuff so, this sounds strange.
 
  • Like
Reactions: ChadD
like this
ManofGod said:
x86 is the 32 bit stuff, AMD owns the X64 stuff so, this sounds strange.
Click to expand...

x86 can be short hand for x86-64 aka amd64 these days. Article short on details has no details. Intel sounds like they're willing to work with people on wild and crazy things. Probably not a nvidia desktop chip, maybe something for a future shield to rival the steam deck? Probably still no. Maybe some more custom work for hyperscalers? Full SoC including an arm based IPMI on one chip, maybe? I've got lots of terrible ideas!
 
toast0 said:
x86 can be short hand for x86-64 aka amd64 these days. Article short on details has no details. Intel sounds like they're willing to work with people on wild and crazy things. Probably not a nvidia desktop chip, maybe something for a future shield to rival the steam deck? Probably still no. Maybe some more custom work for hyperscalers? Full SoC including an arm based IPMI on one chip, maybe? I've got lots of terrible ideas!
Click to expand...
Depends on the cross-licensing deals - AMD technically owns the patents on AMD64/x86_64. Their cross-licensing deal with Intel (forced somewhat on Intel originally, less so later on revisions) - (https://www.sec.gov/Archives/edgar/data/2488/000119312509236705/dex102.htm) allows Intel to USE whatever patents AMD holds on x86, but... I'm not sure that would let them sell a cross-license to AMD64 to someone ~else~.

Thing is, they probably don't have to - I suspect this is mostly about using the foundry and designs to combine AMD64/RISC-V/ARM into the same CPU that intel ~builds~ for you, as a license made product (fully intel produced), more than giving you the bits to make your own. You have to have the soft-license for designing the thing you'd potentially want them to build, if it wasn't something you wanted to pay intel to design for you, but that doesn't mean you get to go design your own AMD64 core and have it manufactured by someone else.

We'll have to see what the actual licensing text says.
 
ManofGod said:
x86 is the 32 bit stuff, AMD owns the X64 stuff so, this sounds strange.
Click to expand...
They don't though, AMD's was a variation of the IA_64, but at this stage Intel, AMD, and VIA all own and implement their own x86-64 instruction sets, that are crosslicensed to high hell but each is distinct.
 
Lakados said:
They don't though, AMD's was a variation of the IA_64, but at this stage Intel, AMD, and VIA all own and implement their own x86-64 instruction sets, that are crosslicensed to high hell but each is distinct.
Click to expand...
Uh, not quite. IA_64 was Itanium. No one else built that mess. Otherwise accurate - but I’m not sure they can sell a license they don’t own to someone else without getting the others (AMD in this case ) to agree.
 
lopoetve said:
Uh, not quite. IA_64 was Itanium. No one else built that mess. Otherwise accurate - but I’m not sure they can sell a license they don’t own to someone else without getting the others (AMD in this case ) to agree.
Click to expand...
AMD's x64 was still heavily based on it, either way with the agreements in place AMD can do no more to stop Intel from licensing out x64 than Intel could do to stop AMD from licensing out x86, which they have been doing since 2016.

But unlike the AMD deals, it's not like Intel would be allowing them to build those cores elsewhere, Intel would just be licensing out the cores so companies could design their own implementation groups that Intel would then build for them to match their needs.
Intel sees the writing on the wall and can't keep gatekeeping x86, it's rapidly dwindling and they need a transition strategy. It's not going away for the consumer any time soon, but Enterprise and Datacenter are very rapidly changing their workflows to use whatever architecture gets them the best performance at the least energy usage. Electricity costs are going up and they need to optimize their workflows from top to bottom to keep ahead of it.
 
Last edited:
When I first read this I got excited thinking that this was huge news, like back in 2005 when Apple announced that Macs would start using X86. That said, it sounds like these chips are going to be mostly for industrial/commercial applications and not for regular users(?) Does anybody foresee any impacts that this could have for end users like you and me? Maybe a beefed up Raspberry Pi with native X86 capabilities down the road or something?
 
ManofGod said:
x86 is the 32 bit stuff, AMD owns the X64 stuff so, this sounds strange.
Click to expand...

This was my thinking... Intel doesn't own x86-64 they have a cross license to use it, not sell it. So what is it Intel is aiming at here... low power 32 bit x86 ? Or are they planning to enrich AMD here?

I also really don't see the point of putting two different archs on one chip. I don't understand what that really gains outside of some sort of short term stop gap solution. Or attempt on Intels part to keep RISC from replacing x86 in commercial applications which is going to happen no matter what Intel tries to pull with "hybrid" stuff. I think that is really the plan here... trying to stave RISC taking over Intels automation stuff. Trying perhaps to confuse the software switch over by putting x86 bits in. The industry is going to rip the bandaid off and go RISC and Intel is figuring out way to late that they are going to be removed from that industry within a few years.

What Intel really needs to do... is develop a line of Intel RISC designs and license them like ARM does. Let all the larger robot arm companies and the like spin their own Intel RISC chips and adapt. Trying to hybrid isn't going to work imo. At best all it does is buy Intel a few years... until such companies completely replace their software stacks to support RISC.
 
ChadD said:
What Intel really needs to do... is develop a line of Intel RISC designs and license them like ARM does. Let all the larger robot arm companies and the like spin their own Intel RISC chips and adapt. Trying to hybrid isn't going to work imo. At best all it does is buy Intel a few years... until such companies completely replace their software stacks to support RISC.
Click to expand...
They announced something similar to that just recently.
https://riscv.org/blog/2022/12/inte...w-capabilities-and-a-growing-ecosystem-intel/
https://www.allaboutcircuits.com/ne...for-risc-v-chip-design-with-intel-pathfinder/

In regards to the x64 licensing there is so much shared IP in there who knows what's going on there but looking at the announcements they aren't exactly "licensing" out the cores, it's not like somebody else can make them.
It's more like they are opening up a catalog for companies to order custom SoCs that Intel can then manufacture in the new plants they have opening up. Their Foveros packaging tech is proving so far to be disgustingly resilient and is currently working with parts made by Intel, Qualcomm, and TSMC all on a single package using the UCIe Standards.
Intel is doing what it can to get ahead of all the custom ARM development out there. ARM has proven itself in the data center to be very cost-efficient at high transaction services, it's why Amazon is pumping so much money into it. And a server cluster lost to an ARM platform is a customer lost to both Intel and AMD because they don't really have anything they can do to win that stack back.
Datacenters are increasingly having to hunt for efficiencies, it's getting to the point where even they can't afford to throw bigger Xeons and Epycs at a solution and they need specialized hardware to do much of the mundane work because things are just getting too hot and hungry. Having ARM cores on the package to handle real-time encryption paired with some RISC cores for data IO could save silicon, and energy, while decreasing thermals and increasing performance.

Really this is the stuff Intel was talking about in 2020 when they were buzzing about their "Lego" processors.
 
ChadD said:
This was my thinking... Intel doesn't own x86-64 they have a cross license to use it, not sell it. So what is it Intel is aiming at here... low power 32 bit x86 ? Or are they planning to enrich AMD here?

I also really don't see the point of putting two different archs on one chip. I don't understand what that really gains outside of some sort of short term stop gap solution. Or attempt on Intels part to keep RISC from replacing x86 in commercial applications which is going to happen no matter what Intel tries to pull with "hybrid" stuff. I think that is really the plan here... trying to stave RISC taking over Intels automation stuff. Trying perhaps to confuse the software switch over by putting x86 bits in. The industry is going to rip the bandaid off and go RISC and Intel is figuring out way to late that they are going to be removed from that industry within a few years.

What Intel really needs to do... is develop a line of Intel RISC designs and license them like ARM does. Let all the larger robot arm companies and the like spin their own Intel RISC chips and adapt. Trying to hybrid isn't going to work imo. At best all it does is buy Intel a few years... until such companies completely replace their software stacks to support RISC.
Click to expand...
The cross licensing agreement is pretty extreme in this case - would have to get a lawyer to really dig in, but it's FULL access to the patents. What that really means is somewhat unknown here.

Define "Commercial applications" in your comment? You thinking big industrial systems? Seems like it from later on but I'm not positive.
 
lopoetve said:
The cross licensing agreement is pretty extreme in this case - would have to get a lawyer to really dig in, but it's FULL access to the patents. What that really means is somewhat unknown here.

Define "Commercial applications" in your comment? You thinking big industrial systems? Seems like it from later on but I'm not positive.
Click to expand...

I agree no one really knows what their cross license says exactly. I just find it unlikely it says here you have a license to our tech go ahead and sell to others. However perhaps there is a provision that says its ok if its fabbed at Intel.

As for applications... I just don't see any other application for mixing RISC and x86. It doesn't fix any problems in consumer products... or server products or just about anyone accept commercial applications. If the cross license says Intel is in the green to put x86-64 in parts they fab for others... this doesn't even solve the industrial systems market anyway. As the real threat to intel here is some of the biggest automation companies doing what companies like Tesla and others have been doing and fab their own chips. I don't see them loving the idea of being tied to Intel fabrication only and forever if they want to keep x86 bits.
 
ChadD said:
I agree no one really knows what their cross license says exactly. I just find it unlikely it says here you have a license to our tech go ahead and sell to others. However perhaps there is a provision that says its ok if its fabbed at Intel.

As for applications... I just don't see any other application for mixing RISC and x86. It doesn't fix any problems in consumer products... or server products or just about anyone accept commercial applications. If the cross license says Intel is in the green to put x86-64 in parts they fab for others... this doesn't even solve the industrial systems market anyway. As the real threat to intel here is some of the biggest automation companies doing what companies like Tesla and others have been doing and fab their own chips. I don't see them loving the idea of being tied to Intel fabrication only and forever if they want to keep x86 bits.
Click to expand...
Oh agreed on the RISC part - although there's a small push (less so than ARM) for such in the DC space as well - I just wasn't sure if I was following your "commercial" statement (as my brain goes elsewhere with that term - namely small to medium business).

And agreed on the former - although as long as Intel is fabbing the wafer, I ~suspect~ they're ok and in the green. Selling it for someone else to fab is almost certainly a no-no.
 
  • Like
Reactions: ChadD
like this
You wouldn't download a CPU core! I guess I could now, I wonder how easy these will be to hack? I also guess this is for industrial or business/server use only?
 
Format _C: said:
You wouldn't download a CPU core! I guess I could now, I wonder how easy these will be to hack? I also guess this is for industrial or business/server use only?
Click to expand...
You could always do your own CPU design - it's just extremely extremely complex. RISC-V is open source - fire up the designer and get at it :D
 
toast0 said:
x86 can be short hand for x86-64 aka amd64 these days. Article short on details has no details. Intel sounds like they're willing to work with people on wild and crazy things. Probably not a nvidia desktop chip, maybe something for a future shield to rival the steam deck? Probably still no. Maybe some more custom work for hyperscalers? Full SoC including an arm based IPMI on one chip, maybe? I've got lots of terrible ideas!
Click to expand...
I have need of a Xeon with a solid 96 E cores, 12 Arm cores, and 4 Risc cores.
If I could pair that up with 300+ GB in ram and 6 TB of redundant SSD storage it would allow me to replace a pair of aging EPYC's and would be dope AF.
 
Lakados said:
I have need of a Xeon with a solid 96 E cores, 12 Arm cores, and 4 Risc cores.
If I could pair that up with 300+ GB in ram and 6 TB of redundant SSD storage it would allow me to replace a pair of aging EPYC's and would be dope AF.
Click to expand...
Why would you want E cores? And with that many cores, why so little ram? My 8280s are all 3T on the memory side; granted, a big chunk of that is PMEM, but...
 
lopoetve said:
Why would you want E cores? And with that many cores, why so little ram? My 8280s are all 3T on the memory side; granted, a big chunk of that is PMEM, but...
Click to expand...

From my reading, E cores are about half the compute in a fourth the space. If your work is friendly to multicore, and throughput is more important than latency, you get twice the throughput in the same die space. If you're asking for 96 cores, you're probably throughput oriented. I agree, that's not much ram though; depends on what you're up to, but I had 2690v3/4 with 768GB ram, thinking of going to 1.5TB, 300GB is peanuts.
 
lopoetve said:
Why would you want E cores? And with that many cores, why so little ram? My 8280s are all 3T on the memory side; granted, a big chunk of that is PMEM, but...
Click to expand...
I have a pair of EPYC servers that are basically emulating a shitload of systems from the 90s because Accounting can't seem to get their heads together and get the software replaced, the replacement software is 4 years behind schedule and like 2M over budget, either way...
So between thread and memory isolation and full data encryption, the EPYC's spend more in overhead than they do on the actual transactions. Going to the E cores which are single thread removes a lot of the overhead so performance would still be fine, have the ARM cores deal with the data encryption as they do that better than the current EPYC or Xeon x86 cores do anyways, then let the RISC cores handle all the IO operations.
But yeah through a convoluted series of Emulators and virtualization, I have a pair of very nice 7702P's that run a dozen or so Windows NT4 instances, and a handful of REHL 5 instances. But because of the age of the systems I have to run full encryption, memory isolation, and all that jazz, and the overhead on the security is 3-4x the actual work being done. It's kinda messed up.
 
toast0 said:
From my reading, E cores are about half the compute in a fourth the space. If your work is friendly to multicore, and throughput is more important than latency, you get twice the throughput in the same die space. If you're asking for 96 cores, you're probably throughput oriented. I agree, that's not much ram though; depends on what you're up to, but I had 2690v3/4 with 768GB ram, thinking of going to 1.5TB, 300GB is peanuts.
Click to expand...
Yeah, the systems are basically emulating a crap load of dual CPU P4's from the early 2000's for Windows NT4 and REHL 5 while accounting bumblefucks their way through moving over the last 50 years of pension, payroll, and A/R to the new systems.
 
Lakados said:
But because of the age of the systems I have to run full encryption, memory isolation, and all that jazz, and the overhead on the security is 3-4x the actual work being done.
Click to expand...
I've found having the system crash and be offline for a couple of days focuses the bean counters' minds quite nicely.
 
1_rick said:
I've found having the system crash and be offline for a couple of days focuses the bean counters' minds quite nicely.
Click to expand...
It gets their heads in place, but then payroll doesn't happen, and then I get the CUPE representatives in my office and it gets ugly. I'll take a convoluted virtualization system over dealing with angry union reps any day of the week.
 
Lakados said:
It gets their heads in place, but then payroll doesn't happen, and then I get the CUPE representatives in my office and it gets ugly. I'll take a convoluted virtualization system over dealing with angry union reps any day of the week.
Click to expand...
I mean, *obviously* don't have it happen on payroll day.

Yeah, yeah, I know, you do multiple payroll runs a week, on different days.
 
Lakados said:
I have a pair of EPYC servers that are basically emulating a shitload of systems from the 90s because Accounting can't seem to get their heads together and get the software replaced, the replacement software is 4 years behind schedule and like 2M over budget, either way...
So between thread and memory isolation and full data encryption, the EPYC's spend more in overhead than they do on the actual transactions. Going to the E cores which are single thread removes a lot of the overhead so performance would still be fine, have the ARM cores deal with the data encryption as they do that better than the current EPYC or Xeon x86 cores do anyways, then let the RISC cores handle all the IO operations.
But yeah through a convoluted series of Emulators and virtualization, I have a pair of very nice 7702P's that run a dozen or so Windows NT4 instances, and a handful of REHL 5 instances. But because of the age of the systems I have to run full encryption, memory isolation, and all that jazz, and the overhead on the security is 3-4x the actual work being done. It's kinda messed up.
Click to expand...
Yike. I take it back.
Sadly from what I'm reading, they won't combine architectures like that - it'll be RISC cores for RISC workloads, ARM for arm workloads, etc. Not a blend.
Lakados said:
Yeah, the systems are basically emulating a crap load of dual CPU P4's from the early 2000's for Windows NT4 and REHL 5 while accounting bumblefucks their way through moving over the last 50 years of pension, payroll, and A/R to the new systems.
Click to expand...
Always the beancounters... Shoot them all!
 
1_rick said:
I mean, *obviously* don't have it happen on payroll day.

Yeah, yeah, I know, you do multiple payroll runs a week, on different days.
Click to expand...
Entry Tuesdays and Thursdays, for payroll on Wednesdays and Fridays, with reconciliation on Mondays. Weeks 1 and 3 are payroll, and 2 and 4 are A/R. I think I would prefer angry union reps over pissing off my suppliers, I can at least buy the union reps a beer and offer my apologies in person, CRA at Dell on the other hand doesn't really care.
 
lopoetve said:
Yike. I take it back.
Sadly from what I'm reading, they won't combine architectures like that - it'll be RISC cores for RISC workloads, ARM for arm workloads, etc. Not a blend.

Always the beancounters... Shoot them all!
Click to expand...
In all fairness to the developers it is a shit project and its mostly the reporting that is screwing everything up. Moving the data from the flat file system the current system uses over to SQL hasn't been the hold-up.
The current software is absurdly flexible, so when a contract is updated it can reflect those changes, so it automatically knows to use contract A for Timeframe A and Contract B for Timeframe B, and if you say do a seniority report on an employee over their 30 years or so, it will correctly calculate it with the contracts that were in place at those times, same with pensions and all that.
 
You must log in or register to reply here.
Back
Top