During a time of increased competitor activity, Intel has decided to disclose some of the high level details surrounding its next generation consumer processor, known as Rocket Lake or Intel’s 11th Gen Core. The new processor family is due in the market in the first quarter of 2021, and is expected to share a socket and motherboard compatibility with the current 10th Gen Comet Lake processors, providing an upgrade path even for those with a Core i9-10900K, Intel’s highest performing desktop processor to date. New 500-series motherboards are also expected to be available.

The new Rocket Lake-S silicon or SoC is going to be known as ‘Cypress Cove’. Intel confuses itself in the press release compared to the PDF presentation, as the press release dictates that this isn’t the core – it specifically states that the core microarchitecture is Ice Lake (Sunny Cove). However the presentation PDF says Cypress Cove is the core. In this instance, to be clear, Sunny Cove and Cypress Cove are set to be practically identical, however Sunny Cove is on 10nm and Cypress Cove is the back-ported variant on 14nm.

Paired with these cores will be the Tiger Lake graphics architecture, known as Xe-LP, which is also being backported from 10nm to 14nm for this product. The combined 14nm representation of Ice Lake cores and Xe-LP graphics is what is going to be known as Rocket Lake, (at least one of) the SoC(s) of the 11th Gen Core family.

With the new processors, Intel is targeting a raw instruction-per-clock uplift in the double digit range, which would be similar to the uplift we saw moving from Comet Lake to Intel’s Ice Lake mobile processors. Because of the node difference, the exact IPC change is likely to be lower than what we’ve seen before, but 10%+ is still highly respectable, especially if Intel is also able to maintain the high frequency it has achieved with the current generation of Comet Lake.

One of the benefits of moving to a back-ported Sunny Cove core will be the inclusion of the AVX-512 vector acceleration unit in Cypress Cove. This enables Intel to enable its library of Deep Learning Boost technologies for AI and ML acceleration, including support for Vector Neural Network Instructions (VNNI), finally bringing AVX-512 to the desktop platform.

However, to mix and match the right combination of core count, graphics, and AVX-512 for die size/yield/cost, it appears that Rocket Lake-S will only offer a maximum of eight cores in its largest configuration. Within the press release PDF, Intel stated that the current silicon as tested is rated for 125 W TDP, with a top turbo boost of 250 W, which matches what we see on the Core i9-10900K already. There’s no escaping the performance-per-watt characteristics of the process node, which indicates that Intel might find hitting those high frequencies a little easier with fewer cores to deal with. Intel is also promoting new overclocking tools with Rocket Lake, however did not go into details.

Another feature that Intel has disclosed with Rocket Lake is the move to PCIe Gen 4.0 on the processor, with up to 20 lanes available. These are likely to be split into one x16 for graphics and one x4 for storage on most motherboards, and this aligns with what we’ve seen on the latest generation of Intel Z490 motherboards, some of which have already promoted support for PCIe 4.0 ‘on future Intel processors’. This means Rocket Lake. Intel also mentions that the memory controller now supports up to DDR4-3200, however the projected performance numbers were done with DDR4-2933 memory.

On the graphics side, moving to the Xe-LP graphics architecture is going to be a big uplift in graphics performance, with Intel suggesting a 50% improvement over current Comet Lake integrated graphics. It is worth noting here in the slide that Intel mentions ‘UHD Graphics ft Xe Graphics Architecture’ – this would perhaps point to a scaled down version of Xe compared to Tiger Lake. I’m fully expecting to see only 32 EUs here, as a balance between die area, power, and performance. In the fine print it suggests that there will be some versions of Rocket Lake without the integrated graphics enabled, similar to the F processors we see on the market today.

That being said, for those units with integrated graphics, Intel is promoting new media encoders and display resolution support, with up to 4K60 12-bit for 4:4:4 HEVC and VP9, or up to 4K60 with 10-bit 4:2:0 AV1, showcasing AV1 support for mainstream processors. Display resolution support has also increased, with up to three 4K60 displays or two 5K60 displays, supporting DP 1.4a (with HBR3) and HDMI 2.0b.

This was an unexpected news announcement this morning - speaking to peers it all seems to be a bit of a surprise - perhaps even for the PR teams, given that the system configurations as 'projected' in the slide above is dated 6th August, almost 3 months ago. It will be interesting to hear if Intel will disclose more details ahead of launch.

Source: Intel

Related Reading

 

 

 

POST A COMMENT

188 Comments

View All Comments

  • dullard - Thursday, October 29, 2020 - link

    To make it easier on developers. Few developers want to have many versions of the software out there, one version for CPUs with AVX-512 and one version without. Remember all the hassle of installing 32-bit or 64-bit versions, and making sure you have the right one? With AVX-512 getting down to almost all CPUs, it encourages developers to finally incorporate it into software. Until then, it was just sporadically included into specific software for specific use cases. Reply
  • brucethemoose - Thursday, October 29, 2020 - link

    One can compile support for multiple SIMD targets into a single executable. Automating this in a standard library is even a goal of some programming languages atm.

    Its just a PITA. I can't even imagine supporting all these x86 architectures, each with their own subset of AVX1 or 2 or 512, as an assembly programmer.
    Reply
  • Buck Turgidson - Thursday, October 29, 2020 - link

    As someone who deals with both x86-64 and ARM64 assembler (as I’m the poor sod who writes the hyper-optimized routines) it’s not as big an issue as you’d think. Nobody (outside of those in the compiler/interpreter space) is writing whole modules or significant libraries in assembler. In most cases, it’s only used sparingly in specific scenarios. Generally, it’s where we discover that either the compiler is grossly inefficient or the intrinsics implementation is poor (sadly, compiler intrinsics are still hit or miss). In that situation, we’ll generally look at the disassembled output, come up with something better, and move the function to an external asm and link it. Generally I keep it symmetrical between ARM and x86, not the least of which is the compilers (especially GCC) seem very good at generating the same inefficiencies across architectures (the load/store’ness of ARM seems to make it worse, I’ve seen some bizarre compiler misfires on ARM around load/store).

    So how does this relate to AVX version? I can count on one hand the number or manually coded AVX functions I’ve written. And when deciding what AVX rev to use, that came down to were there instructions in the later AVX set of great value in the situation I was faced with, if not, you go with lowest common denominator. Keep in mind (despite my negative comments regarding intrinsics) almost everything we’re doing in AVX (and other simd implementations) is being done with intrinsics. So for someone on the team to note a serious enough performance anomaly for me to do doing some hand-coding, is super rare in that space (mainly because the whole point of those instructions is they reduce iterative complexity).

    Most of the time, when I’m having to rework something in assembler, it’s almost always far more mundane stuff (e.g. optimized fallback implementation that’s needed for a CPU that doesn’t support some level of AVX).
    Reply
  • Kangal - Thursday, October 29, 2020 - link

    What about emulators?
    Useless on old ones like Nintendo Wii and lower, but I've heard it is handy for the heavier task ones such PS3, WiiU, and Switch.

    Or how about emulating different ISA, such as Mac/Windows emulating older 32bit-x86 programs on a newer ARM CPU ?
    Reply
  • Buck Turgidson - Saturday, October 31, 2020 - link

    I dunno, I’ve never thought about trying to write an emulator for the PowerPC ISA. Both the 360 and the PS3 are, in some fashion, PowerPC ISA. The PS3’s Cell CPU thingie is a PPC core with a bunch of special vector units, while the 360 has a triple-core, SMT enabled PPC CPU. While I can’t cite specific use-case scenarios for mapping PPC ISA translation to AVX (mainly because I don’t know the PPC ISA), I’m sure there are a few, probably some that are specific to emulation scenarios (beyond just the obvious AltiVec mappings). I’d imagine, in the case of the Cell’s vector units, AVX would be a good use-case, but that’s just a supposition because I assume the Cell vector units have functionality overlap with AVX, but how those Cell vector units work (context and state, types and alignment) I have no idea. That said, to borrow from Hunter S. Thompson, people who write emulators are high powered mutants, never even considered for mass production. Reply
  • sing_electric - Sunday, November 1, 2020 - link

    I'm wondering how the vector execution on the cell was used in practice; it wouldn't surprise me if it was lightly used on many titles given developer unfamiliarity with it. I think IBM released a very low-speed emulator for testing out code for its Cell-based chips. I'm also wondering whether GPU emulation might be a route to try. Reply
  • abufrejoval - Friday, October 30, 2020 - link

    Thanks for your insights!

    It's comments like this, which make Anandtech so attractive.
    Reply
  • RSAUser - Thursday, October 29, 2020 - link

    AVX512 is only useful for a very limited subset of tasks, it usually requires a lot of effort on the part of the developer for little gain, the fact that more CPU have it doesn't really change anything. Reply
  • Klimax - Friday, October 30, 2020 - link

    Inaccurate. AVX512 will not see benefit if scenario is massively memory bandwidth bound and no transcendental functions. Otherwise it can accelerate code incredibly.

    And it actually contains functions like sin or log which never had direct support in any of previous SSE/AVX extensions. (Closest one could get was through SVML) And they are FAST. (Even SVML loses significantly)
    Reply
  • iAPX - Thursday, October 29, 2020 - link

    I would recommend to take a look at x264 source-code: https://code.videolan.org/videolan/x264/-/tree/mas...

    Yes, there are some ASM code today, using AVX, AVX2 and AVX-512 when needed.
    Reply

Log in

Don't have an account? Sign up now