This event includes forward-looking statements about future products and other topics, which are based on our current expectations and subject to risks and uncertainties. Please refer to the press release for this event and our SEC filings at intc.com for more information on the risk factors that could cause actual results to differ materially. Welcome to Architecture Day 2021. In 2018, Intel highlighted the need for continued innovation in 6 key areas. Intel also identified four foundational compute architectures that are necessary for the next era of compute. Since then, Intel has continued to execute this vision, shipping technologies and products like Ice Lake and Tiger Lake CPUs, Intel's first discrete GPUs on Xe-LP architecture, and Agilex FPGAs. In March, Intel announced our new manufacturing strategy, leveraging both internal and external fab infrastructure. In July, Intel unveiled one of our most detailed roadmaps yet, extending the promise of Moore's Law with new transistor, interconnect, and packaging innovations. To accelerate these innovations, Intel created oneAPI, a unified programming model that seamlessly works across domains and is now being used by developers worldwide. Please welcome Intel's Chief Architect and Senior Vice President of Accelerated Computing and Graphics, Raja Koduri. Hello, everyone. It's great to see you all. Thank you for joining us for our Third Architecture Day. Me and my fellow architects and engineers are so happy to be with you virtually. However, I'm so looking forward to doing this with you all live in the same room and immerse in deep, geeky conversations over some quality ice cream and hot wings. This is an awesome time to be a computer architect. Technology is changing at a torrid pace. Looking back at just the last year, technology was at the heart of how we all communicated, worked, played, and survived through the pandemic. Enormous computing power proved crucial. We witnessed the development of life-saving vaccines, advances in computer vision, cryptocurrencies, decentralized finance, augmented reality, and space travel. It's accelerating. We are seeing MetaHuman, GitHub Copilot, software creating software, and this little thing called AI. Some of these save lives, others altered our lifestyles, some are game-changing, and some controversial. No matter where you look, our lives are intertwined with digital technology. Every demanding workload we look into and every innovating customer we talk to have one meta performance ask, 1,000 ask. They ask, "Can you make our workloads 1,000x faster by 2025?" That's just four years away. 1,000 times is Moore's Law to the power of five. That sounds impossible. How will we do that? To meet this 1,000x demand by 2025, we will need to achieve the minimum Moore's Law improvement, 4x or so, in each of these technology areas: process, packaging, memory, and interconnect, and architecture. Architecture is the alchemy that brings them all together with software. Together, they give us the multiplicative factor. All those 4x improvements could combine to give us the 1,000 times we need for demanding workloads. This is just an illustration to show why it's an exciting time to be an architect. Speaking of architects, Pat Gelsinger recently rejoined us as CEO, and he is a renowned architect. Pat reminds us that what we do is important because the world is counting on engineers to solve the most difficult problems, to enrich people's lives, to make them happier, healthier, safer, and to architect our silicon at the speed of software, which means a torrid pace. We have a rich selection of compute engines to choose from. Several flavors of scalar vector matrix and spatial engines to combine and make hybrid computing architectures that deliver nonlinear gains on demanding workloads. When we leverage the best transistor for a given engine, connect them through advanced packaging, integrate high bandwidth, low power caches, equip them with high capacity memories and low latency interconnect, we have hybrid computing clusters in a package. Every product I look at in our roadmap looks like collection of systems on packages, products ranging from watts to kilowatts. Today, my fellow architects will share our advances in accelerated hybrid computing with architectures that establish new foundations in products whose releases are imminent. You'll hear about one of the biggest shifts in x86 architecture in over a decade. We will begin by introducing two next generation x86 core microarchitectures. First, we will present the efficient core, a highly scalable microarchitecture optimized for multi-core performance per watt. Next, we'll present the performance core optimized for single threaded performance and AI. We will walk you through the architectural magic that combines these two cores to deliver our first performance hybrid architecture, Alder Lake, which will delight billions of PC users. You will hear about the advances we are making in visual computing architectures with Xe-HPG and our discrete graphics. Later, we will look at a new accelerated hybrid architecture designed for data center, Sapphire Rapids, which combines our performance cores with new accelerator cores. We'll show you Mount Evans IPU, infrastructure processing unit. This is the beginning of hybrid infrastructure computing in a package. We'll close it with the tour de force of all the latest silicon technologies, our moonshot, Ponte Vecchio. Let's get started. I'd like to welcome the Chief Architect for the Efficient x86 Core, Stephen Robinson. Hey, Raja. Stephen, start us off at the bank. Absolutely. Hey, everybody. I am excited to introduce to you our new microarchitecture, previously codenamed Gracemont. When we started this journey, we wanted to deliver a scalable microarchitecture that could address computing needs across our entire spectrum of products, from low-power mobile applications to many core microservices. Our primary goal was to build the world's most efficient x86 CPU core. We wanted to do that while still delivering more IPC than Intel's most prolific CPU microarchitecture to date, Skylake. We also set an aggressive silicon area target so that multi-core workloads could be scaled out using as many cores as necessary. With these architectural anchors in place, we also wanted to deliver a wide frequency range. This allows us to save power by running at low voltage and creates headroom to increase frequency and ramp up performance for more demanding workloads. Finally, we wanted to provide rich ISA features, such as advanced vector and AI instructions that accelerate modern workloads. I am pleased to say that we delivered on all of our goals. It's my honor to introduce Intel's newest efficient x86 core microarchitecture. Thanks to a deep front end, a wide back end, and a design optimized to take advantage of Intel 7, this CPU core delivers a breakthrough in multi-core performance. Let's now dive deeper into the details, starting with the front end. The first aspect in driving efficient IPC is to make sure we can process instructions as quickly as possible. This starts with accurate branch prediction. Without accurate branch prediction, much of the work ends up being unused, which is wasteful. We implemented a 5,000-entry branch target cache. We complemented it with a long history-based branch prediction. This helps us quickly generate accurate instruction pointers. With accurate branch prediction, things like instruction cache misses can be discovered and remedied early, before becoming critical to program execution. Workloads like web browsers, databases, packet processing, these all benefit from these capabilities. We also have a 64 KB instruction cache that keeps the most useful instructions close without expending power in the memory subsystem. This microarchitecture features Intel's first on-demand instruction length decoder, which generates pre-decode information that's stored alongside the instruction cache. This gives us the best combination of characteristics, where code that has never been seen before is decoded quickly, yet the next time it's executed, we bypass the length decoder and save energy. The new core also features Intel's revolutionary clustered out-of-order decoder that enables decoding up to six instructions per cycle while maintaining the energy efficiency of a much narrower core. It also includes hardware-driven load balancing, which takes long chains of sequential instructions and automatically inserts toggle points to ensure parallelism. The second main aspect to achieving performance is ensuring you extract any parallelism inherent in the program. With five-wide allocation, eight-wide retire, a 256-entry out-of-order window, and 17 execution ports, this microarchitecture delivers more general integer IPC than Intel Skylake core while consuming a fraction of the power. The execution ports are scaled to the unique requirements of each unit, which maximizes both performance and energy efficiency. Four general-purpose integer execution ports are complemented by dual integer multipliers and dividers. We can also resolve two branches per cycle. For vector operations, we have three SIMD ALUs. The SIMD integer multiplier supports Intel's Vector Neural Network Instructions. Two symmetric floating-point pipelines allow executing two independent add or multiply operations. Thanks to Advanced Vector Extensions, we can also execute two floating-point multiply-add instructions per cycle. Advanced crypto units round out the vector stack, which provide AES and SHA acceleration. The final aspect to achieving efficient performance is a fast memory subsystem. Two load pipelines plus two store pipelines enable 32 byte read and 32 byte write bandwidth at the same time. The L2 cache, which is shared among four cores, can be 2 or 4 MB, depending on product level requirements. This large L2 provides high performance and power efficiency for single-threaded workloads by keeping data close. It also provides enough bandwidth to service all four cores. The L2 can provide 64 B of read bandwidth per cycle with 17-cycle latency. The memory subsystem has debuffering, each four-core module can have up to 64 outstanding misses to the last level cache and beyond. Advanced prefetchers exist at all cache levels to automatically detect a wide variety of streaming behavior. Intel Resource Director Technology ensures that software can control resources among the cores. A robust set of security features, along with having an ISA that can support a wide range of data types, is important for every new microarchitecture. We support features like Intel Control-Flow Enforcement Technology and Intel Virtualization Technology Redirection Protection. We put additional focus on security validation and developed several novel techniques to harden against certain attack vectors to maintain tight security. We also implemented the AVX ISA, along with new extensions to support integer AI operations. This allows software to run with great performance. In addition to choosing what to include, one of the most important aspects of designing new microarchitecture is deciding what not to include. We balance this trade-off by focusing on those features that were needed and keeping out the rest. This results in area efficiency, which in turn allows products to scale out the number of cores. This also helps reduce energy per instruction. Minimizing power is the biggest design challenge for today's processors. Power is a combination of multiple factors of which voltage is the most important. This microarchitecture and our focused design effort allow us to run at low voltage to reduce power consumption, while at the same time creating the power headroom to operate at higher frequencies. Let's take a look at the results of this new design. First, looking at latency, if we compare our core to a single Skylake core for a single logical process, we deliver 40% more performance at the same power. Now, we also deliver the same performance while consuming less than 40% of the power. To say it differently, a Skylake core would consume 2.5 times more power to achieve the same performance. This is a tremendous achievement. However, we are even more excited about the throughput results. If we compare four of our new CPU cores against two Skylakes running four threads, we deliver 80% more performance while still consuming less power. Alternatively, we deliver the same throughput while consuming 80% less power. Again, this means that Skylake would need to consume five times the power for the same performance. As you can imagine, these are very exciting results for us. What makes all this truly incredible is when you consider that we can deliver four of our new cores in a similar footprint as a single Skylake core. In conclusion, we are extremely proud of our new highly scalable microarchitecture. Thanks to our deep front-end innovations, our wide back end, and design optimizations using Intel 7, we created a microarchitecture that excels at throughput efficiency. We exceed Skylake core performance while consuming less power in a smaller footprint. I want to thank all of the talented engineers on the architecture and design teams, and I also want to acknowledge the support we got from everyone within the company. Thank you for your time. Back to you, Raja. As we just heard, the new Efficient x86 Core provides a highly scalable architecture that will address compute requirement across the entire spectrum of our customer needs, from low-power mobile applications to mini-core microservices. Next, we are going to take a deep dive into our new Performance x86 Core architecture. While maintaining efficiency, this core is designed for raw speed, pushing the limits of low latency and single-threaded application performance. Without further ado, I'd like to hand things over to the Chief Architect of the Performance Core, Adi Yoaz. Hey, Raja. Take it away. Thank you, Raja. It's an honor to be here. Hello, everyone. I'm really excited for this opportunity to make the first public introduction of the new Performance Core architecture, which was previously codenamed Golden Cove. When we started this journey, we did so with an ambitious goal, not only to deliver the highest performing CPU core Intel has ever built, but also to deliver a step function in CPU architecture performance that will drive the next decade of compute. To do that, we focused on both general purpose compute as well as accelerated compute for emerging workloads. As we looked at the trends in current and future workload patterns, we saw that workloads are growing in their code footprint and in their demand for compute resources. We also saw that data sets are massively growing, and data bandwidth requirements are becoming increasingly critical. We also see exciting trends in demands for greater AI compute. We wanted to not only continue on the path of improving the performance of our existing AVX vector acceleration hardware and ISA, but also to expand on this with a new technology to deliver yet another step function in AI performance acceleration. Last, but certainly not least, we wanted to deliver a scalable architecture with a wide dynamic range to power the broadest set of devices, from low TDP laptops to desktops to data centers. With our new Performance Core architecture, we wanted to enable core configuration options to cover the various needs across all these segments. I am thrilled to announce that we delivered on all of our objectives, and it is my privilege to introduce Intel's new Performance x86 Core architecture, designed for speed, pushing the limits of low latency and single-threaded application performance. To keep driving general purpose performance, we have architected the machine to become wider, deeper, and smarter. It has a deeper out-of-order scheduler and buffers, more physical registers, wider allocation window, and more execution ports. Making the machine wider and deeper can expose higher degrees of parallelism and provide higher performance only if it is fed with instructions from the correct path and with data coming in on time for execution. To make this new wider and deeper machine effective, we also made it smarter with features that improve branch prediction and instruction supply, collapse dependency chains, and bring data closer to the time when it is needed. On top of the baseline features that speed up most common workloads, we added dedicated features for workloads with particular properties. For example, in order to better support applications with large code footprints, we are now tracking many more branch prediction targets. For emerging workloads with large irregular datasets, the machine can simultaneously service four-page table walks. For the evolving trends in machine learning, we added dedicated hardware and new ISA to perform matrix multiplication operations for an order of magnitude performance increase in AI acceleration. This is architected for software ease of use, leveraging the x86 programming model. Additional performance is achieved through core autonomous fine-grain power management technology. The Performance Core integrates a new microcontroller that can capture and account for events in granularity of microseconds instead of milliseconds and tighten the power budget utilization based on actual application behavior. The result is higher average frequency for any given application. This is our largest architectural shift in over a decade. With that as an introduction, let me now dive deeper into the details of our Performance Core architecture, starting with the machine's front end. The first step in building a balanced wider core is to widen and enhance the core's front end. Micro-operation supply was improved both from the decoder side and from the micro-op cache path. The length decode is now doubled, running at 32 B per cycle, and two decoders were added to enable six decoded micro-ops coming per cycle from the decoders. When delivering micro-operations out of the micro-op cache, we can now get eight micro-ops per cycle, and the micro-op cache itself has increased to hold 4K instead of 2.25K micro-operations. This allows us to better feed the out-of-order engine, deliver higher micro-op bandwidth, and do so in a lower latency shorter pipeline. To better support software with large code footprint, we doubled the number of 4K pages and large pages stored in the ITLBs. We have a smarter code prefetch mechanism hiding much of the instruction cache miss latency, and improved branch prediction accuracy to reduce jump mispredicts. The branch target buffer is more than 2X larger than the one on the previous generation, which greatly improves the performance of workloads that have a lot of code. It uses a machine learning algorithm to dynamically grow and shrink its size. It shuts off excess capacity when it's not needed to save power, and it turns on extra capacity when it's needed to improve performance. With a wider and smarter front end, we now turn to the out-of-order part of the machine. The out-of-order engine is where the magic happens, and this is what separates CPU architectures from all other architectures. We are widening the machine by going from five to six wide rename allocation and from 10 to 12 execution ports. The machine is also becoming significantly deeper with the 512 entry reorder buffer, more physical registers, and a deeper distributed per operation type scheduling window, all tuned for performance and power efficiency. To further improve both performance and power efficiency, P-core smart features enable collapsing dependency chains by executing some simple instructions at the allocation stage, thereby saving resources down the pipe. This allows other operations reside on the critical path, run faster while better utilizing execution bandwidth and save power. With a wider, deeper, and smarter out-of-order engine, we also wanted to enhance our execution units significantly. Let me start with the integer part. We added a fifth general-purpose execution port with the fifth integer ALU and the fifth single-cycle LEA. All five LEA execution units can also be used for generic arithmetic calculations like additions and subtractions, as well as for fast multiplications by some fixed numbers. The LEA added on port 10 can also do scaled operations in a single cycle, similar to the LEA we have on ports one and five. It was important for us to increase compute resources here, as ALU operations are so common that much of the software will take advantage of it. Similarly, on the floating point vector side, for the many cases where vector code is prevalent, we have added new fast adders on ports one and five. These are three-cycle fast adders with two-cycle bypass between back-to-back floating point add operations. In our previous generation cores, floating point add operations are executed on the FMA units with a four-cycle latency when executed on port zero and one, and a six-cycle latency when executed on port five. The new performance core supports the execution of new data types with new ISA and associated hardware. FP16 data type is now added in AVX-512 mode, where it comes with a complex number support and is highly effective in speeding up networking applications. I'm super excited about one more big thing regarding our new matrix execution architecture. Before I get to that, let me finalize our general purpose compute advancements. Turning now to the memory subsystem. The L1 data cache was opened up to supply more data to the new wide execution machine, plumbed for 50% higher throughput for the most common scalar and vector loads, while still supporting 1K bit per clock in the case of efficient 512 bit wide vector loads. A very deep out-of-order machine with deeper load buffer and store buffer has the potential to expose much more memory parallelism. Unlocking that potential requires a whole lot of smarts. The new Performance Core tackles this problem from multiple angles. The memory subsystem has learned how to identify independent loads and stores more effectively than ever before. When conflicts are recognized, functionality has been added to react immediately and recover with minimal disruption. We have greatly increased the opportunities where store data can be directly steered to a load, and latency for such cases has been optimized. The new Performance Core was architected recognizing that modern workloads demand more data from all cache levels. To better address mid-range working sets, the L1 data TLB has been increased by 50%, and the L1 data cache itself can fetch 25% more misses in parallel. The L1 data prefetcher has been enhanced to confidently lock onto stride patterns, even in the face of an aggressively out-of-order execution architecture, and has extended its reach 8x compared to the previous generation. The machine can now simultaneously service four-page table walks. This is a 2x capability improvement beneficial for emerging workloads with large irregular datasets. A hungry compute engine needs feeding, and the L2 cache subsystem is engineered to satisfy that need. The L2 cache itself has been customized for two different market segments. The client P-core gets a latency-optimized 1.25 MB L2 cache, while data center P-core gets a generous 2 MB private cache, allowing large code and data workloads to scale to larger core counts. For big data workloads, feeding the core means pulling data into the core from across the system. To that end, the L2 cache subsystem has more than doubled the number of demand or prefetch operations that can be serviced in parallel. A completely new L2 prefetch engine was developed to leverage a deeper understanding of program behavior. The prefetch engine observes the running program in order to estimate the likelihood of future memory access patterns. It can identify multiple potential future sequences, and can prefetch down multiple potential paths, each path at runner head depth individually tailored for its estimated likelihood. This chart shows the performance improvement of our current 11th Gen core architecture to the new Performance Core at ISA frequency. As we see, the effect of the micro architectural enhancements we've discussed thus far on general purpose performance provides an average improvement of 19% across a wide range of workloads. This level of improvement is even larger than what we delivered with the Sunny Cove core over the Skylake core. It is just to give you a taste for what the performance improvement looks like for existing workloads. Of course, for new workloads that take advantage of our new ISA and architectural advancements, the numbers go up significantly. To dramatically increase the IPC of AI applications, we developed a new technology called AMX. AMX is our next generation built-in AI acceleration advancement for machine learning, inference, and training targeted for data center. Today, we are already industry leaders in CPU AI acceleration in the data center market. With INT8 used for inference, our VNNI technology delivers 256 INT8 operations per cycle per core, that is already over 2x our x86 CPU competition. We were not satisfied with that. With AMX, we will expand that by 8x, delivering 2,048 INT8 operations per cycle per core. There are two components in the AMX architecture today. The first component is tiles, which is a new state component consisting of eight two-dimensional registers, each 1 KB in size. The programmer part of this architecture is straightforward: configure, load, store, clear. The more interesting operations are to be carried out by co-processors that operate on tiles. Tile state is always managed, which required new extensions in the XSAVE architecture. The second component is TMUL, which stands for Tile Matrix Multiplication and is the first co-processor attached to the tiles. It is a systolic array supporting all flavors of INT8 with 32-bit accumulation and BF16 with single-precision accumulation. I also wanted to give you a broader view of the underlying architecture behind AMX. The architecture is highly flexible and can be expanded to implement further co-processors down the line to address different types of computation needs. In the current implementation, we have the TMUL engine as a tightly coupled co-processor within the P-core host. The host is doing all loop and address management, as well as the SIMD processing of the data. The TMUL engine performs matrix multiplication in parallel to the host. The resulting power performance is much better than simply running these algorithms on the SIMD hardware, as the matrix engine is much more efficient and the remaining work on the host is generally light. All of the core power budget is given to the matrix engine and the cache subsystem to feed it, which is exactly what you want. The typical flow of a layer in a deep learning topology is for the data to come in straight to the tiles. Meanwhile, the host is running ahead dispatching tile loads while TMUL is operating on the ready data. At the end of the multiplication, the tiles are stored to the nearest cache level to the co-host thanks to the tight coupling with the core. SIMD code is used to post-process the output and store it to the location where the next layer will get it from. There are software techniques to fuse and interleave these operations so that both the host and the AMX unit are busy simultaneously, which provides maximum performance. As I said, on our current implementation, AMX peak compute throughput is 2,000 INT8 operations per cycle per core, which is 8x higher compared with VNNI running on 2 wide FMAs at less than 3x the execution power. With AMX, we can also perform 1 K b float16 operations per cycle to get higher accuracy multiply accumulate computations for training workloads. These are the order of magnitude type increases developers and users are looking for, and that is what we have delivered with our new AMX technology. In conclusion, we are very excited about this new performance core architecture. This P-core is not only the highest performing CPU core Intel has ever built, but also delivers a step function in CPU architecture performance that will drive the next decade of compute. It is a wider, deeper, and smarter machine that delivers substantial improvement for general purpose compute. It is tailored for the increased needs of large datasets and large code footprint applications, and it also delivers an order of magnitude in accelerated performance for AI workloads. The new architecture has enhanced power management capabilities that improve frequencies and optimize power budget utilization, and it also supports core configuration options for scalability across different market segments. Finally, I really want to thank the team of talented architects and engineers at Intel that made these advancements possible. Thank you all for your time. Back to you, Raja. Thank you, Adi. With our new performance and efficient cores, you have seen the details of one of the biggest advancements in x86 architecture in over a decade. Let's put that in context. We have shown you this roadmap of cores and [Monts] in the past. You may have noticed we have changed our nomenclature since. Our [Monts] were designed for the best area-efficient multi-threaded performance. Our cores were designed for maximum single-threaded performance. While efficient core truly excels in throughput efficiency, it's also getting a boost in single-threaded performance. The performance core is not only pushing the limits of low latency and single-threaded performance, it's also getting a boost in multi-threaded performance with additional AI acceleration. Where we want to be is here, where we can combine the best of both. Best of both in one system to get the raw performance of the P-core with the scalability of the E-core. We need a very high performance hybrid. Talking about hybrid, everyone understands the idea of the hybrid car, as using hybrid technology to get the most miles out of a tank of gas. That's a good analogy for the conventional notion of hybrid computing, getting the most hours out of a battery. There is another type of automotive hybrid. The fastest racing cars in the world, like in Formula One, use hybrid technology to achieve maximum performance. In addition to the conventional turbocharged engines that give them top speed and enough range to make it to the finish line on a tank of fuel, they add electric power to blast them out of the corners with acceleration that cannot be achieved with conventional engines. We need a high performance hybrid. The biggest challenge, the magic, is to bring these two cores together, working efficiently with existing software. This is a huge undertaking, and we have been hard at work on this problem for years. We now have the solution. To share more, I would like to invite our Client Architect, Rajshree. Thanks, Raja. Hello, everyone. I'm really excited to share with you unique solution we have developed to ensure two new cores you just heard about, Efficient-core and Performance-core, work seamlessly together so we can maximize system performance and efficiency. As we all know, performance expectation can vary drastically for different computing tasks. One of the most important consideration we had while designing our next generation client CPU SoC was ensuring optimal task scheduling across two different core types. The challenges given to the team were, first, how do we go beyond traditional hybrid as we know it? Second, how do we get both core types to work together intelligently to maximize performance? As Raja mentioned, we could have taken conventional approach of simply assigning threads to cores based on static rules. That leaves a lot of performance on the table and creates overhead with software development. Our solution needed to be dynamic and autonomous to software stack that is running on top. We decided to help OS make more intelligent decisions. It is needed to handle a wide range of common client activities, such as gaming with streaming, content creation, productivity, while dynamically adapting to operating conditions such as temperature and power budget. We also wanted to eliminate the need for software developers to having to rewrite their existing code and remove overhead of handling scheduling task in software. Only a hardware solution could meet all these requirements. We developed Intel Thread Director technology. Thread Director technology is one of the most significant and exciting innovations in our client roadmap. Thread Director technology allows us to provide smarter assistance to the OS by monitoring instruction mix, current state of each core, and relevant microarchitecture telemetry at a granular level. This also allows OS to utilize information it didn't previously have any visibility into at time of making its scheduling decisions. By implementing Intel Thread Director in hardware, we are able to keep advantage of our performance monitoring unit, which provides the best hardware telemetry in the industry. Access to this information allows Intel Thread Director to assist OS in optimal runtime scheduling. Traditionally, OS would have made decisions based on limited information that was available, such as foreground versus background. Thread Director adds a new dimension to the hardware telemetry. Threads with higher performance requirements are assigned to most performant cores. Let's walk through a scheduling example on a real scenario. Let's say a user starts a performance critical task, such as a game or a content creation software. Those threads first will be assigned to our Performance-cores. If a background task such as email sync or network drive backup starts, those lower priority, less demanding tasks will go to our Efficient-cores. Let's assume a case where all the performant cores are busy, but a thread needing even higher performance becomes ready, such as an AI thread using CPU AI instruction. In this situation, Thread Director provides what we refer to as a hint to the OS, indicating there's a higher performance thread needing attention. Thread Director also identifies a candidate thread that could be moved from Performance-cores to Efficient-cores based on relative performance ordering, making room for that AI thread. This is where the dynamic nature of our innovation shines. Nothing is static based on any software. Everything is dynamic based on the current context of whatever is running on the system, all augmented by hardware telemetry. Last, if a thread running on Performance-core enters a spinning state, waiting for work to show up, Thread Director reports this situation back to OS. This thread will be moved over to an E-core, thereby making room for a more performant thread to be allocated to our Performance-cores. This is our animation explanation of the technology. Let's see it in action on Alder Lake, running Windows 11, incorporating Thread Director feedback in real-time. In typical cases, we see combination of scalar and vector instruction, mix of important and background tasks. We are going to see how Thread Director helps OS with placement of these threads. In the first example, we have a representation of a typical media content creation usage we see with real-world software. The green threads that you are seeing here are mostly scalar instruction. The dark blue threads that you see are vector instructions, and the light blue are background task. The vector instructions, for the most part, get prioritized on performance cores as they require more performance, while some of the green threads and the light blue thread go to efficient cores. Let's look at one more example, this time with office productivity and background application. Office productivity, video conferencing, CPU AI instruction usage in these cases is increasing consistently. Placement of these AI threads is going to be key to maximize performance. As we have seen with previous example, we have green threads which are mostly scalar. We have the orange AI threads added to the mix, where you can see Thread Director prioritizes them to Performance cores. As seen before, the light blue tasks are running on Efficient cores. All these threads here in this mix go through various phases within their own execution. You might have noticed there are phases once in a while where the dark blue vector threads or the orange AI thread go to E-cores. These are the phases where they have some scalar instructions in them. This is where the dynamic nature of this technology prioritizing right thread to right core based on current execution context comes in. I do want to show something else. I want to show fully multithreaded synthetic workload running same instruction mix. Here, all threads go use all available core. To enable this level of fine grain coordination for real performance, Intel jointly worked with Microsoft to incorporate this revolutionary capability into upcoming Windows 11 release. Speaking of which, I would like to invite Mehmet Iyigun from Microsoft to share more details. Hello. Throughout the Windows 11 development cycle, my team has been working with our colleagues at Intel to enlighten and optimize our upcoming OS to take full advantage of the performance hybrid architecture and Thread Director in particular. Much of this work centers around the OS thread scheduler, the kernel component that decides which threads to run and where to run them. These decisions have a huge impact on user perceived performance and power consumption, especially on devices built on hybrid processor architectures. To make its decisions, the scheduler considers attributes such as thread priority, the owning application, and whether the application is foreground or background. For example, threads belonging to foreground applications should be scheduled to high-performance cores. However, up until now, the scheduler had no visibility into the workload running on a thread, whether it's copying memory, spinning in a loop, or performing complex calculations. As such, when demand for high-performance cores exceeded supply, it made suboptimal decisions because it couldn't identify the workloads that would benefit most from the Performance-cores. Thread Director helps close this gap. With Thread Director feedback, the Windows 11 thread scheduler is much smarter about dynamically picking the most appropriate core based on the workload to achieve the best power and performance. Even when all P-cores are busy, it can preempt a thread running on a P-core to swap it with a thread running on an E-core if the latter can benefit more from the P-core. The scheduler, of course, does this without violating any of its priority-based fairness guarantees. Beyond thread scheduling, Windows 11 also uses Thread Director hints when deciding which cores to park and unpark for power savings. For example, if all outstanding work targets E-cores, the system can refrain from unparking a P-core. In addition to automatic workload classification provided by Thread Director, Windows 11 also extends the power throttling API, which allows developers to explicitly specify quality of service attributes for their threads. The new EcoQoS classification informs the scheduler that the thread prefers power efficiency over performance. Such threads get scheduled on E-cores, reducing power consumption and leaving the P-cores available for performance critical threads. The Edge browser, as well as various Windows 11 components, now take advantage of the EcoQoS API to boost energy efficiency. This was a short summary of the improvements we put into Windows 11 in collaboration with multiple teams at Microsoft and Intel. There are many more optimizations I did not talk about and many more in planning stages. What is clear is that we're at an inflection point in heterogeneous computing, and we're going to continue seeing tighter integration and information exchange between hardware and the OS to unleash further performance and better life improvements. I'm looking forward to continuing our collaboration with Intel. Thank you. We are very excited about the performance benefits of this technology and the potential it holds for future innovation. With that, I would like to hand it over to my colleague, Arik Gihon, to give you more details about Alder Lake SoC. Thank you. Hi, everyone. I'm very excited to introduce Alder Lake today, Intel's new client architecture on Intel 7 process that scales from the highest performance enthusiast desktop to the thinnest, most responsive Evo laptops. Alder Lake is Intel's first performance hybrid core design, introducing two core types brought together seamlessly through Intel Thread Director technology. Alder Lake supports the latest state-of-the-art industry standards in memory, I/O, and connectivity for no compromise PC experience. Let's get to know Alder Lake. Alder Lake was built for performance. We started with desktop architecture and scaled all the way down to ultra-mobile. One of our most important goals when designing Alder Lake was to support all client segments through a single, highly scalable SoC architecture with three design points. First, a maximum performance two chip socketed desktop with leadership performance, power efficiency, memory, and I/O. Second, a high performance mobile BGA package that adds imaging, larger Xe graphics, and Thunderbolt 4 connectivity. Finally, a thin, low power, high density package with optimized I/O and power delivery. Supporting this huge range of power and performance is an incredible silicon design challenge. Designing Alder Lake was an amazing technical journey for me, and I would like to share with you how we achieved it. Alder Lake architecture is built from a selection of world-class IPs for die-level configurability. We enable multiple combination of performance cores and efficient cores, a large number of I/Os and accelerators, various level of Xe graphics, and four different memory types. Both P-cores and E-cores are built as interchangeable slices that include a portion of the last level cache, allowing us to build multiple die topologies spanning Alder Lake's huge design range. The accelerators and I/Os are connected through a hierarchical structure configured to support the required bus width, queue sizes, number of ports, and memory access feature set. Alder Lake leverages the Xe-LP graphics from Tiger Lake ported to Intel 7. It supports 1080p gameplay and 12-bit end-to-end video pipeline. Finally, the memory subsystem is designed in tiles to cope efficiently with the large required bandwidth range, memory encryption, integrity, and multiple DDR technologies. Let's take a deeper look at each of the key technologies. Everything starts with the new performance hybrid architecture. We use up to eight high single-thread performance cores and up to eight efficient cores, both supporting high dynamic frequency range and per-core power states. The E-cores are clustered with a shared L2 cache and deliver scalable multi-thread performance and efficient offload of background tasks. The last-level cache has a shared structure between the cores and graphics that provides higher effective cache size on a lightly threaded load. For controlling the operation of this massive compute, we have developed an autonomous power management scheme. This controls the various cores to optimize performance per watt according to software and platform preferences. As we saw in the demo, all of this is orchestrated by the Thread Director for proper workload scheduling. We developed a sophisticated hardware runtime mechanism that identified the class of each workload. The class, together with the energy and performance core scoring mechanism, guides the OS to schedule threads on the right core for performance or efficiency per demand. Let me show you the memory capabilities. Alder Lake delivers a superset DDR technologies with Intel's unique PHYs, supporting DDR4 and DDR5 as well as LPDDR4 and LPDDR5 in a single chip, leading the industry through this major memory transition. Alder Lake supports high-frequency DDR speeds and can alter the speed based on runtime bandwidth requirements while tracking the workload behavior. This allowed high speed / high power or low speed / low power operations based on real-time heuristics. If you think this is cool, we also upgraded our PCIe capabilities. Alder Lake is leading the transition to PCIe Gen 5, with up to twice the bandwidth of Gen 4. It supports up to 16 lanes and reach 64 GB per second, ready for the next generation of SSDs and discrete graphics. Let's see how all of this works together. The challenge of building such a highly scalable architecture is that we need to meet the incredible bandwidth demands of the compute and I/O agents without compromising on power. To solve this challenge, we have designed three independent fabrics, each with real-time, demand-based heuristics. While the workload is running, the power management unit collects telemetry from the fabric sources, track the traffic, and select the most efficient work point. The compute fabric can support up to 1,000 GB per second, which is 100 GB per second per core, or per cluster. It connects the cores and graphics through the last-level cache to the memory. It has high dynamic frequency range, and it's capable of dynamically selecting the data path for latency versus bandwidth optimization based on actual fabric loads. It also dynamically adjusts the last-level cache policy, inclusive or non-inclusive, based on utilization. The I/O fabric supports up to 64 GB per second and connects the different types of I/Os as well as internal devices. It can change speed seamlessly without interfering with device's normal operation, selecting the fabric speed to match the required amount of data transfer. Last, the memory fabric can deliver up to 204 GB of data. It dynamically scales its bus width and speed to support multiple operating point for high bandwidth, low latency, or low power. This real-time scaling enables Alder Lake to dynamically shift the power budget to where it matters the most. Finally, I'm working with the team on Alder Lake in the lab now, and I can't wait to have one at home. Thank you, and back to you, Raja. Thanks, Arik. We look forward to seeing Alder Lake in customers' hands later this year. Let's change gears from hybrid computing to visual computing. I'm sure you all want to hear a little bit more about our discrete Xe GPU architectures. If you step back and look at what we have been doing recently, you'll see that we have made tremendous progress on integrated GPU hardware and software in less than three years. We have effectively doubled performance year-over-year two years in a row now, first with Gen9 to Gen11, and then with Gen11 to Xe-LP. This was an incredible start, and this effort removed friction for millions of users. We raised the performance bar for ultra-thin mobile devices. As we have already announced, we have bigger plans. Integrated graphics is constrained, but discrete, on the other hand, is unconstrained. Well, relatively. This is a great time to be entering the high-performance PC graphics market. Why are we doing this? Why now? These are extremely exciting times. Game engines and software teams are producing near real-life in-game visuals in real time, and leading-edge hardware is enabling everything to come together to deliver incredible experiences that allow gamers to feel more immersed than ever before. Publishers, developers, gamers, and creators are constantly pushing the boundaries of what is possible, always asking more from their hardware, and they are also looking for more innovation and choice. The PC ecosystem is built around innovation and choice. Many different OEMs, many different shapes, sizes, and form factors, and many different operating systems, and a diversity of software. The vast choice of what to buy or the flexibility to build your own PC, to customize, upgrade, and to modify. These are some of the reasons the PC market has been so popular and exciting since the beginning. These are the reasons the PC ecosystem is great. 1.5 billion people are PC gamers. Our focus today is to deliver a better experience for gamers and creators, to give them innovation and choice in hardware, coupled with open and accessible software and tools. To create a great experience across form factor segments and users, to remove friction and deliver high-performance graphics experiences to everyone, we recently unveiled Arc, which is a brand for our visual computing products. The word arc is used to describe the narrative flow and the various plot inflections of a story. Every gamer, game, and creator has a story, and every story has an arc. The Arc brand represents the next chapter of our story and our commitment to removing friction from gamers. Building great GPU hardware is necessary but nowhere sufficient. Great software plays a critical role for the user experience. To discuss the progress we are making on software and user experiences, please welcome the leader of our GPU software team, Lisa Pearce. Thanks, Raja. With our first high-performance gaming GPU, it goes without saying that performance and quality are job one. At the heart of our focus is the design of the core driver itself. That covers integrated and discrete graphics products in one unified code base. We've completed a re-architecture of these core driver components, specifically our memory manager and compiler. As a result, this year, we've improved the throughput of CPU-bound titles by up to 18% and improved the game load times by up to 25%. This load time reduction was accomplished through enhancements to our stage compilation technology, such as eliminating redundant shader compilation and improving task scheduling for our compiler threads. We also completed a major refactor to fully optimize our local memory utilization on our discrete graphics products. At the same time, we implemented over 30 large optimizations affecting over 100 gaming workloads that rolled out in our existing install base this year with our unified graphics driver. Now, we are always about new APIs and engines since new games are always pushing up the visual quality bar. For the last three years, we've been co-engineering new features for DX12 Ultimate with Microsoft. We're excited that at launch, we will support hardware-based ray tracing, mesh shading, and sampler feedback. Together, these technologies deliver next-gen visuals in games like "Hitman 3," "Chivalry 2," and many others. We've also been working closely with Epic, and I'm excited to tell you that Unreal Engine 5 runs on our discrete graphics GPUs today. We can't wait to see what game developers will do next in their next-generation engines. At launch, we'll also enable updates to our user controls to help gamers take advantage of these technologies, including support for AI-assisted virtual cameras, game highlights, and of course, capture for streaming that will make use of our high performance and quality hardware encoders. We also will integrate all of our overclocking and performance interfaces directly to the app. Finally, in the end, it is all about experiences. One thing that gets us really excited is enabling a range of experiences across product segments, from integrated graphics to high-performance discrete. Today, I'm excited to share a new feature that will do just that. First, some background. Given a fixed amount of performance potential in a GPU, gamers are forced to make a choice between high quality and acceptable performance. There are cases where you have content that already runs close to 60 FPS at 4K, and the frame rate can be further increased by upscaling. You can have a more recent content like ray tracing that needs a performance boost even to achieve playable frame rates. Over the years, games have developed various technologies to reconstruct a high-res image from fewer pixels. These technologies use novel algorithms to reconstruct details from neighboring pixels in space or time, but they're often accompanied by issues like blurring or ghosting. These technologies can often fall short with high-quality rendering, like ray trace reflections and shadows, detailed geometry, or high-res textures. Additionally, there are computational overhead in doing these operations. Ultimately, we want to target this region of high performance and high quality. Our solution to this problem is XeSS. XeSS is an easy-to-integrate API, and it fits within today's game engine flow. It uses deep learning to synthesize images that are very close to the quality of native high-res rendering. It works by reconstructing sub-pixel details from neighboring pixels, as well as motion-compensated previous frames. This reconstruction is performed by a neural network trained to deliver high performance and great quality. Now let's see XeSS in action. This is a demo prepared by Rens using Unreal Engine. We can see the demo rendering real-time in 4K, but in reality, the engine renders to a smaller 1080p render target, which is upscaled to 4K by XeSS. Compared to rendering in native 4K, there's no visible quality loss. Upscaling from 1080p to 4K with XeSS gives the same quality image as rendered in native 4K. In this scene to the right, you can see the actual content rendered by the engine. The left side shows how this 1080p image is upscaled by XeSS to achieve the final high-quality result. Rendering to a smaller 1080p render target allows to significantly reduce the rendering time and achieve higher frame rates. The cost of upscaling operation remains relatively small compared to the overall render time. Thanks to the use of AI-assisted scaling, we can also achieve up to 2X performance boost. Now, games that would only be playable in low-quality settings can run smoothly at 4K. It may be a challenge to see these details in the live stream, so we've added a high-resolution video in the demo area that can be viewed on demand. Our goal with XeSS was to deliver neural network-based super sampling for a wide range of GPU hardware across the industry. The demo you just saw was running on our recently announced Arc Alchemist SoC, leveraging our new XMX hardware acceleration that we will discuss further in a few minutes. In addition, we also came up with another innovation to enable XeSS on a broad set of hardware, including our competition, with a smart quality-performance trade-off. We accomplished this by using DP4a instruction, which is available on a wide range of shipping hardware, including integrated graphics. This brings the benefits of XeSS neural super sampling approach to millions of gamers. I am thrilled that everyone can experience XeSS. We are excited to have several early game developers engage on XeSS. The SDK for the initial XMX version will be available for ISVs this month, and the DP4a version will be available later this year. At Intel, we believe in open-source standards. XeSS APIs will mature as we gain broad support for games and hardware, and we will open up the tools and SDKs for everyone. To learn more about XMX and our Xe-HPG GPU microarchitecture, let me bring in our GPU Chief Architect, David Blythe. Thanks, Lisa. Hi, everyone. It's time for our new GPU microarchitecture to be introduced to the world. This microarchitecture, which we call Xe-HPG for high-performance gaming, is the convergence of our Xe- LP, HP, and HPC microarchitectures. Xe-HPG is engineered to deliver great scalability and compute efficiency with advanced graphics features. Today, I'll give you a brief introduction to the new compute graphics and scalability capabilities of Xe-HPG. To deliver scalability beyond Xe-LP in Xe MAX and build enthusiast class hardware, we've had to rework the fundamental architecture of our GPU. Starting with the heart of the engine, we defined a new compute building block, which serves as a foundation for the Xe architecture. As part of this architecture change, we're also taking the opportunity to update some of the naming, so you won't hear us talking about execution units or EUs much anymore. The execution units are getting too large to reason about, and the generational changes make it difficult to do comparisons. Allow me to introduce the Xe Core. Xe Cores include efficient arithmetic units, caches, and load store logic. The arithmetic units include engines for traditional floating point and integer vector operations, along with engines to accelerate convolution and matrix operations commonly found in AI workloads. The architecture gives us a core ISA with the flexibility to adapt the Xe Cores for specific workloads and market segments. I don't have time to tell you everything about the Xe Cores we've built for our Xe-HPG microarchitecture today, but I can share some details. For Xe-HPG, Xe Cores include 16 vector engines and 16 matrix engines, which we refer to as XMX or Xe Matrix Extensions. You've already seen XMX in action with the XeSS demo presented by Lisa. With more and more workloads infused with AI, XMX is a key engine for delivering more efficient compute. The Xe-HPG microarchitecture is designed to be gaming first and to build much larger GPUs compared to the maximum of six Xe-cores in Xe-LP. We scaled the hardware required for real-time rendering in a larger building block we call our render slice. The render slice contains four Xe-cores and the rendering fixed function for real-time 3D graphics. The rendering fixed function includes geometry, rasterization, samplers, and pixel backends. Designed for DirectX 12 Ultimate with support for variable rate shading tier two, mesh shading, and sampler feedback. Each slice also includes four new ray tracing units architected to accelerate ray traversal, bounding box intersections, and triangle intersections. They provide full support for DXR or DirectX ray tracing, as well as Vulkan ray tracing. Thanks, David. With Xe-cores and their advanced feature set, we now have next-generation real-time graphics. We also wanted to scale this to enthusiast class performance. Can you walk us through how we achieved that? Of course, Raja. To scale our performance to enthusiast class GPUs, we work on two fronts. First, we replicate these slices, and then we connect them to a shared L2 cache through a high-bandwidth memory fabric. We have the flexibility to scale different configurations up to eight slices. To hit our performance goals, not only did we create an architecture for building larger GPUs and add additional features, but we also challenged ourselves to increase the power efficiency and the operating frequency of the design. Working across architecture and engineering, we performed detailed analysis for power reduction opportunities, which resulted in new methodologies and optimizations at every level of the design from the Xe-core on up. The changes were spread across microarchitecture, logic design, and physical design, and often needed complementary changes. It was truly a team effort, and I'm delighted to say that compared to the Xe-LP IP in our Iris Xe MAX product, we increased the relative operating frequency and the performance per watt each by roughly 1.5 times. I should also point out that the team effort included close cooperation with process technology, and that too contributed to the great results. I'll hand things back to Raja, and he can elaborate on that a little bit more. Thanks, David. Last year, I told you that Xe-HPG GPUs would be built with an external foundry partner. I'm happy to unveil that our partner is TSMC and Alchemist GPUs are built on the N6 process. This is the wafer of Alchemist. This is a great example of our IDM 2.0 partnerships. We have the flexibility to make the right process choice for each architecture. The progress I witness in our labs week by week with Alchemist GPUs and its software is very encouraging. Alchemist GPUs are now sampling to ISVs and partners. I can't wait to get the first generation of our products in your hands by Q1 of 2022. While our post-silicon and software teams are working very hard to get this to you, our design and architecture teams are busy creating the next few generations of our gaming GPUs. Here, I have the codenames, Battlemage with Xe2, Celestial with Xe3, and Druid after. Can't wait to share more at a future event, hopefully live. Welcome back. In the first half of today's event, we shared details about Intel's new x86 compute cores. We also saw Intel's Alder Lake, which reinvents multi-core architecture. In graphics, we showcased our new XeSS technology and upcoming Alchemist GPU. Let's shift gears to the data center, where we have even more exciting announcements. You'll hear about Mount Evans, our new infrastructure processing unit, and then Ponte Vecchio, our GPU for exascale. Let's start with Sapphire Rapids. The technology building blocks for this architecture have been years in the making. This includes a performance x86 core built for the data center, new accelerator cores, new memory architecture, new fabric architecture, new I/O architecture, and a host of new software and security features. This is a big deal for Intel and a big deal for the entire data center ecosystem. To tell you more, let's bring on Sailesh, our Chief Architect for Data Center. Hey, Sailesh. Hey, Raja. Take us away. Hi. Thanks, Raja. Hello, everybody. It's great to be here today. I'm excited to introduce Sapphire Rapids because I believe Sapphire Rapids will establish a new standard in data center architecture. Sapphire Rapids is our next-generation Xeon scalable processor. It delivers great out-of-the-box performance with enhanced capabilities for the breadth of workloads and deployment models in the data center. Sapphire Rapids delivers a step function in performance across a broad set of scalar and parallel workloads. More importantly, it is fundamentally architected for breakthrough performance in elastic computing models like containerized microservices, and for rapidly expanding use of AI in all forms of data-centric compute. Sapphire Rapids also advances the state of the art in memory and I/O technologies. Our overall architecture philosophy for Xeon is to deliver the best infrastructure in the data center. Xeon spans a wide range from monolithic server node deployments to data center scale elastic solutions. It delivers consistent performance across compute, storage, and network usages. Xeon architecture is optimized to deliver great node-level performance, as well as data center-level performance. Sapphire Rapids delivers big improvements at both levels. The new Performance Core in Sapphire Rapids brings significant scalar performance improvements. In addition, the multiple integrated accelerator engines and increased core counts provide a massive increase in data parallel performance. Furthermore, these Performance Cores are paired with the right levels of cache and industry-leading system capabilities of DDR5 and PCIe Gen 5 to provide optimal balance across compute, memory, and I/O. Finally, all of these are integrated through a modular SoC architecture that provides consistent and efficient performance scaling across the socket, the node, and the data center. At data center scale, it is critical to deliver great performance and utilization under multi-tenant usages, low jitter performance to meet the tight SLA or service level agreements, as well as elasticity across the entire infrastructure. In contrast, the industry standard benchmarks focus on node-level compute throughput and do not reflect the reality of data center scale usages. We have drawn deep insights from multiple generations of Xeon products deployed at cloud scale to inform Sapphire Rapids architecture. As a result, we deliver big advances in each of these areas with Sapphire Rapids. For example, it offers several virtualization and telemetry capabilities to improve multi-tenant usages. We expand the QoS capabilities and architecture enhancements to reduce jitter for performance consistency under high utilization. In addition, we are introducing several microarchitecture and architecture capabilities to improve performance across a broad set of workloads to deliver better data center elasticity. Data center deployment models exhibit significant overheads. Sapphire Rapids fundamentally changes the paradigm of handling these overheads through acceleration engines. These accelerators not only speed up the overhead processing multifold, but also significantly offload the cores, enabling them to deliver more application workload performance. As I said, this will be the new standard of data center architecture. Ladies and gentlemen, this is Sapphire Rapids. I would like to call on Chief Engineer Nevine Nassif to introduce the breakthrough SoC architecture that is Sapphire Rapids. Thank you, Sailesh. At the heart of Sapphire Rapids is a new modular tiled architecture that allows us to scale the balanced Xeon architecture beyond the limits of the physical reticle. Sapphire Rapids is the first Xeon product built using EMIB, our latest 55-micron bump pitch silicon bridge technology. This innovative new technology enables independent tiles to be integrated in a package to realize a single logical processor. The resulting performance, power, and density are comparable to an equivalent monolithic die. We're now able to increase core counts, cache, memory, and IO, free from the physical constraints that would otherwise have been imposed on the architecture and would have led to difficult compromises. This base SoC architecture is critical for providing balanced scaling and consistent performance across all workloads. This is key for data center scale elasticity and achieving optimal data center utilization. With this architecture, we're now able to provide software with a single balanced unified memory access, with every thread having full access to all resources on all tiles, including cache, memory, and IO. The result is consistent low latency and high cross-sectional bandwidth across the entire SoC. This is one of the critical ways we achieve low jitter in Sapphire Rapids. While Sapphire Rapids delivers out-of-the-box scalability for existing software and ecosystems, users can enable clustering at sub-NUMA and sub-UMA levels for additional performance and latency improvements. Sapphire Rapids sets a new standard for data center architecture with the seamless integration of cores and acceleration engines providing a heterogeneous compute infrastructure. It delivers the highest levels of compute performance through a combination of a high-performance core, increased core counts, increased AI performance, and the industry's broadest range of data center-relevant accelerators. Sapphire Rapids delivers leadership IO capabilities through CXL 1.1, PCIe Gen5, and UPI 2.0 technologies. All these are provisioned with Intel's highest bandwidth and low latency memory solutions through industry-leading DDR5, Optane, and HBM memory technologies. Now back to Sailesh. Thanks, Nevine. Let's start with the details of the three major pillars that Nevine outlined, starting with the data center performance core. As mentioned earlier, optimizing exclusively for standard benchmarks would have been the easy path, but that does not reflect the full picture of real data center usages. We use the insights from generations of Xeon large-scale deployments to inform our microarchitecture choices for the performance core. Just to provide a flavor of this, data center workloads exhibit large code footprints and are fundamentally bottlenecked by the front-end performance of the core. We fundamentally redesigned the front end to address these bottlenecks in the performance core. Consistent performance under multi-tenant usages is critical. The core delivers several improvements like fast VM migration, enhanced cache, and new TLB QoS capabilities for multi-tenant usages. We introduced autonomous and fine-grained power management to improve core performance without jitter. In addition, we added several new architecture capabilities in the core, including instructions and capabilities relevant for the data center. I want to provide a few examples of new ISA capabilities here. As Adi mentioned, we integrated AMX capabilities to accelerate tensor operations for AI workloads. We are also introducing Accelerator Interfacing Architecture instruction set, AIA, which supports efficient dispatch, synchronization, and signaling to the accelerators and devices from user mode, as opposed to high-overhead kernel mode. To address the growing demands for signal processing, we introduced half-precision floating point to AVX. Another example is the CLDEMOTE instruction. It helps with optimal movement of data across cache hierarchy to improve shared data usage models. Another major area of focus for Sapphire Rapids compute capability was to improve performance significantly for common functions and overheads with at-scale data center deployments. I would like to invite Arijit, the lead architect on Sapphire Rapids, to tell us more. Thank you, Sailesh. One of my key focus areas on Sapphire Rapids was to explore breakthrough improvements for the high levels of common mode tasks causing overhead that we see in data center scale deployment models. Instead of traditional approaches, we embarked on a new direction using optimized acceleration engines. We found these engines to vastly improve processing of these overhead tasks and enable greater utilization of the performance cores for higher user workload performance. We addressed the key challenge of seamlessly integrating acceleration engines with performance cores on Sapphire Rapids through a set of novel technologies such as AIA and advanced virtualization that enables us to avoid kernel mode overheads and complex memory management typically associated with such schemes. Sapphire Rapids supports several critical acceleration engines for processing the most common overheads. I'm excited to introduce a couple of them today. Data center usage models involve significant data movement overhead as part of workload processing. Examples include packet processing, data reductions, and fast checkpointing for virtual machine migration. Sapphire Rapids introduces the data streaming accelerator engine to offload the most common data movement tasks. DSA can move data between CPU caches and DDR memory, as well as I/O attached devices. In this graph, we show an open virtual switch use case in which with up to 4 instances of DSA, we see a nearly 40% reduction in CPU utilization and a 2.5x improvement in data movement performance. This results in nearly doubling the effective core performance for this workload. Intel QuickAssist Technology is not new to Intel products. Sapphire Rapids provides seamless integration of the next generation QAT engine, greatly increasing its performance and usability. All data in the data center is cryptographically protected during storage, transmission, and use. The ever-growing data footprint is increasingly maintained in a compressed format. Our next generation QAT acceleration engine supports the most popular crypto, hash, and compression algorithms and can chain these together. Performing these functions using QAT is significantly faster than the performance core and reduces the number of cores needed for those same functions. Sapphire Rapids QAT achieves up to 400 Gbps of crypto and simultaneous compression and decompression at up to 160 Gbps each. In this example, with the zlib L9 compression algorithm, we see a 50x drop in CPU utilization while also speeding up the compression by 22 times. Without QAT, this level of performance would require upwards of 1,000 performance cores to achieve. Thank you. Back to you, Sailesh. Thanks, Arijit. With growing compute capabilities, a balanced architecture needs to deliver commensurate improvements in I/O. Sapphire Rapids delivers breakthrough advancements with its I/O interfaces. We introduce the industry standard Compute Express Link technology, CXL, for memory expansion and accelerator usages in the data center. To cater to the growing I/O speeds and feeds, we introduce support for PCIe Gen 5, while also enhancing the QoS and DDIO capabilities that go with it. Sapphire Rapids delivers optimal multi-socket performance scaling through advancements to our UPI technology that brings more links at wider width and higher speeds compared to our prior generations. For the data center processor to deliver across all workloads, the compute and I/O capabilities need to be augmented with the right balance of cache and memory architecture to deliver sustained bandwidth at low latencies. Sapphire Rapids supports a large shared cache that allows dynamic sharing across the entire socket. We are almost doubling the shared capacity over prior generations and enhancing the critical QoS capabilities to further improve effectiveness. With industry-leading DDR5 memory technologies, we are delivering the next big step function in bandwidth while simultaneously improving power efficiency. In addition, Sapphire Rapids delivers multifold performance improvements and QoS capabilities with our next generation Intel Optane memory. We are not done with memory just yet. In addition to support for DDR5 and Optane memory technologies, Sapphire Rapids also offers a product version that integrates HBM technology in package for high performance in dense parallel computing that is prevalent with HPC, AI, machine learning, and in-memory data analytic workloads. Typically, CPUs are optimized for capacity, while accelerators and GPUs are optimized for bandwidth. However, with the exponentially growing model sizes, we see constant demand for both capacity and bandwidth without trade-offs. I'm happy to say that Sapphire Rapids does just that by supporting both natively. We further enhance this with support for memory tiering that includes software visible HBM plus DDR and software transparent caching between HBM and DDR. AI usages will become ubiquitous in the data center due to the success relative to traditional methods. In order to deliver data center scale elasticity, great AI performance is required across all tiers of compute. This was one of the major focus areas for Sapphire Rapids. We introduced AMX capabilities that provide massive speed up to the tensor processing that is at the heart of deep learning algorithms. We can perform 2K INT8 operations and 1K bfloat16 operations per cycle. This represents a tremendous increase in compute capabilities that are seamlessly accessible through industry standard frameworks and runtimes. We augment this with strong general purpose capabilities, large caches, high memory bandwidth, and capacity to deliver breakthrough performance improvements for CPU-based training and inference. Let's take a look at AMX in action in our validation labs. Thanks, Sailesh. AMX is a hardware block in the Sapphire Rapids CPU with a new expandable two-dimensional register file and a new matrix multiplier instructions to enhance performance for a variety of deep learning workloads for both inference and training. As you mentioned, we can do more matrix multiplies per clock cycle so we can process data faster. Here in our lab, we have a Sapphire Rapids server running an internally optimized general matrix multiplier GEMM kernel. On the left-hand side, we are running without AMX, and on the right-hand side, we are running with the AMX extensions. With AMX's ability to do more matrix multiplies per clock cycle, you can see that we are executing the GEMM kernel approximately 7.8x faster with advanced matrix extensions. While this demo highlights a highly efficient GEMM kernel to show the architectural capabilities of this platform, we expect substantial performance gain across the AI workloads for both training and inference. We expect the vast majority of new scalable services will be built using elastic compute models like containerized microservices. This trajectory was clear when we started architecting for Sapphire Rapids. To address this, we focused on capabilities and architecture choices to improve the computing model for throughput under tight SLA with low infrastructure overheads. We made architecture enhancements across the product, spanning the core, the accelerators, and the SoC capabilities to really deliver on this. For example, the AIA capabilities we talked about fundamentally reduce the microservices startup time. Advanced telemetry improvements help with optimal microservices load balancing and orchestration. A number of capabilities like QAT and DSA help with reducing the network stack overhead with microservices service mesh. We have been using multiple proxy workloads to develop these capabilities and optimize the open source software stack to benefit from these capabilities. This chart shows the speed up we are modeling in our architecture models and with some early silicon measurements on DeathStarBench and other example proxies that is normalized at the per core level. As you can see, we are seeing some great improvements in performance with the microservices computing model. In summary, Sapphire Rapids provides a big leap in performance and capabilities to establish a new standard in the data center architecture. At the root of Sapphire Rapids is a modular tiled SoC architecture, thanks to the EMIB technology that enables significant scalability by maintaining a monolithic view. It delivers substantial performance across scalar usages and massive performance in emerging parallel workloads like AI. It delivers great improvements for monolithic workload deployment models, while exclusively optimized for elastic compute models like microservices. It brings industry-leading memory and I/O technologies to feed the massive computing capabilities in a balanced way. As one would expect, Sapphire Rapids is a complex undertaking, and I would like to take the opportunity to thank the teams across all of Intel that are bringing Sapphire Rapids to market. Thank you. Back to you, Raja. Thanks, Sailesh. The entire data center ecosystem is eagerly awaiting Sapphire Rapids early next year. Just as important as compute itself is how we deliver that compute. We are in the middle of the infrastructure revolution that is transforming not only how we deliver compute from edge to cloud, but how we build data centers itself. Intel hinted at a new category called Infrastructure Processing Unit, IPU, at the recent Six Five Summit. To tell us more about IPUs and the problems they solve for our customers, here is Guido. Thanks, Raja. This is exactly right. We are in the middle of a revolution. When we started this revolution, the systems that made up cloud data centers looked pretty much like the systems in a classic enterprise data center. But that has changed. We're starting to see these two architectures diverge. The reason for this is that in a classic data center, everything is owned by one party. In the cloud, the workload and the system are owned by different ones, the tenant and the cloud service provider. Here's an example of a typical server in a classic enterprise data center. The physical infrastructure, the hypervisor, and the application are all owned by one entity. In this case, it's a bank. All the software runs on the CPU. For servers that are built for cloud infrastructure, where a different architecture has emerged. They have a dedicated processor that runs the infrastructure functions in the cloud. We call this new category of processor an IPU or infrastructure processing unit. The cloud service provider software runs on this IPU, and the revenue-generating guest software runs on the CPU. For example, a bank's financial app running on the CPU would now be cleanly separated from the cloud service provider's infrastructure software running on the IPU. If you want to think about an analogy, this is a little bit like hotels versus single-family homes. In my home, I want it to be easy to move around from the living room to the kitchen to the dinner table. In a hotel, it's very different. The guest rooms and the dining hall and the kitchen are cleanly separated. The areas where the hotel staff works is different from the area where the hotel guests are. You need to get a badge if you want to move from one to the other in some cases. Essentially, this is the same trend that we're seeing in cloud infrastructure today. This IPU-based architecture has several major advantages. First, the strong separation of infrastructure functions and tenant workloads allows tenants to take full control of the CPU. Second, the cloud operator can offload infrastructure tasks to the IPU. This helps maximize the utilization of the CPU and for public clouds also helps maximize revenue. Third, IPUs allow for fully diskless server architecture in the cloud data center. Let me explain each of these in more detail. In servers with an IPU, infrastructure and tenant workloads are cleanly separated, with the tenant workload running on the CPU and the infrastructure software running on the IPU. The immediate result of this is much better isolation between the two. For example, if I have a spike in infrastructure load, it will no longer lead to performance issues for the CPU. That's obviously a very good property. More importantly, it now allows the tenant to take full control of the CPU. For example, a tenant can bring their own hypervisor and run it on the CPU, but at the same time, the IPU can still confine that hypervisor to a virtual network segment or specific storage volumes. That allows for much, much more flexible architecture. The second advantage of the IPU is about infrastructure function offload. Modern applications today are often structured as microservices that incur substantial communication overhead. In some cases, the majority of all CPU cycles are actually spent on the infrastructure overhead, and the IPU can help reduce this, as you can see in this slide here. With an IPU, the cloud operator can offload these infrastructure tasks to the IPU. Thanks to the IPU's accelerators, they can process these very efficiently. This not only optimizes performance, but if you're a cloud operator, you can now take 100% of the CPU cycles off that CPU and rent them out for guests, which helps to maximize your revenue for the overall system. The third advantage of the IPU is that it can enable the migration to a fully diskless server architecture. This is a big architectural change. Let me explain why this is a great thing. Traditionally in a cloud data center, you will have disk attached to every single server. As tenant demand for disk space is hard to predict, you have to over-provision each of these servers, basically attach more disks than you really need, and you end up with a lot of stranded capacity, so capacity that can't be utilized in a good way. With an IPU, you can move to an entirely diskless model. As all storage is on a central storage service, and when a customer starts a workload on the server, the CSP basically creates a virtual volume on the storage service. Via the management network, the CSP tells the IPU to create a new NVMe SSD based on that virtual volume. As this virtual NVMe SSD shows up on the PCI Express bus just like a regular SSD, this will work with most operating systems and hypervisors out of the box, and we can now boot from that SSD. You may wonder, what does it do for performance? All this network traffic that is coming from these disks. The really brilliant thing about the IPU here is that the actual storage traffic between the storage server and the workload on the server happens on the fast path, meaning there's no involvement of any CPU cores on the IPU or the CPU. It's low latency, it's high throughput with maximum flexibility, a very powerful solution. With a strong separation of infrastructure and tenant, with accelerators that allow us to efficiently offload infrastructure functions, and this ability to move to a really diskless architecture, we think the IPU will be a central component for future data center architectures. If you look at IPUs today, there's basically two types of architectures that are commonly used. The first one are dedicated ASIC IPUs, and the second one are FPGA-based IPUs. Each type has their own advantages and disadvantages. FPGA-based IPUs give you the ability to implement new protocols quickly. You can react to changing requirements or new protocols, or you can, for example, implement your proprietary protocols that are not publicly known on these FPGAs. On the other hand, a dedicated ASIC IPU maximizes performance and efficiency. Both of these are actually different from classic SmartNICs, which lack the capability of executing the infrastructure control plane. Because there's no one-size-fit-all for the different types of infrastructure acceleration, Intel will continue to invest in both types of IPUs as well as SmartNICs. We're deeply engaged with the world's leading cloud providers, including Microsoft, Baidu, JD.com, and VMware. We are already the volume leader in the IPU market with our Xeon D FPGA and Ethernet components. I'm thrilled to announce the arrival of two exciting new FPGA-based products in our IPU portfolio targeted for the cloud and comms market. That's Oak Springs Canyon and Arrow Creek. Let's start with Oak Springs Canyon. Oak Springs Canyon is an FPGA-based IPU that uses Intel Agilex FPGA together with a Xeon D system on a chip. Agilex is the industry's leading FPGA in power, efficiency, and performance, working in concert with Xeon-based servers to provide the performance necessary to offload two times 100 GB workloads and a rich software ecosystem optimized around x86. Oak Springs Canyon leverages the Intel Open FPGA Stack, a scalable source accessible software and hardware infrastructure stack. Oak Springs Canyon is aligned with the needs for the next wave CSP deployments at 100 GB. Oak Springs Canyon also features a hardened crypto block that allows you to secure all infrastructure traffic, storage, and networking at line rate performance. Today, that's an important thing. The second product I want to talk about today is called Arrow Creek. Arrow Creek is an acceleration development platform based on the Agilex FPGA and the E810 100 GB Ethernet controller. It builds upon the success of Intel's PAC N3000, which is deployed today at some of the top comms service providers worldwide. Arrow Creek will help telco providers to offer flexible accelerated workloads like Juniper Contrail, OVS, and SRv6. With these two FPGA-based additions to our portfolio, Intel covers the needs of both cloud and communication service providers. What I'm actually most excited about today is that we're announcing Intel's first dedicated ASIC-based IPU, codenamed Mount Evans. Co-developed with a large CSP, Mount Evans is the foundation of a family of forthcoming ASIC IPUs. Naru, you're one of the key architects of the amazing team that built this technology. Tell us more about it. Thank you, Guido. As Guido just mentioned, Intel is helping to lead this industry transformation by building leadership IPUs based on our FPGA and ASIC assets. I'm here today to introduce you to a product I'm really excited about. That product, codenamed Mount Evans, is our first 200 GB ASIC IPU, or infrastructure processing unit. We have architected and developed Mount Evans hand-in-hand with a top cloud provider. This has provided tremendous insights into deployment requirements for networks at scale. Intel has been working closely with other cloud providers through our FPGA-based solutions, and our learnings with those products have influenced many of the Mount Evans architecture and design trade-offs. Mount Evans has been designed for performance at scale under real-world workloads. Finally, in order to be hyperscale ready, we designed in security and isolation from the ground up throughout the chip. On the technology front, Mount Evans is loaded with innovation. To start with, the focal point of the product is what we believe to be a best-in-class packet processing engine that supports a large number of existing use cases like vSwitch Offload, firewalls, and virtual routing, as well as providing significant headroom for future use cases. Another technology created by extending Intel's proven high-performance Optane NVMe controller enables Mount Evans to emulate NVMe devices. A third technology innovation I'm excited about is a next generation reliable transport protocol. We have co-innovated on this technology with our CSP partner to solve the long tail latency problem on lossy networks. Lastly, a fourth enabling technology that can be used across a variety of use cases is our advanced crypto and compression accelerators, leveraging our high performance Quick Assist Technology. Finally, at Intel, we really want to make IPUs a compelling technology across segments beyond cloud. This, first and foremost, means enabling software developers to do what they do best. We start with innovative performant hardware designed for flexibility and ease of programmability. We add to this the expertise that came in through our Barefoot acquisition, driving the use of the P4 language in the industry as a standard framework for programming network data planes onto IPUs. We'll extend well-known SDKs like DPDK and SPDK to take advantage of IPU capabilities for data and storage processing. Here, I'm showing a high-level block diagram of Mount Evans. As you can see, Mount Evans is organized as a networking subsystem on the left and a compute subsystem on the right. I won't go through every block in the short time we have today, but I did want to highlight a few areas. Mount Evans supports 200 Gbps of throughput, connecting up to four Xeon hosts together. We recognize that cloud performance needs will drive many applications like storage, messaging, and high performance computing to migrate to RDMA-based protocols. Mount Evans supports this with implementations of both RoCE v2 and the new reliable transport technology I mentioned earlier. Our Optane-derived NVMe engine exposes high-performance NVMe devices to the host processors, enabling infrastructure providers to use the IPU to implement their storage protocol of choice, whether it's hardware accelerated NVMe over Fabrics or a custom software backend on the compute system. The programmable packet processor delivers leadership support for use cases like vSwitch Offload, firewalls, telemetry functions, all while supporting up to 200 million packets per second performance on real-world implementations. Finally, Mount Evans provides inline IPsec to secure every packet being sent across the network. On the right-hand side, our compute complex is built on the Arm Neoverse architecture using the Neoverse N1 core. These 16 high-frequency cores come with a large system-level cache backed by three LPDDR4 controllers. The compute complex is tightly coupled with the network subsystem, allowing the network subsystem accelerators to use the system-level cache as a last-level cache, providing high bandwidth, low latency connections between the two, and enabling a flexible combination of hardware and software packet processing. Our lookaside crypto and compression engine is derived from Intel's QuickAssist Technology that you can see in the Xeon roadmap, but we've adapted it for IPU use models. This includes support for the Zstandard compression algorithm. Finally, our dual-core management processor provides an interface to the platform and orchestration layers, supporting robust system manageability. We designed Mount Evans from a software-first mindset. Enabling applications on IPUs requires a robust software foundation. I already shared a few details on using the P4 language for programming network data planes and extending well-known SDKs like DPDK and SPDK. We'll share more details in the next few months. Thank you. Back to you, Raja. Fantastic, Naru. There is a larger software ecosystem story to tell here. We look forward to share more at Intel On. The first step in making progress is to admit we have a problem. At Intel, we had a problem, almost a decade-long problem. We were behind on throughput compute density and support for high bandwidth memories, both of which are essential metrics for HPC and AI and the cornerstones of GPU architecture. The first chart is FP64 flops. The blue line is Intel versus the green line, which is the best in the industry. The second is a similar chart for memory bandwidth. As is obvious, the gaps were quite large. In 2017, when GPU architecture started adding special engines for matrix processing with AI data types, the problem got worse. Now, mind you that the real-world performance deltas between CPUs and GPUs are much lower than these charts indicate. The gaps were real. We really wanted to close this gap in one shot, so we needed a moonshot. We set for ourselves some very ambitious goals. We started a brand-new architecture built for scalability, designed to take advantage of the most advanced silicon technologies, and we leaned in fearlessly. Let me hand it over to Hong to walk you through this brand-new architecture, Xe-HPC. I'm here to talk about how we designed Xe-HPC architecture. How do we scale our architecture to realize the vision set up by Raja? We broke this problem down for four hierarchical building blocks: core, slice, stacks, and link. Let me walk you through each of them. First, I want to introduce the Xe-core, our foundational processing unit through which we scale our architecture. Xe-cores are highly efficient arithmetic machines. In each Xe-core, there are eight vector engines. Each vector engine provide floating point and integer operation on five 12-bit wide vectors. There are also eight matrix engines referred to as XMX or Xe Matrix Extensions. Each XMX engine is built with an eight deep systolic array. XMX performs eight set of five 12-bit wide vector compute operations per clock. Those vector and the matrix engines are supported by a wide load and store unit that can fetch 512 B per clock. Each Xe-core has a large 512 KB L1 data cache, currently the largest in the industry. We optimize Xe-core for large data sets, and this huge L1 cache helps tremendously. L1 cache is also software configurable as a scratchpad, also known as shared local memory. Compelling ops per clock for critical data formats is essential for high performance computing and AI. Here, I'm showcasing this data format and what a Xe-core can do. This is not all. We can also co-issue instructions to exceed those single op per clock rates. Our Intel libraries and kernels take full advantage of this for increased performance of the Xe-core. The next level building block is the slice. For Xe-HPC, a slice has 16 Xe-cores, totaling 8 MB of L1 cache, 16 ray tracing units, and providing one hardware context. The ray tracing units provide fixed function computation for ray traversal, bounding box intersection, and triangle intersection. This makes Xe-HPC very attractive to professional visualization applications. The hardware context feature enables Xe-HPC GPUs to execute multiple applications concurrently without expensive software-based context switches. This greatly improves the utilization of GPUs in the cloud. At the top level, we have the stack. This can be a full GPU in itself. A stack contains four slices. This adds up to 64 Xe-cores, 64 ray tracing units, and four hardware contexts. The stack has a massive L2 cache, four HBM3 controllers, a state-of-the-art media engine, and eight Xe- Links. The Xe memory fabric connects copy engines, the media engine, Xe- Link blocks, HBM, and PCIe. Xe-HPC architecture is also scalable, allowing us to do multi-stack design. This is an industry first. We could only accomplish this because of our EMIB packaging technology. Here, we connect HBM memory fabric on each stack directly. This enables unified coherent memory between the stacks. This is a big deal for software. We can now deliver leadership, compute, and memory bandwidth density for a wide range of HPC and AI systems with a single design. The fourth dimension to our scaling strategy is our Xe- Link. Xe- Link provides high-speed, coherent, unified fabric for GPU to GPU communication. It supports load and store, bulk data transfer, and synchronization semantics. It includes an eight-port switch, enabling up to eight fully connected GPUs in a node without any additional components. This leads to the ability to build very flexible topologies. It is easier to show than tell. Here, we have Xe- Link between two Xe-HPC GPUs. We could connect them with up to eight Xe- Links. Scaling to four GPU for large problem is a popular configuration. Six GPU per node may look familiar to you, as this is the topology of Aurora accelerated network. A popular configuration for AI and large problem is to have eight GPUs in an OAM form factor for Universal Baseboard design following the Open Compute Project Standard. The flexibility of Xe Link enables a high number of coherent and unified accelerators in a single node. There's no need for additional components to scale up. This is a massively scalable architecture, the magnitude of which has never been built before, as far as we know. My colleague, Masooma, will take you through how we turn this architecture into an implementation. Hong talked about the amazing Xe- HPC architecture. My team and I, along with the help of our partners, IP, test, packaging, process technology, and manufacturing teams, had the challenge and privilege to bring this architecture to life as the Ponte Vecchio chip. It is an understatement to say that Ponte Vecchio is the most complex chip and product that I have worked on in my 30 years of chip building. Actually, I'm not even sure if it is accurate to call it a chip. It is a collection of chips that we call tiles that are woven together with high bandwidth interconnects that are made to function like one monolithic silicon. Planning Ponte Vecchio execution was a completely different paradigm. I have worked on new SoC architecture, new IP architecture, new memory architecture, new I/O architecture, new packaging technology, new power delivery technology, new interconnects, new signal integrity techniques, new reliability methodology, completely new software, and new verifications methodology. Never have I dealt with all of this newness in one product, and that was the challenge that was Ponte Vecchio. It is amazing and somewhat unbelievable that the chip is alive and fully kicking with workloads. The Ponte Vecchio chip, as you see in this picture, is composed of several complex designs that manifest in tiles. Compute tile, Rambo tile, Xe- Link tile, and a base tile with high-speed HBM memory, which are then assembled through EMIB tile that enables a low-power, high-speed connection between the tiles. These are put together in a Foveros packaging that creates that 3D stacking of active silicon for power and interconnect density. The high-speed MDFI interconnect allows the stack to scale from 1 to 2. All of this comes together in a manufacturing marvel across several different process technology nodes. Ponte Vecchio was new and novel in many ways, with a myriad challenges. While the multi-tile approach helped break down the problem into smaller chunks and provided flexibility, execution planning was orders of magnitude more complex. I want to walk you through a few big challenges from the many that we had on Ponte Vecchio. Foveros was critical for Ponte Vecchio 3D stacking, and we have some key learnings with its implementation, both functional and physical. We had to transfer data at 1.5x speed over our original plan to minimize the number of Foveros connections. We also had to lock the Foveros locations early in the design on all the tiles, which meant that the floor plan was locked very early. Since we pioneered this 3D implementation, we had to innovate continuously on die to die implementation and verification methodology. We developed many tools, methods, and scripts in real time and performed validation at multiple levels of hierarchy with new BFMs and test benches to keep the tiles independent and keep hierarchies clean and crisp. This facilitated an independent schedule for each of the four main tiles and enabled their own debug packages. With this divide and conquer approach, we were able to stage both pre- and post-silicon validation, such that the chip booted within few days of the SoC package assembly with the flashing of Hello World. This was a huge sigh of relief and a cheer for thousands of engineers across Intel. The staged approach, while essential, meant that the RTL versions of the various tiles had to be in sync for the integrity of the top-level model. High-power, multi-tile package posed its own challenges related to signal integrity, reliability, and power delivery, as there was no precedent, internal or external, to Intel. Foveros implementation was complex and time-consuming. Just for context, Ponte Vecchio has two orders of magnitude more Foveros connections than any previous Intel designs. All the electrical and physical collaterals had to be generated from scratch and verified prior to delivery to our partner teams. Now let me tell you more about some of the most sophisticated and complex of these Ponte Vecchio tiles. While Ponte Vecchio was a challenge in aggregate, these individual tiles had a level of design complexity of their own. Compute tile is a dense package of Xe cores and is the heart of Ponte Vecchio. One tile has eight Xe-cores with a total of 4 MB L1 cache, are key to delivering power-efficient compute. It is built on the most advanced TSMC process technology called N5. We paved the way with the design infrastructure setup, tool flows, and methodology for this node at Intel. This tile has an extremely tight 36 micron bump pitch for 3D stacking with Foveros. This is just one example of our IDM 2.0 strategy of combining internal and external process nodes that Pat has outlined. Base tile is the connective tissue of Ponte Vecchio. It is a large die built on Intel 7 optimized for Foveros technology. It is where all the complex I/O and high bandwidth components come together with the SoC infrastructure, PCIe Gen 5, HBM2E memory, MDFI links to connect tile to tile, and EMIB bridges that challenged physics. Super high bandwidth, 3D connect with high 2D interconnect and low latency makes this an infinite connectivity machine. Implementation of this tile was the hardest design challenge on Ponte Vecchio. We worked closely with the Intel technology development team to match the requirements on bandwidth, bump pitch, and signal integrity. Xe- Link tile provides the connectivity between GPUs supporting eight links per tile. It is critical for scale-up for HPC and AI. We are targeting the fastest SerDes supported at Intel, up to 90 GB. When we won the Aurora Exascale supercomputer contract, this was a new tile added to enable the scale-up solution as per their requirement. We built this incredible tile in less than one year. It is highly gratifying to see Ponte Vecchio powered on and successfully running hundreds of workloads and hitting some industry-leading performance numbers on A0 silicon. Here in my hand is this marvel, Ponte Vecchio. Let me now hand this to Raja. Thank you, Masooma. You and your team have done a fantastic job. Thank you, Raja. Highly appreciate it. This is an incredibly proud moment to be holding this marvel of engineering in my hand. What began as a moonshot that many said could not be done, nothing inspires Intel engineers like hearing those four words, it can't be done. Thousands of engineers said we can, let me show you what they have already done. That GPU Masooma handed me is a zero silicon, as she noted, which is our first stepping. It already produces greater than 45 teraflops of sustained vector single precision performance, validating that our compute tiles are healthy. We also measured greater than 5 TB per second of sustained memory fabric bandwidth, which validates our Foveros 3D packaging technology, over 2 TB per second of aggregate memory and scale-up bandwidth, this proves all our EMIB bridges are very healthy. There is still more performance to be had. These are all leadership compute and bandwidth numbers that already erase the huge flop and bandwidth gap problem I mentioned earlier today. Ponte Vecchio will be available in PCIe cards with Xe- Link interconnect bridge. The OEM module form factor that I just showed you will be integrated into a carrier baseboard that brings together multiple GPUs with Xe- Links. Our OEM partners will provide various accelerated compute systems utilizing this Ponte Vecchio subsystems and Sapphire Rapids. For years, taking advantage of GPU-accelerated computing systems like this has been a major headache for software developers. They had to rewrite the parts they wanted to accelerate in different specialized languages, OpenCL, CUDA, et cetera. Otherwise, the GPU did them no good. We already led the industry in CPU-based performance for both AI and conventional workloads, and we wanted a seamless way to take advantage of GPU-based acceleration. We needed another moonshot, a software moonshot. We needed a programming framework that let software developers transparently program for any mix of CPUs and accelerators. Many said this could not be done. We created oneAPI. The oneAPI industry initiative provides an open, standards-based, unified software stack that is cross-architecture and cross-vendor. The first version of the industry spec was released in September of last year, which specified a common hardware abstraction layer, data parallel programming language, and comprehensive collection of performance libraries addressing math, deep learning, data analytics, and video processing domains. OneAPI allows developers to break free from proprietary languages and programming models. It exposes and exploits cutting-edge features of the latest hardware. A comprehensive set of libraries speed development of frameworks, applications, and services. The language and libraries work seamlessly with other ecosystem languages like Python, C++, and Fortran. Releasing an open specification is one thing. The question I'm sure that's on your mind is whether the industry sees the value and will invest their own effort to adopt. The answer is a resounding yes. There are now DPC++ and oneAPI library implementations for NVIDIA GPUs, AMD GPUs, and Arm CPUs. It's also being adopted broadly by ISVs, operating system vendors, end users, and academics. We know that oneAPI version 1.0 is just the beginning of the journey. Key industry leaders are helping to evolve the specification to support additional use cases and architectures. The provisional version 1.1 spec was released in May, which adds new graph interfaces for deep learning workloads and advanced ray tracing libraries. We expect version 1.1 spec to be finalized by the end of the year. Here is a sampling of key ecosystem players who support and are actively engaged in oneAPI. OneAPI has developed broad momentum across the industry. For example, U.S. national labs that are developing exascale computers have adopted oneAPI components. This will allow them to use CPU and GPU architectures from different vendors. Beyond the industry spec, Intel released the first commercial implementation of the full oneAPI stack. Our oneAPI product offering includes the foundational base toolkit, which adds compilers, analyzers, debuggers, and porting tools beyond the spec language and libraries. Over 200,000 developers have installed Intel's oneAPI product since our first production release in December 2020, and that was before they had access to Xe-HPC. We anticipate an exponential growth in developer base when we enable access to this architecture. There are over 300 applications already deployed in market from ISVs across multiple segments that utilize the unified programming model of oneAPI. We have over 80 key HPC applications, AI frameworks, and middleware functional on Xe-HPC that utilize oneAPI to quickly port from either existing CPU-only or CUDA-based GPU implementations. Let's look at oneAPI in action with AI Analytics Toolkit. It's been exciting over the last four to five years to see the growth in HPC and AI, and there's no better way to see the excitement than to look at the progression and performance to the image recognition benchmark, ResNet-50. The gold standard has been set with one architecture over the last several years with record-setting performance. Well, we're pleased to announce a new era with Ponte Vecchio. Built on the Xe-HPC microarchitecture with an alchemy of technologies and more than 100 billion transistors, the Ponte Vecchio GPU was designed to take on the most challenging AI and HPC workloads. ResNet-50 inference throughput on Ponte Vecchio with Sapphire Rapids exceeds 43,000 images per second, surpassing the standard you see today in market. With training, while we're still in early stages, initial testing shows the compute, memory, and interconnect bandwidth of Xe-HPC have unlocked the capacity to train the largest data sets and models. Today, we are already seeing leadership performance on Ponte Vecchio with over 3,400 images per second. This is only the beginning as we continue with software optimizations and tuning. We're excited about the dawn of a new era where a new architecture can raise the bar to meet the ever-growing compute demands of the data center. Xe architecture and oneAPI are more than AI training and inference and HPC flops. Let's take a look at some eye candy with oneAPI Rendering Toolkit. Now I'm excited to show you early results of our oneAPI implementation of the advanced ray tracing in the provisional 1.1 oneAPI specification running on oneAPI-based CPU and Xe GPU platforms. The Intel oneAPI Rendering Toolkit has six high-performance, feature-rich, open source software components, including the Academy Award-winning Intel Embree ray tracing library. These are already running on Intel and third-party CPUs like Apple's M1. Now you'll be the first to see oneAPI Rendering Toolkit running cross-architecture on CPUs and GPUs. Let's show a typical artist workflow creating, reviewing, then delivering a movie-quality scene backed by tools using Intel oneAPI Rendering Toolkit. Everything you'll see is an untouched live computer screen capture using film-quality assets at native HD 1080p resolution. First, let's show an artist creating a scene backed by Intel Embree using the tool Houdini from SideFX. The artist creates in HD with interactive path trace rendering on a Xeon workstation without a discrete GPU. For this phase of the design, the CPU provides the interactivity the artist needs. When they pause to review, the path trace rendering converges towards photoreal quality. It's time for the artist to review the scene with the director. This is where the oneAPI game changer comes in. You're looking at a real-time walkthrough of an Intel history-inspired path trace scene at the fictitious 4004 Moore Lane. Using the oneAPI software architecture, we show Embree and AI-based Intel Open Image Denoise, which took less than three days to port onto a pre-production ray tracing capable Xe GPU. Now the same feature-rich render kit capabilities artists and app developers crave on CPUs, including ray tracing and AI, are now accelerated on GPUs. The artist and director can review the scene instantly and interactively with full-featured native HD denoised path trace rendering. Okay, once the scene is ready for final movie-ready 4K rendering, studios can choose an Intel Xeon CPU-based render farm or seamlessly add oneAPI-capable Xe GPUs to improve their workflow. Here is one 4K full fidelity frame rendered with a ray tracing capable Xe GPU. The full 4K movie is available for viewing in the demo showcase. In quick summary, two years ago, we announced oneAPI with the goal of open, cross-platform, cross-architecture development, and execution. Today, we've shown that oneAPI has gone from an ambitious goal to a delivered reality for developers and creators. That was a fantastic demo of oneAPI and the rendering capabilities of Xe. All of this was set in motion with Argonne National Laboratory and the Aurora project, which combines Sapphire Rapids, Ponte Vecchio, Optane Memory, and oneAPI to power the next generation of Exascale applications. Here is an individual Aurora blade with two Sapphire Rapids and six Ponte Vecchios addressing the need of converged HPC and AI workloads. Tens of thousands of these blades connected via high-speed fabric will be deployed next year to unleash Exascale. Less than two years ago, I shared our goals for Ponte Vecchio. It's an incredible moment for us, seeing this extraordinary silicon engineering effort and ambitious software initiative coming to life in our labs. This is no longer a moonshot for us. We still have a ways to go, and we are not done yet, but we can't wait to take you along on this journey when we bring this architecture to all our customers early next year. Thank you for joining me and my colleagues and for being part of our architecture journey. Please welcome a famous Intel architect and now Intel CEO, Pat Gelsinger. I appreciate the opportunity to join you as we bring Architecture Day to a close. I'm extremely proud of what our technology leaders just showed you. This was the result of years of hard work by the most talented team of architects and engineers in the world. You have just seen one of Intel's most significant advances in x86 architectures in over a decade. It's that big. For generations, the primary driver of compute was process, lithography, geometry, getting to the next node, all the exciting foundational innovations that will power products through 2025 and beyond. We laid out one of the most detailed process and packaging roadmaps we've ever produced at our recent Intel Accelerated event. Looking ahead, we face daunting compute challenges that can only be solved through revolutionary architectures and platforms. The good news, we already have developed many of these microarchitectures for performance and efficiency, heterogeneous computing at every level and in every dimension. From sub-chip to board to system to data center, and from edge and endpoint devices to network to cloud, everything is designed to intelligently use the best compute resource, the optimal architecture for each task. Much of this goodness you have seen at this event. For the billions of PC users in the world, Alder Lake is an entirely new performance hybrid client CPU architecture, reinventing our multi-core architecture with two different x86 cores and a revolutionary hardware scheduler. The new performance x86 core is the highest performing CPU core we have ever built. Faster, wider, smarter, deeper, and with built-in AI acceleration. Designed for the highest performance general purpose compute, it pushes the limits of low latency and single-threaded applications. Our new efficient x86 core is built for scale and designed to push the limits of multi-core performance per watt. We engaged early with developers and APIs and engine leaders on our new discrete GPU for enthusiast gaming. The new scalable Xe-HPG architecture takes a software-first design approach to deliver high performance and reduced friction for gamers and creators. Sapphire Rapids sets a new standard for data center architecture. It is the architectural underpinning of a heterogeneous compute infrastructure with our highest compute density and highest memory bandwidth. Our innovative EMIB packaging technology helps make all this possible. Sapphire Rapids brings new higher performance CPUs, increased core counts, new memory capabilities, new interface standards, increased AI performance, and the industry's broadest range of accelerators. Ponte Vecchio is a tour de force of Intel technologies, providing our highest compute density and bandwidth for Exascale computing. We co-architected Mount Evans, our newest IPU, or Infrastructure Processing Unit, with one of the top cloud providers to offload infrastructure tasks. Our talented architectures and engineers made possible all this technology magic. It's an exciting time for Intel. Our strategy and execution are accelerating. We are charting the course for a new era of innovation and technological leadership. Our breadth and depth of software, silicon, and platforms, our packaging and process technologies, and Intel's at-scale manufacturing uniquely positions Intel to capitalize on the vast growth opportunity. In addition, our IDM 2.0 approach is the powerful combination of three capabilities: Intel's internal factory network, strategic use of foundry capacity, and Intel Foundry Services. It's powered by Intel's leading-edge packaging and process technology and our world-class IP portfolio. Intel is back, and this story is just beginning. We have even more technical magic saved for our Innovation Event in October. Let me hand it over to Greg Lavender, our CTO, to give you just a little bit more detail on this incredible technical event. I can't wait to see you all again. Thank you, Pat. I'm so excited to host the Intel Innovation Event, my first event as the new CTO of Intel. Intel Innovation will be the inaugural flagship event and a tour de force of technology. From the smallest devices at the edge to cutting-edge mobile, laptop, PC clients through the network of today and tomorrow into the heart of the data center. We have two full days of technical keynotes, breakout sessions, hands-on demos, and networking events planned on today's hottest topics, from AI to 5G, the edge, the data center, cloud, and client solutions. The agenda is packed and awesome. I hope you will attend. Our teams at Intel can't wait to see you in person or virtually online, October 27th through the 28th. I can't wait for you to join us at Intel Innovation in October. Come join us. October can't get here fast enough. I really hope you'll come join us in October. See you there. Thank you for joining us at Architecture Day.