De-blocking integer pipelines during mathematical pipeline phases in graphical environment

Abstract

The name of the invention is "de-blocking integer pipelines during mathematical pipeline phases in a graphical environment". An apparatus for facilitating de-blocking of integer pipelines during a mathematical pipeline phase in a graphical environment is disclosed. The apparatus includes execution resources comprising: a thread arbiter; a plurality of execution pipeline hardware circuitry modules including mathematical execution pipelines and integer execution pipelines for sharing resources of the thread arbiter; the arbitration hardware circuit module is used for determining whether the mathematical execution pipeline can be used for loading mathematical operation object data of the mathematical instruction; the mathematical instruction temporary storage buffer is used for storing mathematical operation object data in response to the fact that the mathematical execution pipeline is not available; wherein the integer execution pipeline is used for receiving integer operation object data of an integer instruction and bypassing mathematical operation object data in the mathematical instruction temporary storage buffer at the same time; and wherein the mathematical execution pipeline is to receive the mathematical operation object data from the mathematical instruction register buffer in response to the mathematical execution pipeline becoming available.

Description

Technical Field

[0001] The present disclosure relates generally to data processing, and more particularly to data processing via a general purpose graphics processing unit, including deblocking an integer pipeline during a math pipeline stage in a graphics environment. Background Art

[0002] Current parallel graphics data processing includes systems and methods developed to perform specific operations on graphics data, such as, for example, linear interpolation, tessellation, rasterization, texture mapping, depth testing, etc. Traditionally, graphics processors have used fixed-function compute units to process graphics data. More recently, however, portions of graphics processors have been made programmable, enabling such processors to support a wider variety of operations for processing vertex and fragment data.

[0003] To further improve performance, graphics processors typically implement processing techniques such as pipelining, which attempt to process as much graphics data as possible in parallel throughout different parts of the graphics pipeline. Parallel graphics processors with a single instruction multiple thread (SIMT) architecture are designed to maximize the amount of parallel processing in the graphics pipeline. In the SIMT architecture, groups of parallel threads attempt to execute program instructions together synchronously as frequently as possible to improve processing efficiency. A general overview of software and hardware for the SIMT architecture can be found in Shane Cook's "CUDA Programming", Chapter 3, pages 37-51 (2013). BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The embodiments described herein are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like reference numerals indicate similar elements and in which:

[0005] Figure 1 is a block diagram of a processing system according to an embodiment.

[0006] Figure 2A is a block diagram of an embodiment of a processor having one or more processor cores, an integrated memory controller, and an integrated graphics processor.

[0007] Figure 2B is a block diagram of the hardware logic of a graphics processor core block according to some embodiments described herein.

[0008] Figure 2CA graphics processing unit (GPU) is illustrated that includes a collection of specialized graphics processing resources arranged into a multi-core group.

[0009] Figure 2D is a block diagram of a general-purpose graphics processing unit (GPGPU) that may be configured as a graphics processor and / or a computing accelerator according to embodiments described herein.

[0010] Figure 3A is a block diagram of a graphics processor, which may be a discrete graphics processing unit, or may be a graphics processor integrated with multiple processing cores or other semiconductor devices such as, but not limited to, a memory device or a network interface.

[0011] Figure 3B A graphics processor having a tiled architecture is illustrated according to embodiments described herein.

[0012] Figure 3C A computing accelerator according to embodiments described herein is illustrated.

[0013] Figure 4 is a block diagram of a graphics processing engine of a graphics processor according to some embodiments.

[0014] Figure 5A A graphics core cluster is illustrated according to an embodiment.

[0015] Figure 5B Illustrated is a vector engine of a graphics core according to an embodiment.

[0016] Figure 5C A matrix engine of a graphics core according to an embodiment is illustrated.

[0017] Figure 6 A slice of a multi-chip processor according to an embodiment is illustrated.

[0018] Figure 7 is a block diagram illustrating a graphics processor instruction format according to some embodiments.

[0019] Figure 8 is a block diagram of another embodiment of a graphics processor.

[0020] Fig.9A is a block diagram illustrating a graphics processor command format that may be used to program a graphics processing pipeline in accordance with some embodiments.

[0021] Fig. 9B is a block diagram illustrating a graphics processor command sequence according to an embodiment.

[0022] Fig.10 An example graphics software architecture for a data processing system is illustrated in accordance with some embodiments.

[0023] Fig.11A is a block diagram illustrating an IP core development system that may be used to fabricate an integrated circuit to perform operations according to an embodiment.

[0024] Fig. 11B Illustrated is a cross-sectional side view of an integrated circuit package assembly 1170 according to some embodiments described herein.

[0025] Fig. 11C A package assembly including multiple hardware logic chiplet units connected to a substrate is illustrated.

[0026] Fig.11D A package assembly including interchangeable chiplets according to an embodiment is illustrated.

[0027] Fig.12 is a block diagram illustrating an example system-on-chip integrated circuit that may be fabricated using one or more IP cores in accordance with an embodiment.

[0028] Fig.13A An example graphics processor of a system-on-chip integrated circuit that may be fabricated using one or more IP cores in accordance with an embodiment is illustrated.

[0029] Fig. 13B An additional example graphics processor 1340 is illustrated of a system-on-chip integrated circuit that may be fabricated using one or more IP cores in accordance with an embodiment.

[0030] Fig.14 is a block diagram illustrating an example integrated circuit graphics processor having execution resources for providing integer pipeline de-blocking during a math pipeline stage in a graphics environment in accordance with an embodiment.

[0031] Fig.15 is a block diagram illustrating a detailed view of example execution resources for providing support for integer pipeline deblocking during a math pipeline stage according to implementations herein.

[0032] Figure 16A-16B A schematic diagram comparing a hardware baseline without a math instruction staging buffer and an updated hardware implementation with a math instruction staging buffer according to implementations herein is illustrated.

[0033] Fig.17 is a flow chart illustrating an embodiment of a method for utilizing a scratch buffer for integer pipeline deblocking during a math pipeline stage in a graphics environment.

[0034] Fig.18 is a flow chart illustrating an embodiment of a method for utilizing staged loading of operand data for deblocking an integer pipeline during a math pipeline stage in a graphics environment. DETAILED DESCRIPTION

[0035] A graphics processing unit (GPU) is communicatively coupled to a host / processor core to accelerate, for example, graphics operations, machine learning operations, pattern analysis operations, and / or various general purpose GPU (GPGPU) functions. The GPU may be communicatively coupled to a host processor / core via a bus or another interconnect (e.g., a high-speed interconnect such as PCIe or NVLink). Alternatively, the GPU may be integrated on the same package or chip as the core and communicatively coupled to the core via an internal processor bus / interconnect (i.e., inside the package or chip). Regardless of the manner in which the GPU is connected, the processor core may assign work to the GPU in the form of a sequence of commands / instructions contained in a work descriptor. The GPU then uses dedicated circuit modules / logic to efficiently process these commands / instructions.

[0036] In the following description, numerous specific details are set forth to provide a more comprehensive understanding. However, it will be apparent to those skilled in the art that the embodiments described herein may be practiced without one or more of these specific details. In other instances, well-known features are not described to avoid obscuring the details of the current embodiments. System Overview

[0037] Figure 1 1 is a block diagram of a processing system 100 according to an embodiment. The processing system 100 may be used in a single-processor desktop computer system, a multi-processor workstation system, or a server system having a large number of processors 102 or processor cores 107. In one embodiment, the processing system 100 is a processing platform incorporated into a system-on-a-chip (SoC) integrated circuit for use in a mobile, handheld, or embedded device, such as in an Internet-of-things (IoT) device with wired or wireless connectivity to a local or wide area network.

[0038] In one embodiment, the processing system 100 may include, be coupled with, or be integrated into: a server-based gaming platform; a gaming console, including gaming and media consoles; a mobile gaming console, a handheld gaming console, or an online gaming console. In some embodiments, the processing system 100 is part of: a mobile phone, a smart phone, a tablet computing device, or a mobile internet-connected device, such as a laptop with low internal storage capacity. The processing system 100 may also include, be coupled with, or be integrated into: a wearable device, such as a smart watch wearable device; smart glasses or clothing that is enhanced with augmented reality (AR) or virtual reality (VR) features to provide visual, audio, or tactile output to supplement the real-world visual, audio, or tactile experience or otherwise provide text, audio, graphics, video, holographic images or video, or tactile feedback; other augmented reality (AR) devices; or other virtual reality (VR) devices. In some embodiments, the processing system 100 includes or is part of a television or set-top box device. In one embodiment, processing system 100 may include, be coupled to, or be integrated into an autonomous vehicle such as a bus, a tractor trailer, an automobile, a motorcycle or electric bicycle, an airplane, or a glider (or any combination thereof). An autonomous vehicle may use processing system 100 to process the environment sensed around the vehicle.

[0039] In some embodiments, one or more processors 102 each include one or more processor cores 107 to process instructions that, when executed, perform operations for system or user software. In some embodiments, at least one of the one or more processor cores 107 is configured to process a specific instruction set 109. In some embodiments, the instruction set 109 may facilitate complex instruction set computing (CISC), reduced instruction set computing (RISC), or computing via very long instruction words (VLIW). One or more processor cores 107 may process different instruction sets 109, which may include instructions to facilitate emulation of other instruction sets. The processor core 107 may also include other processing devices, such as a digital signal processor (DSP).

[0040] In some embodiments, the processor 102 includes a cache memory 104. Depending on the architecture, the processor 102 may have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared between various components of the processor 102. In some embodiments, the processor 102 also uses an external cache (e.g., a level 3 (L3) cache or a last level cache (Last Level Cache, LLC)) (not shown), which can be shared between the processor cores 107 using known cache coherence techniques. A register file 106 may additionally be included in the processor 102 and may include different types of registers (e.g., integer registers, floating point registers, status registers, and instruction pointer registers) for storing different types of data. Some registers may be general purpose registers, while other registers may be specific to the design of the processor 102.

[0041] In some embodiments, one or more processors 102 are coupled to one or more interface buses 110 to transmit communication signals, such as address, data, or control signals, between the processor 102 and other components in the processing system 100. The interface bus 110 may be a processor bus in one embodiment, such as a version of a Direct Media Interface (DMI) bus. However, the processor bus is not limited to a DMI bus, and may include one or more peripheral component interconnect buses (e.g., PCI, PCI Express), memory buses, or other types of interface buses. In one embodiment, the processor(s) 102 include a memory controller 116 and a platform controller hub 130. The memory controller 116 facilitates communication between memory devices and other components of the processing system 100, while the platform controller hub (PCH) 130 provides connections to I / O devices via a local I / O bus.

[0042] The memory device 120 may be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, a flash memory device, a phase change memory device, or some other memory device having suitable performance to act as a process memory. In one embodiment, the memory device 120 may operate as a system memory for the processing system 100 to store data 122 and instructions 121 for use when one or more processors 102 execute applications or processes. The memory controller 116 is also coupled to an optional external graphics processor 118, which may communicate with one or more graphics processors 108 in the processor 102 to perform graphics and media operations. In some embodiments, graphics, media, and / or computing operations may be assisted by an accelerator 112, which is a coprocessor that may be configured to perform a specialized set of graphics, media, or computing operations. For example, in one embodiment, the accelerator 112 is a matrix multiplication accelerator used to optimize machine learning or computing operations. In one embodiment, accelerator 112 is a ray tracing accelerator that can be used to perform ray tracing operations in coordination with graphics processor 108. In one embodiment, external accelerator 119 can be used instead of accelerator 112 or in coordination with accelerator 112.

[0043] In some embodiments, the display device 111 may be connected to the processor(s) 102. The display device 111 may be one or more of an internal display device such as in a mobile electronic device or a laptop device or an external display device attached via a display interface (e.g., a display port, etc.). In one embodiment, the display device 111 may be a head mounted display (HMD), such as a stereoscopic display device for use in virtual reality (VR) applications or augmented reality (AR) applications.

[0044] In some embodiments, the platform controller hub 130 enables peripherals to be connected to the memory device 120 and the processor 102 via a high-speed I / O bus. The I / O peripherals include, but are not limited to, an audio controller 146, a network controller 134, a firmware interface 128, a wireless transceiver 126, a touch sensor 125, a data storage device 124 (e.g., non-volatile memory, volatile memory, hard drive, flash memory, NAND, 3D NAND, 3D XPoint, etc.). The data storage device 124 can be connected via a storage interface (e.g., SATA) or via a peripheral bus such as a peripheral component interconnect bus (e.g., PCI, PCI Express). The touch sensor 125 can include a touch screen sensor, a pressure sensor, or a fingerprint sensor. The wireless transceiver 126 can be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver such as a 3G, 4G, 5G, or long-term evolution (LTE) transceiver. The firmware interface 128 enables communication with the system firmware and can be, for example, a unified extensible firmware interface (UEFI). The network controller 134 may be capable of enabling network connectivity to a wired network. In some embodiments, a high performance network controller (not shown) is coupled to the interface bus 110. The audio controller 146, in one embodiment, is a multi-channel high definition audio controller. In one embodiment, the processing system 100 includes an optional legacy I / O controller 140 for coupling legacy (e.g., Personal System 2 (PS / 2)) devices to the system. The platform controller hub 130 may also be connected to one or more Universal Serial Bus (USB) controllers 142 to connect input devices, such as a keyboard and mouse 143 combination, a camera 144, or other USB input devices.

[0045] It will be appreciated that the processing system 100 shown is an example and is not limiting, as other types of data processing systems configured in different ways may also be used. For example, instances of the memory controller 116 and the platform controller hub 130 may be integrated into a discrete external graphics processor, such as the external graphics processor 118. In one embodiment, the platform controller hub 130 and / or the memory controller 116 may be external to the one or more processors 102 and reside in a system chipset that communicates with the processor(s) 102.

[0046] For example, a circuit board ("sled") may be used on which components (such as CPUs, memory, and other components) are placed that are designed for increased thermal performance. In some embodiments, processing components such as processors are located on the top side of the sled, while near memory such as DIMMs are located on the bottom side of the sled. As a result of the enhanced air flow provided by this design, the components can operate at higher frequencies and power levels than in typical systems, thereby improving performance. In addition, the sled is configured to blindly mate with power and data communication cables in the rack, thereby enhancing their ability to be quickly removed, upgraded, reinstalled, and / or replaced. Similarly, the various components located on the sled (such as processors, accelerators, memory, and data storage drives) are configured to be easily upgraded due to their increased spacing from each other. In an illustrative embodiment, the components additionally include hardware certification features to confirm their authenticity.

[0047] The data center can utilize a single network architecture ("fabric") that supports multiple other network architectures including Ethernet and Omni-Path. The skids can be coupled to the switches via optical fiber that provides higher bandwidth and lower latency than typical twisted pair cabling (e.g., Category 5, Category 5e, Category 6, etc.). Due to the high-bandwidth, low-latency interconnect and network architecture, the data center can pool physically dispersed resources (such as memory, accelerators (e.g., GPUs, graphics accelerators, FPGAs, ASICs, neural network and / or artificial intelligence accelerators, etc.) and data storage drives) in use and provide them to computing resources (e.g., processors), thereby enabling the computing resources to access the pooled resources as if the pooled resources were local.

[0048] A power supply or power source can provide voltage and / or current to the processing system 100 or any component or system described herein. In one example, the power supply includes an AC to DC (alternating current to direct current) adapter for plugging into a wall socket. Such AC power can be a renewable energy (e.g., solar power) power source. In one example, the power source includes a DC power source, such as an external AC to DC converter. In one example, the power source or power supply includes wireless charging hardware to charge via proximity to a charging field. In one example, the power source can include an internal battery, an alternating current supply, a motion-based power supply, a solar power supply, or a fuel cell source.

[0049] Figures 2A-2D The figure illustrates a computing system and a graphics processor provided by the embodiments described herein. Elements having the same reference numerals (or names) as elements of any other figure in this document Figures 2A-2D The elements of may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0050] Figure 2A 2 is a block diagram of an embodiment of a processor 200 having one or more processor cores 202A-202N, an integrated memory controller 214, and an integrated graphics processor 208. The processor 200 may include additional cores, up to and including the additional core 202N represented by the dashed box. Each of the processor cores 202A-202N includes one or more internal cache units 204A-204N. In some embodiments, each processor core may also have access to one or more shared cache units 206. The internal cache units 204A-204N and the shared cache units 206 represent a cache memory hierarchy within the processor 200. The cache memory hierarchy may include at least one level of instruction and data cache within each processor core, and one or more levels of shared intermediate level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, where the highest level of cache before external memory is classified as LLC. In some embodiments, cache coherence logic maintains coherence between the various cache units 206 and 204A-204N.

[0051] In some embodiments, the processor 200 may also include a set of one or more bus controller units 216 and a system agent core 210. The one or more bus controller units 216 manage a set of peripheral buses, such as one or more PCI or PCI Express buses. The system agent core 210 provides management functionality for various processor components. In some embodiments, the system agent core 210 includes one or more integrated memory controllers 214 to manage access to various external memory devices (not shown).

[0052] In some embodiments, one or more of the processor cores 202A-202N include support for simultaneous multithreading. In such embodiments, the system agent core 210 includes components for coordinating and operating the cores 202A-202N during multithreaded processing. The system agent core 210 may additionally include a power control unit (PCU) that includes logic and components for regulating the power state of the processor cores 202A-202N and the graphics processor 208.

[0053] In some embodiments, the processor 200 additionally includes a graphics processor 208 for performing graphics processing operations. In some embodiments, the graphics processor 208 is coupled to a set of shared cache units 206 and a system agent core 210 including one or more integrated memory controllers 214. In some embodiments, the system agent core 210 also includes a display controller 211 for driving the graphics processor output to one or more coupled displays. In some embodiments, the display controller 211 may also be a separate module coupled to the graphics processor via at least one interconnect, or may be integrated within the graphics processor 208.

[0054] In some embodiments, a ring-based interconnect 212 is used to couple the internal components of processor 200. However, alternative interconnect units may be used, such as point-to-point interconnects, switched interconnects, mesh interconnects, or other technologies, including those known in the art. In some embodiments, graphics processor 208 is coupled to ring-based interconnect 212 via I / O link 213.

[0055] The example I / O link 213 represents at least one of a plurality of kinds of I / O interconnects, including an on-package I / O interconnect that facilitates communication between various processor components and a high-performance embedded memory module 218, such as an eDRAM module or a high-bandwidth memory (HBM) module. In some embodiments, each of the processor cores 202A-202N and the graphics processor 208 can use the embedded memory module 218 as a shared last-level cache.

[0056] In some embodiments, the processor cores 202A-202N are homogeneous cores that execute the same instruction set architecture. In another embodiment, the processor cores 202A-202N are heterogeneous in terms of instruction set architecture (ISA), wherein one or more of the processor cores 202A-202N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment, the processor cores 202A-202N are heterogeneous in terms of microarchitecture, wherein one or more cores with relatively high power consumption are coupled with one or more power cores with lower power consumption. In one embodiment, the processor cores 202A-202N are heterogeneous in terms of computing power. In addition, the processor 200 can be implemented on one or more chips, or as a SoC integrated circuit having the components shown in the figure in addition to other components.

[0057] Figure 2Bis a block diagram of the hardware logic of the graphics processor core block 219 according to some embodiments described herein. In some embodiments, elements having the same reference numbers (or names) as elements of any other figure herein Figure 2B The elements of the graphics processor core block 219 may operate or function in a manner similar to that described elsewhere herein. The graphics processor core block 219 is an example of a partition of a graphics processor. The graphics processor core block 219 may be included in Figure 2A The graphics processor 208 or a discrete graphics processor, parallel processor, and / or computing accelerator may be within the integrated graphics processor 208 or a discrete graphics processor, parallel processor, and / or computing accelerator. A graphics processor as described herein may include multiple graphics core blocks based on a target power and performance envelope. Each graphics processor core block 219 may include a functional block 230 coupled to multiple graphics cores 221A-221F, wherein the multiple graphics cores 221A-221F include modular blocks of fixed function logic and general purpose programmable logic. The graphics processor core block 219 also includes a shared / cache memory 236 accessible by all graphics cores 221A-221F, rasterizer logic 237, and additional fixed function logic 238.

[0058] In some embodiments, the functional block 230 includes a geometry / fixed function pipeline 231, which can be shared by all graphics cores in the graphics processor core block 219. In various embodiments, the geometry / fixed function pipeline 231 includes a 3D geometry pipeline, a video front end unit, a thread spawner and a global thread dispatcher, and a unified return buffer manager that manages a unified return buffer. In one embodiment, the functional block 230 also includes a graphics SoC interface 232, a graphics microcontroller 233, and a media pipeline 234. The graphics SoC interface 232 provides an interface between the graphics processor core block 219 and other core blocks within the graphics processor or computing accelerator SoC. The graphics microcontroller 233 is a programmable subprocessor that can be configured to manage various functions of the graphics processor core block 219, including thread dispatching, scheduling, and preemption. The media pipeline 234 includes logic used to facilitate decoding, encoding, pre-processing, and / or post-processing of multimedia data (including image and video data). The media pipeline 234 implements media operations via requests to computational or sampling logic within the graphics cores 221A-221F. One or more pixel backends 235 may also be included within the functional block 230. The pixel backend 235 includes a cache memory for storing pixel color values ​​and may perform blending operations and lossless color compression of rendered pixel data.

[0059] In one embodiment, the graphics SoC interface 232 enables the graphics processor core block 219 to communicate with a general purpose application processor core (e.g., CPU) and / or other components within the SoC or system host CPU coupled to the SoC via a peripheral interface. The graphics SoC interface 232 can also enable communication with off-chip memory hierarchy elements such as shared last level cache memory, system RAM, and / or embedded on-chip or on-package DRAM. The SoC interface 232 can also enable communication with fixed function devices within the SoC such as a camera imaging pipeline, and can enable the use and / or implementation of global memory atomics that can be shared between the graphics processor core block 219 and the CPU within the SoC. The graphics SoC interface 232 can also enable power management control for the graphics processor core block 219, and can enable the interface between the clock domain of the graphics processor core block 219 and other clock domains within the SoC. In one embodiment, the graphics SoC interface 232 can enable reception of command buffers from a command streamer and a global thread dispatcher that are configured to provide commands and instructions to each of one or more graphics cores within the graphics processor. Commands and instructions may be dispatched to the media pipeline 234 when media operations are to be performed, or to the geometry and fixed function pipeline 231 when graphics processing operations are to be performed. When compute operations are to be performed, the compute dispatch logic may dispatch commands to the graphics cores 221A-221F, bypassing the geometry and media pipelines.

[0060] The graphics microcontroller 233 may be configured to perform various scheduling and management tasks for the graphics processor core block 219. In one embodiment, the graphics microcontroller 233 may perform scheduling of graphics and / or computational workloads on the various vector engines 222A-222F, 224A-224F and matrix engines 223A-223F, 225A-225F within the graphics core 221A-221F. In this scheduling model, host software executing on the CPU core of the SoC containing the graphics processor core block 219 may submit a workload to one of a plurality of graphics processor doorbells, which invokes scheduling operations on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting the workload to the command stream converter, preempting existing workloads running on the engine, monitoring the progress of the workload, and notifying the host software when the workload is completed. In one embodiment, the graphics microcontroller 233 may also facilitate a low power or idle state for the graphics processor core block 219, thereby providing the graphics processor core block 219 with the ability to save and restore registers within the graphics processor core block 219 across low power state transitions independent of the operating system and / or graphics driver software on the system.

[0061] The graphics processor core block 219 may have more or fewer graphics cores 221A-221F than shown, up to N modular graphics cores. For each group of N graphics cores, the graphics processor core block 219 may also include a shared / cache memory 236 (which may be configured as a shared memory or a cache memory), a rasterizer logic 237, and additional fixed function logic 238 to accelerate various graphics and compute processing operations.

[0062] Within each graphics core 221A-221F is a collection of execution resources that can be used to perform graphics, media, and compute operations in response to requests made by a graphics pipeline, a media pipeline, or a shader program. The graphics core 221A-221F includes multiple vector engines 222A-222F, 224A-224F, matrix acceleration units 223A-223F, 225A-225D, cache / shared local memory (SLM), samplers 226A-226F, and ray tracing units 227A-227F.

[0063] The vector engines 222A-222F, 224A-224F are general purpose graphics processing units capable of performing floating point and integer / fixed point logic operations to serve graphics, media, or compute operations (including graphics, media, or compute / GPGPU programs). The vector engines 222A-222F, 224A-224F can operate with variable vector widths using SIMD, SIMT, or SIMT+SIMD execution modes. The matrix acceleration units 223A-223F, 225A-225D contain matrix-matrix and matrix-vector acceleration logic that improves the performance of matrix operations, particularly low-precision and mixed-precision (e.g., INT8, FP16, BF16) matrix operations for machine learning. In one embodiment, each of the matrix acceleration units 223A-223F, 225A-225D contains one or more systolic arrays of processing elements that can perform concurrent matrix multiplication or dot product operations on matrix elements.

[0064] Samplers 226A-226F may read media or texture data into memory and may sample the data differently based on the configured sampler state and the texture / media format being read. Threads executing on vector engines 222A-222F, 224A-224F or matrix acceleration units 223A-223F, 225A-225D may utilize caches / SLMs 228A-228F within each execution core. Caches / SLMs 228A-228F may be configured as cache memory or a shared memory pool that is local to each of the corresponding graphics cores 221A-221F. Ray tracing units 227A-227F within graphics cores 221A-221F include ray traversal / intersection circuitry modules for performing ray traversals using a bounding volume hierarchy (BVH) and identifying intersections between rays and primitives enclosed within the BVH volume. In one embodiment, the ray tracing units 227A-227F include circuitry for performing depth testing and culling (e.g., using a depth buffer or similar arrangement). In one implementation, the ray tracing units 227A-227F perform traversal and intersection operations in concert with image denoising, at least a portion of which may be performed using associated matrix acceleration units 223A-223F, 225A-225D.

[0065] Figure 2C Illustrated is a graphics processing unit (GPU) 239 containing a dedicated set of graphics processing resources arranged into multi-core groups 240A-240N. Illustrated are details of multi-core group 240A. Multi-core groups 240B-240N may be equipped with the same or similar set of graphics processing resources.

[0066] As illustrated, multi-core group 240A may include a set of graphics cores 243, a set of tensor cores 244, and a set of ray tracing cores 245. Scheduler / dispatcher 241 schedules and dispatches graphics threads for execution on the various cores 243, 244, 245. In one embodiment, tensor core 244 is a sparse tensor core having hardware that enables multiplication operations with zero-valued inputs to be bypassed. Figure 2C GPU 239 graphics core 243 relative to Figure 2B The graphics cores 221A-221F of the embodiment of the present invention are different in the level of abstraction of the hierarchy, which is similar to Figure 2C The multi-core group 240A-240N. Figure 2C The graphics core 243, tensor core 244 and ray tracing core 245 are similar to Figure 2B Vector engines 222A-222F, 224A-224F, matrix engines 223A-223F, 225A-225F and ray tracing units 227A-227F.

[0067] The set of register files 242 may store operand values ​​used by cores 243, 244, 245 when executing graphics threads. These register files may contain, for example, integer registers for storing integer values, floating point registers for storing floating point values, vector registers for storing packed data elements (integer and / or floating point data elements), and tile registers for storing tensor / matrix values. In one embodiment, tile registers are implemented as a combined set of vector registers.

[0068] One or more combined level 1 (L1) caches and shared memory units 247 store graphics data locally within each multi-core group 240A, such as texture data, vertex data, pixel data, light data, bounding volume data, etc. One or more texture units 247 can also be used to perform texture operations, such as texture mapping and sampling. A level 2 (L2) cache 253 shared by all or a subset of the multi-core groups 240A-240N stores graphics data and / or instructions for multiple concurrent graphics threads. As illustrated, the L2 cache 253 can be shared across multiple multi-core groups 240A-240N. One or more memory controllers 248 couple the GPU 239 to a memory 249, which can be a system memory (e.g., DRAM) and / or a dedicated graphics memory (e.g., GDDR6 memory).

[0069] The input / output (I / O) circuit module 250 couples the GPU 239 to one or more I / O devices 252, such as a digital signal processor (DSP), a network controller, or a user input device. On-chip interconnects may be used to couple the I / O devices 252 to the GPU 239 and the memory 249. One or more I / O memory management units (IOMMUs) 251 of the I / O circuit module 250 couple the I / O devices 252 directly to the memory 249. In one embodiment, the IOMMU 251 manages multiple sets of page tables to map virtual addresses to physical addresses in the memory 249. In this embodiment, the I / O devices 252, the CPU(s) 246, and the GPU 239 may share the same virtual address space.

[0070] In one implementation, IOMMU 251 supports virtualization. In this case, it may manage a first set of page tables to map guest / graphics virtual addresses to guest / graphics physical addresses, and a second set of page tables to map guest / graphics physical addresses to system / host physical addresses (e.g., within memory 249). The base address of each of the first and second sets of page tables may be stored in a control register and swapped out upon context switch (e.g., so that a new context is provided with access to the associated set of page tables). Although in Figure 2C Not shown, each of the cores 243, 244, 245 and / or multi-core groups 240A-240N may include a translation lookaside buffer (TLB) to cache guest virtual to guest physical translations, guest physical to host physical translations, and guest virtual to host physical translations.

[0071] In one embodiment, CPU 246, GPU 239, and I / O devices 252 are integrated on a single semiconductor chip and / or chip package. Memory 249 may be integrated on the same chip, or may be coupled to memory controller 248 via an off-chip interface. In one implementation, memory 249 includes GDDR6 memory that shares the same virtual address space as other physical system-level memory, although the underlying principles of the embodiments described herein are not limited to this particular implementation.

[0072] In one embodiment, the tensor core 244 includes multiple functional units specifically designed to perform matrix operations, which are the basic computational operations used to perform deep learning operations. For example, simultaneous matrix multiplication operations can be used for neural network training and reasoning. The tensor core 244 can perform matrix processing using a variety of operand precisions, including single-precision floating point (e.g., 32 bits), half-precision floating point (e.g., 16 bits), integer words (16 bits), bytes (8 bits), and half bytes (4 bits). In one embodiment, a neural network implementation extracts features of each rendered scene, potentially combining details from multiple frames to construct a high-quality final image.

[0073] In a deep learning implementation, parallel matrix multiplication work may be scheduled for execution on the tensor core 244. The training of neural networks in particular utilizes a large number of matrix dot product operations. To process the inner product formula of the N x N x N matrix multiplication, the tensor core 244 may contain at least N dot product processing elements. Before the matrix multiplication begins, a full matrix is ​​loaded into the slice register, and for each of the N loops, at least one column of the second matrix is ​​loaded. For each loop, there are N dot products that are processed.

[0074] Depending on the specific implementation, matrix elements may be stored in different precisions, including 16-bit words, 8-bit bytes (e.g., INT8), and 4-bit nibbles (e.g., INT4). Different precision modes may be specified for the tensor cores 244 to ensure that the most efficient precision is used for different workloads (e.g., such as inference workloads that can tolerate quantization to bytes and nibbles).

[0075] In one embodiment, the ray tracing core 245 accelerates ray tracing operations for both real-time ray tracing and non-real-time ray tracing implementations. In particular, the ray tracing core 245 includes a ray traversal / intersection circuit module for performing ray traversals using a bounding volume hierarchy (BVH) and identifying intersections between primitives and rays enclosed within the BVH. The ray tracing core 245 may also include a circuit module for performing depth testing and culling (e.g., using a Z buffer or similar arrangement). In one implementation, the ray tracing core 245 performs traversal and intersection operations in concert with the image denoising techniques described herein, at least a portion of which may be executed on the tensor core 244. For example, in one embodiment, the tensor core 244 implements a deep learning neural network to perform denoising of frames generated by the ray tracing core 245. However, (one or more) CPUs 246, graphics core 243, and / or ray tracing core 245 may also implement all or part of a denoising and / or deep learning algorithm.

[0076] Additionally, as described above, a distributed approach to noise reduction may be employed, wherein the GPU 239 is in a computing device coupled to other computing devices via a network or high-speed interconnect. In this embodiment, the interconnected computing devices share neural network learning / training data to improve the speed at which the entire system learns to perform noise reduction for different types of image frames and / or different graphics applications.

[0077] In one embodiment, the ray tracing core 245 handles all BVH traversals and ray-primitive intersections, thereby saving the graphics core 243 from being overloaded with thousands of instructions per ray. In one embodiment, each ray tracing core 245 includes a first set of specialized circuit modules for performing bounding box tests (e.g., for traversal operations) and a second set of specialized circuit modules for performing ray-triangle intersection tests (e.g., intersecting traversed rays). Therefore, in one embodiment, the multi-core group 240A can only initiate ray probes, and the ray tracing core 245 independently performs ray traversals and intersections and returns hit data (e.g., hits, no hits, multiple hits, etc.) to the thread context. While the ray tracing core 245 performs traversal and intersection operations, the other cores 243, 244 are freed up to perform other graphics or computational work.

[0078] In one embodiment, each ray tracing core 245 includes a traversal unit to perform BVH test operations and an intersection unit to perform ray-primitive intersection tests. The intersection unit generates a "hit", "no hit", or "multiple hits" response, and the intersection unit provides the response to the appropriate thread. During traversal and intersection operations, execution resources of other cores (e.g., graphics core 243 and tensor core 244) are freed to perform other forms of graphics work.

[0079] In one particular embodiment described below, a hybrid rasterization / ray tracing approach is used where the work is distributed between graphics core 243 and ray tracing core 245.

[0080] In one embodiment, the ray tracing core 245 (and / or other cores 243, 244) includes hardware support for a ray tracing instruction set such as Microsoft's DirectX Ray Tracing (DXR), which includes the DispatchRays command and ray generation, closest hit, any hit, and miss shaders, which enables the assignment of a unique set of textures and shaders for each object. Another ray tracing platform that can be supported by the ray tracing core 245, graphics core 243, and tensor core 244 is Vulkan 1.1.85. However, note that the underlying principles of the embodiments described herein are not limited to any particular ray tracing ISA.

[0081] In general, the various cores 245, 244, 243 may support a ray tracing instruction set that includes instructions / functions for ray generation, closest hit, any hit, ray-primitive intersection, per-primitive and hierarchy bounding box construction, misses, visits, and exceptions. More specifically, one embodiment includes ray tracing instructions to perform the following functions:

[0082] Light Generation - Ray generation instructions can be executed per pixel, sample, or other user-defined work assignments.

[0083] Closest hit - A closest hit instruction may be executed to locate the closest intersection point of a ray through primitives within the scene.

[0084] Any hit - Any hit command identifies multiple intersections between primitives and rays within the scene to potentially identify a new closest intersection point.

[0085] intersect - The intersection instructions perform ray-primitive intersection tests and output the results.

[0086] Per-primitive bounding box construction - This instruction builds a bounding box around a given primitive or group of primitives (e.g., when building a new BVH or other acceleration data structure).

[0087] miss - Indicates that the ray missed the scene or all geometry within a specified region of the scene.

[0088] visit ——Indicates the sub-volume that the ray will traverse.

[0089] abnormal --Contains various types of exception handlers (e.g., called for various error conditions).

[0090] In one embodiment, the ray tracing core 245 may be adapted to accelerate general computing operations that can be accelerated using computing techniques similar to ray intersection testing. A computing framework may be provided that enables shader programs to be compiled into low-level instructions and / or primitives that perform general computing operations via the ray tracing core. Example computing problems that may benefit from computing operations performed on the ray tracing core 245 include calculations involving the propagation of beams, waves, rays, or particles in a coordinate space. Interactions associated with that propagation may be calculated relative to a geometry or mesh in the coordinate space. For example, calculations associated with the propagation of an electromagnetic signal through an environment may be accelerated via the use of instructions or primitives that are executed via the ray tracing core. Diffraction and reflection of the signal through objects in the environment may be calculated as direct ray tracing simulations.

[0091] The ray tracing core 245 can also be used to perform calculations that are not directly similar to ray tracing. For example, the ray tracing core 245 can be used to accelerate mesh projection, mesh refinement, and volume sampling calculations. General coordinate space calculations, such as nearest neighbor calculations, can also be performed. For example, a set of points near a given point can be found by defining a bounding box around the given point in the coordinate space. The BVH and ray detection logic within the ray tracing core 245 can then be used to determine the set of intersections of points within the bounding box. The intersection constitutes the origin and the nearest neighbors of that origin. The calculations performed using the ray tracing core 245 can be performed in parallel with the calculations performed on the graphics core 243 and the tensor core 244. The shader compiler can be configured to compile a compute shader or other general graphics processing program into a low-level primitive that can be parallelized across the graphics core 243, the tensor core 244, and the ray tracing core 245.

[0092] Figure 2D2 is a block diagram of a general purpose graphics processing unit (GPGPU) 270 that can be configured as a graphics processor and / or a computing accelerator according to embodiments described herein. The GPGPU 270 can be interconnected with a host processor (e.g., one or more CPUs 246) and memories 271, 272 via one or more system and / or memory buses. In one embodiment, the memory 271 is a system memory that can be shared with one or more CPUs 246, while the memory 272 is a device memory dedicated to the GPGPU 270. In one embodiment, the components within the memory 272 and the GPGPU 270 can be mapped to memory addresses accessible to one or more CPUs 246. Access to the memories 271 and 272 can be facilitated via a memory controller 268. In one embodiment, the memory controller 268 includes an internal direct memory access (DMA) controller 269, or can include logic to perform operations that would otherwise be performed by a DMA controller.

[0093] GPGPU 270 includes a plurality of cache memories, including L2 cache 253, L1 cache 254, instruction cache 255, and shared memory 256. At least a portion of the shared memory 256 may also be partitioned as cache memories. GPGPU 270 also includes a plurality of computing units 260A-260N, which represent similar Figure 2B Graphics cores 221A-221F and Figure 2C The hierarchical abstraction level of the multi-core group 240A-240N of the GPGPU 270 is shown. Each compute unit 260A-260N includes a set of vector registers 261, scalar registers 262, vector logic units 263, and scalar logic units 264. The compute units 260A-260N may also include a local shared memory 265 and a program counter 266. The compute units 260A-260N may be coupled with a constant cache 267, which may be used to store constant data, which is data that will not change during the execution of a kernel or shader program executed on the GPGPU 270. In one embodiment, the constant cache 267 is a scalar data cache, and the cached data may be directly fetched into the scalar registers 262.

[0094] During operation, one or more CPUs 246 may write commands to registers or memories in GPGPU 270 that have been mapped into an accessible address space. Command processor 257 may read commands from registers or memories and determine how those commands will be processed within GPGPU 270. Thread dispatcher 258 may then be used to dispatch threads to computing units 260A-260N to execute those commands. Each computing unit 260A-260N may execute threads independently of other computing units. In addition, each computing unit 260A-260N may be independently configured for conditional computations and may conditionally output the results of the computations to memory. When the submitted commands are completed, command processor 257 may interrupt one or more CPUs 246.

[0095] Figures 3A-3C FIG. 1 illustrates a block diagram of an additional graphics processor and computing accelerator architecture provided by the embodiments described herein. Figures 3A-3C The elements of may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0096] Figure 3A 3 is a block diagram of a graphics processor 300, which may be a discrete graphics processing unit, or may be a graphics processor integrated with multiple processing cores or other semiconductor devices such as, but not limited to, memory devices or network interfaces. In some embodiments, the graphics processor communicates via a memory mapped I / O interface to registers on the graphics processor and through commands placed in the processor memory. In some embodiments, the graphics processor 300 includes a memory interface 314 for accessing memory. The memory interface 314 may be an interface to local memory, one or more internal caches, one or more shared external caches, and / or to system memory.

[0097] In some embodiments, the graphics processor 300 also includes a display controller 302 for driving display output data to a display device 318. The display controller 302 includes hardware for displaying and composing multiple layers of video or one or more overlay planes of user interface elements. The display device 318 can be an internal or external display device. In one embodiment, the display device 318 is a head mounted display device, such as a virtual reality (VR) display device or an augmented reality (AR) display device. In some embodiments, the graphics processor 300 includes a video codec engine 306 to encode media into one or more media coding formats, decode media from one or more media coding formats, or transcode media between one or more media coding formats, wherein the media coding formats include but are not limited to Moving Picture Experts Group (MPEG) formats (such as MPEG-2), Advanced Video Coding (AVC) formats, such as H.264 / MPEG-4 AVC, H.265 / HEVC, Alliance for Open Media (AOMedia) VP8, VP9, ​​and the Society of Motion Picture & Television Engineers (SMPTE) 421M / VC-1 and Joint Photographic Experts Group (JPEG) formats (such as JPEG and Motion JPEG (MJPEG) formats.

[0098] In some embodiments, graphics processor 300 includes a block image transfer (BLIT) engine for performing two-dimensional (2D) rasterizer operations (including, for example, bit-boundary block transfers). However, in one embodiment, 2D graphics operations are performed using one or more components of graphics processing engine (GPE) 310. In some embodiments, GPE 310 is a compute engine for performing graphics operations including three-dimensional (3D) graphics operations and media operations.

[0099] In some embodiments, GPE 310 includes a 3D pipeline 312 for performing 3D operations, such as rendering three-dimensional images and scenes using processing functions that operate on 3D primitive shapes (e.g., rectangles, triangles, etc.). 3D pipeline 312 includes programmable and fixed-function elements that perform various tasks within the element and / or spawn execution threads to 3D / media subsystem 315. While 3D pipeline 312 can be used to perform media operations, embodiments of GPE 310 also include a media pipeline 316 specifically for performing media operations, such as video post-processing and image enhancement.

[0100] In some embodiments, the media pipeline 316 includes fixed-function or programmable logic units to perform one or more specialized media operations, such as video decoding acceleration, video deinterlacing, and video encoding acceleration, instead of or on behalf of the video codec engine 306. In some embodiments, the media pipeline 316 additionally includes a thread spawning unit to spawn threads for execution on the 3D / media subsystem 315. The spawned threads perform calculations for media operations on one or more graphics cores included in the 3D / media subsystem 315.

[0101] In some embodiments, the 3D / media subsystem 315 includes logic for executing threads derived from the 3D pipeline 312 and the media pipeline 316. In one embodiment, the pipeline sends thread execution requests to the 3D / media subsystem 315, which includes thread dispatch logic for arbitrating and dispatching the various requests to available thread execution resources. The execution resources include an array of graphics cores used to handle 3D and media threads. In some embodiments, the 3D / media subsystem 315 includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory, which includes registers and addressable memory to share data between threads and store output data.

[0102] Figure 3B A graphics processor 320 having a tiled architecture is illustrated according to embodiments described herein. In one embodiment, the graphics processor 320 includes a graphics processing engine cluster 322 having graphics engine tiles 310A-310D. Figure 3AMultiple instances of a graphics processing engine 310. Each graphics engine slice 310A-310D can be interconnected via a set of slice interconnects 323A-323F. Each graphics engine slice 310A-310D can also be connected to a memory module or memory device 326A-326D via a memory interconnect 325A-325D. The memory device 326A-326D can use any graphics memory technology. For example, the memory device 326A-326D can be a graphics double data rate (GDDR) memory. The memory device 326A-326D is, in one embodiment, an HBM module, which can be on the die with its corresponding graphics engine slice 310A-310D. In one embodiment, the memory device 326A-326D is a stacked memory device, which can be stacked on top of its corresponding graphics engine slice 310A-310D. In one embodiment, as Figures 11B-11D As described in further detail in , each graphics engine slice 310A-310D and associated memory 326A-326D resides on a separate chiplet that is bonded to a base die or base substrate.

[0103] Graphics processor 320 may be configured with a non-uniform memory access (NUMA) system in which memory devices 326A-326D are coupled to associated graphics engine slices 310A-310D. A given memory device may be accessed by a graphics engine slice rather than a slice to which it is directly connected. However, access latency to memory devices 326A-326D may be lowest when accessing a local slice. In one embodiment, a cache coherent NUMA (ccNUMA) system may be implemented that uses slice interconnects 323A-323F to enable communication between cache controllers within a graphics engine slice 310A-310D to maintain a consistent memory image when more than one cache stores the same memory location.

[0104] The graphics processing engine cluster 322 may be connected to an on-chip or on-package fabric interconnect 324. In one embodiment, the fabric interconnect 324 includes a network processor, a network on a chip (NoC), or another switching processor to enable the fabric interconnect 324 to function as a packet switching fabric interconnect that exchanges data packets between components of the graphics processor 320. The fabric interconnect 324 may enable communication between the graphics engine slices 310A-310D and components such as the video codec engine 306 and one or more replication engines 304. The replication engines 304 may be used to move data out of, into, and between memory devices 326A-326D and memory external to the graphics processor 320 (e.g., system memory). The fabric interconnect 324 may also be coupled to one or more of the slice interconnects 323A-323F to facilitate or enhance the interconnection between the graphics engine slices 310A-310D. Fabric interconnect 324 may also be configured to interconnect multiple instances of graphics processor 320 (e.g., via host interface 328), thereby enabling slice-to-slice communication between graphics engine slices 310A-310D of multiple GPUs. In one embodiment, graphics engine slices 310A-310D of multiple GPUs may be presented to a host system as a single logical device.

[0105] The graphics processor 320 may optionally include the display controller 302 to enable connection to the display device 318. The graphics processor may also be configured as a graphics or computing accelerator. In an accelerator configuration, the display controller 302 and the display device 318 may be omitted.

[0106] The graphics processor 320 may be connected to a host system via a host interface 328. The host interface 328 may enable communication between the graphics processor 320, system memory, and / or other system components. The host interface 328 may be, for example, a PCI Express bus or another type of host system interface. For example, the host interface 328 may be an NVLink or NVSwitch interface. The host interface 328 and the fabric interconnect 324 may collaborate to enable multiple instances of the graphics processor 320 to act as a single logical device. The collaboration between the host interface 328 and the fabric interconnect 324 may also enable the individual graphics engine slices 310A-310D to be presented to the host system as different logical graphics devices.

[0107] Figure 3C FIG. 3 illustrates a computing accelerator 330 according to an embodiment described herein. The computing accelerator 330 may include Figure 3BThe computing engine cluster 332 may include a collection of computing engine slices 340A-340D, which include execution logic optimized for parallel or vector-based general computing operations. In some embodiments, the computing engine slices 340A-340D do not include fixed-function graphics processing logic, although in one embodiment, one or more of the computing engine slices 340A-340D may include logic for performing media acceleration. The computing engine slices 340A-340D may be connected to the memory 326A-326D via the memory interconnect 325A-325D. The memory 326A-326D and the memory interconnect 325A-325D may be similar technologies to those in the graphics processor 320, or may be different. The computing engine slices 340A-340D may also be interconnected via a collection of slice interconnects 323A-323F, and may be connected to and / or interconnected by the fabric interconnect 324. Communication across slices may be facilitated via fabric interconnect 324. Fabric interconnect 324 may also facilitate communication between compute engine slices 340A-340D of multiple instances of compute accelerator 330 (e.g., via host interface 328). In one embodiment, compute accelerator 330 includes a large L3 cache 336 that may be configured as a device-wide cache. Computation accelerator 330 may also communicate with Figure 3B The graphics processor 320 is similarly connected to a host processor and memory via a host interface 328 .

[0108] The computing accelerator 330 may also include an integrated network interface 342. In one embodiment, the network interface 342 includes a network processor and controller logic that enables the computing engine cluster 332 to communicate through the physical layer interconnect 344 without traversing the memory of the host system with data. In one embodiment, one of the computing engine slices 340A-340D is replaced by the network processor logic, and the data to be transmitted or received via the physical layer interconnect 344 can be directly transmitted to or from the memory 326A-326D. Multiple instances of the computing accelerator 330 can be combined into a single logical device via the physical layer interconnect 344. Alternatively, the various computing engine slices 340A-340D can be presented as different network accessible computing accelerator devices. Graphics processing engine

[0109] Figure 4 is a block diagram of a graphics processing engine 410 of a graphics processor according to some embodiments. In one embodiment, the graphics processing engine (GPE) 410 is Figure 3A A version of the GPE 310 shown in FIG. Figure 3BGraphics engine chips 310A-310D of FIG. Elements having the same reference numerals (or names) as elements of any other drawings herein Figure 4 The elements of may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto. Figure 3A 410. The 3D pipeline 312 and the media pipeline 316 of the GPE 410. The media pipeline 316 is optional in some embodiments of the GPE 410 and may not be explicitly included within the GPE 410. For example, and in at least one embodiment, separate media and / or image processors are coupled to the GPE 410.

[0110] In some embodiments, the GPE 410 is coupled to or includes a command stream converter 403 that provides a command stream to the 3D pipeline 312 and / or the media pipeline 316. Alternatively or additionally, the command stream converter 403 may be directly coupled to a unified return buffer 418. The unified return buffer 418 may be communicatively coupled to the graphics core cluster 414. In some embodiments, the command stream converter 403 is coupled to a memory, which may be a system memory, or one or more of an internal cache memory and a shared cache memory. In some embodiments, the command stream converter 403 receives commands from the memory and sends the commands to the 3D pipeline 312 and / or the media pipeline 316. The commands are instructions taken from a ring buffer that stores commands for the 3D pipeline 312 and the media pipeline 316. In one embodiment, the ring buffer may additionally include a batch command buffer that stores a batch of multiple commands. Commands for 3D pipeline 312 may also include references to data stored in memory, such as, but not limited to, vertex and geometry data for 3D pipeline 312 and / or image data and memory objects for media pipeline 316. 3D pipeline 312 and media pipeline 316 process commands and data by performing operations via logic within the respective pipelines or by dispatching one or more execution threads to graphics core cluster 414. In one embodiment, graphics core cluster 414 includes one or more graphics core blocks (e.g., graphics core block 415A, graphics core block 415B), each block including one or more graphics cores. Each graphics core includes: a collection of graphics execution resources, which includes general and graphics-specific execution logic used to perform graphics and compute operations; and fixed-function texture processing and / or machine learning and artificial intelligence acceleration logic, such as matrix or AI acceleration logic.

[0111] In various embodiments, the 3D pipeline 312 may include fixed function and programmable logic to process one or more shader programs, such as vertex shaders, geometry shaders, pixel shaders, fragment shaders, compute shaders, or other shaders and / or GPGPU programs, by processing instructions and dispatching execution threads to the graphics core cluster 414. The graphics core cluster 414 provides a unified block of execution resources for use in processing these shader programs. The multi-purpose execution logic within the graphics core blocks 415A-415B of the graphics core cluster 414 includes support for various 3D API shader languages ​​and can execute multiple simultaneous execution threads associated with multiple shaders.

[0112] In some embodiments, graphics core cluster 414 includes execution logic for performing media functions such as video and / or image processing. In one embodiment, the graphics core includes general purpose logic that can be programmed to perform parallel general purpose computing operations in addition to graphics processing operations. The general purpose logic can be used with the graphics cores in the graphics core cluster 414. Figure 1 The processor core(s) 107 or as in Figure 2A The general logic within the cores 202A-202N in the MCU performs processing operations in parallel or in combination.

[0113] Output data generated by threads executing on graphics core cluster 414 can output data to memory in unified return buffer (URB) 418. URB 418 can store data for multiple threads. In some embodiments, URB 418 can be used to send data between different threads executing on graphics core cluster 414. In some embodiments, URB 418 can additionally be used for synchronization between threads on the graphics core array and fixed function logic within shared function logic 420.

[0114] In some embodiments, graphics core cluster 414 is scalable such that the cluster contains a variable number of graphics cores, each of which has a variable number of graphics cores based on the target power and performance level of GPE 410. In one embodiment, execution resources are dynamically scalable such that execution resources can be enabled or disabled.

[0115] The graphics core cluster 414 is coupled to shared function logic 420, which includes a plurality of resources shared between the graphics cores in the graphics core array. The shared functions within the shared function logic 420 are hardware logic units that provide specialized supplemental functionality to the graphics core cluster 414. In various embodiments, the shared function logic 420 may include, but is not limited to, sampler 421, math 422, and inter-thread communication (ITC) 423 logic. Additionally, some embodiments implement one or more caches 425 within the shared function logic 420. The shared function logic 420 may implement Figure 2B The additional fixed function logic 238 may have the same or similar functionality.

[0116] At least in the case where the demand for a given specialized function is insufficient to be contained within the graphics core cluster 414, the shared function is implemented. Instead, a single instantiation of the specialized function is implemented as an independent entity in the shared function logic 420 and is shared between the execution resources within the graphics core cluster 414. The exact set of functions that are shared within the graphics core cluster 414 and contained within the graphics core cluster 414 varies across embodiments. In some embodiments, specific shared functions within the shared function logic 420 that are widely used by the graphics core cluster 414 can be contained within the shared function logic 416 within the graphics core cluster 414. In various embodiments, the shared function logic 416 within the graphics core cluster 414 can contain some or all of the logic within the shared function logic 420. In one embodiment, all logic elements within the shared function logic 420 can be replicated within the shared function logic 416 of the graphics core cluster 414. In one embodiment, the shared function logic 420 is excluded in favor of the shared function logic 416 within the graphics core cluster 414. Graphics processing resources

[0117] Figure 5A-5C Execution logic including an array of processing elements employed in a graphics processor is illustrated according to embodiments described herein. Figure 5A A graphics core cluster is illustrated according to an embodiment. Figure 5B Illustrated is a vector engine of a graphics core according to an embodiment. Figure 5C A matrix engine of a graphics core according to an embodiment is illustrated. Figure 5A-5C Elements having the same reference numeral as elements of any other figure herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto. For example, Figure 5A-5C The components can be Figure 2B The graphics processor core block 219 and / or Figure 4In one embodiment, Figure 5A-5C The components have Figure 2A Graphics processor 208, Figure 2C GPU 239, or Figure 2D The equivalent components of GPGPU 270 have similar functionality.

[0118] like Figure 5A As shown in FIG. 1 , in one embodiment, the graphics core cluster 414 includes a graphics core block 415, which may be Figure 4 Graphics core block 415 may include any number of graphics cores (e.g., graphics core 515A, graphics core 515B, all the way up to graphics core 515N). Multiple instances of graphics core block 415 may be included. In one embodiment, the components of graphics cores 515A-515N have the same Figure 2B 221F of the graphics core 221A-221F. In such embodiments, the graphics cores 515A-515N each include circuit modules, which include but are not limited to: vector engines 502A-502N, matrix engines 503A-503N, memory load / store units 504A-504N, instruction caches 505A-505N, data caches / shared local memories 506A-506N, ray tracing units 508A-508N, samplers 510A-2710N. The circuit modules of the graphics cores 515A-515N may additionally include fixed function logic 512A-512N. The number of vector engines 502A-502N and matrix engines 503A-503N within a designed graphics core 515A-515N may vary based on the workload, performance, and power targets for the design.

[0119] Referring to the graphics core 515A, the vector engine 502A and the matrix engine 503A may be configured to perform parallel computational operations on data in various integer and floating point data formats based on instructions associated with the shader program. Each vector engine 502A and the matrix engine 503A may act as a programmable general purpose computing unit capable of executing multiple simultaneous hardware threads while processing multiple data elements in parallel for each thread. The vector engine 502A and the matrix engine 503A support processing variable width vectors in various SIMD widths, including but not limited to SIMD8, SIMD16, and SIMD32. The input data elements may be stored in registers as packed data types, and the vector engine 502A and the matrix engine 503A may process each element based on the data size of the element. For example, when operating on a 256-bit wide vector, the 256 bits of the vector are stored in registers, and the vector is processed as four separate 64-bit packed data elements (quad-word (QW) size data elements), eight separate 32-bit packed data elements (double-word (DW) size data elements), sixteen separate 16-bit packed data elements (word (W) size data elements), or thirty-two separate 8-bit data elements (byte (B) size data elements). However, different vector widths and register sizes are possible. In one embodiment, the vector engine 502A and the matrix engine 503A can also be configured to perform SIMT operations on thread groups (e.g., 8, 16 or 32 threads) or warps of various sizes.

[0120] Continuing with the graphics core 515A, the memory load / store unit 504A services memory access requests issued by the vector engine 502A, the matrix engine 503A, and / or other components of the graphics core 515A that have access to memory. The memory access request may be processed by the memory load / store unit 504A to load or store the requested data into a cache or memory, or from a cache or memory into a register file associated with the vector engine 502A and / or the matrix engine 503A. The memory load / store unit 504A may also perform prefetch operations. In one embodiment, the memory load / store unit 504A is configured to provide SIMT scatter / gather prefetch or block prefetch for data stored in the memory 610, from memory that is local to other slices via the slice interconnect 608, or from the system memory. Prefetching may be performed for a specific L1 cache (e.g., data cache / shared local memory 506A), L2 cache 604, or L3 cache 606. In one embodiment, a prefetch to L3 cache 606 automatically causes the data to be stored in L2 cache 604 .

[0121] Instruction cache 505A stores instructions to be executed by graphics core 515A. In one embodiment, graphics core 515A also includes instruction fetch and prefetch circuit modules that fetch or prefetch instructions into instruction cache 505A. Graphics core 515A also includes instruction decoding logic for decoding instructions within instruction cache 505A. Data cache / shared local memory 506A can be configured as a data cache managed by a cache controller that implements a cache replacement strategy and / or configured as a shared memory that is explicitly managed. Ray tracing unit 508A includes circuit modules for accelerating ray tracing operations. Sampler 510A provides texture sampling for 3D operations and media sampling for media operations. Fixed function logic 512A includes fixed function circuit modules that are shared between instances of vector engine 502A and matrix engine 503A. Graphics cores 515B-515N can operate in a similar manner to graphics core 515A.

[0122] The functionality of instruction caches 505A-505N, data cache / shared local memory 506A-506N, ray tracing units 508A-508N, samplers 510A-2710N, and fixed function logic 512A-512N corresponds to the equivalent functionality in the graphics processor architecture described herein. For example, instruction caches 505A-505N may be used in the same manner as Figure 2D The data cache / shared local memory 506A-506N, ray tracing units 508A-508N, and samplers 510A-2710N can operate in a manner similar to the instruction cache 255 of FIG. Figure 2B The fixed function logic 512A-512N may include the cache / SLM 228A-228F, ray tracing units 227A-227F, and samplers 226A-226F. Figure 2B In one embodiment, ray tracing units 508A-508N include components for performing the operations performed by Figure 2C A circuit module for ray tracing acceleration operations performed by the ray tracing core 245.

[0123] like Figure 5BAs shown in FIG. 5 , in one embodiment, the vector engine 502 includes an instruction fetch unit 537, a general register file array (GRF) 524, an architectural register file array (ARF) 526, a thread arbiter 522, an issue unit 530, a branch unit 532, a set of SIMD floating point units (FPUs) 534, and a set of integer SIMD ALUs 535 in one embodiment. The GRF 524 and ARF 526 include a set of general register files and architectural register files associated with each hardware thread that can be active in the vector engine 502. In one embodiment, the per-thread architectural state is maintained in the ARF 526, while data used during thread execution is stored in the GRF 524. The execution state of each thread, including the instruction pointer for each thread, can be saved in thread-specific registers in the ARF 526.

[0124] In one embodiment, the vector engine 502 has an architecture that is a combination of Simultaneous Multi-Threading (SMT) and fine-grained Interleaved Multi-Threading (IMT). The architecture has a modular configuration that can be fine-tuned at design time based on the target number of simultaneous threads and the number of registers per graphics core, where graphics core resources are divided across logic for executing multiple simultaneous threads. The number of logical threads that can be executed by the vector engine 502 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread.

[0125] In one embodiment, the vector engine 502 can issue multiple instructions in coordination, and these instructions can be different instructions respectively. The thread arbiter 522 can dispatch instructions to one of the send unit 530, the branch unit 532 or (one or more) SIMD FPU534 for execution. Each execution thread can access 128 general registers in the GRF 524, wherein each register can store 32 bytes accessible as a variable width vector of a 32-bit data element. In one embodiment, each thread has access to 4 kilobytes in the GRF 524, but the embodiment is not limited thereto, and more or less register resources can be provided in other embodiments. In one embodiment, the vector engine 502 is partitioned into seven hardware threads that can independently perform computing operations, but the number of threads of each vector engine 502 can also vary according to the embodiment. For example, in one embodiment, a maximum of 16 hardware threads are supported. In an embodiment in which seven threads can access 4 kilobytes, the GRF 524 can store a total of 28 kilobytes. With 16 threads accessing 4 kilobytes, a total of 64 kilobytes can be stored by GRF 524. Flexible addressing modes allow registers to be addressed together, effectively creating wider registers or representing strided rectangular block data structures.

[0126] In one embodiment, memory operations, sampler operations, and other longer latency system communications are dispatched via "send" instructions executed by message passing send unit 530. In one embodiment, branch instructions are dispatched to a dedicated branch unit 532 to facilitate SIMD scatter and eventual convergence.

[0127] In one embodiment, the vector engine 502 includes one or more SIMD floating point units (FPU(s)) 534 for performing floating point operations. In one embodiment, the FPU(s) 534 also supports integer calculations. In one embodiment, the FPU(s) 534 can perform up to M number of 32-bit floating point (or integer) operations, or perform up to 2M 16-bit integer or 16-bit floating point operations. In one embodiment, at least one of the FPU(s) provides extended math capabilities that support high throughput transcendental math functions and double precision 64-bit floating points. In some embodiments, a set of 8-bit integer SIMD ALUs 535 also exists and can be specifically optimized to perform operations associated with machine learning calculations. In one embodiment, the SIMD ALUs are replaced by a set of additional SIMD FPUs 534 that can be configured to perform integer and floating point operations. In one embodiment, the SIMD FPUs 534 and SIMD ALUs 535 can be configured to execute SIMT programs. In one embodiment, combined SIMD+SIMT operations are supported.

[0128] In one embodiment, an array of multiple instances of vector engine 502 may be instantiated in a graphics core. For scalability, product architects may choose the exact number of vector engines to group per graphics core. In one embodiment, vector engine 502 may execute instructions across multiple execution lanes. In further embodiments, each thread executed on vector engine 502 is executed on a different lane.

[0129] like Figure 5C As shown in, in one embodiment, the matrix engine 503 includes an array of processing elements configured to perform tensor operations, which include vector / matrix and matrix / matrix operations, such as but not limited to matrix multiplication and / or dot product operations. The matrix engine 503 is configured by processing elements (PE 552AA-PE 552MN) of M rows and N columns, and the processing elements (PE 552AA-PE 552MN) include multipliers and adder circuits organized in a pipelined manner. In one embodiment, the processing elements 552AA-PE 552MN form a physical pipeline stage of a systolic array of N width and M depth, which can be used to perform vector / matrix operations or matrix / matrix operations in a data-parallel manner, including matrix multiplication, fused multiplication and addition, dot product or other general matrix-matrix multiplication (GEMM) operations. In one embodiment, the matrix engine 503 supports 16-bit floating point operations, as well as 8-bit, 4-bit, 2-bit and binary integer operations. The matrix engine 503 may also be configured to accelerate certain machine learning operations. In such embodiments, the matrix engine 503 may be configured with support for a bfloat (brain floating point) 16-bit floating point format with a different number of mantissa bits and exponent bits relative to the Institute of Electrical and Electronics Engineers (IEEE) 754 format, or a tensor floating point 32-bit floating point format (TF32).

[0130] In one embodiment, during each cycle, each stage may add the result of the operation performed at that stage to the output of the previous stage. In other embodiments, after a set of computation cycles, the pattern of data movement between processing elements 552AA-552MN may vary based on the instructions or macro operations being executed. For example, in one embodiment, a partial sum loopback can be implemented, and the processing element may instead add the output of the current cycle to the output generated in the previous cycle. In one embodiment, the final stage of the systolic array may be configured with a loop to the initial stage of the systolic array. In such embodiments, the number of physical pipeline stages may be decoupled from the number of logical pipeline stages supported by the matrix engine 503. For example, where the processing elements 552AA-552MN are configured as a systolic array of M physical stages, a loop from stage M to the initial pipeline stage may enable the processing elements 552AA-PE552MN to operate as a systolic array of, for example, 2M, 3M, 4M, etc. logical pipeline stages.

[0131] In one embodiment, the matrix engine 503 includes memories 541A-541N, 542A-542M for storing input data in the form of row and column data for the input matrix. The memories 542A-542M can be configured to store the row elements (A0-Am) of the first input matrix, and the memories 541A-541N can be configured to store the column elements (B0-Bn) of the second input matrix. The row elements and column elements are provided as inputs to the processing elements 552AA-552MN for processing. In one embodiment, the row elements and column elements of the input matrix can be stored in the systolic register file 540 in the matrix engine 503 before those elements are provided to the memories 541A-541N, 542A-542M. In one embodiment, the systolic register file 540 is excluded, and the registers (e.g., Figure 5B 502 of the vector engine 502) or other memory of the graphics core including the matrix engine 503 (e.g., Figure 5A The data cache / shared local memory 506A for the matrix engine 503A) loads the memories 541A-541N, 542A-542M. The results generated by the processing elements 552AA-552MN are then output to the output buffers and / or written to the register files (e.g., systolic register file 540, GRF 524, data cache / shared local memory 506A-506N) for further processing by other functional units of the graphics processor or for output to memory.

[0132] In some embodiments, the matrix engine 503 is configured with support for input sparsity, wherein multiplication operations for sparse regions of input data can be bypassed by skipping multiplication operations for operands with zero values. In one embodiment, processing elements 552AA-552MN are configured to skip the execution of certain operations with zero-valued inputs. In one embodiment, the sparsity within the input matrix can be detected, and operations with known zero output values ​​can be bypassed before being submitted to processing elements 552AA-552MN. Loading zero-valued operands into processing elements can be bypassed, and processing elements 552AA-552MN can be configured to perform multiplication on non-zero-valued input elements. The matrix engine 503 can also be configured with support for output sparsity, so that operations with results predetermined to zero are bypassed. For input sparsity and / or output sparsity, in one embodiment, metadata is provided to processing elements 552AA-552MN to indicate which processing elements and / or data channels will be active during a certain processing cycle.

[0133] In one embodiment, the matrix engine 503 includes hardware to enable operations on sparse data with a compressed representation of a sparse matrix, which stores non-zero values ​​and metadata identifying the position of the non-zero values ​​in the matrix. Example compressed representations include but are not limited to compressed tensor representations, such as compressed sparse row (compressed sparse row, CSR) representation, compressed sparse column (compressed sparse column, CSC) representation, compressed sparse fiber (compressed sparse fiber, CSF) representation. Support for compressed representation enables operations to be performed on input in compressed tensor format without being decompressed or decoded using compressed representation. In such embodiments, operations can be performed on non-zero input values, and the resulting non-zero output values ​​can be mapped to the output matrix. In some embodiments, hardware support for machine-specific lossless data compression formats is also provided, which are used when transmitting data in hardware or transmitting data across a system bus. Such data may be retained in a compressed format for sparse input data, and the matrix engine 503 may use compression metadata for the compressed data to enable operations to be performed on non-zero values ​​or to enable multiplication operations to bypass blocks of zero data input.

[0134] In various embodiments, the input data may be provided by the programmer in a compressed tensor representation, or the codec may compress the input data into a compressed tensor representation or another sparse data encoding. In addition, to support compressed tensor representation, streaming compression of the sparse input data may be performed before the sparse input data is provided to the processing elements 552AA-552MN. In one embodiment, compression is performed on data written to a cache memory associated with the graphics core cluster 414, wherein the compression is performed by an encoding supported by the matrix engine 503. In one embodiment, the matrix engine 503 includes support for inputs with structured sparsity, in which a predetermined level or predetermined pattern of sparsity is applied to the input data. The data may be compressed to a known compression ratio, wherein the compressed data is processed by the processing elements 552AA-552MN according to metadata associated with the compressed data.

[0135] Figure 6 A slice 600 of a multi-slice processor according to an embodiment is illustrated. In one embodiment, slice 600 represents Figure 3B Graphics engine chips 310A-310D or Figure 3C Slice 600 of a multi-slice graphics processor includes an array of graphics core clusters (e.g., graphics core cluster 414A, graphics core cluster 414B, through graphics core cluster 414N), where each graphics core cluster has an array of graphics cores 515A-515N. Slice 600 also includes a global dispatcher 602 for dispatching threads to processing resources of slice 600.

[0136] Slice 600 may include or be coupled with L3 cache 606 and memory 610. In various embodiments, L3 cache 606 may be excluded, or slice 600 may include additional levels of cache, such as an L4 cache. Figure 3B and Figure 3C , each instance of a slice 600 in a multi-chip graphics processor has an associated memory 610. In one embodiment, the multi-chip processor may be configured as a multi-chip module in which the L3 cache 606 and / or the memory 610 reside on a separate chiplet that is distinct from the graphics core clusters 414A-414N. In this context, a chiplet is an at least partially packaged integrated circuit that contains different logic units that can be assembled into a larger package with other chiplets. For example, the L3 cache 606 may be contained in a dedicated cache chiplet, or reside on the same chiplet as the graphics core clusters 414A-414N. In one embodiment, the L3 cache 606 may be contained in a dedicated cache chiplet such as Fig. 11CIn the active base die or active interposer shown in FIG.

[0137] Memory fabric 603 enables communication between graphics core clusters 414A-414N, L3 cache 606, and memory 610. L2 cache 604 is coupled to memory fabric 603 and may be configured to cache transactions executed via memory fabric 603. Slice interconnect 608 enables communication with other slices on the graphics processor and may be Figure 3B and Figure 3C 604. In an embodiment where L3 cache 606 is excluded from slice 600, L2 cache 604 may be configured as a combined L2 / L3 cache. Memory fabric 603 may be configured to route data to L3 cache 606 or to a memory controller associated with memory 610 based on the presence or absence of L3 cache 606 in a particular implementation. L3 cache 606 may be configured as a per-tile cache that is dedicated to the processing resources of slice 600 or may be a partition of a GPU-wide L3 cache.

[0138] Figure 7 700 is a block diagram illustrating a graphics processor instruction format 700 in accordance with some embodiments. In one or more embodiments, the graphics processor core supports an instruction set having instructions in a variety of formats. Solid line boxes illustrate components that are generally included in the graphics core instructions, while dashed lines include components that are optional or included in a subset of instructions. In some embodiments, the graphics processor instruction format 700 described and illustrated are macroinstructions because they are instructions supplied to the graphics core, as opposed to micro-operations that are generated from instruction decoding once the instruction is processed. Therefore, a single instruction can cause the hardware to perform multiple micro-operations.

[0139] In some embodiments, the graphics processor natively supports instructions in 128-bit instruction format 710. Based on the selected instructions, instruction options, and the number of operands, 64-bit compact instruction format 730 can be used for some instructions. Native 128-bit instruction format 710 provides access to all instruction options, while some options and operations are restricted in 64-bit format 730. Available native instructions in 64-bit format 730 vary with the embodiment. In some embodiments, a set of index values ​​in index field 713 is used to partially compress instructions. The graphics core hardware references a set of compression tables based on the index values, and uses the compression table output to reconstruct native instructions in 128-bit instruction format 710. Instructions of other sizes and formats can be used.

[0140] For each format, the instruction opcode 712 defines the operation to be performed by the graphics core. The graphics core executes each instruction in parallel across multiple data elements of each operand. For example, in response to an add instruction, the graphics core performs a simultaneous addition operation across each color channel representing a texture element or a picture element. By default, the graphics core executes each instruction across all data channels of the operand. In some embodiments, the instruction control field 714 enables control of certain execution options such as channel selection (e.g., predication) and data channel order (e.g., swizzle). For instructions using the 128-bit instruction format 710, the execution size field 716 limits the number of data channels that will be executed in parallel. In some embodiments, the execution size field 716 is not available for use in the 64-bit compact instruction format 730.

[0141] Some graphics core instructions have up to three operands including two source operands, src0 720, src1 722, and one destination 718. In some embodiments, the graphics core supports dual destination instructions where one of the destinations is implicit. Data manipulation instructions may have a third source operand (e.g., src2 724), where the instruction opcode 712 determines the number of source operands. The last source operand of an instruction may be an immediate (e.g., hard-coded) value passed with the instruction.

[0142] In some embodiments, the 128-bit instruction format 710 includes an access / address mode field 726 that specifies, for example, whether direct register addressing mode or indirect register addressing mode is used. When direct register addressing mode is used, the register address of one or more operands is directly provided by bits in the instruction.

[0143] In some embodiments, 128-bit instruction format 710 includes access / address mode field 726, and this access / address mode field 726 specifies the address mode and / or access mode of instruction.In one embodiment, access mode is used to define the data access alignment of instruction.Some embodiments support access modes including 16-byte aligned access modes and 1-byte aligned access modes, wherein the byte alignment of access mode determines the access alignment of instruction operand.For example, when in the first mode, instruction can use byte-aligned addressing for source operand and destination operand, and when in the second mode, instruction can use 16-byte aligned addressing for all source operand and destination operand.

[0144] In one embodiment, the address mode portion of the access / address mode field 726 determines whether the instruction uses direct addressing or indirect addressing. When using direct register addressing mode, the bits in the instruction directly provide the register address of one or more operands. When using indirect register addressing mode, the register address of one or more operands can be calculated based on the address register value and the address immediate field in the instruction.

[0145] In some embodiments, instructions are grouped based on the opcode 712 bit field to simplify opcode decoding 740. For 8-bit opcodes, bits 4, 5, and 6 allow the graphics core to determine the type of opcode. The precise opcode grouping shown is only an example. In some embodiments, the move and logic opcode group 742 contains data movement and logic instructions (e.g., move (mov), compare (cmp)). In some embodiments, the move and logic group 742 shares five most significant bits (MSB), where the move (mov) instruction takes the form of 0000xxxxb, and the logic instruction takes the form of 0001xxxxb. The flow control instruction group 744 (e.g., call, jump (jmp)) contains instructions in the form of 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 746 contains a mixture of instructions, including synchronization instructions (e.g., wait, send) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group 748 includes component-by-component arithmetic instructions (e.g., add, multiply (mul)) in the form of 0100xxxxb (e.g., 0x40). The parallel math instruction group 748 performs arithmetic operations in parallel across data channels. The vector math group 750 includes arithmetic instructions (e.g., dp4) in the form of 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic such as dot product operations on vector operands. The illustrated opcode decode 740 can be used in one embodiment to determine which portion of the graphics core will be used to execute the decoded instructions. For example, some instructions can be designated as systolic instructions to be executed by a systolic array. Other instructions such as ray tracing instructions (not shown) can be routed to a ray tracing core or ray tracing logic within a slice or partition of the execution logic. Graphics Pipeline

[0146] Figure 8 8 is a block diagram of another embodiment of a graphics processor 800. Elements having the same reference numbers (or names) as elements of any other figure herein Figure 8 The elements of may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0147] In some embodiments, graphics processor 800 includes a geometry pipeline 820, a media pipeline 830, a display engine 840, a thread execution logic 850, and a rendering output pipeline 870. In some embodiments, graphics processor 800 is a graphics processor within a multi-core processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writes to one or more control registers (not shown) or via commands, which are issued to graphics processor 800 via ring interconnect 802. In some embodiments, ring interconnect 802 couples graphics processor 800 to other processing components, such as other graphics processors or general-purpose processors. Commands from ring interconnect 802 are interpreted by command stream converter 803, which supplies instructions to various components of geometry pipeline 820 or media pipeline 830.

[0148] In some embodiments, command stream converter 803 directs the operation of vertex fetcher 805, which reads vertex data from memory and executes vertex processing commands provided by command stream converter 803. In some embodiments, vertex fetcher 805 provides vertex data to vertex shader 807, which performs coordinate space transformation and lighting operations on each vertex. In some embodiments, vertex fetcher 805 and vertex shader 807 execute vertex processing instructions by dispatching execution threads to graphics cores 852A-852B via thread dispatcher 831.

[0149] In some embodiments, the graphics cores 852A-852B are arrays of vector processors with instruction sets for performing graphics and media operations. In some embodiments, the graphics cores 852A-852B have an attached L1 cache 851 that is specific to each array or shared between arrays. The cache can be configured as a data cache, an instruction cache, or partitioned into a single cache containing data and instructions in different partitions.

[0150] In some embodiments, the geometry pipeline 820 includes a tessellation component to perform hardware-accelerated tessellation of 3D objects. In some embodiments, a programmable hull shader 811 configures the tessellation operation. A programmable domain shader 817 provides back-end evaluation of the tessellation output. The tessellation 813 operates under the direction of the hull shader 811 and contains dedicated logic to generate a collection of detailed geometric objects based on a coarse geometric model provided as input to the geometry pipeline 820. In some embodiments, if tessellation is not used, the tessellation component (e.g., hull shader 811, tessellation 813, and domain shader 817) can be bypassed. The tessellation component can operate based on data received from the vertex shader 807.

[0151] In some embodiments, the complete geometric object may be processed by the geometry shader 819 via one or more threads dispatched to the graphics core 852A-852B, or may proceed directly to the clipper 829. In some embodiments, the geometry shader operates on the entire geometric object, rather than on vertices or patches of vertices as in previous stages of the graphics pipeline. If tessellation is disabled, the geometry shader 819 receives input from the vertex shader 807. In some embodiments, the geometry shader 819 may be programmed by a geometry shader program to perform geometry tessellation when the tessellation unit is disabled.

[0152] Before rasterization, the clipper 829 processes the vertex data. The clipper 829 can be a programmable clipper or a fixed function clipper with clipping and geometry shader functions. In some embodiments, the rasterizer and depth test component 873 in the rendering output pipeline 870 dispatches a pixel shader to convert the geometric object into a per-pixel representation. In some embodiments, the pixel shader logic is included in the thread execution logic 850. In some embodiments, the application can bypass the rasterizer and depth test component 873 and access the unrasterized vertex data via the stream output unit 823.

[0153] The graphics processor 800 has an interconnect bus, interconnect fabric, or some other interconnect mechanism that allows data and messages to be passed between the main components of the processor. In some embodiments, the graphics core 852A-852B and associated logic units (e.g., L1 cache 851, sampler 854, texture cache 858, etc.) are interconnected via data ports 856 to perform memory accesses and communicate with the rendering output pipeline components of the processor. In some embodiments, the sampler 854, cache 851, 858, and graphics core 852A-852B each have a separate memory access path. In one embodiment, the texture cache 858 can also be configured as a sampler cache.

[0154] In some embodiments, the render output pipeline 870 contains a rasterizer and depth test component 873, which converts vertex-based objects into associated pixel-based representations. In some embodiments, the rasterizer logic includes a windower / masker unit for performing fixed-function triangle and line rasterization. An associated rendering buffer 878 and depth buffer 879 are also available in some embodiments. A pixel operation component 877 performs pixel-based operations on data, although in some instances, pixel operations associated with 2D operations (e.g., bit block image transfers with blending) are performed by the 2D engine 841, or replaced by a display controller 843 using an overlay display plane when displaying. In some embodiments, a shared L3 cache 875 is available to all graphics components, allowing data to be shared without using main system memory.

[0155] In some embodiments, the media pipeline 830 includes a media engine 837 and a video front end 834. In some embodiments, the video front end 834 receives pipeline commands from the command stream converter 803. In some embodiments, the media pipeline 830 includes a separate command stream converter. In some embodiments, the video front end 834 processes the media commands before sending the commands to the media engine 837. In some embodiments, the media engine 837 includes thread spawning functionality to spawn threads for dispatching to the thread execution logic 850 via the thread dispatcher 831.

[0156] In some embodiments, the graphics processor 800 includes a display engine 840. In some embodiments, the display engine 840 is external to the processor 800 and is coupled to the graphics processor via the ring interconnect 802 or some other interconnect bus or fabric. In some embodiments, the display engine 840 includes a 2D engine 841 and a display controller 843. In some embodiments, the display engine 840 contains dedicated logic that can operate independently of the 3D pipeline. In some embodiments, the display controller 843 is coupled to a display device (not shown), which can be a system-integrated display device (such as in a laptop computer), or can be an external display device attached via a display device connector.

[0157] In some embodiments, the geometry pipeline 820 and the media pipeline 830 can be configured to perform operations based on multiple graphics and media programming interfaces, and are not specific to any one application programming interface (application programming interface, API). In some embodiments, the driver software for the graphics processor translates API calls specific to a specific graphics or media library into commands that can be processed by the graphics processor. In some embodiments, support is provided for the Open Graphics Library (OpenGL), the Open Computing Language (OpenCL) and / or the Vulkan graphics and computing APIs all from the Khronos Group. In some embodiments, support can also be provided for the Direct3D library from Microsoft. In some embodiments, a combination of these libraries can be supported. Support can also be provided for the Open Source Computer Vision Library (OpenCV). If a mapping from the pipeline of a future API to the pipeline of a graphics processor can be performed, a future API with a compatible 3D pipeline will also be supported. Graphics pipeline programming

[0158] Fig.9A is a block diagram illustrating a graphics processor command format 900 that may be used to program a graphics processing pipeline in accordance with some embodiments. Fig. 9B is a block diagram illustrating a graphics processor command sequence 910 according to an embodiment. Fig.9A The solid-line boxes in illustrate components that are generally included in the graphics command, while the dashed lines include components that are optional or included in a subset of the graphics commands. Fig.9A The example graphics processor command format 900 includes a data field to identify the client of the command 902, a command operation code (opcode) 904, and a data field 906. Some commands also include a sub-opcode 905 and a command size 908.

[0159] In some embodiments, client 902 specifies the client unit of the graphics device that processes the command data. In some embodiments, the graphics processor command parser checks the client field of each command to adjust the further processing of the command, and routes the command data to the appropriate client unit. In some embodiments, the graphics processor client unit includes a memory interface unit, a rendering unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline for processing commands. Once the command is received by the client unit, the client unit reads the opcode 904 and the sub-opcode 905 (if the sub-opcode 905 exists) to determine the operation to be performed. The client unit uses the information in the data field 906 to execute the command. For some commands, an explicit command size 908 is expected to specify the size of the command. In some embodiments, the command parser automatically determines the size of at least some of the commands in the command based on the command opcode. In some embodiments, the command is aligned via multiples of double words. Other command formats can be used.

[0160] Fig. 9B The flowchart in 910 illustrates an example graphics processor command sequence 910. In some embodiments, software or firmware of a data processing system featuring an embodiment of a graphics processor uses a version of the command sequence shown to set up, execute, and terminate a set of graphics operations. The sample command sequence is shown and described for purposes of example, as embodiments are not limited to these particular commands or this command sequence. Additionally, commands may be issued as batches of commands in a command sequence so that the graphics processor will process the sequence of commands at least partially concurrently.

[0161] In some embodiments, the graphics processor command sequence 910 may begin with a pipeline flush command 912 to cause any active graphics pipeline to complete the currently pending commands for that pipeline. In some embodiments, the 3D pipeline 922 and the media pipeline 924 are not operating concurrently. The pipeline flush is performed to cause the active graphics pipeline to complete any pending commands. In response to the pipeline flush, the command parser for the graphics processor will suspend command processing until the active drawing engine completes pending operations and the associated read cache is invalidated. Optionally, any data in the rendering cache marked as "dirty" may be flushed to memory. In some embodiments, the pipeline flush command 912 may be used for pipeline synchronization, or used before placing the graphics processor in a low power state.

[0162] In some embodiments, when a command sequence explicitly switches between pipelines using the graphics processor, the pipeline select command 913 is used. In some embodiments, the pipeline select command 913 is utilized once within the execution context before issuing pipeline commands unless the context will issue commands for both pipelines. In some embodiments, the pipeline flush command 912 is utilized before a pipeline switch via the pipeline select command 913.

[0163] In some embodiments, pipeline control commands 914 configure the graphics pipeline for operation and are used to program 3D pipeline 922 and media pipeline 924. In some embodiments, pipeline control commands 914 configure pipeline states for active pipelines. In one embodiment, pipeline control commands 914 are used for pipeline synchronization and to clear data from one or more cache memories within active pipelines before processing a batch of commands.

[0164] In some embodiments, commands associated with return buffer state 916 are used to configure a set of return buffers for a corresponding pipeline to write data. Some pipeline operations utilize allocation, selection, or configuration of one or more return buffers into which these operations write intermediate data during processing. In some embodiments, the graphics processor also uses one or more return buffers to store output data and perform cross-thread communication. In some embodiments, return buffer state 916 includes selecting the size and number of return buffers to be used for a set of pipeline operations.

[0165] The remaining commands in the command sequence differ based on the active pipeline for the operation.Based on the pipeline determination 920 , the command sequence is tailored to either the 3D pipeline 922 starting at the 3D pipeline state 930 or the media pipeline 924 starting at the media pipeline state 940 .

[0166] The commands used to configure the 3D pipeline state 930 include 3D state setting commands for the vertex buffer state, vertex element state, constant color state, depth buffer state, and other state variables to be configured before processing 3D primitive commands. The values ​​of these commands are determined based at least in part on the specific 3D API in use. In some embodiments, the 3D pipeline state 930 commands can also selectively disable or bypass certain pipeline elements if those elements will not be used.

[0167] In some embodiments, the 3D primitive 932 command is used to submit the 3D primitive to be processed by the 3D pipeline. The command and associated parameters passed to the graphics processor via the 3D primitive 932 command are forwarded to the vertex acquisition function in the graphics pipeline. The vertex acquisition function uses the 3D primitive 932 command data to generate a vertex data structure. The vertex data structure is stored in one or more return buffers. In some embodiments, the 3D primitive 932 command is used to perform vertex operations on the 3D primitive via a vertex shader. In order to process the vertex shader, the 3D pipeline 922 dispatches the shader program to the graphics core.

[0168] In some embodiments, the 3D pipeline 922 is triggered via an execution 934 command or event. In some embodiments, a register write triggers the command execution. In some embodiments, the execution is triggered via a "go" or "kick" command in a command sequence. In one embodiment, the command execution is triggered using a pipeline synchronization command that flushes the command sequence through the graphics pipeline. The 3D pipeline will perform geometry processing for 3D primitives. Once the operation is completed, the resulting geometric object is rasterized, and the pixel engine colors the resulting pixels. For those operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0169] In some embodiments, when performing media operations, the graphics processor command sequence 910 follows the media pipeline 924 path. In general, the specific use and mode of programming for the media pipeline 924 depends on the media or computing operations to be performed. Specific media decoding operations can be offloaded to the media pipeline during media decoding. In some embodiments, the media pipeline can also be bypassed, and the resources provided by one or more general processing cores can be used to perform media decoding in whole or in part. In one embodiment, the media pipeline also includes elements for general purpose graphics processor unit (GPGPU) operations, wherein the graphics processor is used to perform SIMD vector operations using a compute shader program that is not explicitly related to the rendering of graphics primitives.

[0170] In some embodiments, the media pipeline 924 is configured in a similar manner to the 3D pipeline 922. A set of commands to configure the media pipeline state 940 is dispatched or placed in a command queue before the media object commands 942. In some embodiments, the commands for the media pipeline state 940 contain data to configure the media pipeline elements that will be used to process the media objects. This includes data to configure the video decoding and video encoding logic within the media pipeline, such as encoding and decoding formats. In some embodiments, the commands for the media pipeline state 940 also support the use of one or more pointers to an "indirect" state element that contains a batch of state settings.

[0171] In some embodiments, media object commands 942 supply pointers to media objects for processing by the media pipeline. The media object includes a memory buffer that contains video data to be processed. In some embodiments, all media pipeline states should be valid before issuing media object commands 942. Once the pipeline states are configured and the media object commands 942 are queued, the media pipeline 924 is triggered via an execute command 944 or an equivalent execute event (e.g., a register write). The output from the media pipeline 924 can then be post-processed by operations provided by the 3D pipeline 922 or the media pipeline 924. In some embodiments, GPGPU operations are configured and executed in a manner similar to media operations. Graphics Software Architecture

[0172] Fig.10 An example graphics software architecture for data processing system 1000 is illustrated in accordance with some embodiments. In some embodiments, the software architecture includes 3D graphics application 1010, operating system 1020, and at least one processor 1030. In some embodiments, processor 1030 includes graphics processor 1032 and one or more general purpose processor cores 1034. Graphics application 1010 and operating system 1020 each execute in system memory 1050 of the data processing system.

[0173] In some embodiments, the 3D graphics application 1010 contains one or more shader programs, which contain shader instructions 1012. The shader language instructions can be in a high-level shader language, such as Direct3D's High-Level Shader Language (HLSL), OpenGL Shader Language (GLSL), etc. The application also contains executable instructions 1014 in a machine language suitable for execution by the general-purpose processor core 1034. The application also contains graphics objects 1016 defined by vertex data.

[0174] In some embodiments, operating system 1020 is from Microsoft Corporation Operating system, proprietary UNIX-like operating system or open source UNIX-like operating system using a variant of the Linux kernel. Operating system 1020 can support graphics API 1022, such as Direct3D API, OpenGL API or Vulkan API. When Direct3D API is in use, operating system 1020 uses front-end shader compiler 1024 to compile any shader instruction 1012 using HLSL into a lower-level shader language. Compilation can be just-in-time (JIT) compilation or the application can perform shader precompilation. In some embodiments, high-level shaders are compiled into low-level shaders during the compilation of 3D graphics application 1010. In some embodiments, shader instructions 1012 are provided in an intermediate form (such as a version of the Standard Portable Intermediate Representation (SPIR) used by Vulkan API).

[0175] In some embodiments, the user mode graphics driver 1026 contains a backend shader compiler 1027 for converting shader instructions 1012 into hardware specific representations. When the OpenGL API is in use, the shader instructions 1012 in the GLSL high level language are passed to the user mode graphics driver 1026 for compilation. In some embodiments, the user mode graphics driver 1026 uses the operating system kernel mode functions 1028 to communicate with the kernel mode graphics driver 1029. In some embodiments, the kernel mode graphics driver 1029 communicates with the graphics processor 1032 to dispatch commands and instructions. IP Core Implementation

[0176] One or more aspects of at least one embodiment may be implemented by representative code stored on a machine-readable medium, which represents and / or defines logic within an integrated circuit such as a processor. For example, a machine-readable medium may contain instructions representing various logic within a processor. When read by a machine, the instructions may cause the machine to make logic to perform the techniques described herein. Such representations, referred to as "IP cores," are reusable units of logic for an integrated circuit that may be stored on a tangible machine-readable medium as a hardware model describing the organization of the integrated circuit. The hardware model may be supplied to various customers or manufacturing facilities, which load the hardware model on a manufacturing machine that manufactures the integrated circuit. The integrated circuit may be manufactured so that the circuit performs the described operations associated with any of the embodiments described herein.

[0177] Fig.11A1 is a block diagram of an IP core development system 1100 that can be used to manufacture an integrated circuit to perform operations according to an embodiment. The IP core development system 1100 can be used to generate modular, reusable designs that can be incorporated into a larger design or used to construct an entire integrated circuit (e.g., a SOC integrated circuit). The design facility 1130 can generate a software simulation 1110 of an IP core design using a high-level programming language (e.g., C / C++). The software simulation 1110 can be used to design, test, and verify the behavior of the IP core using a simulation model 1112. The simulation model 1112 can include functional simulation, behavioral simulation, and / or timing simulation. A register transfer level (RTL) design 1115 can then be created or synthesized from the simulation model 1112. The RTL design 1115 is an abstraction of the behavior of an integrated circuit that models the flow of digital signals between hardware registers, including associated logic executed using the modeled digital signals. In addition to the RTL design 1115, a lower level design at a logic level or transistor level can also be created, designed, or synthesized. Therefore, the specific details of the initial design and simulation can vary.

[0178] The RTL design 1115 or equivalent may be further synthesized by the design facility into a hardware model 1120, which may be in a hardware description language (HDL) or some other representation of physical design data. The HDL may be further simulated or tested to verify the IP core design. The IP core design may be stored using a non-volatile memory 1140 (e.g., a hard disk, flash memory, or any non-volatile storage medium) for delivery to a third-party fabrication facility 1165. Alternatively, the IP core design may be transmitted via a wired connection 1150 or a wireless connection 1160 (e.g., via the Internet). The fabrication facility 1165 may then fabricate an integrated circuit based at least in part on the IP core design. The fabricated integrated circuit may be configured to perform operations according to at least one embodiment described herein.

[0179] Fig. 11BA cross-sectional side view of an integrated circuit package assembly 1170 according to some embodiments described herein is illustrated. The integrated circuit package assembly 1170 illustrates an implementation of one or more processors or accelerator devices as described herein. The package assembly 1170 includes a plurality of hardware logic units 1172, 1174 connected to a substrate 1180. The logic 1172, 1174 may be implemented at least in part in configurable logic or fixed functionality logic hardware, and may include one or more portions of any of the (one or more) processor cores, (one or more) graphics processors, or other accelerator devices described herein. Each unit of logic 1172, 1174 may be implemented within a semiconductor die and coupled to the substrate 1180 via an interconnect structure 1173. The interconnect structure 1173 may be configured to route electrical signals between the logic 1172, 1174 and the substrate 1180, and may include interconnects such as, but not limited to, bumps or pillars. In some embodiments, the interconnect structure 1173 can be configured to route electrical signals, such as, for example, input / output (I / O) signals and / or power or ground signals associated with the operation of the logic 1172, 1174. In some embodiments, the substrate 1180 is an epoxy-based laminate substrate. In other embodiments, the substrate 1180 can include other suitable types of substrates. The package assembly 1170 can be connected to other electrical devices via the package interconnect 1183. The package interconnect 1183 can be coupled to the surface of the substrate 1180 to route electrical signals to other electrical devices, such as a motherboard, other chipsets, or multi-chip modules.

[0180] In some embodiments, the logic units 1172, 1174 are electrically coupled to a bridge 1182, which is configured to route electrical signals between the logic units 1172, 1174. The bridge 1182 can be a dense interconnect structure that provides routing for electrical signals. The bridge 1182 can include a bridge substrate composed of glass or a suitable semiconductor material. Circuit routing features can be formed on the bridge substrate to provide chip-to-chip connections between the logic units 1172, 1174.

[0181] Although two logic cells 1172, 1174 and bridge 1182 are illustrated, the embodiments described herein may include more or fewer logic cells on one or more dies. Since bridge 1182 may be excluded when logic is included on a single die, the one or more dies may be connected by zero or more bridges. Alternatively, multiple dies or logic cells may be connected by one or more bridges. In addition, multiple logic cells, dies, and bridges may be connected together in other possible configurations, including three-dimensional configurations.

[0182] Fig. 11CA package assembly 1190 including multiple hardware logic chiplet units connected to a substrate 1180 is illustrated. Graphics processing units, parallel processors, and / or computing accelerators as described herein can be composed of a variety of silicon chiplets manufactured separately. A variety of collections of chiplets with different IP core logic can be assembled into a single device. In addition, active interposer technology can be used to integrate chiplets into a base die or base chiplet. The concepts described herein enable interconnection and communication between different forms of IP within a GPU. IP cores can be manufactured using different process technologies and constructed during manufacturing, which avoids the complexity of bringing multiple IPs (especially on large SoCs with several flavors of IP) together in the same manufacturing process. The ability to use multiple process technologies improves the time to market and provides a cost-effective way to create multiple product SKUs. In addition, disaggregated IPs are more easily independently power-gated, and components that are not in use on a given workload can be powered off, thereby reducing overall power consumption.

[0183] In various embodiments, the packaging assembly 1190 may include components and chiplets interconnected by the fabric 1185 and / or one or more bridges 1187. The chiplets within the packaging assembly 1190 may have a 2.5D arrangement using chip-on-wafer-on-substrate stacking, where multiple dies are stacked side by side on a silicon interposer 1189 that couples the chiplets to the substrate 1180. The substrate 1180 includes electrical connections to the packaging interconnects 1183. In one embodiment, the silicon interposer 1189 is a passive interposer that includes through-silicon vias (TSVs) to electrically couple the chiplets within the packaging assembly 1190 to the substrate 1180. In one embodiment, the silicon interposer 1189 is an active interposer that includes embedded logic in addition to the TSVs. In such embodiments, the chiplets within the packaging assembly 1190 are arranged on top of the active interposer 1189 using 3D face-to-face die stacking. In addition to the interconnect fabric 1185 and silicon bridge 1187, the active interposer 1189 may also contain cache memory 1192, hardware logic for I / O 1191, and other hardware logic 1193. The fabric 1185 enables communication between the various logic chiplets 1172, 1174 and the logic 1191, 1193 within the active interposer 1189. The fabric 1185 may be a NoC interconnect or another form of packet switching fabric that exchanges data packets between components of the package assembly. For complex assemblies, the fabric 1185 may be a dedicated chiplet that enables communication between the various hardware logic of the package assembly 1190.

[0184] A bridge fabric 1187 within the active interposer 1189 may be used to facilitate point-to-point interconnections between, for example, a logic or I / O chiplet 1174 and a memory chiplet 1175. In some implementations, the bridge fabric 1187 may also be embedded within the substrate 1180. The hardware logic chiplet may include a dedicated hardware logic chiplet 1172, a logic or I / O chiplet 1174, and / or a memory chiplet 1175. The hardware logic chiplet 1172 and the logic or I / O chiplet 1174 may be implemented at least in part in configurable logic or fixed functionality logic hardware and may include one or more portions of any of the processor core(s), graphics processor(s), parallel processors, or other accelerator devices described herein. The memory chiplet 1175 may be a DRAM (e.g., GDDR, HBM) memory or a cache (SRAM) memory. The cache memory 1192 within the active interposer 1189 (or substrate 1180 ) may function as a global cache for the package assembly 1190 , as part of a distributed global cache, or as a dedicated cache for the fabric 1185 .

[0185] Each chiplet can be fabricated as a separate semiconductor die and coupled to a base die embedded within or coupled to a substrate 1180. Coupling to the substrate 1180 can be performed via an interconnect structure 1173. The interconnect structure 1173 can be configured to route electrical signals between the various chiplets and logic within the substrate 1180. The interconnect structure 1173 can include interconnects such as, but not limited to, bumps or pillars. In some embodiments, the interconnect structure 1173 can be configured to route electrical signals such as, for example, input / output (I / O) signals and / or power or ground signals associated with the operation of the logic, I / O, and memory chiplets. In one embodiment, an additional interconnect structure couples the active interposer 1189 to the substrate 1180.

[0186] In some embodiments, substrate 1180 is an epoxy-based laminate substrate. In other embodiments, substrate 1180 may include other suitable types of substrates. Package assembly 1190 may be connected to other electrical devices via package interconnect 1183. Package interconnect 1183 may be coupled to the surface of substrate 1180 to route electrical signals to other electrical devices, such as a motherboard, other chipsets, or multi-chip modules.

[0187] In some embodiments, the logic or I / O chiplet 1174 and the memory chiplet 1175 can be electrically coupled via a bridge 1187, which is configured to route electrical signals between the logic or I / O chiplet 1174 and the memory chiplet 1175. Bridge 1187 can be a dense interconnect structure that provides routing for electrical signals. Bridge 1187 can include a bridge substrate composed of glass or a suitable semiconductor material. Circuit routing features can be formed on the bridge substrate to provide chip-to-chip connections between the logic or I / O chiplet 1174 and the memory chiplet 1175. Bridge 1187 can also be referred to as a silicon bridge or an interconnect bridge. For example, in some embodiments, bridge 1187 is an embedded multi-die interconnect bridge (Embedded Multi-die Interconnect Bridge, EMIB). In some embodiments, bridge 1187 can be simply a direct connection from one chiplet to another chiplet.

[0188] Fig.11D A package assembly 1194 including interchangeable chiplets 1195 according to an embodiment is illustrated. Interchangeable chiplets 1195 can be assembled into standardized slots on one or more base chiplets 1196, 1198. The base chiplets 1196, 1198 can be coupled via a bridge interconnect 1197, which can be similar to other bridge interconnects described herein and can be, for example, EMIB. The memory chiplets can also be connected to the logic or I / O chiplets via the bridge interconnect. The I / O and logic chiplets can communicate via an interconnect fabric. The base chiplets can each support one or more slots in a standardized format for one of logic or I / O or memory / cache.

[0189] In one embodiment, SRAM and power delivery circuits may be fabricated into one or more of the base chiplets 1196, 1198, which may be fabricated using a different process technology relative to the interchangeable chiplets 1195 stacked on top of the base chiplets. For example, the base chiplets 1196, 1198 may be fabricated using a larger process technology, while the interchangeable chiplets may be fabricated using a smaller process technology. One or more of the interchangeable chiplets 1195 may be memory (e.g., DRAM) chiplets. Different memory densities may be selected for the package assembly 1194 based on power and / or performance as a target for the product using the package assembly 1194. Additionally, logic chiplets with different numbers of types of functional units may be selected at assembly time based on power and / or performance as a target for the product. Additionally, chiplets containing different types of IP logic cores may be inserted into the interchangeable chiplet slots, thereby enabling a hybrid processor design that can mix and match different technology IP blocks. Example System-on-Chip Integrated Circuit

[0190] Figure 12-13B An example integrated circuit and associated graphics processor that can be fabricated using one or more IP cores according to various embodiments described herein are illustrated. In addition to what is illustrated, other logic and circuits may also be included, including additional graphics processors / cores, peripheral interface controllers, or general purpose processor cores.

[0191] Fig.12 1 is a block diagram illustrating an example system-on-chip integrated circuit 1200 that may be fabricated using one or more IP cores according to an embodiment. The example integrated circuit 1200 includes one or more application processors 1205 (e.g., CPUs), at least one graphics processor 1210, and may additionally include an image processor 1215 and / or a video processor 1220, any of which may be modular IP cores from the same or multiple different design facilities. The integrated circuit 1200 includes peripherals or bus logic that includes a USB controller 1225, a UART controller 1230, a SPI / SDIO controller 1235, and an I2S / I2C controller 1240. In addition, the integrated circuit may include a display device 1245 coupled to one or more of a high-definition multimedia interface (HDMI) controller 1250 and a mobile industry processor interface (MIPI) display interface 1255. Storage may be provided by a flash memory subsystem 1260 that includes flash memory and a flash memory controller. A memory interface may be provided via a memory controller 1265 for accessing SDRAM or SRAM memory devices. Some integrated circuits additionally include an embedded security engine 1270 .

[0192] Figure 13A-13B is a block diagram illustrating an example graphics processor for use within a SoC according to embodiments described herein. Fig.13A An example graphics processor 1310 of a system-on-chip integrated circuit that may be fabricated using one or more IP cores in accordance with an embodiment is illustrated. Fig. 13B An additional example graphics processor 1340 is illustrated that may be fabricated using one or more IP cores of a system-on-chip integrated circuit in accordance with an embodiment. Fig.13A Graphics processor 1310 is an example of a low-power graphics processor core. Fig. 13B The graphics processor 1340 of FIG. 1310 is an example of a higher performance graphics processor core. Each of the graphics processors in the graphics processor 1310 and the graphics processor 1340 may be Fig.12A variation of graphics processor 1210 .

[0193] like Fig.13A As shown in , the graphics processor 1310 includes a vertex processor 1305 and one or more fragment processors 1315A-1315N (e.g., 1315A, 1315B, 1315C, 1315D up to 1315N-1 and 1315N). The graphics processor 1310 can execute different shader programs via separate logic, so that the vertex processor 1305 is optimized to perform operations for the vertex shader program, while the one or more fragment processors 1315A-1315N perform fragment (e.g., pixel) shading operations for the fragment or pixel shader program. The vertex processor 1305 performs the vertex processing stage of the 3D graphics pipeline and generates primitives and vertex data. The (one or more) fragment processors 1315A-1315N use the primitives and vertex data generated by the vertex processor 1305 to generate a frame buffer displayed on a display device. In one embodiment, the fragment processor(s) 1315A-1315N are optimized to execute fragment shader programs as provided for the OpenGL API, which can be used to perform similar operations as pixel shader programs as provided for the Direct 3D API.

[0194] The graphics processor 1310 additionally includes one or more memory management units (MMUs) 1320A-1320B, (one or more) caches 1325A-1325B, and (one or more) circuit interconnects 1330A-1330B. The one or more MMUs 1320A-1320B provide virtual address to physical address mapping for the graphics processor 1310 (including for the vertex processor 1305 and / or (one or more) fragment processors 1315A-1315N), which can reference vertex or image / texture data stored in memory in addition to vertex or image / texture data stored in one or more caches 1325A-1325B. In one embodiment, the one or more MMUs 1320A-1320B can be synchronized with other MMUs within the system, including those with Fig.12 One or more MMUs associated with one or more application processors 1205, image processor 1215, and / or video processor 1220 enable each processor 1205-1220 to participate in a shared or unified virtual memory system. According to an embodiment, one or more circuit interconnects 1330A-1330B enable graphics processor 1310 to interface with other IP cores within the SoC via an internal bus of the SoC or via a direct connection.

[0195] like Fig. 13B As shown, graphics processor 1340 includes Fig.13A The graphics processor 1340 includes one or more MMUs 1320A-1320B, (one or more) caches 1325A-1325B, and (one or more) circuit interconnects 1330A-1330B of the graphics processor 1310. The graphics processor 1340 includes one or more shader cores 1355A-1355N (e.g., 1355A, 1355B, 1355C, 1355D, 1355E, 1355F through 1355N-1 and 1355N) that provide a unified shader core architecture in which a single core or a single type of core can execute all types of programmable shader code, including shader program code used to implement vertex shaders, fragment shaders, and / or compute shaders. The unified shader core architecture can also be configured to execute directly compiled high-level GPGPU programs (e.g., CUDA). The exact number of shader cores present can vary between embodiments and implementations. In addition, the graphics processor 1340 includes: an inter-core task manager 1345, which acts as a thread dispatcher for dispatching execution threads to one or more shader cores 1355A-1355N; and a tiling unit 1358 for accelerating tiling operations for tile-based rendering, in which rendering operations for a scene are subdivided in image space, for example to exploit local spatial consistency within a scene or to optimize the use of internal caches. Unblocks the integer pipeline during the math pipeline stage in a graphics environment

[0196] Parallel computing is a type of computing in which many calculations or processes are performed simultaneously. Parallel computing can have many forms, including but not limited to SIMD or SIMT. SIMD describes a computer with multiple processing elements that perform the same operation on multiple data points at the same time. In one example, the accompanying drawings discussed above relate to SIMD and its implementation in EU, FPU and ALU in a general-purpose processor. In a common SIMD machine, data is packaged into registers, each of which contains a channel array. Instructions operate on data found in channel n of a register with data found in the same channel of another register. SIMD machines are advantageous in areas where a single instruction sequence can be applied to a large amount of data at the same time. For example, in one embodiment, a graphics processor (e.g., GPGPU, GPU, etc.) can be used to perform SIMD vector operations using a compute shader program.

[0197] As an alternative to or in addition to using SIMD, various embodiments may also be applicable to using execution by using single instruction multiple threads (SIMT). References to SIMD cores or operations may also be applicable to SIMT or to SIMD together with SIMT. The following description is discussed in terms of SIMD machines. However, the embodiments herein are not limited to applications in the SIMD context, but may be applied to other parallel computing paradigms, such as, for example, SIMT. For ease of discussion and explanation, the following description generally focuses on SIMD implementations. However, the embodiments may be similarly applied to SIMT machines without modifying the described techniques and methods. With respect to SIMT machines, similar patterns as discussed below may be followed to provide instructions to a systolic array and execute the instructions on a SIMT machine. Other types of parallel computing machines may also utilize the embodiments herein.

[0198] Parallel rendering graphics architectures are frequently used to perform matrix multiplication operations. For example, matrix multiplication operations are a large portion of artificial intelligence (AI) / machine learning (ML) workloads. Thus, enhancements to parallel rendering graphics architectures that can reduce power requirements (e.g., dynamic capacitance), increase read and write throughput, and / or reduce bandwidth when performing matrix multiplication operations will provide improved performance of the parallel rendering graphics architecture.

[0199] Implementations herein seek to improve parallel rendering graphics architectures by improving the performance of executing operations such as integer operations and mathematical operations, including addition, subtraction, multiplication, sine, cosine, logarithm, tangent, exponential operations, etc. In some implementations, integer instructions may refer to basic integer operations, including addition, subtraction, multiplication, and mathematical instructions may refer to transcendental mathematical operations, such as sine, cosine, logarithm, and exponential operations, for example. Implementations herein may refer to "extended math" instructions or operations, which may cover both integer instructions / operations and mathematical instructions / operations.

[0200] In some conventional graphics architectures, the integer execution pipeline ("pipeline") (e.g., FPU1) and the math execution pipe share many of the same processing resources, such as the same decoders, the same thread arbiter, and the same address calculations. However, in general, the math pipe may be associated with a lower throughput than the integer execution pipe. For example, in some graphics architectures, dispatching a math instruction from the arbiter to the math execution pipe may take four stages (i.e., 4 cycles), while dispatching an integer instruction from the arbiter to the integer execution pipe may take one stage (i.e., 1 cycle). In this way, a math instruction to the math pipe may generate 3 cycles (e.g., a "bubble") in the arbiter, which may block subsequent instructions to the math execution pipe or the integer execution pipe via the shared resources. For example, if a math instruction is followed by an integer instruction, the integer instruction may be blocked from execution until the math instruction can be fully dispatched, and thus integer pipe utilization is reduced.

[0201] Embodiments solve the above technical problems by providing support for integer pipeline deblocking during a math pipeline stage in a graphics environment. Implementations herein provide hardware support in execution resources of a graphics architecture, which can achieve higher throughput through the integer execution pipeline during a math execution pipeline stage. Implementations herein provide a math instruction temporary buffer data structure to allow multiple stages of temporary storage of source data such as math instruction operand data, so that the integer instruction source data is free to be loaded into the instruction execution pipeline in the next clock of the execution resource.

[0202] Embodiments provide technical advantages of improving the performance of a processor. The discussed approach for implementing a math instruction temporary buffer before a math instruction execution pipeline in an execution resource of a graphics environment can improve computational throughput for integer operations. This results in improved processor performance and efficiency.

[0203] Fig.14 1 is a block diagram illustrating an example integrated circuit graphics processor 1400 having execution resources for providing integer pipeline deblocking during a math pipeline stage in a graphics environment according to an embodiment. In one implementation, the graphics processor 1400 may include a GPGPU or a GPU, such as described herein with respect to Figure 1-13B In one implementation, graphics processor 1400 may include a processing core of a GPGPU or GPU, such as described herein. Figure 1-13B Example graphics cores described herein. Elements having the same or similar names as elements of any other figures herein Fig.14The elements of depict the same elements as in other figures, may operate or function in a manner similar thereto, may include the same components, and may be linked to other entities such as those described elsewhere herein, but are not limited thereto.

[0204] Example graphics processor 1400 may be a variation of graphics processor 108, 208, 1210, or any graphics processor described herein, and may be used in place of any graphics processor described. Example graphics processor 1400 may also be a variation of graphics core 515 described herein, and may be used in place of any graphics core described. Example execution resource 1405 may be a variation of execution unit 600, or any execution unit or processing resource described herein, and may be used in place of any execution resource described. Thus, discussion herein in conjunction with any feature of a graphics processor also discloses corresponding combinations with graphics processor 1400, but is not limited thereto.

[0205] Fig.14 The graphics processor 1400 illustrated in FIG. 1400 may include one or more execution resources 1405. The execution resources 1405 may be compute-optimized processing resources, such as EUs, for example, Figure 3C Execution resource 1405 may also be used in computing engine slices 340A-340D in the embodiment of the present invention, but is not limited thereto. Figure 3B In one implementation, execution resource 1405 may also be associated with graphics engine slices 310A-310D. Figure 5A and Figure 5B The same as the vector engine 502 in .

[0206] Execution resources 1405 may include a thread controller 1410 to manage the execution of threads in execution resources 1405. Execution resources 1405 may additionally include a register file (not shown) that stores registers that may be assigned to hardware threads within execution resources 1405.

[0207] Thread controller 1410 may include instruction fetch 1412 that may receive instructions from multiple threads executing on graphics processor 1400 and pass the instructions to an instruction queue (not shown) corresponding to a particular thread of the instructions, where each thread is associated with a particular instruction queue. Each instruction queue feeds a dedicated decoder, such as but not limited to FPU decode 1420, systolic decode 1422, and extended math decode 1424. Decoders 1420, 1422, 1424 decode instructions for execution by compute resource(s) 1440.

[0208] The decoded instructions are passed to the arbiter 1430 of the execution resource 1405. The arbiter 1430 can generate addresses for accessing data in the memory utilized by the instructions. The arbiter 1430 can receive data from one or more memory banks and dispatch thread instructions and / or data to corresponding computing resources 1440 of the execution resource 1405. The arbiter 1430 can include multiple dedicated GRF read and dispatch units, such as, for example, FPU GRF read / dispatch 1432, systolic GRF read / dispatch 143, and extended math GRF read / dispatch 1436. Each dedicated read / dispatch unit 1432, 1434, 1436 can handle address generation, GRF read control, and instruction dispatch for corresponding types of instructions (e.g., FPU, systolic, extended math, etc.). As previously described, extended math instructions can refer to both math instructions and integer instructions. The arbiter 1430 can then provide the data and decoded instructions to (one or more) computing resources 1440.

[0209] The computing resource(s) 1440 may include a variety of different types of functional units. Figure 2D Graphics execution unit GPGPU 270 Figure 2D The computing units 260A-260N operate similarly. The computing resource(s) 1440 may also be connected to Figure 5B Graphics vector engine 502 Figure 5B The SIMD FPU 534 and / or SIMDALU 535 operate similarly.

[0210] In the implementation herein, the computing resource(s) 1440 may include one or more groups of functional units configured in a pipelined manner to provide an execution pipeline, such as a floating point unit pipeline 1441 (FPU), a SP (Float 32) pipeline 1442, a DP (Float 64) pipeline 1443, a systolic pipeline 1444, an integer (INT) pipeline 1445, and a math pipeline 1446, to name a few examples.

[0211] In one implementation, the FPU0 pipeline 1441 may be capable of performing single precision (SP) floating point (FP32) and / or DP floating point (FP64) operations. The integer 1445 and math pipelines 1446 may be capable of executing all instructions that do not involve any floating point operations. The systolic pipeline 1444 may be capable of performing matrix multiplication operations, such as dot product accumulate systolic (DPAS) operations that include multiple multiply-accumulate operations.

[0212] In the implementation herein, the execution resource 1405 is enhanced to provide for integer pipeline deblocking during the math pipeline stage implemented in the execution resource 1405. The implementation herein provides hardware support in the execution resource 1405 of the graphics architecture, which enables higher throughput through the integer execution pipeline 1445 during the math execution pipeline 1446 stage. The implementation herein provides a math instruction scratch buffer 1450 in the execution resource 1405 to allow for multiple stages of scratch storage of math instruction source data (such as math instruction operand data). Because the integer execution pipeline 1445 and the math execution pipeline 1446 share various resources of the execution resource 1405, such as the extended math decode 1424 and the extended math GRF read / dispatch 1436, the inclusion of the math instruction scratch buffer 1450 before the compute resource(s) 1440 enables the integer instruction source data to be freely loaded into the instruction execution pipeline 1445 in the next clock of the execution resource.

[0213] Figure 15-18 Further details are provided regarding the manner in which enhancements are implemented to provide integer pipeline de-blocking during a math pipeline stage implemented in execution resource 1405.

[0214] Fig.15 1 is a block diagram illustrating a detailed view of an example execution resource 1500 for providing support for integer pipeline deblocking during a math pipeline stage according to implementations herein. In one implementation, the execution resource 1500 may be part of the graphics processor 1400 and may be used in conjunction with the graphics processor 1400. Fig.14 1405. For example, execution resource 1500 may provide a more detailed view of the components of execution resource 1405. Thus, elements having the same or similar names as elements of any other figure in this document are shown in FIG. Fig.15 The elements of depict the same elements as in other figures, may operate or function in a manner similar thereto, may include the same components, and may be linked to other entities such as those described elsewhere herein, but are not limited thereto.

[0215] Fig.15 The execution resources 1500 may include an operation object data buffer 1510, a math instruction temporary buffer 1520, one or more math pipeline arbiters 1530-0, 1530-1, and execution pipelines 1540-1550 (including an integer pipeline 1540 and a math pipeline 1550). In one implementation, the math instruction temporary buffer 1520 and the execution pipeline 1550 are connected to each other. Fig.14 The math instruction temporary buffer 1450 is the same as the integer pipeline 1540. Fig.14 The integer pipeline 1445 is the same as that of Fig.14The integer pipeline 1540 and the execution pipeline 1550 may include hardware resources such as FPU, ALU and / or MAC units. In one implementation, the computational resources of the integer pipeline 1540 and the math pipeline 1550 may be logically partitioned according to the channels and precisions supported.

[0216] As about Fig.14 As discussed, as part of executing instructions (such as math or integer instructions) by an execution resource (such as execution resource 1405 or execution resource 1500), various hardware circuit modules of execution resource 1500 may be used to process the instructions (with respect to Fig.14 In the case of integer and math instructions, these instructions share resources of execution resources 1500, such as decode resources (e.g., Fig.14 For math or integer instructions processed by execution resources 1500, data returned from the GRF can then be read from the arbiter (e.g., Fig.14 The arbiter 1430 of the decoded instruction is provided to the operation object data buffer 1510 together with the decoded instruction. The operation object data buffer 1510 may contain one or more OA FLOPS to store the operation object data of one or more sources of the instruction, such as Src0 operation object data buffer 1512 and Src1 operation object data buffer 1514. The operation on the decoded instruction can then be performed by the corresponding pipeline 1540, 1550.

[0217] In some implementations, the execution resource 1500 circuit module should include a new interface to the operand data buffer 1510 for math pipeline instruction completion. The interface may include a math instruction temporary buffer 1520 and one or more math pipeline arbiters 1530-0, 1530-1 (collectively referred to herein as math pipeline arbiters 1530). The math instruction temporary buffer 1520 may be a data structure capable of storing one or more stages of source data for a math instruction, such as a first in first out (FIFO) queue or other buffer data structure. Storing one or more stages of source operand data for a math instruction in the math instruction temporary buffer allows the operand data buffer to be free to load integer source data in the next clock cycle of the execution resource 1500.

[0218] In some implementations, math pipeline arbiter 1530 provides an optimization to reduce the number of cycles used to load math pipeline 1550 from math instruction scratch buffer 1520. For example, reading from math instruction scratch buffer 1520 may take more than 1 cycle. To hide this extra cycle, when writing to math instruction scratch buffer 1520 (e.g., writing 4 stages of source operand data), the first stage of source operand data may also be fed to math pipeline 1550 while multiple stages are also being loaded into math instruction scratch buffer 1520. Math pipeline arbiter 1530 enables the first stage of source operand data to be fed to math pipeline 1550.

[0219] Fig.16A 1600 is a schematic diagram comparing a hardware baseline 1600 without a math instruction scratch buffer to an updated hardware implementation 1605 with a math instruction scratch buffer according to implementations herein. The baseline 1600 schematically illustrates an arbiter 1610 (such as Fig.14 The math instruction 1612 is issued by the math pipeline 1620 (such as the arbiter 1430) followed by the integer (int) instruction 1614. The math instruction 1612 is sent by the math pipeline 1620 (such as Figure 14-15 1446, 1550) executes in 4 stages over 4 cycles of execution resources, as shown by the four circles in the baseline schematic 1600. However, the integer pipeline 1630 is blocked from executing integer instruction 1614 for three cycles (as shown by the 3 "X's") until the execution of math instruction 1612 is completed as math pipeline 1620. This blocking is due to the shared resources of the math and integer pipelines being occupied by multiple stages of math instruction 1612.

[0220] Updated hardware implementation 1605 illustrates the operation of math pipeline 1620 and integer pipeline 1630 when utilizing math instruction scratch buffers as discussed herein. As shown in the schematic diagram of updated hardware implementation 1605, the arbiter issues math instruction 1612, which causes the source operand data of the math instruction to be loaded into the math instruction scratch buffer (e.g., Figure 14-15 1450, 1520). This allows math pipeline 1620 to execute multiple stages of math instructions in parallel with integer pipeline 1630 executing integer instructions 1614. In this case, integer pipeline 1630 is no longer blocked from executing integer instructions 1614 while waiting for stages of math instruction 1612 to clear shared resources for execution.

[0221] Fig. 16B16 shows a schematic diagram comparing a hardware baseline 1650 without a math instruction scratch buffer to an updated hardware implementation 1660 with a math instruction scratch buffer when multiple math instructions are dispatched before integer instructions according to implementations herein. The baseline 1650 schematically illustrates an arbiter 1610 (such as Fig.14 The arbiter 1430) issues a first math instruction 1612, followed by a second math instruction 1616, followed by an integer (int) instruction 1614.

[0222] Math instructions 1612, 1616 are executed by math pipeline 1620 (such as Figure 14-15 1650) executes in 8 stages over 8 cycles of execution resources, as shown by the eight circles in the baseline schematic 1650. However, the integer pipeline 1630 is blocked from executing integer instruction 1614 for seven cycles (as shown by the seven "Xs") until the execution of the second math instruction 1616 is completed as the math pipeline 1620. This blocking is due to the shared resources of the math and integer pipelines being occupied by multiple stages of math instructions 1612, 1616.

[0223] Updated hardware implementation 1660 illustrates the operation of math pipeline 1620 and integer pipeline 1630 when utilizing math instruction scratch buffers as discussed herein. As shown in the schematic diagram of updated hardware implementation 1605, the arbiter issues first and second math instructions 1612, 1616, which causes the source operand data of the math instructions 1612, 1616 to be loaded into a math instruction scratch buffer (such as Figure 14-15 1450, 1520). This allows the math pipeline 1620 to execute multiple stages of math instructions 1612, 1616 in parallel with the integer pipeline 1630 executing integer instructions 1614. In this case, the integer pipeline 1630 is no longer blocked from executing integer instructions 1614 while waiting for stages of math instructions 1612, 1616 to clear shared resources for execution.

[0224] Fig.17 is a flow chart illustrating an embodiment of a method 1700 for utilizing a scratch buffer for deblocking an integer pipeline during a math pipeline stage in a graphics environment. The method 1700 may be performed by processing logic that may include hardware (e.g., circuit modules, dedicated logic, programmable logic, etc.), software (such as instructions running on a processing device), or a combination thereof. For simplicity and clarity in presentation, the processes of the method 1700 are illustrated in a linear sequence; however, it is contemplated that any number of the processes may be performed in parallel, asynchronously, or in a different order. Additionally, for simplicity, clarity, and ease of understanding, reference to Figure 1-Figure 1Many of the components and processes described in 6 may not be repeated or discussed below. In one implementation, a processor (such as Fig.14 GPU 1400 or Fig.15 The execution resource 1500) can execute the method 1700.

[0225] Method 1700 begins at processing block 1710, where a processor may determine that a math execution pipeline of an execution resource is not available to load math operand data for a math instruction executed by the execution resource. In one implementation, the math operand data is received from a thread arbiter of the execution resource. In implementations herein, an integer execution pipeline of the execution resource and a math execution pipeline of the execution resource may share a thread arbiter. Then, at block 1720, in response to the math execution pipeline being unavailable, the processor may load the math operand data for the math instruction into a math instruction temporary buffer.

[0226] Subsequently, at block 1730, the processor may load integer operand data for the integer instruction into the integer execution pipeline. In one implementation, the integer operand data is received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer. Finally, at block 1740, in response to the math execution pipeline becoming available, the processor may load the math operand data from the math instruction scratch buffer into the math execution pipeline.

[0227] Fig.18 is a flow chart illustrating an embodiment of a method 1800 for utilizing the loading of staged operand data for deblocking an integer pipeline during a math pipeline stage in a graphics environment. The method 1800 may be performed by processing logic that may include hardware (e.g., circuit modules, dedicated logic, programmable logic, etc.), software (such as instructions running on a processing device), or a combination thereof. For simplicity and clarity in presentation, the processes of the method 1800 are shown in a linear sequence; however, it is contemplated that any number of the processes may be performed in parallel, asynchronously, or in a different order. Additionally, for simplicity, clarity, and ease of understanding, reference to Figure 1-Figure 17 Many of the components and processes described may not be repeated or discussed below. In one implementation, a processor (such as Fig.14 GPU 1400 or Fig.15 The execution resource 1500) can execute the method 1800.

[0228] Method 1800 begins at processing block 1810, where a processor may load a first stage of a plurality of stages of math operand data into a math execution pipeline of an execution resource. In one implementation, the math operand data is for a math instruction executed by the execution resource and is received from a thread arbiter of the execution resource. In some implementations, the integer execution pipeline of the execution resource and the math execution pipeline of the execution resource share a thread arbiter. Then, at block 1820, the processor may load the first stage of the math operand data and the remaining stages of the plurality of stages of the math operand data into a math instruction temporary buffer concurrently with loading the first stage into the math execution pipeline.

[0229] Subsequently, at block 1830, the processor may load integer operand data for the integer instruction into the integer execution pipeline. In one implementation, the integer operand data is received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer. Finally, at block 1840, in response to the math execution pipeline becoming available, the processor may load the remaining stages of the math operand data from the math instruction scratch buffer into the math execution pipeline.

[0230] The following examples relate to further embodiments. Example 1 is a device for facilitating deblocking an integer pipeline during a math pipeline stage in a graphics environment. The device of Example 1 includes a processor, the processor comprising: a processing core having at least one execution resource, including: a thread arbiter; a plurality of execution pipeline hardware circuit modules, the plurality of execution pipeline hardware circuit modules including a math execution pipeline and an integer execution pipeline for sharing resources of the thread arbiter; an arbitration hardware circuit module, the arbitration hardware circuit module for determining whether the math execution pipeline is available to load math operand data of a math instruction, the math operand data being received from the thread arbiter; and a math instruction temporary buffer, the math instruction temporary buffer for storing the math operand data in response to the math execution pipeline being unavailable; wherein the integer execution pipeline is to receive integer operand data of an integer instruction, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction temporary buffer; and wherein the math execution pipeline is to receive the math operand data from the math instruction temporary buffer in response to the math execution pipeline becoming available.

[0231] In Example 2, the subject matter of Example 1 may optionally include, wherein the math instruction scratch buffer comprises a first-in-first-out (FIFO) queue data structure. In Example 3, the subject matter of any of Examples 1-2 may optionally include, wherein the math instruction scratch buffer is configured to store math operand data for more than one math instruction. In Example 4, the subject matter of any of Examples 1-3 may optionally include, wherein the math operand data comprises a plurality of stages of math operand data, and wherein the arbitration hardware circuit module is to load a first stage of the plurality of stages of the math operand data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operand data into the math instruction scratch buffer.

[0232] In Example 5, the subject matter of any one of Examples 1-4 may optionally include, wherein the math instruction scratch buffer is to store the math operand data to enable the thread arbiter to continue loading the integer operand data into the integer execution pipeline. In Example 6, the subject matter of any one of Examples 1-5 may optionally include, wherein the math instruction performs an operation, the operation comprising at least one of the following operations: a sine operation, a cosine operation, a logarithm operation, a tangent operation, or an exponential operation.

[0233] In Example 7, the subject matter of any one of Examples 1-6 may optionally include, wherein the integer execution pipeline and the math execution pipeline include an arithmetic logic unit (ALU), and the arithmetic logic unit (ALU) includes a plurality of adders and shifters. In Example 8, the subject matter of any one of Examples 1-7 may optionally include, wherein the processor includes a graphics processing unit (GPU). In Example 9, the subject matter of any one of Examples 1-8 may optionally include, wherein the processor is at least one of a single instruction multiple data (SIMD) machine or a single instruction multiple thread (SIMT) machine.

[0234] Example 10 is a method for facilitating deblocking an integer pipeline during a math pipeline stage in a graphics environment. The method of Example 10 may include: determining, by an execution resource of a processor core of a graphics processor, that a math execution pipeline of the execution resource is unavailable to load math operand data of a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein the integer execution pipeline of the execution resource and the math execution pipeline of the execution resource share the thread arbiter; in response to the math execution pipeline being unavailable, loading the math operand data of the math instruction into a math instruction scratch buffer; loading integer operand data of integer instructions into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; and in response to the math execution pipeline becoming available, loading the math operand data from the math instruction scratch buffer into the math execution pipeline.

[0235] In Example 11, the subject matter of Example 10 can optionally include, wherein the math instruction scratch buffer comprises a first-in-first-out (FIFO) queue data structure. In Example 12, the subject matter of Examples 10-11 can optionally include, wherein the math instruction scratch buffer is configured to store math operand data for more than one math instruction.

[0236] In Example 13, the subject matter of Examples 10-12 may optionally include, wherein the math operand data includes a plurality of stages of math operand data, and wherein the thread arbiter is to load a first stage of the plurality of stages of the math operand data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operand data into the math instruction scratch buffer. In Example 14, the subject matter of Examples 10-13 may optionally include, wherein the math instruction scratch buffer is to store the math operand data so that the thread arbiter can continue to load the integer operand data into the integer execution pipeline. In Example 15, the subject matter of Examples 10-14 may optionally include, wherein the math instruction performs an operation, the operation including at least one of the following operations: a sine operation, a cosine operation, a logarithm operation, a tangent operation, or an exponential operation.

[0237] Example 16 is a non-transitory computer-readable storage medium for facilitating deblocking an integer pipeline during a math pipeline stage in a graphics environment. The non-transitory computer-readable storage medium of Example 16 has instructions stored thereon, which, when executed by one or more processors, cause the processors to: determine, by an execution resource of a processor core of the one or more processors, that a math execution pipeline of the execution resource is unavailable to load math operand data of a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein the integer execution pipeline of the execution resource and the math execution pipeline of the execution resource share the thread arbiter; in response to the math execution pipeline being unavailable, load the math operand data of the math instruction into a math instruction scratch buffer; load integer operand data of an integer instruction into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; and in response to the math execution pipeline becoming available, load the math operand data from the math instruction scratch buffer into the math execution pipeline.

[0238] In Example 17, the subject matter of Example 16 can optionally include, wherein the math instruction scratch buffer comprises a first-in-first-out (FIFO) queue data structure. In Example 18, the subject matter of Examples 16-17 can optionally include, wherein the math instruction scratch buffer is configured to store math operand data for more than one math instruction.

[0239] In Example 19, the subject matter of Examples 16-18 may optionally include, wherein the math operand data includes a plurality of stages of math operand data, and wherein the thread arbiter is to load a first stage of the plurality of stages of the math operand data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operand data into the math instruction scratch buffer. In Example 20, the subject matter of Examples 16-19 may optionally include, wherein the math instruction scratch buffer is to store the math operand data to enable the thread arbiter to continue loading the integer operand data into the integer execution pipeline.

[0240] Example 21 is a system for facilitating integer pipeline deblocking during a math pipeline stage in a graphics environment. The system of Example 21 may optionally include a memory; and a processing core communicatively coupled to the memory, the processing core having at least one execution resource, including: a thread arbiter; a plurality of execution pipeline hardware circuit modules, the plurality of execution pipeline hardware circuit modules including a math execution pipeline and an integer execution pipeline for sharing resources of the thread arbiter; an arbitration hardware circuit module, the arbitration hardware circuit module for determining whether the math execution pipeline is available to load math operand data of a math instruction, the math operand data being received from the thread arbiter; and a math instruction temporary buffer, the math instruction temporary buffer for storing the math operand data in response to the math execution pipeline being unavailable; wherein the integer execution pipeline is to receive integer operand data of an integer instruction, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction temporary buffer; and wherein the math execution pipeline is to receive the math operand data from the math instruction temporary buffer in response to the math execution pipeline becoming available.

[0241] In Example 22, the subject matter of Example 21 may optionally include, wherein the math instruction scratch buffer comprises a first-in-first-out (FIFO) queue data structure. In Example 23, the subject matter of any of Examples 21-22 may optionally include, wherein the math instruction scratch buffer is configured to store math operand data for more than one math instruction. In Example 24, the subject matter of any of Examples 21-23 may optionally include, wherein the math operand data comprises a plurality of stages of math operand data, and wherein the arbitration hardware circuit module is to load a first stage of the plurality of stages of the math operand data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operand data into the math instruction scratch buffer.

[0242] In Example 25, the subject matter of any one of Examples 21-24 may optionally include, wherein the math instruction scratch buffer is to store the math operand data to enable the thread arbiter to continue loading the integer operand data into the integer execution pipeline. In Example 26, the subject matter of any one of Examples 21-25 may optionally include, wherein the math instruction performs an operation, the operation comprising at least one of the following operations: a sine operation, a cosine operation, a logarithm operation, a tangent operation, or an exponential operation.

[0243] In Example 27, the subject matter of any one of Examples 21-26 may optionally include, wherein the integer execution pipeline and the math execution pipeline include an arithmetic logic unit (ALU), and the arithmetic logic unit (ALU) includes a plurality of adders and shifters. In Example 28, the subject matter of any one of Examples 21-27 may optionally include, wherein the processor includes a graphics processing unit (GPU). In Example 29, the subject matter of any one of Examples 21-28 may optionally include, wherein the processor is at least one of a single instruction multiple data (SIMD) machine or a single instruction multiple thread (SIMT) machine.

[0244] Example 30 is a device for facilitating deblocking an integer pipeline during a math pipeline stage in a graphics environment, comprising the following components: a component for determining, using an execution resource of a processor core of a graphics processor, that a math execution pipeline of the execution resource is unavailable to load math operand data of a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein the integer execution pipeline of the execution resource and the math execution pipeline of the execution resource share the thread arbiter; a component for loading the math operand data of the math instruction into a math instruction scratch buffer in response to the math execution pipeline being unavailable; a component for loading integer operand data of integer instructions into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; and a component for loading the math operand data from the math instruction scratch buffer into the math execution pipeline in response to the math execution pipeline becoming available. In Example 31, the subject matter of Example 30 may optionally include an apparatus further configured to perform the method of any one of Examples 11 to 15.

[0245] Example 32 is at least one machine-readable medium comprising a plurality of instructions, which in response to being executed on a computing device, cause the computing device to perform a method according to any of Examples 10-15. Example 33 is an apparatus for facilitating integer pipeline deblocking during a math pipeline stage in a graphics environment, configured to perform a method as described in any of Examples 10-15. Example 34 is an apparatus for facilitating integer pipeline deblocking during a math pipeline stage in a graphics environment, comprising components for performing a method as described in any of Examples 10-15. The specific details in the examples may be used anywhere in one or more embodiments.

[0246] The foregoing description and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be appreciated by those skilled in the art that various modifications and changes may be made to the embodiments described herein without departing from the broader spirit and scope of the features set forth in the appended claims. The present disclosure thus provides the following technical solutions: Technical solution 1. A processor, comprising: A processing core having at least one execution resource including: Thread arbiter; A plurality of execution pipeline hardware circuit modules, wherein the plurality of execution pipeline hardware circuit modules include a math execution pipeline and an integer execution pipeline for sharing resources of the thread arbiter; an arbitration hardware circuit module, the arbitration hardware circuit module being used to determine whether the math execution pipeline is available to load math operand data of a math instruction, the math operand data being received from the thread arbiter; and a math instruction temporary storage buffer, the math instruction temporary storage buffer being used to store the math operation object data in response to the math execution pipeline being unavailable; wherein the integer execution pipeline is to receive integer operand data of an integer instruction, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction temporary buffer; and The math execution pipeline is to receive the math operation object data from the math instruction temporary buffer in response to the math execution pipeline becoming available. Technical Solution 2. A processor as described in Technical Solution 1, wherein the math instruction temporary buffer includes a first-in-first-out (FIFO) queue data structure. Technical Solution 3. A processor as described in Technical Solution 1, wherein the math instruction temporary buffer is configured to store math operation object data of more than one math instruction. Technical Solution 4. A processor as described in Technical Solution 1, wherein the mathematical operation object data includes multiple stages of mathematical operation object data, and wherein the arbitration hardware circuit module is to load the first stage of the multiple stages of the mathematical operation object data directly into the mathematical execution pipeline, and load the remaining stages of the multiple stages of the mathematical operation object data into the mathematical instruction temporary buffer. Technical Solution 5. A processor as described in Technical Solution 1, wherein the math instruction temporary buffer is to store the math operation object data so that the thread arbitrator can continue to load the integer operation object data into the integer execution pipeline. Technical Solution 6. A processor as described in Technical Solution 1, wherein the mathematical instruction performs an operation, and the operation includes at least one of the following operations: sine operation, cosine operation, logarithm operation, tangent operation, or exponential operation. Technical Solution 7. A processor as described in Technical Solution 1, wherein the integer execution pipeline and the mathematical execution pipeline include an arithmetic logic unit (ALU), and the arithmetic logic unit (ALU) includes multiple adders and shifters. Technical Solution 8. A processor as described in Technical Solution 1, wherein the processor includes a graphics processing unit (GPU). Technical Solution 9. A processor as described in Technical Solution 1, wherein the processor is at least one of a single instruction multiple data (SIMD) machine or a single instruction multiple thread (SIMT) machine. Technical solution 10. A method comprising: determining, by an execution resource of a processor core of a graphics processor, that a math execution pipeline of the execution resource is unavailable for loading math operand data for a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein an integer execution pipeline of the execution resource and a math execution pipeline of the execution resource share the thread arbiter; In response to the math execution pipeline being unavailable, loading the math operand data of the math instruction into a math instruction temporary buffer; loading integer operand data for integer instructions into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; and In response to the math execution pipeline becoming available, the math operand data is loaded from the math instruction scratch buffer to the math execution pipeline. Technical Solution 11. A method as described in Technical Solution 10, wherein the math instruction temporary buffer includes a first-in-first-out (FIFO) queue data structure. Technical Solution 12. A method as described in Technical Solution 10, wherein the math instruction temporary buffer is configured to store math operation object data of more than one math instruction. Technical Solution 13. A method as described in Technical Solution 10, wherein the mathematical operation object data includes multiple stages of mathematical operation object data, and wherein the thread arbitrator loads the first stage of the multiple stages of the mathematical operation object data directly into the mathematical execution pipeline, and loads the remaining stages of the multiple stages of the mathematical operation object data into the mathematical instruction temporary buffer. Technical Solution 14. A method as described in Technical Solution 10, wherein the math instruction temporary buffer is to store the math operation object data so that the thread arbitrator can continue to load the integer operation object data into the integer execution pipeline. Technical Solution 15. A method as described in Technical Solution 10, wherein the mathematical instruction performs an operation, and the operation includes at least one of the following operations: sine operation, cosine operation, logarithm operation, tangent operation, or exponential operation. Technical solution 16. A non-transitory computer-readable medium having instructions stored thereon, wherein the instructions, when executed by one or more processors, cause the processor to: determining, by an execution resource of a processor core of the one or more processors, that a math execution pipeline of the execution resource is unavailable for loading math operand data for a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein an integer execution pipeline of the execution resource and a math execution pipeline of the execution resource share the thread arbiter; In response to the math execution pipeline being unavailable, loading the math operand data of the math instruction into a math instruction temporary buffer; loading integer operand data for integer instructions into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; and In response to the math execution pipeline becoming available, the math operand data is loaded from the math instruction scratch buffer to the math execution pipeline. Technical Solution 17. A non-transitory computer-readable medium as described in Technical Solution 16, wherein the mathematical instruction temporary storage buffer includes a first-in-first-out (FIFO) queue data structure. Technical Solution 18. A non-transitory computer-readable medium as described in Technical Solution 16, wherein the math instruction temporary buffer is configured to store math operation object data of more than one math instruction. Technical Solution 19. A non-transitory computer-readable medium as described in Technical Solution 16, wherein the mathematical operation object data includes multiple stages of mathematical operation object data, and wherein the thread arbitrator is to load the first stage of the multiple stages of the mathematical operation object data directly into the mathematical execution pipeline, and load the remaining stages of the multiple stages of the mathematical operation object data into the mathematical instruction temporary buffer. Technical Solution 20. A non-transitory computer-readable medium as described in Technical Solution 16, wherein the mathematical instruction temporary buffer is to store the mathematical operation object data so that the thread arbitrator can continue to load the integer operation object data into the integer execution pipeline.

Claims

1. A processor, comprising: A processing core having at least one execution resource including: Thread arbiter; A plurality of execution pipeline hardware circuit modules, wherein the plurality of execution pipeline hardware circuit modules include a math execution pipeline and an integer execution pipeline for sharing resources of the thread arbiter; an arbitration hardware circuit module, the arbitration hardware circuit module being used to determine whether the math execution pipeline is available to load math operand data of a math instruction, the math operand data being received from the thread arbiter; and a math instruction temporary storage buffer, the math instruction temporary storage buffer being used to store the math operation object data in response to the math execution pipeline being unavailable; wherein the integer execution pipeline is to receive integer operand data of an integer instruction, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction temporary buffer; and The math execution pipeline is to receive the math operation object data from the math instruction temporary buffer in response to the math execution pipeline becoming available.

2. The processor of claim 1, wherein: The math instruction temporary storage buffer includes a first-in-first-out (FIFO) queue data structure.

3. The processor according to any one of claims 1 to 2, wherein: The math instruction temporary buffer is configured to store math operand data of more than one math instruction.

4. The processor according to any one of claims 1 to 3, wherein: The math operation object data includes a plurality of stages of the math operation object data, and wherein the arbitration hardware circuit module is to load a first stage of the plurality of stages of the math operation object data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operation object data into the math instruction temporary buffer.

5. The processor according to any one of claims 1 to 4, wherein: The math instruction temporary buffer is to store the math operand data so that the thread arbiter can continue to load the integer operand data into the integer execution pipeline.

6. The processor according to any one of claims 1 to 5, wherein: The math instructions perform an operation including at least one of a sine operation, a cosine operation, a logarithm operation, a tangent operation, or an exponential operation.

7. The processor according to any one of claims 1 to 6, wherein: The integer execution pipeline and the math execution pipeline include an arithmetic logic unit (ALU) including a plurality of adders and shifters.

8. The processor according to any one of claims 1 to 7, wherein: The processor includes a graphics processing unit (GPU).

9. The processor according to any one of claims 1 to 8, wherein: The processor is at least one of a single instruction multiple data (SIMD) machine or a single instruction multiple thread (SIMT) machine.

10. A method comprising: determining, by an execution resource of a processor core of a graphics processor, that a math execution pipeline of the execution resource is unavailable for loading math operand data for a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein an integer execution pipeline of the execution resource and a math execution pipeline of the execution resource share the thread arbiter; In response to the math execution pipeline being unavailable, loading the math operand data of the math instruction into a math instruction temporary buffer; loading integer operand data for integer instructions into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; and In response to the math execution pipeline becoming available, the math operand data is loaded from the math instruction scratch buffer to the math execution pipeline.

11. The method of claim 10, wherein: The math instruction temporary storage buffer includes a first-in-first-out (FIFO) queue data structure.

12. The method according to any one of claims 10 to 11, wherein: The math instruction temporary buffer is configured to store math operand data of more than one math instruction.

13. The method according to any one of claims 10 to 12, wherein: The math operation object data includes a plurality of stages of the math operation object data, and wherein the thread arbiter is to load a first stage of the plurality of stages of the math operation object data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operation object data into the math instruction temporary buffer.

14. The method according to any one of claims 10 to 13, wherein: The math instruction temporary buffer is to store the math operand data so that the thread arbiter can continue to load the integer operand data into the integer execution pipeline.

15. A non-transitory computer readable medium having stored thereon instructions which, when executed by one or more processors, cause the processors to: determining, by an execution resource of a processor core of the one or more processors, that a math execution pipeline of the execution resource is unavailable for loading math operand data for a math instruction executed by the execution resource, the math operand data being received from a thread arbiter of the execution resource, wherein The integer execution pipeline of the execution resource and the math execution pipeline of the execution resource share the thread arbiter; In response to the math execution pipeline being unavailable, loading the math operand data of the math instruction into a math instruction temporary buffer; loading integer operand data for integer instructions into the integer execution pipeline, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction scratch buffer; as well as In response to the math execution pipeline becoming available, the math operand data is loaded from the math instruction scratch buffer to the math execution pipeline.

16. The non-transitory computer readable medium of claim 15, wherein: The math instruction temporary storage buffer includes a first-in-first-out (FIFO) queue data structure.

17. The non-transitory computer readable medium of any one of claims 15-16, wherein: The math instruction temporary buffer is configured to store math operand data of more than one math instruction.

18. The non-transitory computer readable medium of any one of claims 15-17, wherein: The math operation object data includes a plurality of stages of the math operation object data, and wherein the thread arbiter is to load a first stage of the plurality of stages of the math operation object data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operation object data into the math instruction temporary buffer.

19. The non-transitory computer readable medium of any one of claims 15-18, wherein: The math instruction temporary buffer is to store the math operand data so that the thread arbiter can continue to load the integer operand data into the integer execution pipeline.

20. A system for facilitating integer pipeline deblocking during a math pipeline stage in a graphics environment, wherein: The system comprises: Memory; and a processing core communicatively coupled to the memory, the processing core having at least one execution resource including: Thread arbiter; A plurality of execution pipeline hardware circuit modules, wherein the plurality of execution pipeline hardware circuit modules include a math execution pipeline and an integer execution pipeline for sharing resources of the thread arbiter; an arbitration hardware circuit module, the arbitration hardware circuit module being used to determine whether the math execution pipeline is available to load math operand data of a math instruction, the math operand data being received from the thread arbiter; and a math instruction temporary storage buffer, the math instruction temporary storage buffer being used to store the math operation object data in response to the math execution pipeline being unavailable; wherein the integer execution pipeline is to receive integer operand data of an integer instruction, the integer operand data being received from the thread arbiter while bypassing the math operand data in the math instruction temporary buffer; and The math execution pipeline is to receive the math operation object data from the math instruction temporary buffer in response to the math execution pipeline becoming available.

21. The system of claim 20, wherein: The math instruction temporary storage buffer includes a first-in-first-out (FIFO) queue data structure.

22. The system of any one of claims 20-21, wherein: The math instruction temporary buffer is configured to store math operand data of more than one math instruction.

23. The system of any one of claims 20-22, wherein: The math operation object data includes a plurality of stages of the math operation object data, and wherein the arbitration hardware circuit module is to load a first stage of the plurality of stages of the math operation object data directly into the math execution pipeline and load the remaining stages of the plurality of stages of the math operation object data into the math instruction temporary buffer.

24. The system of any one of claims 20-23, wherein: The math instruction temporary buffer is to store the math operand data so that the thread arbiter can continue to load the integer operand data into the integer execution pipeline.

25. An apparatus for facilitating integer pipeline deblocking during a math pipeline stage in a graphics environment, comprising means for performing the method of any one of claims 10-14.

Images