Discussion Intel current and future Lakes & Rapids thread

[coercitiv]

They are not going to say "Oops, we got caught with our pants down!". But to make it sound like "Intel 64" was their creation? Ugh.

To be fair, it sounds like everyone names this instruction set the way they want:

Various names are used for the instruction set. Prior to the launch, x86-64 and x86_64 were used, while upon the release AMD named it AMD64.[1] Intel initially used the names IA-32e and EM64T before finally settling on "Intel 64" for its implementation. Some in the industry, including Apple,[2][3][4] use x86-64 and x86_64, while others, notably Sun Microsystems[5] (now Oracle Corporation) and Microsoft,[6] use x64. The BSD family of OSs and several Linux distributions[7][8] use AMD64, as does Microsoft Windows internally.[9][10]

 

[SiliconFly]

They've had hundreds if not thousands of people working on it, just as with any similar project. I don't think it's fair to look for one hero or villain in what's really a team effort.

Though I'm not very impressed with DG2. Sure, they got something out the door, but looking at the amount of silicon, it should really be competing with the 3070 instead of 3060 (if not higher), and of course it was very late to market. They need to close the gap a lot if they're to have any chance.

Intel ARC is Raja's brainchild.

 

[SiliconFly]

DG2 is very important for Battlemage because they can polish the drivers+software from this and the learning curve from DG2 should benefit Battlemage, game devs can add XeSS and so on. I'm curious how MTL tGPU will perform. They don't have to use the GDDR6 memory controller which is a bottleneck according to Intel and who knows what they have changed.

MTL tGPU fixes major DG2 hardware issues that hampered performance. Should be slightly better than DG2.

 

[igor_kavinski]

Envisioning a Simplified Intel® Architecture

Intel investigated architectural enhancements and modifications for a 64-bit mode-only architecture.

www.intel.com

Which architecture do you think this will debut in? I don't believe for a second that this is a "proposal". They have everything ready to go. This is their way of informing AMD, hey, we just changed the rules. Have fun!

So now, while AMD engineers will be grumbling doing validation for all the old stuff that their arch still supports, Intel will be using that saved time and transistors to implement some much needed performance enhancements.

 

[igor_kavinski]

MTL tGPU fixes major DG2 hardware issues that hampered performance. Should be slightly better than DG2.

If it fixes major issues, why would it only be slightly better?

 

[mikk]

I was under the impression that Xe/tiger lake's iGPU was heavily influenced by both Raja AND as a response to Raven Ridge. The design is decidedly more modern than 630, the size is the reaction.

Koduri joined Intel in 2017 and first Xe LP iGPUs came 3 years later, so yes it should or could be influenced from Raja Koduri. We don't know if Xe LP was coming regardless of Koduri though.

Which architecture do you think this will debut in? I don't believe for a second that this is a "proposal". They have everything ready to go. This is their way of informing AMD, hey, we just changed the rules. Have fun!

So now, while AMD engineers will be grumbling doing validation for all the old stuff that their arch still supports, Intel will be using that saved time and transistors to implement some much needed performance enhancements.

A fresh architecture makes most sense which should be Nova Lake. Maybe it's build from the ground up with 64 bit only in mind.

 

[igor_kavinski]

A fresh architecture makes most sense which should be Nova Lake. Maybe it's build from the ground up with 64 bit only in mind.

I can imagine Jim Keller telling them, OMG! What crap are you laden with? Throw this away. And that. And this too! What are you? Cavemen??? This has no business being in a modern CPU! Gosh! I need a drink (he leaves the room and everyone else just looks at each other with embarrassed expressions, red in the face, wishing they had been somewhere else).

 

[SiliconFly]

If it fixes major issues, why would it only be slightly better?

The architecture remains the same. Major performance improvements for Alchemist is mostly in software drivers now. Not hardware.

 

[SiliconFly]

They've had hundreds if not thousands of people working on it, just as with any similar project. I don't think it's fair to look for one hero or villain in what's really a team effort.

Though I'm not very impressed with DG2. Sure, they got something out the door, but looking at the amount of silicon, it should really be competing with the 3070 instead of 3060 (if not higher), and of course it was very late to market. They need to close the gap a lot if they're to have any chance.

It's not just the silicon. For excellent performance, the software graphics driver should have all the required optimizations.

Raja started out with a blank slate. The first set of drivers literally had no optimizations. Intel has just completed it's 3rd round of driver optimizations recently with at least a dozen more rounds to go if it wants to match AMD & Nvidia driver performance. It's a tedious/time-consuming job that takes way too much time. Best we can expect a reasonably optimized driver is in 2024 during the launch of Battlemage.

Intel has almost doubled the performance of ARC GPUs already since launch by just adding driver optimizations. A fully optimized driver should triple the performance at least and bring the performance of 770 closer to RTX 3070. But that might take a year at least or maybe even more. Like Jensen once said, GPUs are friggin' hard.

And with a fully optimized graphics driver and more EUs and architectural improvements, Battlemage tGPU in Arrow Lake might turn out to be a killer product!!!

 

[moinmoin]

What's with the graphics Raja talk in this CPU thread?

while AMD engineers will be grumbling doing validation for all the old stuff that their arch still supports

AMD actually has a track record of removing instructions again that see too little use (most prominently 3DNow!) whereas Intel until now kept supporting everything they added (until retroactively killing AVX512 in ADL anyway).

These changes touch the fundamental booting sequence baggage that x86 grew over its lifespan which is something AMD could never change without Intel's support so it's a good thing this is being tackled.

 

[mikk]

Intel has almost doubled the performance of ARC GPUs already since launch by just adding driver optimizations. A fully optimized driver should triple the performance at least and bring the performance of 770 closer to RTX 3070. But that might take a year at least or maybe even more. Like Jensen once said, GPUs are friggin' hard.

And with a fully optimized graphics driver and more EUs and architectural improvements, Battlemage tGPU in Arrow Lake might turn out to be a killer product!!!

They don't. Sure there is a huge improvement for dx9 but not for the much more important dx11 and dx12 APIs. There are improvements but nothing like DX9. Also the architecture has some bottlenecks which they can't remove with a driver. I hope they can fix the biggest bottlenecks with Battlemage. Arrow Lake isn't using Battlemage tGPU, it uses the one from Alchemist, they call it Xe LPG, same as Meteor Lake with more EUs. Some refer to Xe LPG+ on Arrow Lake. Lunar Lake gets Xe2 LPG and Panther Lake gets Xe3 LPG.

 

[Doug S]

Envisioning a Simplified Intel® Architecture

Intel investigated architectural enhancements and modifications for a 64-bit mode-only architecture.

www.intel.com

Intel just published a proposal for a version of X86 (X86-S) with some of the legacy instructions and other outdated functionality removed. In particular, no 32b OS support, nor native 16b support. This proposal does still support 32b apps, however, so probably not a big deal for most people.

That's a really poor half hearted attempt to get rid of legacy. If you're going to do it, really do it!

I can't wait to see Linus tear them a new one when he gets a load of this mess. All support for 16 & 32 bit code should have been removed, including at ring 3. Deprecating instructions but leaving them "ignored" means the opcodes can't be reused which is a real shame for an ISA starved for shorter instruction encodings! Requiring paging in 64 bit mode and booting in 64 bit mode? How's that supposed to work, is UEFI going to have to include a page table? Why not just support a pageless mode, not everything is a PC and not everything needs paging. Or is Intel giving up on x86 for embedded uses and just conceding that to ARM/RISC-V? I guess so.

 

[Exist50]

Which architecture do you think this will debut in? I don't believe for a second that this is a "proposal". They have everything ready to go. This is their way of informing AMD, hey, we just changed the rules. Have fun!

So now, while AMD engineers will be grumbling doing validation for all the old stuff that their arch still supports, Intel will be using that saved time and transistors to implement some much needed performance enhancements.

I agree with you. There's no way this is just some theoretical "what if". And if there's one architecture that would drive such an initiative, it would have to be Royal. No doubt in my mind about that. However, for hybrid, at least Atom will also need to support this ISA mode. Though I suppose it's possible they maintain the ability to boot as either "legacy" x86 or the new x86s.

Regarding AMD, however, I don't think this changes the competitive picture much. It's going to be years before we see anything on the market supporting this, given how long OS changes take, and it shouldn't be too difficult to apply to an already full x86 baseline. I can think of two main reasons for Intel to push this change. 1) They're designing something properly from scratch, and want to cut as much legacy overhead as possible, or 2) they're scared of security issues with some of this legacy, and want to be more proactive about preventing them.

 

[Hulk]

That's a really poor half hearted attempt to get rid of legacy. If you're going to do it, really do it!

I can't wait to see Linus tear them a new one when he gets a load of this mess. All support for 16 & 32 bit code should have been removed, including at ring 3. Deprecating instructions but leaving them "ignored" means the opcodes can't be reused which is a real shame for an ISA starved for shorter instruction encodings! Requiring paging in 64 bit mode and booting in 64 bit mode? How's that supposed to work, is UEFI going to have to include a page table? Why not just support a pageless mode, not everything is a PC and not everything needs paging. Or is Intel giving up on x86 for embedded uses and just conceding that to ARM/RISC-V? I guess so.

Why do you think Intel presented the plan that they did instead of the one you and Linus (you project will) recommend? I'm not being snarky, it's an honest question. What are the pros and cons of Intel's plan as you see it?

 

[Mopetar]

96 is the year of the Rat. It's for new beginnings. I'm guessing you ignored her but if you had accepted her offer, your life could have turned out different

I suppose homeless and living under a bridge is different, but I'm not sure I'd want such a thing.

 

[igor_kavinski]

Craziest thing would be, if MTL launches with ability to work in x86-S mode and Windows 12 is built to use that. But then Zen 5 would need to have this too. Or maybe Microsoft will maintain two versions of the bootloader, one for legacy and one for x86-S.

 

[Exist50]

Craziest thing would be, if MTL launches with ability to work in x86-S mode and Windows 12 is built to use that. But then Zen 5 would need to have this too. Or maybe Microsoft will maintain two versions of the bootloader, one for legacy and one for x86-S.

There's going to have to be a period of time where the OS and/or hardware vendors support both. If the OSs were to drop support, then you couldn't upgrade any of the hardware on the market today, which is a non-starter. And if the hardware vendors drop support, then they can't run any older OS. That might be tolerable in the consumer market, but would be trickier for enterprise.

Either way, not going to happen with MTL. The lead time is far too short. Nova Lake time frame seems more likely.

 

[BorisTheBlade82]

If I understand it correctly, existing CPUs should be upwards compatible - they simply carry a bit of ballast. Also, Intel did not say that much about what kind of benefits they expect. Yes, boot should be accelerated. But how much area is there to be saved, how about performance in general?

 

[Doug S]

Why do you think Intel presented the plan that they did instead of the one you and Linus (you project will) recommend? I'm not being snarky, it's an honest question. What are the pros and cons of Intel's plan as you see it?

The pros are: this should have been done a long time ago
The cons are: if you're going to do it, don't do it in half measures make a clean break with the 8086/286/386 cruft

 

[Exist50]

If I understand it correctly, existing CPUs should be upwards compatible

I don't think it's quite that simple. It seems like there's certain behaviors (e.g. undefined instruction handling) that will require the CPU to be aware of which mode it's running in. Probably wouldn't be too hard to adapt to, but will require some hardware work.

 

[A///]

My take from the news was a ring still supports 32 bit instruction and executing old code is still possible. this is cleaning up a process related to the core of the os and the startup functions. if intel removed all legacy function amd would have a field day.

 

[aigomorla]

magic 8 balls

This got me though Uni.
Each time i would ask the 8 ball, will my teacher suck... and unfortunately, it always came out "outlook not so good".
I knew i shouldn't even take that class then.

But even then that still got me to graduate....
Intel can't even do that properly as of late.

A fresh architecture makes most sense which should be Nova Lake. Maybe it's build from the ground up with 64 bit only in mind.

This is too difficult without stable platform.
The last time Intel pulled this off was during Merom and Dolthan.
They had Dolthan to make Merom which became Penryn that later turned into the Core arch.
Before that we had space heaters smithfields and prescotts which were utter waste of silicon and better off as foot warmers.

My take from the news was a ring still supports 32 bit instruction and executing old code is still possible. this is cleaning up a process related to the core of the os and the startup functions. if intel removed all legacy function amd would have a field day.

lol thinking back when everything was moved to UEFI.

 

[Hulk]

The pros are: this should have been done a long time ago
The cons are: if you're going to do it, don't do it in half measures make a clean break with the 8086/286/386 cruft

I don't think I communicated my question clearly.
Why would Intel NOT be making a clean break if that is clearly the right path?

 

[DrMrLordX]

They had Dolthan to make Merom which became Penryn that later turned into the Core arch.

Minor nitpicks: Penryn came after Conroe. Also it was Dothan, not Dolthan. But again, minor stuff.

 

[Thunder 57]

Minor nitpicks: Penryn came after Conroe. Also it was Dothan, not Dolthan. But again, minor stuff.

You don't say?