Discussion Intel current and future Lakes & Rapids thread

[S'renne]

So Intel has this new AVX10 thing...

Intel's New AVX10 Brings AVX-512 Capabilities to E-Cores

Future hybrid chips will have the goodness of AVX-512 features on both P- and E-cores.

www.tomshardware.com

 

[poke01]

How many instructions do they need? It's poor planning.

 

[Ajay]

How many instructions do they need? It's poor planning.

Yep. Though, if Intel does (along with AMD) zap the old x86 crud as it has been suggesting, then I guess it'll be a wash.

 

[coercitiv]

How many instructions do they need? It's poor planning.

It's poor planning in the sense that they came out with it AFTER the switch to hybrid topology. Even so, it's still better than the sad reality of making consumer products with AVX 512 hardware that is fused off or disabled in firmware.

 

[poke01]

It's poor planning in the sense that they came out with it AFTER the switch to hybrid topology.

yes this is what I meant. sorry for the confusion

 

[DrMrLordX]

How many instructions do they need? It's poor planning.

Kinda makes you wish Intel and AMD would just license SVE2 from ARM and roll with that instead.

 

[NostaSeronx]

Kinda makes you wish Intel and AMD would just license SVE2 from ARM and roll with that instead.

They don't have to license RVV from the RISC-V Foundation. They can just yoink it and slap a prefix like RVEX(alternate isa encapsulation) and say it has similar properties as RVV. Which in turn RVV 1.0~2.0 has a upper-limit of 65536-bit vectors, with a defined limit of 4096-bit.

AVX512/AVX10 still has L'L 11 for 1024-bit reserved. Needs a second instructions set like AMX to get matrix, with different registers.
SVE caps out at 2048-bit and needs SME to get more utility.
RVV does both SVE/SME and gives a upper limit of 65536-bit. Anyone can take the RVV spec and modify it for their own architecture.



Intel's partnership with SiFive with the above means they can technically do two things.
- Gut x86 and loan E-cores to SiFive
- Have SiFive and themselves develop toolchains to support RVV-x86-64(Intel's distribution of E-cores) and RVV-rv64(SiFive's distribution of Intel E-cores). I don't see them doing P-core licensing with future forest and future lake-n processors.

US9898291B2 - Microprocessor with arm and X86 instruction length decoders - Google Patents

A microprocessor natively translates and executes instructions of both the x86 instruction set architecture (ISA) and the Advanced RISC Machines (ARM) ISA. An instruction formatter extracts distinct ARM instruction bytes from a stream of instruction bytes received from an instruction cache and...

patents.google.com

https://en.wikipedia.org/wiki/Alternate_Instruction_Set
Just a reminder, almost everyone in this patent and the makers of AIS is at Intel.

Also, Intel is already a premier member of the RISC-V foundation. So, in fact they are already licensing RVV officially. => "Use of RISC-V Trademark (name and/or logo) for commercialization" If they take RVV smoosh it into x86 isa, they can use the RISC-V trademark.

 

[Doug S]

Kinda makes you wish Intel and AMD would just license SVE2 from ARM and roll with that instead.

You mean ARM's SIMD extensions that basically no one is using in real world code yet?

Intel has essentially deprecated 512 bit vectors, allowing people to have the useful parts of AVX512 with 256 bit vectors. Why would they need the kind of scalability that SVE2 promises (but does not use since ARM is designing cores that only support 128 bit vectors) when Intel has decided that the hassle of implementing 512 bits isn't worth it for the tiny niche of people who find it useful?

Intel has bigger things to worry about, like how the heck they will ever get anyone to use APX. That's not a simple check/branch code path in a few limited cases like AVX256 and AVX512. Making use of APX requires essentially a whole new binary, so there isn't going to be a lot of it out there (other than benchmarks lol)

 

[moinmoin]

Intel has bigger things to worry about, like how the heck they will ever get anyone to use APX.

Ensure that open source compilers like LLVM and GCC support it well.

Then all open source projects can potentially profit of it with a simple re-compile. And all the companies of close source products either ignore it (giving open source projects and their users a potential advantage) or catch up as well.

 

[dullard]

Intel is definitely in play as a foundry for national security interests. The problem is that the volumes needed by this interest are very small compared to the commercial sector. It's nothing that can sustain Intel in trying to be a leading, or even a close 2nd, foundry.

And now Ericsson is in on Intel 18A for 5G chips. One more reason Intel is all in on 18A and not 20A.

Intel, Ericsson to work together on custom 5G chip

Intel Corp on Tuesday said that it will work with Swedish telecommunications gear maker Ericsson to make a custom chip for Ericsson's 5G networking gear, using the most advanced manufacturing technology Intel has disclosed.

www.reuters.com

 

[Doug S]

Ensure that open source compilers like LLVM and GCC support it well.

Then all open source projects can potentially profit of it with a simple re-compile. And all the companies of close source products either ignore it (giving open source projects and their users a potential advantage) or catch up as well.

Compiler support isn't the problem. Hardware support is. Sure they can do a "simple recompile", and get a totally different binary that what runs on all hardware sold today. For the typical case that gets a few percent speedup that's not worth it to deliver/support two complete binaries instead of one.

This is only going to done in niche cases where either that few percent really matters (look for Intel to provide plenty of "help" getting benchmarks recompiled so the new hardware looks as good as possible) or the speedup is a lot more due to having the type of code where e.g. 16 registers just isn't enough and another 16 avoids a lot of hassle or hits renaming engine limits (especially since Intel doesn't "really" have 16 registers now due to specialization)

 

[DrMrLordX]

You mean ARM's SIMD extensions that basically no one is using in real world code yet?

Yes, that one.

 

[Exist50]

Compiler support isn't the problem. Hardware support is. Sure they can do a "simple recompile", and get a totally different binary that what runs on all hardware sold today. For the typical case that gets a few percent speedup that's not worth it to deliver/support two complete binaries instead of one.

This is only going to done in niche cases where either that few percent really matters (look for Intel to provide plenty of "help" getting benchmarks recompiled so the new hardware looks as good as possible) or the speedup is a lot more due to having the type of code where e.g. 16 registers just isn't enough and another 16 avoids a lot of hassle or hits renaming engine limits (especially since Intel doesn't "really" have 16 registers now due to specialization)

Way I think of it, x86S, AVX10, and APX are basically the spirits from The Ghost of Christmas Past.

x86S - Addressing the legacy of x86's past, so the architecture can move beyond it going forward.

AVX10 - Addressing the fragmentation of the present.

APX - Plotting a course for a viable future for x86.

Realistically, it will take many years to see this full transition play out for APX in particular, but no point in delaying it.

 

[coercitiv]

Realistically, it will take many years to see this full transition play out for APX in particular, but no point in delaying it.

This morning I indirectly stumbled upon Linus Torvalds' opinion on the matter. Bold emphasis mine.

It does sound like Intel is de-emphasizing AVX512.

I'm obviously not unhappy about that. I think 256-bit vectors are a much better middle ground than 512-bit ones were, and I think one of the reasons people liked AVX512 was the new instructions it provided.

And if this actually finally makes the 'New AVX256' (aka "AVX10") be widely available and gets rid of the ridiculous market segmentation, that would be a good thing. Of course, since it pushes the baseline up to that new thing, it's still at least a decade away from actually being so widely available that you can take it for granted. So it's not helping anything at all in the short term, quite the reverse - just adding yet another case.

 

[SiliconFly]

Intel 4 was in development for a very long time even before pat gelsinger joined & considering MTL ES samples are comfortably hitting 5GHz+, I'd say Intel 4 is in fact a very healthy state. Might meet all targets. No doubt.

But the same doesn't apply to Intel 20A. Max clock regression (Fmax) is still very much an big question with Intel 20A. And yields too. Worst part is, we're already in Q3 2023 and Intel still hasn't announced ARL 20A tapeout yet which is pretty serious. At this point, ARL might not make it out in 2024!

 

[Geddagod]

But the same doesn't apply to Intel 20A. Max clock regression (Fmax) is still very much an big question with Intel 20A. And yields too. Worst part is, we're already in Q3 2023 and Intel still hasn't announced ARL 20A tapeout yet which is pretty serious. At this point, ARL might not make it out in 2024!

Intel doesn't look like they are differentiating between Intel 20A and TSMC 3nm ARL. They announced LNL tape out, which appears to be more ambitious than ARL (for what's on the 'compute' tile anyway), and who knows, maybe they announce ARL tape out in the earnings call tmmrw. Again, it's really weird how quite Intel is being on ARL in comparison to LNL. Might just be bcuz LNL is just a more interesting product though.

 

[SiliconFly]

How many instructions do they need? It's poor planning.

Considering the usage, this AVX cr*p is a huge burden on the CPUs. Takes up disproportionate amount of die space for it's usage. Increases complexity & has a heavy impact on boost clocks. Honestly, these things shud be off main die (uncore) at least in client CPUs.

 

[Gideon]

This morning I indirectly stumbled upon Linus Torvalds' opinion on the matter. Bold emphasis mine.

From a reply (emphasis mine):

RWT Forums - Real World Tech

content overridden

www.realworldtech.com

Yes, the 512-bit register size was a minor feature of AVX-512.

What matters are the mask registers and various useful instructions that are missing in AVX.

So I also believe that it is great that Intel promises now that these features will be available in all CPUs.

Zen 4 has shown quite large increases in performance by using 512-bit instructions, but this is mainly because it has a rather limited instruction decoder.

In CPUs where much more instructions can be decoded in parallel, like in Zen 5 and in the future Intel CPUs, the instruction decoder will no longer be a bottleneck, so 512-bit instructions will no longer have a such enhanced performance as on Zen 4.

It might just as well be a quess (and more decode capability for Zen 5 is to some degree "for granted" anyway) but still fun to point out

I'm still holding on to my dream that AMD set up similar targets for Zen 5 as they did for Zen 1:

• ~40% ST IPC uplift with slightly regressed (<10%) clocks for top-end desktop (gettin full worth of the IPC in server and mobile)
• 8 wide decode (possibly Tremont style 4+4)
• a much large ROB, wider backend, all the other goodies ...

And that they'll then continue to expand that same core architecture for 3-4 major iterations (as with Zen 1)

Ambitious? Yes, very much so , but so was Zen. And as we know "only the paranoid survive". If Intel continued to execute with Arrow Lake as they did with Tiger Lake and Alder Lake, it would be pretty much the minimum required just to keep a slight edge. And it's not smart to make business plans on the assumption of the competitor to screwing up forever. That leads to where AMD was in 2006 Or Intel in 2017.

 

[clemsyn]

And now Ericsson is in on Intel 18A for 5G chips. One more reason Intel is all in on 18A and not 20A.

Intel, Ericsson to work together on custom 5G chip

Intel Corp on Tuesday said that it will work with Swedish telecommunications gear maker Ericsson to make a custom chip for Ericsson's 5G networking gear, using the most advanced manufacturing technology Intel has disclosed.

www.reuters.com

Exist50 mentioned that Ericsson is working with Intel back in June 18. Interesting that they are working on 18A.

 

[Geddagod]

Exist50 mentioned that Ericsson is working with Intel back in June 18. Interesting that they are working on 18A.

Would make sense they continue their partnership on Intel 18A if they were also working on a chip on Intel 4. Seems like good progress has been made with their collaboration on the Intel 4 chip if Intel is going to name them for partnership on Intel 18A as well. So good news for both nodes.
Though if this is the 'big partner' Intel said they were going to announce later in the year, I am a tiny bit disappointed. I didn't expect much, but from the way Intel was hyping up the announcement, I thought it was going to be someone more major- perhaps Qualcom or something of that sort. Or maybe Ericsson is more of a 'major company' than I think lol

 

[clemsyn]

Would make sense they continue their partnership on Intel 18A if they were also working on a chip on Intel 4. Seems like good progress has been made with their collaboration on the Intel 4 chip if Intel is going to name them for partnership on Intel 18A as well. So good news for both nodes.
Though if this is the 'big partner' Intel said they were going to announce later in the year, I am a tiny bit disappointed. I didn't expect much, but from the way Intel was hyping up the announcement, I thought it was going to be someone more major- perhaps Qualcom or something of that sort. Or maybe Ericsson is more of a 'major company' than I think lol

Isn't Qualcom in the RAMP-C Program of Intel?

RAMP-C Program on Intel 18A Adds 2 Strategic Defense Industrial Base Customers

www.intel.com

"Boeing and Northrop Grumman join the current lineup of RAMP-C customers – Nvidia, Qualcomm, Microsoft and IBM – and will work closely with Intel and its ecosystem partners, Cadence and Synopsys, to enable access to state-of-the-art technologies that help protect U.S. national security.
The program allows both commercial foundry customers and the DoD to utilize Intel’s significant investments in leading-edge process technologies, including Intel 18A, and establishes an ecosystem for commercial and government customers. Intel 18A process development continues on track and RAMP-C customers are developing test chips."

Or is the RAMP-C different?

 

[Geddagod]

Isn't Qualcom in the RAMP-C Program of Intel?

Qaulcomm and Intel's relationship has been... questionable?
Reports of 18a not living up to Qcom expectations as reported by Washington Times IIRC, to the CEO of Qcom claiming they are evaluating Intel's foundry services, but not having any products planning to use them (in 2021) makes me wonder.
The link you provided does seem to indicate that Qcomm is indeed a customer for Intel foundries, but to what extent? And is the RAMP-C program mean that they will fab products on their nodes, or is it just evaluating the foundry?
Idk.

 

[moinmoin]

Compiler support isn't the problem. Hardware support is.

I guess this is the fundamentally different perspective one has when coming with a decades old closed source legacy baggage in a closed source OS (most private PC users) compared to up to date datacenter usage where when open source is used hardware can be bought to make use of specific ISA extensions and once compiler support is there software can be re-compiled to make use of that.

All of Intel's new accelerators in SPR (the only good parts of it) only make sense in the latter context.

This is only going to done in niche cases where either that few percent really matters

If your use case is an often run workload in a bigger datacenter those few percent will still make a significant difference.

 

[Exist50]

Exist50 mentioned that Ericsson is working with Intel back in June 18. Interesting that they are working on 18A.

Would make sense they continue their partnership on Intel 18A if they were also working on a chip on Intel 4. Seems like good progress has been made with their collaboration on the Intel 4 chip if Intel is going to name them for partnership on Intel 18A as well. So good news for both nodes.

This really should not be viewed in the context of IFS. It's a design win for Intel's networking group, no more, no less. Of course, if they're going to be using 18A, that is not a negative indicator for the process health, but it's obfuscated through too many other layers to really make any meaningful claims beyond that. They haven't even named when this contract is targeted for.

The competitors for this contract would be companies like Marvell. In theory, Marvell could have won the contact and decide to use Intel fabs through IFS, which ironically would have been more significant for Intel's manufacturing ambitions. But naturally, Intel's internal teams don't operate under the same cost/incentive structure, and the networking group has always been among the first to a node.

Though I would have to think that Ericsson returning to Intel means they're reasonably happy with the work on their Intel 4 part, so in that sense, I suppose there is something more to be extracted from this announcement.

 

[Exist50]

Exist50 mentioned that Ericsson is working with Intel back in June 18. Interesting that they are working on 18A.

Oh, in case I wasn't clear then, that chip they were showing off was the Intel 4 "custom networking ASIC" that's popped up on slides. Doubt we'll see any silicon from this new deal for a while yet. For these kind of contracts, serious work only begins after the deal is won.