Dynamic accumulator allocation

Abstract

The invention relates to dynamic accumulator allocation. A system includes a graphics processing unit (GPU) including at least one processor and a plurality of registers. In some examples, based on execution of an instruction by at least one in at least one processor, a particular number of registers is allocated to a thread, and the number of registers is assigned to the thread. In some examples, a compiler is to account for register requirements of a code segment and the number of registers available in determining the number of registers for allocation to the code segment.

Description

Background Art

[0001] Some graphics processing units (GPUs) utilize registers called accumulators to store values ​​generated during computations. Accumulators can operate relatively faster than general register files (GRFs) and provide lower latency and lower power usage. However, the number of available registers may be limited, and insufficient registers may be available for threads and cores. Some GPUs and central processing units (CPUs) utilize operand caches (e.g., forwarding or bypass networks), whereby one or more caches may store read requests or write requests, or both, when data is read or written between a general register file and an arithmetic logic unit (ALU). BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Therefore, in order that the manner in which the features of the present embodiments may be understood in detail, a more particular description of the embodiments briefly summarized above may be made with reference to the embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical embodiments and therefore should not be considered to limit the scope of the embodiments.

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

[0004] 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.

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

[0006] Figure 2C A graphics processing unit (GPU) is shown, which includes a collection of dedicated graphics processing resources arranged as a multi-core group.

[0007] 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.

[0008] Figure 3Ais 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.

[0009] Figure 3B Illustrated is a graphics processor having a tiled architecture according to embodiments described herein.

[0010] Figure 3C Illustrated is a computing accelerator according to embodiments described herein.

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

[0012] Figure 5A Illustrated is a graphics core cluster according to an embodiment.

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

[0014] Figure 5C Illustrated is a matrix engine of a graphics core according to an embodiment.

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

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

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

[0018] 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.

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

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

[0021] 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.

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

[0023] Fig. 11C A package assembly is shown that includes a hardware logic chiplet of multiple units connected to a substrate.

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

[0025] Fig.12 is a block diagram illustrating an exemplary system-on-chip integrated circuit that may be fabricated using one or more IP cores according to an embodiment.

[0026] Fig.13A An exemplary 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.

[0027] Fig. 13B An additional exemplary 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.

[0028] Fig.14 Describe the example system.

[0029] Fig.15 An example of depicting a register.

[0030] Fig.16 Depicts an example of a code snippet.

[0031] Fig.17 Describe the example process.

[0032] Fig.18 Describe the example process. DETAILED DESCRIPTION

[0033] Some designs allocate a fixed number of accumulators per thread. However, allocating a fixed number of accumulators per thread may limit the performance of threads (such as computationally intensive operations). Some examples described herein provide a pool of one or more registers that can be shared by one or more threads executed on a processor, and one or more threads can access or retain registers as needed or release registers when registers are not in use. Threads (e.g., sequences of instructions executed by a processor) can be executed on a GPU. Therefore, the number of registers available per thread can be increased without increasing the size of the physical array of accumulators, and the time to complete the thread can be potentially reduced. In some examples, the compiler can determine the allocation of the number of registers (e.g., accumulators (accumulator, ACC)) for code blocks associated with the thread. For example, the compiler can allocate a fixed number of registers per thread, or allocate a register pool for sharing between threads. When registers are shared between threads, threads can dynamically allocate or release the allocated registers. In some examples, while waiting for an operation (such as a memory access request, a texture access request, or the release of a barrier) to be completed, a thread can release its registers for use by other threads so that other threads can advance the operation. For example, the compiler may insert an instruction called ZeroAccSync before a code block to cause register deallocation, waiting, and allocation of a specific number of registers to the code block. System Overview

[0034] 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 within a system-on-a-chip (SoC) integrated circuit for use in a mobile device, handheld device, or embedded device, such as for use within an Internet-of-things (IoT) device having wired or wireless connectivity to a local area network or a wide area network.

[0035] In one embodiment, the processing system 100 may include, be coupled to, 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 to, 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 within an autonomous vehicle, such as a bus, a tractor trailer, an automobile, a motor or electric power cycle, an airplane, or a glider (or any combination thereof). The autonomous vehicle may use processing system 100 to process the environment sensed around the vehicle.

[0036] In some embodiments, one or more processors 102 each include one or more processor cores 107, which are used to process instructions, and when these instructions are executed, they perform operations for system and user software. In some embodiments, at least one processor core in the one or more processor cores 107 is configured to process a specific instruction set 109. In some embodiments, the instruction set 109 can facilitate complex instruction set computing (Complex Instruction Set Computing, CISC), reduced instruction set computing (Reduced Instruction Set Computing, RISC) or calculation via very long instruction words (VLIW). One or more processor cores 107 can process different instruction sets 109, and different instruction sets 109 may include instructions for facilitating the simulation of other instruction sets. The processor core 107 may also include other processing devices, such as a digital signal processor (Digital Signal Processor, DSP).

[0037] 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 third level (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.

[0038] 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 processors 102 and other components in the processing system 100. In one embodiment, the interface bus 110 can be a processor bus, 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.

[0039] 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 operations and media operations. In some embodiments, graphics operations, media operations, and / or computing operations may be assisted by an accelerator 112, which is a coprocessor that can be configured to perform a collection of specialized graphics operations, media operations, or computing operations. For example, in one embodiment, the accelerator 112 is a matrix multiplication accelerator for optimizing 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.

[0040] In some embodiments, a 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.

[0041] In some embodiments, the platform controller hub 130 enables peripheral devices 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 (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 can enable network connection to a wired network. In some embodiments, a high-performance network controller (not shown) is coupled to the interface bus 110. In one embodiment, the audio controller 146 is a multi-channel high-definition audio controller. In one embodiment, the processing system 100 includes an optional traditional I / O controller 140 for coupling traditional (e.g., Personal System 2 (PS / 2)) devices to the system. The platform controller hub 130 can 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.

[0042] It will be appreciated that the processing system 100 shown is exemplary and non-limiting, as other types of data processing systems configured in different manners 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.

[0043] For example, a circuit board ("sled") may be used on which components (such as CPUs, memory and other components) are placed and designed to achieve improved thermal performance. In some examples, processing components such as processors are located on the top side of the sled, while nearby memory such as DIMMs are located on the bottom side of the sled. As a result of the enhanced airflow provided by the design, 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 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 (such as processors, accelerators, memory and data storage drives) located on the sled are configured to be easily upgraded due to their increased spacing from each other. In an illustrative embodiment, the components additionally include hardware authentication features for proving their authenticity.

[0044] The data center may utilize a single network architecture ("fabric") that supports multiple other network architectures, including Ethernet and omni-path. The sleds may be coupled to the switches via optical fiber, which 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 may, in use, centralize 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, and provide them to computing resources (e.g., processors) as needed, thereby enabling the computing resources to access these centralized resources as if the centralized resources were local.

[0045] A power supply or power source may 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 may be a renewable energy (e.g., solar) 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 for charging by approaching a charging field. In one example, the power source may include an internal battery, an AC supply, a motion-based power supply, a solar power supply, or a fuel cell source.

[0046] Figure 2A-2D Illustrated is a computing system and graphics processor provided by embodiments described herein. Figure 2A-2DElements having the same reference numeral (or name) 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.

[0047] 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 also has 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 mid-level cache, such as a second level (L2), third level (L3), fourth level (L4), or other level of cache, wherein the highest level of cache before external memory is classified as LLC. In some embodiments, cache coherency logic maintains coherency between cache units 206 and 204A-204N.

[0048] 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 buses or PCI Express buses. The system agent core 210 provides management functions for various processor components. In some embodiments, the system agent core 210 includes one or more integrated memory controllers 214 for managing access to various external memory devices (not shown).

[0049] In some embodiments, one or more of the processor cores 202A-202N include support for simultaneous multithreaded operations. 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.

[0050] 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, which includes 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 can also be a separate module coupled to the graphics processor via at least one interconnect, or can be integrated within the graphics processor 208.

[0051] In some embodiments, a ring-based interconnect 212 is used to couple the internal components of the 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, the graphics processor 208 is coupled to the ring-based interconnect 212 via an I / O link 213.

[0052] Exemplary I / O link 213 represents at least one of a plurality of various 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 (HMB) module. In some embodiments, each of processor cores 202A-202N and graphics processor 208 may use embedded memory module 218 as a shared last-level cache.

[0053] 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 and 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 may be implemented on one or more chips, or as a SoC integrated circuit having the components illustrated in addition to other components.

[0054] 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, Figure 2B Elements having the same reference numerals (or names) as elements of any other figure herein may operate or function in a manner similar to that described elsewhere herein. Graphics processor core block 219 is an example of a partition of a graphics processor. Graphics processor core block 219 may be included in Figure 2A The graphics processor 208 may be integrated into the 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, and the multiple graphics cores 221A-221F include modular blocks of fixed function logic and general programmable logic. The graphics processor core block 219 also includes a shared / cache memory 236 that can be accessed by all graphics cores 221A-221F, rasterizer logic 237, and additional fixed function logic 238.

[0055] In some embodiments, the functional block 230 includes a geometry / fixed function pipeline 231 that 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 generator and a global thread dispatcher, and a unified return buffer manager that manages the 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 for facilitating the decoding, encoding, preprocessing, and / or post-processing of multimedia data (including images and video data). The media pipeline 234 implements media operations via requests to the calculation or sampling logic within the graphics cores 221A-221F. One or more pixel backends 235 may also be included within functional block 230. Pixel backend 235 includes buffer memory for storing pixel color values ​​and is capable of performing blending operations and lossless color compression on rendered pixel data.

[0056] 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 within a system host CPU coupled to the SoC via a peripheral interface. The graphics SoC interface 232 also enables 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 such as camera imaging pipelines within the SoC, and enable the use and / or implementation of global memory atomicity, which can be shared between the graphics processor core block 219 and the CPU within the SoC. The graphics SoC interface 232 can also implement power management controls for the graphics processor core block 219 and enable interfaces 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 enables receiving command buffers from a command stream converter and a global thread dispatcher configured to provide commands and instructions to each of the one or more graphics cores within the graphics processor. The commands and instructions can be dispatched to the media pipeline 234 when media operations are to be performed, and can be dispatched 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 can dispatch commands to the graphics cores 221A-221F, thereby bypassing the geometry pipeline and the media pipeline.

[0057] 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 execute graphics workloads and / or compute workloads scheduled 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 including the graphics processor core block 219 may submit a workload to one of a plurality of graphics processor doorbells, which invokes a scheduling operation to the appropriate graphics engine. The scheduling operation includes determining which workload to run next, submitting the workload to the command stream converter, preempting an existing workload 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 is also capable of facilitating 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.

[0058] The graphics processor core block 219 may have more or fewer graphics cores 221A-221F than those shown, up to a maximum of N modular graphics cores. For each set 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 for accelerating various graphics and compute processing operations.

[0059] Within each graphics core 221A-221F is a collection of execution resources that can be used to perform graphics operations, media operations, and compute operations in response to requests made by the graphics pipeline, media pipeline, or shader programs. Graphics cores 221A-221F include 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.

[0060] 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 operations, media operations, or compute operations (including graphics programs, media programs, or compute / GPGPU programs). The vector engines 222A-222F, 224A-224F are capable of operating with variable vector widths using SIMD execution mode, SIMT execution mode, or SIMT+SIMD execution mode. The matrix acceleration units 223A-223F, 225A-225D include matrix-matrix and matrix-vector acceleration logic that improves the performance of matrix operations, especially 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 includes one or more systolic arrays of processing elements capable of performing concurrent matrix multiplication or dot product operations on matrix elements.

[0061] Samplers 226A-226F can read media data or texture data into memory and can sample the data in different ways 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 can utilize caches / SLMs 228A-228F within each execution core. Caches / SLMs 228A-228F can be configured as a pool of cache memory or shared memory local to each graphics core in the corresponding graphics cores 221A-221F. Ray tracing units 227A-227F within graphics cores 221A-221F include ray traversal / intersection circuitry 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 coordination with image denoising, at least a portion of which may be performed using associated matrix acceleration units 223A-223F, 225A-225D.

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

[0063] 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 with 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 FPGA differ in the level of abstraction of the hierarchy. Figure 2B The graphics core 221A-221F and Figure 2C The multi-core groups 240A-240N are similar. Figure 2C The graphics core 243, tensor core 244 and ray tracing core 245 are respectively Figure 2B The vector engines 222A-222F, 224A-224F, matrix engines 223A-223F, 225A-225F and ray tracing units 227A-227F are similar.

[0064] The set of register files 242 may store operand values ​​used by the cores 243, 244, 245 when executing a graphics thread. These register files may include, 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 slice registers for storing tensor / matrix values. In one embodiment, the slice registers are implemented as a combined set of vector registers.

[0065] One or more combined first level (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 second level (L2) cache 253 shared by all multi-core groups 240A-240N or a subset of multi-core groups 240A-240N stores graphics data and / or instructions for multiple concurrent graphics threads. As shown, 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).

[0066] Input / output (I / O) circuitry 250 couples 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 I / O devices 252 to GPU 239 and memory 249. One or more I / O memory management units (IOMMUs) 251 of I / O circuitry 250 directly couple I / O devices 252 to memory 249. In one embodiment, IOMMU 251 manages a plurality of page table sets for mapping virtual addresses to physical addresses in memory 249. In this embodiment, I / O devices 252, CPU(s) 246, and GPU 239 may share the same virtual address space.

[0067] In one implementation, the IOMMU 251 supports virtualization. In this case, the IOMMU 251 can manage a first set of page tables for mapping guest / graphics virtual addresses to guest / graphics physical addresses and a second set of page tables for mapping guest / graphics physical addresses to system / host physical addresses (e.g., within memory 249). The base address of each of the first set of page tables and the second set of page tables can be stored in a control register and swapped out at context switch (e.g., so that the new context is provided with access to the relevant set of page tables). Although not described in detail in the prior art, the IOMMU 251 can manage a first set of page tables for mapping guest / graphics virtual addresses to guest / graphics physical addresses and a second set of page tables for mapping guest / graphics physical addresses to system / host physical addresses (e.g., within memory 249). Figure 2C , but each of the cores 243, 244, 245 and / or multi-core groups 240A-240N may include a translation lookaside buffer (TLB) for caching guest virtual to guest physical translations, guest physical to host physical translations, and guest virtual to host physical translations.

[0068] 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 memories, but the underlying principles of the embodiments described herein are not limited to this particular implementation.

[0069] In one embodiment, the tensor core 244 includes multiple functional units specifically designed to perform matrix operations, which are basic computational operations for performing deep learning operations. For example, synchronized matrix multiplication operations can be used for neural network training and inference. 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.

[0070] 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 requires a large number of matrix dot product operations. To handle the inner product formulation of the N x N x N matrix multiplication, the tensor core 244 may include at least N dot product processing elements. Before the matrix multiplication begins, a complete matrix is ​​loaded into the slice register, and for each of the N cycles, at least one column of the second matrix is ​​loaded. For each cycle, there are N dot products that are processed.

[0071] Depending on the specific implementation, matrix elements can 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 can 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, which can tolerate quantization to bytes and nibbles).

[0072] In one embodiment, the ray tracing core 245 accelerates ray tracing operations for both real-time ray tracing implementations and non-real-time ray tracing implementations. Specifically, the ray tracing core 245 includes a ray traversal / intersection circuit that uses a bounding volume hierarchy (BVH) to perform ray traversals and identify intersections between rays and primitives enclosed within the BVH volume. The ray tracing core 245 may also include circuits 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 conjunction with the image denoising techniques described herein, at least portions 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 on frames generated by the ray tracing core 245. However, the CPU(s) 246, graphics core 243, and / or ray tracing core 245 may also implement all or portions of the denoising and / or deep learning algorithms.

[0073] In addition, as described above, a distributed approach to denoising may be employed, wherein 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 denoising for different types of image frames and / or different graphics applications.

[0074] In one embodiment, the ray tracing core 245 handles all BVH traversals and ray-primitive intersections, thereby preventing the graphics core 243 from being overloaded with thousands of instructions for each ray. In one embodiment, each ray tracing core 245 includes a first set of specialized circuits for performing bounding box tests (e.g., for traversal operations) and a second set of specialized circuits for performing ray-triangle intersection tests (e.g., intersecting rays that have been traversed). Therefore, in one embodiment, the multi-core group 240A can simply start ray detection, 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.

[0075] In one embodiment, each ray tracing core 245 includes a traversal unit for performing BVH test operations and an intersection unit for performing ray-primitive intersection tests. The intersection unit generates a "hit", "no hit", or "multiple hits" response, which it provides 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 up to perform other forms of graphics work.

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

[0077] In one embodiment, the ray tracing core 245 (and / or other cores 243, 244) includes hardware support for ray tracing instruction sets, such as Microsoft's DirectX Ray Tracing (DXR), which includes the DispatchRays command; and ray generation shaders, nearest hit shaders, any hit shaders, and miss shaders, which enable unique shader and texture sets to be assigned to 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, it should be noted that the basic principles of the embodiments described herein are not limited to any particular ray tracing ISA.

[0078] In general, each core 245, 244, 243 may support a ray tracing instruction set including instructions / functions for: ray generation, nearest 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 for performing the following functions:

[0079] Light Generation - Ray generation instructions can be executed for each pixel, sample, or other user-defined work assignment.

[0080] Recent Hits - A nearest hit command may be executed to locate the closest intersection of a ray with a primitive within the scene.

[0081] Any hit - Any hit command identifies multiple intersections between rays and primitives within the scene, thereby potentially identifying a new closest intersection point.

[0082] intersect ——The intersection instruction performs a ray-primitive intersection test and outputs the result.

[0083] 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).

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

[0085] visit ——Indicates the subvolume that the ray will traverse.

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

[0087] 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. Exemplary 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 electromagnetic signals through an environment may be accelerated using instructions or primitives that are executed via a ray tracing core. Refraction and reflection of signals through objects in the environment may be calculated as direct ray tracing simulations.

[0088] 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 in 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 neighbor 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.

[0089] Figure 2D2 is a block diagram of a general purpose graphics processing unit (GPGPU) 270 according to an embodiment described herein, which GPGPU 270 can be configured as a graphics processor and / or a computing accelerator. 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, memory 271 is a system memory that can be shared with one or more CPUs 246, while memory 272 is a device memory dedicated to GPGPU 270. In one embodiment, components within GPGPU 270 and memory 272 can be mapped to memory addresses that can be accessed by one or more CPUs 246. Access to memories 271 and 272 can be facilitated via a memory controller 268. In one embodiment, memory controller 268 includes an internal direct memory access (DMA) controller 269, or can include logic for performing operations that would otherwise be performed by a DMA controller.

[0090] 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 into cache memories. GPGPU 270 also includes a plurality of computing units 260A-260N, which represent the computing units 260A-260N and the computing units 260A-260N. Figure 2B Graphics cores 221A-221F and Figure 2C The computing units 260A-260N may be coupled to a constant cache 267, which may be used to store constant data, which is data that does not change during the execution of a kernel program or a 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 register 262.

[0091] During operation, one or more CPUs 246 may write commands to registers in GPGPU 270, or to memory in GPGPU 270 that has been mapped into an accessible address space. Command processor 257 may read commands from registers or memory and determine how to process those commands 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 computation and may conditionally output the results of the computation to memory. Command processor 257 may interrupt one or more CPUs 246 when the submitted commands are completed.

[0092] Figure 3A-3C A block diagram illustrating additional graphics processor and computing accelerator architectures provided by embodiments described herein. Figure 3A-3C Elements having the same reference numeral (or name) 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.

[0093] 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 using commands placed into 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.

[0094] 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 compositing one or more overlay planes of a display and multiple layers of video or 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 for encoding media into one or more media coding formats, decoding media from one or more media coding formats, or transcoding media between one or more media coding formats, wherein the one or more 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).

[0095] 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.

[0096] 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 act 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 may be used to perform media operations, embodiments of GPE 310 also include a media pipeline 316 that is specifically used to perform media operations, such as video post-processing and image enhancement.

[0097] In some embodiments, the media pipeline 316 includes fixed-function or programmable logic units for performing 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 generation unit for generating threads for execution on the 3D / media subsystem 315. The generated threads perform calculations for media operations on one or more graphics cores included in the 3D / media subsystem 315.

[0098] In some embodiments, the 3D / media subsystem 315 includes logic for executing threads generated by the 3D pipeline 312 and the media pipeline 316. In some embodiments, the pipeline sends thread execution requests to the 3D / media subsystem 315, which includes thread dispatch logic for arbitrating and dispatching various requests for available thread execution resources. The execution resources include an array of graphics cores for processing 3D threads 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 a shared memory for sharing data between threads and for storing output data, which includes registers and addressable memory.

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

[0100] 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 different from the graphics engine slice to which the memory device is directly connected. However, when accessing the local slice, access latency to memory devices 326A-326D may be minimized. In one embodiment, a cache coherent NUMA (ccNUMA) system is enabled that uses slice interconnects 323A-323F to enable communication between cache controllers within graphics engine slices 310A-310D to maintain a consistent memory image when more than one cache stores the same memory location.

[0101] 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 for enabling the fabric interconnect 324 to function as a packet-switched fabric interconnect for exchanging 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 306 and one or more replication engines 304. The replication engines 304 may be used to move data out of the memory devices 326A-326D and memory external to the graphics processor 320 (e.g., system memory), move data into the memory devices 326A-326D and memory external to the graphics processor 320 (e.g., system memory), and move data between the 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 tile interconnects 323A-323F to facilitate or enhance interconnections between the graphics engine tiles 310A-310D. The fabric interconnect 324 may also be configured to interconnect multiple instances of the graphics processor 320 (e.g., via the host interface 328), thereby enabling tile-to-tile communication between the graphics engine tiles 310A-310D of multiple GPUs. In one embodiment, the graphics engine tiles 310A-310D of multiple GPUs may be presented to the host system as a single logical device.

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

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

[0104] Figure 3C FIG. 3 shows a computing accelerator 330 according to an embodiment described herein. The computing accelerator 330 may include Figure 3B The 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, but 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 memories 326A-326D via the memory interconnects 325A-325D. The memories 326A-326D and the memory interconnects 325A-325D may be technologies similar to those in the graphics processor 320, or may be different technologies. The compute engine slices 340A-340D may also be interconnected via a set of slice interconnects 323A-323F, and may be connected to and / or interconnected through a fabric interconnect 324. Cross-slice communication may be facilitated via the fabric interconnect 324. The fabric interconnect 324 may also facilitate communication between the compute engine slices 340A-340D of multiple instances of a compute accelerator 330 (e.g., via a host interface 328). In one embodiment, the compute accelerator 330 includes a large L3 cache 336 that may be configured as a device-wide cache. The compute accelerator 330 may also communicate with the host computer 328 to communicate with the host computer 328. Figure 3B The graphics processor 320 is similarly connected to a host processor and memory via a host interface 328 .

[0105] 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 over a physical layer interconnect 344 without the data having to cross the memory of the host system. In one embodiment, one of the computing engine slices 340A-340D is replaced by the network processor logic, and data to be transmitted or received via the physical layer interconnect 344 can be transmitted directly 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, each computing engine slice 340A-340D can be presented as a different network accessible computing accelerator device. Graphics processing engine

[0106] 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 3B Graphics engine slices 310A-310D. Figure 4 Elements having the same reference numeral (or name) 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 3A 3D pipeline 312 and media pipeline 316 are illustrated. Media pipeline 316 is optional in some embodiments of GPE 410 and may not be explicitly included within GPE 410. For example and in at least one embodiment, separate media and / or image processors are coupled to GPE 410.

[0107] In some embodiments, GPE 410 is coupled to or includes a command stream converter 403 that provides a command stream to 3D pipeline 312 and / or media pipeline 316. Alternatively or additionally, command stream converter 403 may be directly coupled to unified return buffer 418. Unified return buffer 418 may be communicatively coupled to graphics core cluster 414. In some embodiments, command stream converter 403 is coupled to a memory, which may be system memory, or one or more of an internal cache memory and a shared cache memory. In some embodiments, command stream converter 403 receives commands from memory and sends these commands to 3D pipeline 312 and / or media pipeline 316. These commands are instructions taken from a ring buffer that stores commands for 3D pipeline 312 and 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 the 3D pipeline 312 may also include references to data stored in memory, such as, but not limited to, vertex data and geometry data for the 3D pipeline 312 and / or image data and memory objects for the media pipeline 316. The 3D pipeline 312 and the media pipeline 316 process commands and data by performing operations via logic within the corresponding pipelines or by dispatching one or more execution threads to the graphics core cluster 414. In one embodiment, the 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, including: general and graphics-specific execution logic for performing graphics operations and compute operations; and fixed-function texture processing logic and / or machine learning and artificial intelligence acceleration logic, such as matrix or AI acceleration logic.

[0108] In various embodiments, the 3D pipeline 312 may include fixed function and programmable logic for processing 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 execution resource block for use in processing these shader programs. The multi-function 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.

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

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

[0111] In some embodiments, graphics core cluster 414 is scalable such that the cluster includes a variable number of graphics cores, each having 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 as needed.

[0112] The graphics core cluster 414 is coupled to shared function logic 420, which includes a plurality of resources that are 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 functions to the graphics core cluster 414. In various embodiments, the shared function logic 420 may include, but is not limited to, sampler 421 logic, math 422 logic, and inter-thread communication (ITC) 423 logic. In addition, 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 performs the same or similar functions.

[0113] Shared functionality is implemented at least in cases where the demand for a given specialized function is insufficient to be included within the graphics core cluster 414. Instead, a single instantiation of that specialized function is implemented as an independent entity in the shared functionality logic 420 and is shared between execution resources within the graphics core cluster 414. The exact set of functions shared between the graphics core clusters 414 and included within the graphics core cluster 414 varies from embodiment to embodiment. In some embodiments, specific shared functions within the shared functionality logic 420 that are widely used by the graphics core clusters 414 may be included within the shared functionality logic 416 within the graphics core cluster 414. In various embodiments, the shared functionality logic 416 within the graphics core cluster 414 may include some or all of the logic within the shared functionality logic 420. In one embodiment, all logic elements within the shared functionality logic 420 may be replicated within the shared functionality logic 416 of the graphics core cluster 414. In one embodiment, the shared functionality logic 420 is excluded in favor of the shared functionality logic 416 within the graphics core cluster 414. Graphics processing resources

[0114] 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 Illustrated is a graphics core cluster according to an embodiment. Figure 5B Illustrated is a vector engine of a graphics core according to an embodiment. Figure 5C Illustrated is a matrix engine of a graphics core according to an embodiment. 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 the GPGPU 270 have similar functions.

[0115] 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 to graphics core 515N) and may include multiple instances of graphics core block 415. 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 circuits including, but 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, and samplers 510A-510N. The circuits 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.

[0116] With reference to graphics core 515A, vector engine 502A and matrix engine 503A are configurable to perform parallel computational operations on data in various integer and floating point data formats based on instructions associated with shader programs. Each vector engine 502A and matrix engine 503A can act as a programmable general purpose computing unit capable of executing multiple synchronous hardware threads while processing multiple data elements in parallel for each thread. Vector engine 502A and matrix engine 503A support processing of variable width vectors in various SIMD widths, including but not limited to SIMD8, SIMD16 and SIMD32. Input data elements can be stored in registers as compact data types, and vector engine 502A and matrix engine 503A can 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 various sizes of unit groups and thread groups (e.g., 8, 16 or 32 threads).

[0117] 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 pre-fetch operations. In one embodiment, the memory load / store unit 504A is configured to perform pre-fetch operations for data stored in the vector engine 502A and / or the matrix engine 503A. Figure 6 In the memory 610, from Figure 6 The slice interconnect 608 provides SIMT scatter / gather prefetch or block prefetch for data that is local to other slices or from system memory. Figure 6, a prefetch may be performed to 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.

[0118] Reference Figure 5A , instruction cache 505A stores instructions to be executed by graphics core 515A. In one embodiment, graphics core 515A also includes instruction acquisition and prefetch circuits 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 circuits 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 circuits that are shared between instances of vector engine 502A and matrix engine 503A. Graphics cores 515B-515N can operate in a manner similar to graphics core 515A.

[0119] The functions of instruction caches 505A-505N, data caches / shared local memory 506A-506N, ray tracing units 508A-508N, samplers 510A-510N, and fixed function logic 512A-512N correspond to the equivalent functions in the graphics processor architecture described herein. Figure 2D The data cache / shared local memory 506A-506N, ray tracing units 508A-508N and samplers 510A-510N 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 of the CPU. Figure 2B In one embodiment, ray tracing units 508A-508N include components of geometry / fixed function pipeline 231 and / or additional fixed function logic 238. Figure 2C The ray tracing core 245 is a circuit for performing ray tracing acceleration operations.

[0120] 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.

[0121] 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.

[0122] 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) SIMDFPU 534 for execution. Each execution thread can access 128 general registers in the GRF 524, wherein each register can store 32 bytes that can be accessed as a variable width vector with 32-byte data elements. 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.

[0123] 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.

[0124] 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 32-bit floating point (or integer) operations, or 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 535 of 8-bit integer SIMD ALUs 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 534 of additional SIMD ALUs that can be configured to perform integer and floating point operations. In one embodiment, the SIMD FPU 534 and the SIMD ALU 535 can be configured to execute SIMT programs. In one embodiment, combined SIMD+SIMT operations are supported.

[0125] 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 grouped 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.

[0126] like Figure 5C As shown in, in one embodiment, the matrix engine 503 includes an array of processing elements configured to perform tensor operations, including vector / matrix operations and matrix / matrix operations, such as but not limited to matrix multiplication and / or dot product operations. The matrix engine 503 can be configured using processing elements (552AA-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-552MN form the physical pipeline stage of the systolic array of N width and M depth, and the systolic array 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 can also be configured to accelerate specific 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, or a tensor floating point 32-bit floating point format (TF32), having a different number of mantissa bits and exponent bits relative to the Institute of Electrical and Electronics Engineers (IEEE) 754 format.

[0127] 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 executed. For example, in one embodiment, a partial sum loopback is enabled, 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-552MN to operate as a systolic array of logical pipeline stages, such as 2M, 3M, 4M, etc.

[0128] 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 element rows and column elements of the input matrix can be stored in the systolic register file 540 in the matrix engine 503 before these 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 524 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 memory 541A-541N, 542A-542M. The results generated by the processing elements 552AA-552MN are then output to the output buffer and / or written to the register file (e.g., the systolic register file 540, the GRF 524, the data cache / shared local memory 506A-506N) for further processing by other functional units of the graphics processor or for output to the memory.

[0129] In some embodiments, the matrix engine 503 is configured with support for input sparsity, wherein multiplication operations of sparse regions of input data can be bypassed by skipping multiplication operations of operands with zero values. In one embodiment, processing elements 552AA-552MN are configured to skip the execution of certain operations with zero-value 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-value operands into processing elements can be bypassed, and processing elements 552AA-552MN can be configured to perform multiplication on non-zero-value input elements. The matrix engine 503 can also be configured with support for output sparsity, so that operations with results predetermined to zero can be 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 the cycle for a certain processing cycle.

[0130] In one embodiment, the matrix engine 503 includes hardware for enabling 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. Exemplary compressed representations include, but are not limited to, compressed tensor representations, such as, compressed sparse rows (CSR) representations, compressed sparse columns (CSC) representations, compressed sparse fibers (CSF) representations. Support for compressed representations enables operations to be performed on inputs in compressed tensor format without the need for compressed representations to be decompressed or decoded. In such embodiments, operations can be performed only on non-zero input values, and the resulting non-zero output values ​​can be mapped into the output matrix. In some embodiments, hardware support for machine-specific lossless data compression formats is also provided, which are used when transmitting data within hardware or across system buses. Such data can be retained in a compressed format for sparse input data, and the matrix engine 503 can use compressed metadata for compressed data to enable operations to be performed only on non-zero values ​​or to enable blocks of zero data input to be bypassed for multiplication operations.

[0131] 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 sparse input data may be performed before the 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 using 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 compression elements 552AA-552MN according to metadata associated with the compressed data.

[0132] Figure 6 FIG. 6 is a diagram of a slice 600 of a multi-slice processor according to an embodiment. 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), wherein 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.

[0133] 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 includes different logic units that can be assembled into a larger package with other chiplets. For example, the L3 cache 606 may be included 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 included in a separate chiplet such as Fig. 11CAn active base die or an active interpose is shown.

[0134] Memory structure 603 enables communication between graphics core cluster 414A-414N, L3 cache 606, and memory 610. L2 cache 604 is coupled to memory structure 603 and may be configured to cache transactions executed via memory structure 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 structure 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 part of a GPU-wide L3 cache.

[0135] Figure 7 is a block diagram illustrating a graphics processor instruction format 700 according to 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 typically included in the graphics core instructions, while dashed lines include components that are optional or included only in a subset of the instructions. In some embodiments, the graphics processor instruction format 700 described and illustrated are macroinstructions in that they are instructions supplied to the graphics core, as opposed to micro-operations that result from instruction decoding that occurs once the instruction is processed. Thus, a single instruction may cause the hardware to perform multiple micro-operations.

[0136] 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. The native 128-bit instruction format 710 provides access to all instruction options, while some options and operations are limited in 64-bit format 730. The native instructions available in 64-bit format 730 vary from embodiment to embodiment. In some embodiments, the instructions are partially compressed using a set of index values ​​in index field 713. The graphics core hardware references a set of compression tables based on the index values ​​and uses the compression table output to reconstruct the native instructions of 128-bit instruction format 710. Instructions of other sizes and formats can be used.

[0137] 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 addition instruction, the graphics core performs a synchronous 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 in 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 the 64-bit compact instruction format 730.

[0138] 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.

[0139] In some embodiments, the 128-bit instruction format 710 includes an access / addressing 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 addresses of one or more operands are provided directly by bits in the instruction.

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

[0141] In one embodiment, the addressing mode portion of the access / addressing mode field 726 determines whether the instruction uses direct addressing or indirect addressing. When direct register addressing mode is used, the bits in the instruction directly provide the register address of one or more operands. When indirect register addressing mode is used, 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.

[0142] In some embodiments, instructions are grouped based on the opcode 712 bit field to simplify opcode decoding 740. For an 8-bit opcode, bits 4, 5, and 6 allow the graphics core to determine the type of opcode. The exact opcode grouping shown is only an example. In some embodiments, the move and logic opcode group 742 includes 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 (call), jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 746 includes a mixture of instructions, including synchronization instructions (e.g., wait (wait), send (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)) of the form 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) of the form 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic on vector operands, such as dot product calculations. In one embodiment, the illustrated opcode decode 740 can be used to determine which portion of the graphics core will be used to execute the decoded instructions. For example, some instructions may be designated as systolic instructions to be executed by a systolic array. Other instructions, such as ray tracing instructions (not shown), may be routed to a ray tracing core or ray tracing logic within a slice or partition of the execution logic. Graphics Pipeline

[0143] Figure 8 is a block diagram of another embodiment of a graphics processor 800 . Figure 8 Elements having the same reference numeral (or name) 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.

[0144] In some embodiments, the 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, the 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 issued to the graphics processor 800 through the ring interconnect 802. In some embodiments, the ring interconnect 802 couples the graphics processor 800 to other processing components (such as other graphics processors or general-purpose processors). Commands from the ring interconnect 802 are interpreted by a command stream converter 803, which supplies instructions to various components of the geometry pipeline 820 or the media pipeline 830.

[0145] 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.

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

[0147] In some embodiments, the geometry pipeline 820 includes a tessellation component for performing hardware accelerated tessellation of 3D objects. In some embodiments, a programmable shell 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 shell shader 811 and contains dedicated logic for generating a detailed set of geometric objects based on a coarse geometric model that is provided as input to the geometry pipeline 820. In some embodiments, if tessellation is not used, the tessellation component (e.g., the shell shader 811, the tessellation 813, and the domain shader 817) can be bypassed. The tessellation component can operate based on data received from the vertex shader 807.

[0148] 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 is programmable by a geometry shader program to perform geometry tessellation when the tessellation unit is disabled.

[0149] Before rasterization, the clipper 829 processes the vertex data. The clipper 829 can be a fixed function clipper or a programmable clipper with clipping and geometry shader functions. In some embodiments, the rasterizer and depth test component 873 in the render output pipeline 870 dispatches a pixel shader to convert the geometric object into a pixel-by-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 outflow unit 823.

[0150] The graphics processor 800 has an interconnect bus, interconnect structure, 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 port 856 to perform memory access 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.

[0151] In some embodiments, the render output pipeline 870 includes a rasterizer and depth test component 873 that 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. In some embodiments, an associated rendering buffer 878 and depth buffer 879 are also available. The pixel operation component 877 performs pixel-based operations on data, but in some instances, pixel operations associated with 2D operations (e.g., using mixed bit block image transfers) are performed by the 2D engine 841, or replaced by the display controller 843 using an overlay display plane when displaying. In some embodiments, a shared L3 cache 875 can be used for all graphics components, allowing data to be shared without using main system memory.

[0152] 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 them to the media engine 837. In some embodiments, the media engine 837 includes a thread generation function for generating threads for dispatching to the thread execution logic 850 via the thread dispatcher 831.

[0153] 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 can be coupled to the graphics processor via the ring interconnect 802, or some other interconnect bus or structure. 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 or an external display device attached via a display device connector.

[0154] In some embodiments, the geometry pipeline 820 and the media pipeline 830 may be configured to perform operations based on multiple graphics and media programming interfaces, and are not dedicated to any one application programming interface (API). In some embodiments, the driver software for the graphics processor converts API calls dedicated to a specific graphics or media library into commands that can be processed by the graphics processor. In some embodiments, support is provided for all of the Open Graphics Library (OpenGL), Open Computing Language (OpenCL) and / or Vulkan graphics and computing APIs from the Khronos Group. In some embodiments, support may also be provided for the Direct3D library from Microsoft. In some embodiments, a combination of these libraries may be supported. Support may 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, future APIs with compatible 3D pipelines will also be supported. Graphics pipeline programming

[0155] 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 commands, while the dashed lines include components that are optional or included only in a subset of the graphics commands. Fig.9A An exemplary graphics processor command format 900 includes a data field for identifying a client 902 of the command, a command operation code (opcode) 904, and a data field 906. A subopcode 905 and a command size 908 are also included in some commands.

[0156] In some embodiments, client 902 specifies a client unit of a graphics device that processes command data. In some embodiments, a 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, a 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 a command is received by a client unit, the client unit reads an opcode 904 and a sub-opcode 905 (if present) 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 a double word. Other command formats may be used.

[0157] Fig. 9B 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 establish, execute, and terminate a set of graphics operations. The sample command sequence is shown and described for exemplary purposes only, as embodiments are not limited to these particular commands or command sequences. In addition, commands may be issued as batches of commands in a command sequence so that the graphics processor will process the command sequence in an at least partially concurrent manner.

[0158] In some embodiments, the graphics processor command sequence 910 can begin with a pipeline dump clear command 912 to cause any active graphics pipeline to complete currently pending commands for the pipeline. In some embodiments, the 3D pipeline 922 and the media pipeline 924 do not operate concurrently. The pipeline dump clear is performed to cause the active graphics pipeline to complete any pending commands. In response to the pipeline dump clear, 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 marked as "dirty" in the rendering cache can be dumped to memory. In some embodiments, the pipeline dump clear command 912 can be used for pipeline synchronization, or can be used before placing the graphics processor in a low power state.

[0159] In some embodiments, when a command sequence requires the graphics processor to explicitly switch between pipelines, pipeline select command 913 is used. In some embodiments, pipeline select command 913 is only required once in an execution context before issuing pipeline commands, unless the context is issuing commands for both pipelines. In some embodiments, pipeline flush command 912 is required immediately before a pipeline switch via pipeline select command 913.

[0160] 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 are used to clear data from one or more cache memories within an active pipeline before processing a batch of commands.

[0161] In some embodiments, commands associated with return buffer state 916 are used to configure a set of return buffers for a corresponding pipeline for writing data. Some pipeline operations require the allocation, selection, or configuration of one or more return buffers into which the operation writes 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.

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

[0163] The commands for configuring the 3D pipeline state 930 include 3D state setting commands for vertex buffer state, vertex element state, constant color state, depth buffer state, and other state variables that will be configured before processing 3D primitive commands. The values ​​of these commands are determined at least in part based 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.

[0164] 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.

[0165] In some embodiments, the 3D pipeline 922 is triggered via an execute 934 command or event. In some embodiments, a register write triggers command execution. In some embodiments, execution is triggered via a "go" or "kick" command in a command sequence. In some embodiments, command execution is triggered using a pipeline synchronization command to flush 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 objects are rasterized and the pixel engine shades the resulting pixels. For those operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0166] In some embodiments, when performing media operations, the graphics processor command sequence 910 follows the media pipeline 924 path. In general, the specific purpose and manner of programming for the media pipeline 924 depends on the media or computing operations to be performed. During media decoding, specific media decoding operations can be migrated to the media pipeline. In some embodiments, the media pipeline can also be bypassed, and the media decoding can be performed in whole or in part using resources provided by one or more general processing cores. 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 compute shader programs that are not explicitly related to the rendering of graphics primitives.

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

[0168] 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, before issuing media object commands 942, all media pipeline states must be valid. Once the pipeline state is configured and the media object commands 942 are queued, the media pipeline 924 is triggered via an execution command 944 or an equivalent execution 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

[0169] Fig.10 An exemplary 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.

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

[0171] In some embodiments, operating system 1020 is from Microsoft Corporation The operating system 1020 may be a graphics API 1022, such as a Direct3D API, an OpenGL API, or a Vulkan API. When the Direct3D API is in use, the operating system 1020 uses a front-end shader compiler 1024 to compile any shader instructions 1012 using HLSL into a lower-level shader language. The compilation may be just-in-time (JIT) compilation or application executable shader precompilation. In some embodiments, during the compilation of the 3D graphics application 1010, high-level shaders are compiled into low-level shaders. In some embodiments, the shader instructions 1012 are provided in an intermediate form, such as a certain version of the Standard Portable Intermediate Representation (SPIR) used by the Vulkan API.

[0172] In some embodiments, the user mode graphics driver 1026 includes a backend shader compiler 1027 to compile shader instructions 1012 into a hardware specific representation. 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 function 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

[0173] One or more aspects of at least one embodiment may be implemented by representative code stored on a machine-readable medium that represents and / or defines logic within an integrated circuit (such as a processor). For example, a machine-readable medium may include instructions representing various logic within a processor. When read by a machine, the instructions may cause the machine to manufacture logic for performing 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 each customer or manufacturing facility that loads the hardware model on a manufacturing machine that manufactures the integrated circuit. The integrated circuit may be manufactured so that the circuit performs the operations described in association with any of the embodiments described herein.

[0174] Fig.11A1 is a block diagram illustrating an IP core development system 1100 that can be used to manufacture an integrated circuit to perform an operation according to an embodiment. The IP core development system 1100 can be used to generate a modular, reusable design that can be incorporated into a larger design or used to build an entire integrated circuit (e.g., a system on a chip (SOC or SOC integrated circuit)). The design facility 1130 can generate a software simulation 1110 of the IP core design in 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 (including associated logic that is executed using the modeled digital signals) that models the flow of digital signals between hardware registers. In addition to the RTL design 1115, a lower level design at the logic level or transistor level can also be created, designed, or synthesized. Thus, the specific details of initial design and simulation may vary.

[0175] The RTL design 1115 or an 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 manufacturing 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 manufacturing facility 1165 may then manufacture an integrated circuit based at least in part on the IP core design. The manufactured integrated circuit may be configured to perform operations according to at least one embodiment described herein.

[0176] 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-function 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 logic unit 1172, 1174 may be implemented within a semiconductor die and coupled to the substrate 1180 via an interconnect organization 1173. The interconnect organization 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 organization 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 may 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.

[0177] In some embodiments, logic units 1172, 1174 are electrically coupled to a bridge 1182 configured to route electrical signals between logic 1172 and logic 1174. Bridge 1182 may be a dense interconnect fabric that provides routing for electrical signals. Bridge 1182 may include a bridge substrate composed of glass or a suitable semiconductor material. Circuit features may be formed on the bridge substrate to provide a chip-to-chip connection between logic 1172 and logic 1174.

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

[0179] Fig. 11CThe package assembly 1190 is shown, which includes a hardware logic chiplet of multiple units connected to the substrate 1180. Graphics processing units, parallel processors and / or computing accelerators as described herein may be composed of various silicon chiplets manufactured separately. Chiplets with various sets of different IP core logic can be assembled into a single device. In addition, the chiplets can be integrated into the base die or base chiplet using active interposer technology. The concepts described herein enable interconnection and communication between different forms of IP within the GPU. The IP cores can be manufactured using different process technologies and constructed during manufacturing, which avoids the complexity of converging multiple IPs into the same manufacturing process, especially for large SoCs with several styles of IP. Allowing the use of multiple process technologies improves time to market and provides a cost-effective method to create multiple product SKUs. In addition, the decomposed IP is easier to modify to be independently power-gated, and components that are not in use for a given workload can be turned off, thereby reducing overall power consumption.

[0180] In various embodiments, the package assembly 1190 may include components and chiplets interconnected by structures 1185 and / or one or more bridges 1187. The chiplets within the package 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 package 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 package 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 package assembly 1190 are arranged on top of the active interposer 1189 using 3D face-to-face die stacking. The active interposer 1189 may include hardware logic for I / O 1191, cache memory 1192, and other hardware logic 1193 in addition to the interconnect structure 1185 and silicon bridge 1187. The structure 1185 enables communication between the various logic chiplets 1172, 1174 and the logic 1191, 1193 within the active interposer 1189. The structure 1185 may be a network-on-chip (NoC) interconnect or another form of packet-switched structure that exchanges data packets between components of the package assembly. For complex assemblies, the structure 1185 may be a dedicated chiplet that enables communication between the various hardware logics of the package assembly 1190.

[0181] A bridge organization 1187 within the active interposer 1189 may be used to facilitate, for example, point-to-point interconnections between a logic or I / O chiplet 1174 and a memory chiplet 1175. In some implementations, the bridge organization 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-function logic hardware and may include one or more portions of any of the processor core(s), graphics processor(s), parallel processor, 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 structure 1185 .

[0182] Each chiplet may be fabricated as a separate semiconductor die and may be coupled to a base die that is embedded within or coupled to a substrate 1180. Coupling to the substrate 1180 may be performed via an interconnect organization 1173. The interconnect organization 1173 may be configured to route electrical signals between the various chiplets and logic within the substrate 1180. The interconnect organization 1173 may include interconnects such as, but not limited to, bumps or pillars. In some embodiments, the interconnect organization 1173 may 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 logic, I / O, and memory chiplets. In one embodiment, an additional interconnect organization couples the active interposer 1189 to the substrate 1180.

[0183] 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.

[0184] In some embodiments, the logic or I / O chiplet 1174 and the memory chiplet 1175 may be electrically coupled via a bridge 1187 configured to route electrical signals between the logic or I / O chiplet 1174 and the memory chiplet 1175. The bridge 1187 may be a dense interconnect tissue that provides routing for electrical signals. The bridge 1187 may include a bridge substrate composed of glass or a suitable semiconductor material. Circuit features may 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. The bridge 1187 may also be referred to as a silicon bridge or an interconnect bridge. For example, in some embodiments, the bridge 1187 is an embedded multi-die interconnect bridge (Embedded Multi-die Interconnect Bridge, EMIB). In some embodiments, the bridge 1187 may simply be a direct connection from one chiplet to another chiplet.

[0185] Fig.11D A package assembly 1194 including interchangeable chiplets 1195 is illustrated according to an embodiment. Interchangeable chiplets 1195 can be assembled into standardized sockets 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. Memory chiplets can also be connected to logic or I / O chiplets via a bridge interconnect. The I / O and logic chiplets can communicate via an interconnect structure. The base chiplets can each support one or more sockets in a standardized format for one of logic or I / O or memory / cache.

[0186] In one embodiment, the 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, which are 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 for the product using the package assembly 1194. In addition, logic chiplets with different numbers of types of functional units may be selected at assembly time based on power and / or performance for the product. In addition, chiplets containing IP logic cores of different types may be inserted into the interchangeable chiplet sockets, thereby enabling hybrid processor designs that can mix and match IP blocks of different technologies. Exemplary System-on-Chip Integrated Circuit

[0187] Figure 12-13B An exemplary integrated circuit and associated graphics processor that can be manufactured 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.

[0188] Fig.12 1 is a block diagram illustrating an exemplary system-on-chip integrated circuit 1200 that can be manufactured using one or more IP cores according to an embodiment. The exemplary 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, either of which may be modular IP cores from the same design facility or multiple different design facilities. The integrated circuit 1200 includes peripheral or bus logic, including a USB controller 1225, a UART controller 1230, an SPI / SDIO controller 1235, and an I 2 S / I 2 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 (including flash memory and a flash memory controller). A memory interface may be provided via a memory controller 1265 to obtain access to SDRAM or SRAM memory devices. Some integrated circuits additionally include an embedded security engine 1270.

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

[0190] 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, all the way 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 vertex shader programs, while one or more fragment processors 1315A-1315N perform fragment (e.g., pixel) shading operations for fragment or pixel shader programs. The vertex processor 1305 performs the vertex processing stage of the 3D graphics pipeline and generates primitives and vertex data. (One or more) fragment processors 1315A-1315N use the primitive data and vertex data generated by the vertex processor 1305 to generate a frame buffer that is displayed on a display device. In one embodiment, the fragment processor(s) 1315A-1315N are optimized to execute fragment shader programs as provided in the OpenGL API, which can be used to perform similar operations as pixel shader programs as provided in the Direct 3D API.

[0191] 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 to physical address mappings for the graphics processor 1310 (including for the vertex processor 1305 and / or (one or more) fragment processors 1315A-1315N), which may reference vertex data or image / texture data stored in memory in addition to vertex data or image / texture data stored in the one or more caches 1325A-1325B. In one embodiment, the one or more MMUs 1320A-1320B may be synchronized with other MMUs within the system so that each processor 1205-1220 may participate in a shared or unified virtual memory system, including other MMUs within the system. Fig.12One or more MMUs associated with one or more application processors 1205, image processor 1215, and / or video processor 1220. According to an embodiment, one or more circuit interconnects 131330A-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.

[0192] like Fig. 13B As shown in FIG. 1 , the graphics processor 1340 includes Fig.13A One or more MMUs 1320A-1320B, caches 1325A-1325B, and circuit interconnects 1330A-1330B of a graphics processor 1310. Graphics processor 1340 includes one or more shader cores 1355A-1355N (e.g., 1355A, 1355B, 1355C, 1355D, 1355E, 1355F, all the way to 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 for implementing 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 may vary by embodiment and implementation. In addition, the graphics processor 1340 includes an inter-core task manager 1345 that 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. Register Allocation

[0193] Fig.14Depicting an example system. Processor 1400 may include one or more of the following: one or more processors; one or more cores; one or more accelerators; one or more application specific integrated circuits (ASICs); one or more field programmable gate arrays (FPGAs); one or more graphics processing units (GPUs); one or more storage devices; or other. Memory 1404 may include one or more of the following: one or more registers, one or more general register files (GRFs), one or more arithmetic logic units (ALUs), one or more accumulators, one or more cache devices (e.g., first level cache (L1), second level cache (L2), third level cache (L3), last level cache (LLC)), volatile memory devices, non-volatile memory devices, or persistent memory devices. For example, memory 1404 may include static random access memory (SRAM) memory technology or memory technology consistent with high bandwidth memory (HBM) or double data rate (DDR), etc.

[0194] For at least one code segment 1408 stored in the memory 1404, the compiler 1402 can determine how many registers are requested from zero to the maximum allowed number of allocable registers, and indicate this in the register assignment 1406. The maximum allowed number of allocable registers to the code segment can be a set value (e.g., 4 or other number set by the administrator) or [total number of registers-the number of registers allocated to one or more code segments]. The code segment can be executed with a lower latency with a larger register allocation than other code segments, and the compiler 1402 can allocate the number of registers to the code segment based on the balance between how many registers the code can utilize and how many different threads want to share the same register resource. For example, a block in the kernel can be executed with a lower latency based on the allocation of 12 registers, and another block in the same kernel may not be able to utilize registers that exceed 4 allocations. Therefore, applying per code segment block control to register allocation can provide improvements while potentially preventing performance degradation by overusing shared resources.

[0195] For one or more of code segments 1408-0 to 1408-M (where M is an integer), compiler 1402 can generate compiled code 1420 with register assignment 1422 of register 1456 based on register assignment 1406-0 to 1406-M. The upper limit of the number of registers that can be requested can be set to 16 or other numbers. Compiler 1402 can specify the number of registers so that it is allocated to one or more of code segments 1408-0 to 1408-M in the corresponding register assignment 1406-0 to 1406-M. Compiler 1402 can allocate registers or accumulators to the first thread and reduce the registers or accumulators allocated to the second thread to reduce the waiting time for the first thread to complete. Processor 1400 can provide compiled code 1420 including code segments 1408-0 to 1408-M and register assignment 1422 including register assignment 1406-0 to 1406-M.

[0196] Note that compiler 1402 does not need to issue register assignment instructions in the kernel, and backward compatibility can be maintained. In some examples, if compiler 1402 does not issue register assignment instructions for a code segment, graphics processor 1450 can allocate a default number of registers to the code segment. For SIMD32 code in a thread, registers are accessed in even and odd pairs to handle SIMD16 operations, and register assignment instructions for a code segment can allocate an even number of registers for the thread.

[0197] GPU 1450 may include a graphics processor and associated circuits described herein. Scheduler 1452 may assign machine-readable instructions from compiled code 1420 to threads. Processors and various circuits may execute instructions from compiled code 1420 and allocate registers 1456 based on register assignment 1422. Registers 1456 may provide an operand cache or a local register storing data written or read by one or more threads. Registers 1456 may store data and instructions (e.g., compiled code 1420) to process data. Registers 1456 may include an array of one or more accumulators and / or registers. Registers 1456 may be implemented as accumulators, general registers, general register file arrays (general register file array, GRF) and / or volatile memory. For example, an accumulator array may include a single 2048-bit wide array (or 512 bits per quadrant), with a single read port per arithmetic logic unit (arithmetic logic unit, ALU). In some examples, graphics processor 1450 may perform allocation of multiple registers to threads based on register assignment 1422. A thread may be associated with a sequence of instructions executed by a processor. A thread executed by GPU 1450 may allocate and release one or more registers for a particular block of code being executed based on the parameters of register assignment 1422.

[0198] In some examples, register assignment 1422 may be implemented as an instruction instance (e.g., instruction ZeroAccSync) for each code segment. Instruction ZeroAccSync may be represented using the following semantics that specifies the number of registers to be allocated by GPU 1450 to the associated code segment and an optional scoreboard identifier (SBID), for example: (W)ZeroAccSync X,$Y in: X represents the number of registers requested, and $Y represents SBID.

[0199] In some examples, register assignment 1422 may be implemented as an instruction (e.g., instruction ZeroAccSync), which, when executed by GPU 1450, may perform one or more of (1) to (3). At (1), the thread's allocated accumulator or register is released. When a thread waits for an operation to complete, such as a memory request, a texture request, or a barrier, the accumulator or register may be released. While the thread is waiting for the operation to complete, one or more other execution threads that are performing calculations and are not in a waiting state may utilize the released accumulator or register for active calculations. Releasing the thread's allocated accumulator or register may include writing zero or overwriting the contents of the thread's allocated accumulator or register. For security reasons and architectural consistency, the contents of a register may be set to zero before being assigned to another thread. To save power, registers do not need to be physically zeroed. Alternatively, a single bit per register stores information that may be read as a zero value. For example, execution of the ZeroAccSync instruction may set a single read-to-zero bit to save power, save write ports, and reduce energy consumption. In some examples, compiler 1402 may allow the contents of registers to be accessible across code segment blocks to preserve data in registers.

[0200] At (2), the thread may wait until an (optionally) provided scoreboard identifier (SBID) in scoreboard 1458 indicates one or more conditions that block the operation of the thread. The SBID may be set for a wide variety of conditions whereby the thread cannot proceed until the SBID is valid. Examples of conditions include another thread completing an operation, a pipeline flush, a memory operation completing, a data read completing, a data write completing, another thread progressing through a user-defined barrier, or other synchronization purposes, etc. In some examples, if the provided SBID is null or zero, no wait is performed and the thread may proceed upon or after register allocation.

[0201] At (3), a number of registers specified for the thread in register assignment 1422 are requested from the shared pool of registers 1456. If, for (3), a number of registers specified for the thread in register assignment 1422 are not available, the thread may wait until sufficient registers are available.

[0202] Based on a thread assigned to at least one of the processors 1454 being scheduled to begin execution, the thread may wait for the allocation of the number of registers specified in its register assignment 1422 (e.g., a ZeroAccSync instruction) before beginning execution. In the case where a thread waits until a sufficient number of registers are available before it can execute or resume execution, there is a possibility of deadlock behavior due to the lack of a sufficient number of registers. The compiler 1402 may issue one or more additional ZeroAccSync instructions within a delay loop so that the waiting child thread can be assigned to the number of accumulators specified in the associated ZeroAccSync instruction, then release the allocated accumulators and allow the parent thread to execute. If multiple threads are requesting registers, the graphics processor 1450 may allocate registers to the threads in a round-robin manner so that the threads ultimately receive the highest priority and are able to execute. In some cases, if fewer than the requested number of registers are available for allocation to a thread, the allocated GRF registers may be allocated as registers to the thread.

[0203] When saving and restoring individual threads, register counts and contents may be saved for a thread, and upon restoration, multiple registers (and in some cases, the contents of registers) specified by ZeroAccSync may be assigned to that thread. However, the reallocation of registers may cause register restoration to be delayed until sufficient registers have been freed by other threads, and may limit the number and combination of threads that may restore registers at one time. Registers for some threads may be restored, and those threads may execute until they have freed sufficient registers for use by other threads.

[0204] To reduce the possibility of deadlock caused by threads waiting for register allocation, compiler 1402 may cause one or more of the following to be performed. "ZeroAccSync 0" is executed before a possible thread blocking operation so that when the operation is executed, the thread is not using the register and cannot prevent another thread from executing or using the register. The code may contain a "livelock" to poll a shared resource, issuing ZeroAccSync for multiple ACCs, because ZeroAccSync first releases all registers and reallocates registers, and the thread may pause and allow (one or more) other threads that have been waiting for the longest time or a time above a threshold amount of time to execute and be allocated registers instead. "ZeroAccSync 0" is executed before a barrier, potential blocking operation, or memory access to avoid deadlock by releasing registers allocated to the thread and allowing the released registers to be allocated to another thread or threads. Before a branch to an earlier address, a ZeroAccSync instruction may be executed so that a fairness scheme may be applied by releasing registers allocated to the thread and allowing the released registers to be allocated to another thread or threads.

[0205] The compiler 1402 may be configured with an upper limit on the number of registers that may be allocated to a block of a kernel by a software developer. The compiler 1402 may compile each kernel and limit register allocation based on the upper limit. After compiling the kernel, the compiler 1402 may check each block to determine the number of ACCs allocated, which may be less than the upper limit, and then insert a ZeroAccSync at the beginning of the block with the requested number of registers. In this way, the ZeroAccSync instruction may not control how many registers a code block uses or is allocated, but may record the number of registers that the compiler 1402 requested to be allocated.

[0206] In some examples, the compiler 1402 may compile code, assign registers, and schedule instructions for execution, and then insert a ZeroAccSync into one or more of the following: (a) the beginning of a kernel (e.g., machine-readable code generated by the compiler 1402), (b) an instruction that is a branch target (e.g., the beginning of a block), and / or (c) between an instruction that sends a command (e.g., a kernel request to read data from a memory or write data to a memory) and a result of using the data read from the memory. One or more of these ZeroAccSync instructions may request a specified number of registers. As discussed above, ZeroAccSync may not control how many registers are used or allocated, but may record the number of registers that the compiler 1402 determines to allocate to the code segment. When a ZeroAccSync is inserted, the ZeroAccSync may be marked with an associated SBID so that the thread may not use the register while it is waiting for data to return and the SBID to become valid. Thus, while waiting for the SBID to become valid, the register may be freed for use by the thread.

[0207] In some examples, threads may periodically release their registers to prevent deadlock, and context save and restore may occur when executing the ZeroAccSync instruction rather than elsewhere in the kernel.

[0208] In some examples, operations (1) to (3) can be ordered to be performed in order to free registers, then wait for the state of the specified SBID to change to clear or the operation is complete, and then allocate the requested number of registers. The ordering of (1) to (3) can allow other threads to continue and ensure forward progress of the threads so as to avoid deadlock or reduce the possibility of deadlock. Therefore, multiple threads can have different numbers of allocated registers at a given time.

[0209] In some examples, ZeroAccSync may allow some registers to retain content. For example, "ZeroAccSync2,6,nul" may retain data in ACC0 and ACC1, release the other ACCs, and then wait until ACC2 / 3 / 4 / 5 can be acquired (and zeroed) before proceeding.

[0210] Multiple memory Send commands may be issued in a code block (e.g., a core requesting a read from or write to data in memory), and the code segment may wait for completion of the Send commands based on the execution of a ZeroAccSync instruction, where an SBID may be associated with each Send command. In some examples, if ZeroAccSync is assigned multiple SBIDs or a bit mask of SBIDs, the number of instructions issued may be reduced and all of the instructions may be waited for to complete (e.g., to a valid status). In some examples, ZeroAccSync may have additional controls and may be used in conjunction with Sync.swsb may wait for one or more events in a similar manner, such as events "allrd", "allwr", "bar", "host", or other options.

[0211] In some examples, registers 1456 may be split into a floating point pipeline ACC and an integer pipeline ACC. In this case, ZeroAccSync may specify two allocation requests, one for each ACC array, and both allocation requests must be satisfied for the thread to proceed. Physically different sized arrays may be used for each pipeline. Threads may read data from independent read ports per ALU.

[0212] In some examples, before the setup and payload of the next kernel begin to be sent to the GRF, the compiler 1402 can insert an End Of Thread (EOT) flag to cause the release of registers and allow other threads to use them, and the next kernel iteration begins. In this way, existing kernels that do not use ZeroAccSync can run without any modification and can also run on the same core as kernels that use ZeroAccSync.

[0213] Fig.15 Depicts an example of a register. For example, the register can be divided into eight accumulators (e.g., acc0, acc1, acc2, acc3, acc3 / 7, acc2 / 6, acc1 / 5, and acc0 / 4). The accumulators can be allocated between threads as described herein. The accumulators can receive addresses and data (for writes) and output data for read operations.

[0214] Fig.16Depicts an example pixel shader that utilizes ZeroAccSync to allocate registers to a code segment following ZeroAccSync. The instruction "(W)Zeroaccsync 0,nul" may cause the code segment to not wait for SBID because it is the beginning of a kernel. In addition, the code segment is not allocated registers, so the four registers automatically allocated to the code segment are freed for use by other threads.

[0215] The instruction "(W)Zeroaccsync 0,$0" can allocate zero registers to the code segment and wait for the completion of SBID$0 (for example, send.smpl(16|M0)r4 r7 r8:1 0x0 0x0212021A{A@1,$0}). The instruction "(W)zeroaccsync 4,$1" can allocate four registers to the code segment and wait for the completion of SBID$0 (for example, send.smpl(16|M0)r14 r9 r10:1 0x0 0x02420019{$1}).

[0216] At the end of time (EOT) of the thread associated with a code segment, the registers allocated to the code segment may be freed.

[0217] Fig.17 An example process is described. The process may be performed by a compiler. At 1702, a compiler executed by a processor may process an instruction set to determine register allocations to an instruction subset. The instruction set may be written in any language, such as one or more languages ​​specified herein. For example, a plurality of registers may be allocated to an instruction subset based on a processing load of the instruction subset. For example, the processing load of the instruction subset may be based on the number of calculations performed and / or the number or size of operands generated. For example, a plurality of registers may be allocated to an instruction subset based on a balance of register usage of each subset of instructions executed and taking into account the total number of available registers. In some examples, the number of registers allocated to an instruction subset may be limited to a specific number or the total number of registers specified by an administrator, developer.

[0218] At 1704, based on the determined number of allocated registers, a register allocation instruction may be inserted into or before the instruction subset to indicate the number of allocated registers. In some examples, the register allocation instruction may specify a scoreboard identifier for an operation to be completed before allocating registers to the instruction subset (e.g., thread). At 1706, a compiled instruction with one or more register allocation instructions may be provided for execution by a graphics processor.

[0219] Fig.18Describe an example process. The process can be performed by a graphics processor. At 1802, registers can be allocated to threads. For example, the default allocation can be a number X registers, where X is an integer. A thread can be associated with a compiled instruction subset. In some examples, the number of registers allocated to a thread can be allocated based on the indicated number of registers of the code segment generated by the compiler. At 1804, the registers allocated to the thread can be released for use by one or more other threads. At 1806, a determination can be made as to whether one or more conditions that allow the allocation of a number X registers to a thread are met. For example, one or more conditions can be met to allow the allocation of a number X registers to a thread based on an SBID indicating that the operation is complete. For example, one or more conditions can be met to allow the allocation of a number X registers to a thread based on the number X registers being available for allocation. At 1806, based on meeting one or more conditions, at 1808, the number X registers can be allocated to the thread. Operation 1806 can be repeated based on one or more conditions not being met.

[0220] Each example can be realized using hardware elements, software elements or a combination of the two. In some examples, hardware elements may include devices, parts, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, ASICs, PLDs, DSPs, FPGAs, memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. In some examples, software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, APIs, instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or combinations thereof. Determining whether to use hardware elements and / or software elements to realize an example may be different according to any number of factors, such as, as desired for a given implementation, required computing rate, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance constraints. A processor may be a hardware state machine, digital control logic, a central processing unit, or one or more combinations of any hardware, firmware, and / or software elements.

[0221] Some examples may be implemented using or as an article of manufacture or at least one computer-readable medium. A computer-readable medium may include a non-transient storage medium for storing logic. In some examples, a non-transient storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. In some examples, logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, APIs, instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or combinations thereof.

[0222] According to some examples, a computer-readable medium may include a non-transient storage medium for storing or maintaining instructions that, when executed by a machine, a computing device, or a system, cause the machine, a computing device, or a system to perform methods and / or operations according to the described examples. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Instructions may be implemented according to a predefined computer language, manner, or syntax for instructing a machine, a computing device, or a system to perform a function. Instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0223] One or more aspects of at least one example may be implemented by representative instructions stored on at least one machine-readable medium, which represent various logic within the processor, and which, when read by a machine, computing device, or system, causes the machine, computing device, or system to fabricate logic for performing the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and supplied to various customers or manufacturing facilities to load into fabrication machines that actually fabricate the logic or processor.

[0224] The appearance of the phrase "one example" or "example" does not necessarily refer to the same example or embodiment. Any aspect described herein may be combined with any other aspect or similar aspect described herein, whether or not the aspects are described with respect to the same figure or element. The division, omission, or inclusion of block functions depicted in the figures does not infer that the hardware components, circuits, software, and / or elements used to implement these functions must be divided, omitted, or included in each embodiment.

[0225] The expressions "coupled" and "connected," as well as their derivatives, may be used to describe some examples. These terms are not necessarily intended to be synonymous with each other. For example, descriptions using the terms "connected" and / or "coupled" may indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0226] The terms "first", "second" and the like herein do not indicate any order, quantity or importance, but are used to distinguish one element from another element. The terms "a" and "an" herein do not indicate a limit to quantity, but represent that there is at least one item cited. The term "asserted" used in reference to a signal herein represents the state of a signal, wherein the signal is active, and this can be achieved by applying any logic level of logic 0 or logic 1 to the signal. The terms "following" or "after..." may refer to immediately following another or other events or following another or other events. Other sequences of operations may also be performed according to alternative embodiments. In addition, additional operations may be added or removed depending on a specific application. Any combination of variations may be used, and those of ordinary skill in the art who benefit from the present disclosure will appreciate many variations, modifications and alternative embodiments of the present disclosure.

[0227] Unless specifically stated otherwise, it is understood that separator language such as the phrase "at least one of X, Y, or Z" is generally used to present that an item, project, etc. can be any of X, Y, or Z or a combination thereof (e.g., X, Y, and / or Z). Therefore, such separator language is generally not intended to imply and should not imply that certain embodiments require that at least one X, at least one Y, or at least one Z each be present. Furthermore, unless specifically stated otherwise, it is also understood that separator language such as the phrase "at least one of X, Y, and Z" means X, Y, Z, or a combination thereof, including "X, Y, and / or Z."

[0228] The following provides illustrative examples of the devices, systems, and methods disclosed herein. Embodiments of the devices, systems, and methods may include one or more of the examples described below and combinations thereof.

[0229] Example 1 includes one or more examples and includes a device comprising: a graphics processing unit (GPU), comprising: at least one processor and a plurality of registers, wherein: based on an instruction executed by at least one of the at least one processor to allocate a specific number of registers to the thread, the number of registers is assigned to the thread from the plurality of registers.

[0230] Example 2 includes one or more examples wherein: if the number of registers in the plurality of registers is not available, waiting for the number of registers in the plurality of registers to be available to assign the number of registers to the thread.

[0231] Example 3 includes one or more examples wherein: based on execution of the instruction, one or more registers assigned to the thread are released, waiting for clearing of at least one condition, and allocating the number of registers from a plurality of registers to the thread.

[0232] Example 4 includes one or more examples wherein the instruction is to specify a particular number of registers to be assigned to the thread and an identifier of a condition to be satisfied prior to allocation of the particular number of registers.

[0233] Example 5 includes one or more examples wherein, based on at least one of the at least one processor executing an instruction to allocate the particular number of registers to the thread, assigning the number of registers to the thread includes waiting for a condition to be satisfied before allocating the particular number of registers from the plurality of registers.

[0234] Example 6 includes one or more examples wherein at least one of the at least one processor is to allocate use of the general register file to the thread based on fewer than the particular number of registers being available for allocation from the plurality of registers.

[0235] Example 7 includes one or more examples and includes a central processing unit (CPU), wherein the CPU is to execute a compiler to compile a code segment having instructions, and wherein the compiled code segment is associated with a thread.

[0236] Example 8 includes one or more examples and includes a method comprising: a graphics processing unit (GPU) executes: based on a compiler-specified instruction having a compiled code segment for allocating a number of registers in the GPU to the thread, allocating the number of registers to the thread.

[0237] Example 9 includes one or more examples and includes the GPU performing: based on less than the number of registers being available, waiting for the number of registers to be available, and assigning the number of registers to the thread.

[0238] Example 10 includes one or more examples and includes the GPU performing: based on execution of the instruction, releasing registers assigned to the thread, waiting for clearing of at least one condition, and allocating the number of registers to the thread.

[0239] Example 11 includes one or more examples wherein the instruction specifies a number of registers assigned to the thread and an identifier of a condition to be satisfied prior to allocation of the number of registers.

[0240] Example 12 includes one or more examples wherein, based on the execution of the instruction by the GPU, assigning the number of registers to the thread comprises: waiting for a condition to be satisfied prior to the allocation of the number of registers.

[0241] Example 13 includes one or more examples and includes the GPU performing: allocating use of the general register file to the thread based on fewer than the number of registers being available for allocation.

[0242] Example 14 includes one or more examples and includes a GPU accessing a compiler-specified instruction having a compiled code segment from a memory and executing the compiler-specified instruction having the compiled code segment.

[0243] Example 15 includes one or more examples and includes a non-transitory computer-readable medium including instructions stored thereon, which if executed by one or more processors causes the one or more processors to: execute a compiler to compile an instruction set including a first code segment and a second code segment, wherein: the compiler is used to provide a first instruction associated with the first code segment to specify a first number of registers to be allocated to the first code segment, and the compiler is used to provide a second instruction associated with the second code segment to specify a second number of registers to be allocated to the second code segment.

[0244] Example 16 includes one or more examples wherein a first instruction is used to specify a first number of registers to be assigned to a first thread associated with a first code segment and an identifier of a condition to be satisfied before the first number of registers are allocated to the first thread, and a second instruction is used to specify a second number of registers to be assigned to a second thread associated with a second code segment and an identifier of a condition to be satisfied before the second number of registers are allocated to the second thread.

[0245] Example 17 includes one or more examples wherein, if the first number of registers are not available, assigning the first number of registers to the thread occurs after the first number of registers are available.

[0246] Example 18 includes one or more examples wherein execution of a first instruction by a graphics processor is to cause: releasing registers assigned to a first thread, waiting for clearing of at least one condition, and allocating a first number of registers to the first thread.

[0247] Example 19 includes one or more examples wherein releasing the register assigned to the first thread includes allowing the released register to be reallocated to another thread.

[0248] Example 20 includes one or more examples wherein execution of the first instruction by the graphics processor is to cause: allocating use of a general register file to a thread based on fewer than the first number of registers being available for allocation to the first thread.

Claims

1. A device comprising: Graphics Processing Unit GPU, including: at least one processor; and Multiple registers, including: Based on execution of an instruction by at least one of the at least one processor to allocate a particular number of registers to a thread, the number of registers is assigned to the thread from the plurality of registers.

2. The device of claim 1, wherein: If the number of registers in the plurality of registers is not available, waiting for the number of registers in the plurality of registers to be available to assign the number of registers to the thread.

3. The device according to any one of claims 1 to 2, wherein: Based on the execution of the instructions, one or more registers assigned to the thread are released, waiting for clearing of at least one condition, and allocating the number of registers from the plurality of registers to the thread.

4. The device according to any one of claims 1 to 3, wherein: The instruction is for specifying the particular number of registers to be assigned to the thread and an identifier of a condition to be satisfied prior to allocation of the particular number of registers.

5. The device according to claim 4, wherein: Based on executing instructions by the at least one of the at least one processor to allocate the particular number of registers to the thread, assigning the number of registers to the thread includes waiting for the condition to be satisfied before allocating the particular number of registers from the plurality of registers.

6. The device according to any one of claims 1 to 5, wherein: The at least one of the at least one processor is for allocating use of a general register file to the thread based on fewer than the particular number of registers being available for allocation from the plurality of registers.

7. The device according to any one of claims 1 to 6, comprising: A central processing unit (CPU), wherein the CPU is used to execute a compiler to compile a code segment having the instructions, and wherein the compiled code segment is associated with the thread.

8. A method comprising: Graphics Processing Unit GPU performs: Based on a compiler-specified instruction having a compiled code segment for allocating a number of registers in the GPU to a thread, allocating the number of registers to the thread.

9. The method of claim 8, comprising: The GPU performs: Based on fewer than the number of registers being available, waiting for the number of registers to be available to assign the number of registers to the thread.

10. The method of claim 9, comprising: The GPU performs: Based on the execution of the instruction, registers assigned to the thread are released, waiting for the clearing of at least one condition, and allocating the number of registers to the thread.

11. The method of claim 10, wherein: The instruction specifies a number of registers to be assigned to the thread and an identifier of a condition to be satisfied prior to allocation of the number of registers.

12. The method of claim 11, wherein: Assigning the number of registers to the thread based on execution of the instruction by the GPU includes waiting for the condition to be satisfied prior to allocation of the number of registers.

13. The method according to any one of claims 9 to 12, comprising: The GPU performs: Based on fewer than the number of registers being available for allocation, use of a general register file is allocated to the thread.

14. The method according to any one of claims 9 to 12, comprising: The GPU accesses compiler-specified instructions having compiled code segments from a memory and executes the compiler-specified instructions having the compiled code segments.

15. A non-transitory computer readable medium comprising instructions stored thereon, the instructions, if executed by one or more processors, causing the one or more processors to: A compiler is executed to compile an instruction set including a first code segment and a second code segment, wherein: The compiler is configured to provide a first instruction associated with the first code segment to specify a first number of registers to be allocated to the first code segment, and The compiler is configured to provide a second instruction associated with the second code segment to specify a second number of registers to be allocated to the second code segment.

16. The computer readable medium of claim 15, wherein: The first instruction is for specifying the first number of registers to be allocated to a first thread associated with the first code segment and an identifier of a condition to be satisfied before the first number of registers is allocated to the first thread, and The second instruction is for specifying the second number of registers to be allocated to a second thread associated with the second code segment and an identifier of a condition to be satisfied before the second number of registers are allocated to the second thread.

17. The computer-readable medium of claim 16, wherein: If the first number of registers are not available, assigning the first number of registers to the thread occurs after the first number of registers are available.

18. The computer-readable medium of any one of claims 16-17, wherein: The execution of the first instruction by the graphics processor causes: releasing registers assigned to the first thread, waiting for at least one condition to be cleared, and allocating the first number of registers to the first thread.

19. The computer-readable medium of claim 18, wherein: Releasing registers assigned to the first thread includes allowing the released registers to be reallocated to another thread.

20. The computer readable medium of claim 16, wherein: The graphics processor executes the first instruction so that: Based on fewer than the first number of registers being available for allocation to the first thread, use of a general register file is allocated to the first thread.

Images