Determination of the idle power state

Abstract

Methods and apparatus related to techniques for determining an idle power state are described. In an embodiment, power configuration logic determines a power state configuration for a portion of a processor. The power state configuration corresponds to a plurality of settings for operation of the portion of the processor during an idle period. Additionally, the power configuration logic determines the power state configuration at least in part based on one or more (e.g., runtime) workload measurements. Other embodiments are also disclosed and claimed.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Application No. 15 / 719,541, titled "DETERMINATION OF IDLE POWER STATE", filed on September 28, 2017, under 35 U.S.C§365(c). The entire disclosure of these documents is incorporated herein by reference for all purposes. Technical Field

[0003] Embodiments generally relate to data processing, and more particularly to data processing via a graphics processing unit. For example, some embodiments relate to techniques for determining an idle power state. Background Art

[0004] As integrated circuit manufacturing technology advances, manufacturers are able to integrate additional functions on a single silicon substrate. As the number of functions increases, the number of components on a single integrated circuit (IC) chip also increases. The additional components increase additional signal switching, thereby generating more heat and / or consuming more power. The additional heat may damage the components on the chip due to, for example, thermal expansion. Additionally, the additional power consumption may limit the locations and / or usage models of these devices, for example, especially for devices that operate on battery power. Therefore, efficient power management can directly affect the efficiency, lifespan, and usage models of electronic devices. Brief Description of the Drawings

[0005] To enable a more particular understanding of the features described herein for the embodiments, the embodiments may be described in more detail by reference to the embodiments, some of which are illustrated in the drawings. However, it should be noted that the drawings only show typical embodiments and should not be considered as limiting their scope.

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

[0007] Figure 2 、 Figure 3 、 Figure 4 and Figure 5 illustrate various components of a processor according to some embodiments.

[0008] Figures 6A - 6B illustrates thread execution logic according to embodiments described herein, the thread execution logic including an array of processing elements employed in a graphics processor core.

[0009] Figure 7 illustrates a graphics core instruction format according to some embodiments.

[0010] Figure 8It is a block diagram of another embodiment of a graphics processing unit.

[0011] Figure 9A and Figure 9B respectively illustrate a graphics processing unit command format and sequence according to some embodiments.

[0012] Figure 10 Illustrates an exemplary graphics software architecture for a data processing system according to some embodiments.

[0013] Figure 11A Illustrates a diagram of IP core development according to an embodiment.

[0014] Figure 11B Illustrates a cross-sectional side view of an integrated circuit package assembly according to some embodiments described herein.

[0015] Figures 12 - 1 4 illustrates an exemplary integrated circuit and associated graphics processing unit that can be fabricated using one or more IP cores according to various embodiments described herein.

[0016] Figures 13A - 13B Is a block diagram showing an exemplary graphics processing unit used within a SoC according to an embodiment described herein.

[0017] Figures 14A - 14B Illustrates additional exemplary graphics processing unit logic according to an embodiment described herein.

[0018] Figure 15 Illustrates the information flow between various components of a graphics system according to an embodiment.

[0019] Figure 16 and Figure 17 Illustrate sample settings for two examples according to some embodiments. Detailed Description

[0020] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. However, the various embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments. Additionally, various means may be used to perform the various aspects of the embodiments, such as integrated semiconductor circuits (“hardware”), computer-readable instructions organized into one or more programs (“software”), or some combination of hardware and software. For the purposes of this disclosure, references to “logic” shall mean hardware, software, firmware, or some combination thereof.

[0021] As described above, efficient power management can directly affect the efficiency, lifespan, and usage model of electronic devices. Taking a graphics system as an example, the graphics hardware may still consume a large amount of power during the idle state. Some solutions can support coarse power gating (CPG), RC1e, RC6 for rendering and media, and select the graphics frequency based on the idle metric and the number of idle / busy transitions using a hardware finite state machine. As discussed herein, "RCx" generally refers to the power state during the idle time of the graphics processing unit (GPU). For example, RC6 corresponds to a lower power state (consuming less power) than RC5, and RC0 refers to the full / active power state, etc.

[0022] To this end, some embodiments provide techniques for energy-efficient configuration of graphics hardware (e.g., GPU or one or more parts thereof) during the idle state. In an embodiment, a computing engine (which is also generally referred to as power configuration "logic" herein) can determine the optimal configuration for the graphics hardware based on state characteristics and / or workload metrics. In various embodiments, the optimal configuration can be identified through various selected states. Therefore, some embodiments provide better battery life and / or better performance under power-constrained graphics workloads. Other embodiments are also disclosed and claimed.

[0023] In addition, some embodiments can be applied to a computing system including one or more processors (e.g., having one or more processor cores), such as those discussed with reference to Figure 1 etc., including, for example, mobile computing devices such as smartphones, tablets, UMPCs (ultra-mobile personal computers), laptops, Ultrabook TM computing devices, wearable devices (e.g., smartwatches or smart glasses), etc.

[0024] In some embodiments, the graphics processing unit (GPU) is communicatively coupled to the host / processor core to accelerate graphics operations, machine learning operations, pattern analysis operations, and various general-purpose GPU (GPGPU) functions. The GPU can be communicatively coupled to the host processor / core via a bus or another interconnect (e.g., a high-speed interconnect such as PCIe or NVLink). In other embodiments, the GPU can be integrated on the same package or chip as the core and communicatively coupled to the core via an internal processor bus / interconnect (i.e., inside the package or chip). Regardless of the way the GPU is connected, the processor core can assign work to the GPU in the form of a sequence of commands / instructions contained in a work descriptor. Then, the GPU uses dedicated circuitry / logic to efficiently process these commands / instructions.

[0025] In the following description, numerous specific details are set forth in order to provide a more thorough understanding. However, it will be apparent to one of ordinary skill in the art that embodiments described herein may be practiced without one or more of these specific details. In other instances, well-known features have not been described in order to avoid obscuring the details of the embodiments.

[0026] System Overview

[0027] Figure 1 is a block diagram of a processing system 100 according to an embodiment. In various embodiments, system 100 includes one or more processors 102 and one or more graphics processors 108, and may be a single-processor desktop system, a multi-processor workstation system, or a server system with a large number of processors 102 or processor cores 107. In one embodiment, system 100 is a processing platform incorporated within a system-on-chip (SoC) integrated circuit used in a mobile device, a handheld device, or an embedded device.

[0028] In one embodiment, system 100 may include, or be incorporated within, a server-based gaming platform, a game console (including a game and media console, a mobile game console, a handheld game console, or an online game console). In some embodiments, system 100 is a mobile phone, a smartphone, a tablet computing device, or a mobile Internet device. The processing system 100 may also include, be coupled to, or be integrated within a wearable device (e.g., a smartwatch wearable device, a smart glasses device, an augmented reality device, or a virtual reality device). In some embodiments, the processing system 100 is a television or set-top box device having one or more processors 102 and a graphical interface generated by one or more graphics processors 108.

[0029] In some embodiments, each of the one or more processors 102 includes one or more processor cores 107 to process instructions that, when executed, perform operations for system and user software. In some embodiments, each of the one or more processor cores 107 is configured to process a particular instruction set 109. In some embodiments, the instruction set 109 may facilitate complex instruction set computing (CISC), reduced instruction set computing (RISC), or computing via very long instruction words (VLIW). The multiple processor cores 107 may each process a different instruction set 109, which may include instructions for facilitating the emulation of other instruction sets. The processor cores 107 may also include other processing devices (e.g., a digital signal processor (DSP)).

[0030] 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 caches. In some embodiments, the cache memory is shared among the various components of the processor 102. In some embodiments, the processor 102 also uses an external cache (e.g., a level 3 (L3) cache or a last level cache (LLC)) (not shown), which may be shared among the processor cores 107 using known cache coherence techniques. A register file 106 is also included in the processor 102, which may include different types of registers for storing different types of data (e.g., integer registers, floating point registers, status registers, and instruction pointer registers). Some registers may be general purpose registers, while other registers may be dedicated to the design of the processor 102.

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

[0032] The memory device 120 can 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 can operate as a system memory for the system 100 to store data 122 and instructions 121 for use when one or more processors 102 execute an application or process. The memory controller 116 is also coupled to an optional external graphics processor 112, which can communicate with one or more of the graphics processors 108 in the processor 102 to perform graphics operations and media operations. In some embodiments, a display device 111 can be connected to the processor 102. The display device 111 can 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., DisplayPort, etc.). In one embodiment, the display device 111 can be a head-mounted display (HMD) (e.g., a stereoscopic display device for virtual reality (VR) applications or augmented reality (AR) applications).

[0033] 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 peripheral devices 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., a hard disk drive, a flash memory, etc.). The data storage device 124 can be connected via a storage interface (e.g., SATA) or via a peripheral bus (e.g., a peripheral component interconnect bus (e.g., PCI, PCI Express)). The touch sensor 125 can include a touch screen sensor, a pressure sensor, or a fingerprint sensor. The wireless transceiver 126 can be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver (e.g., a 3G, 4G, or long term evolution (LTE) transceiver). The firmware interface 128 enables communication with system firmware and can be, for example, a unified extensible firmware interface (UEFI). The network controller 134 can enable a network connection to a wired network. In some embodiments, a high-performance network controller (not shown) is coupled to the interface bus 110. The audio controller 146 is a multi-channel high-definition audio controller in one embodiment. In one embodiment, the system 100 includes an optional legacy I / O controller 140 for coupling legacy (e.g., personal system 2 (PS / 2)) devices to the system. The platform controller hub 130 can also be connected to one or more universal serial bus (USB) controllers 142, which connect input devices (e.g., a keyboard and mouse 143 combination, a camera 144, or other USB input devices).

[0034] It should be understood that the illustrated system 100 is exemplary and not restrictive, as other types of data processing systems configured differently can also be used. For example, instances of the memory controller 116 and the platform controller hub 130 can be integrated into a discrete external graphics processor (e.g., the external graphics processor 112). In one embodiment, the platform controller hub 130 and / or the memory controller 160 can be external to one or more of the processors 102. For example, the system 100 can include an external memory controller 116 and a platform controller hub 130, which can be configured as a memory controller hub and a peripheral controller hub within a system-on-chip for communicating with the processor 102.

[0035] Figure 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. Figure 2 Those elements with the same reference numerals (or names) as elements in any other figure herein can operate or function in any manner similar to the manner described elsewhere herein, but are not limited thereto. The processor 200 can 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 can also access one or more shared cache units 206.

[0036] The internal cache units 204A - 204N and the shared cache units 206 represent the cache memory hierarchy within the processor 200. The cache memory hierarchy can include at least one level of instruction and data cache within each processor core and one or more levels of shared intermediate - level caches (e.g., level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache), where the highest - level cache before external memory is classified as the LLC. In some embodiments, cache coherence logic maintains coherence between the respective cache units 206 and 204A - 204N.

[0037] In some embodiments, the processor 200 can 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 (e.g., one or more PCI 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 to manage access to various external memory devices (not shown).

[0038] In some embodiments, one or more of the processor cores 202A - 202N include support for simultaneous multithreading. In this embodiment, 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 states of the processor cores 202A - 202N and the graphics processor 208.

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

[0040] In some embodiments, a ring - based interconnect unit 212 is used to couple the internal components of the processor 200. However, alternative interconnect units (e.g., point - to - point interconnects, switched interconnects, or other techniques, including techniques well - known in the art) may be used. In some embodiments, the graphics processor 208 is coupled to the ring interconnect 212 via an I / O link 213.

[0041] The exemplary I / O link 213 represents at least one of a variety of I / O interconnects, including an on - package I / O interconnect that facilitates communication between various processor components and a high - performance embedded memory module 218 (e.g., an eDRAM module). In some embodiments, each of the processor cores 202A - 202N and the graphics processor 208 uses the embedded memory module 218 as a shared last - level cache.

[0042] 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), where one or more of the processor cores 202A - 202N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment, the processor cores 202A - 202N are heterogeneous in terms of microarchitecture, where one or more cores with relatively high power consumption are coupled to one or more cores with lower power consumption. Additionally, the processor 200 may be implemented on one or more chips, or implemented as a SoC integrated circuit having the shown components in addition to other components.

[0043] Figure 3 is a block diagram of a graphics processor 300, which can be a discrete graphics processing unit or can be a graphics processor integrated with multiple processing cores. In some embodiments, the graphics processor communicates via a memory-mapped I / O interface to registers on the graphics processor and with commands placed in the processor memory. In some embodiments, the graphics processor 300 includes a memory interface 314 for accessing memory. The memory interface 314 can be an interface to local memory, one or more internal caches, one or more shared external caches, and / or an interface to system memory.

[0044] In some embodiments, the graphics processor 300 also includes a display controller 302 to drive display output data to a display device 320. The display controller 302 includes hardware for one or more overlay planes for displaying and compositing multi-layer video or user interface elements. The display device 320 can be an internal or external display device. In one embodiment, the display device 320 is a head-mounted display device (e.g., a virtual reality (VR) display device or an augmented reality (AR) display device). In some embodiments, the graphics processor 300 includes a video codec engine 306 to encode media to, decode media from, or transcode between one or more media encoding formats including, but not limited to, Moving Picture Experts Group (MPEG) formats (e.g., MPEG-2), Advanced Video Coding (AVC) formats (e.g., H.264 / MPEG-4 AVC), and Society of Motion Picture and Television Engineers (SMPTE) 421M / VC-1 and Joint Photographic Experts Group (JPEG) formats (e.g., JPEG and Motion JPEG (MJPEG) formats).

[0045] In some embodiments, the graphics processor 300 includes a block image transfer (BLIT) engine 304 to perform 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 a graphics processing engine (GPE) 310. In some embodiments, the GPE 310 is a computing engine for performing graphics operations including three-dimensional (3D) graphics operations and media operations.

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

[0047] In some embodiments, the media pipeline 316 includes fixed function or programmable logic units to perform one or more dedicated media operations (e.g., video decoding acceleration, video deinterlacing, and video encoding acceleration) in place of or on behalf of the video codec engine 306. In some embodiments, the media pipeline 316 additionally includes a thread generation unit to generate threads for execution on the 3D / media subsystem 315. The generated threads perform calculations on media operations on one or more graphics execution units included in the 3D / media subsystem 315.

[0048] In some embodiments, the 3D / media subsystem 315 includes logic for executing the threads generated by the 3D pipeline 312 and the media pipeline 316. In one embodiment, the pipeline sends thread execution requests to the 3D / media subsystem 315, which includes thread dispatch logic for arbitrating and dispatching various requests for available thread execution resources. The execution resources include an array of graphics execution units to process 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 shared memory (including registers and addressable memory) to share data between threads and store output data.

[0049] Graphics Processing Engine

[0050] 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 3 the version of the GPE 310 shown. Figure 4 Elements with the same reference numerals (or names) as elements in any other figure herein can operate or function in any manner similar to the ways described elsewhere herein, but are not limited thereto. For example, shown Figure 33D pipeline 312 and media pipeline 316. The media pipeline 316 is optional in some embodiments of the GPE 410 and may not be explicitly included within the GPE 410. For example, and in at least one embodiment, a separate media and / or image processor is coupled to the GPE 410.

[0051] In some embodiments, the GPE 410 is coupled to or includes a command streamer 403 that provides a command stream to the 3D pipeline 312 and / or the media pipeline 316. In some embodiments, the command streamer 403 is coupled to a memory, which can be system memory, or one or more of an internal cache memory and a shared cache memory. In some embodiments, the command streamer 403 receives commands from the memory and sends the commands to the 3D pipeline 312 and / or the media pipeline 316. The commands are directives fetched from a ring buffer that stores commands for the 3D pipeline 312 and the media pipeline 316. In one embodiment, the ring buffer can additionally include a batch command buffer that stores batches of multiple commands. Commands for the 3D pipeline 312 can also include references to data stored in the memory, such as but not limited to vertex and geometry data for the 3D pipeline 312 and image data and memory objects for the media pipeline 316. The 3D pipeline 312 and the media pipeline 316 process commands and data by executing operations via logic within each pipeline or by dispatching one or more execution threads to the graphics core array 414. In one embodiment, the graphics core array 414 includes one or more blocks of graphics cores (e.g., graphics core 415A, graphics core 415B), and each block includes one or more graphics cores. Each graphics core includes a set of graphics execution resources that include general-purpose and graphics-specific execution logic for performing graphics and computing operations, as well as fixed-function texture processing and / or machine learning and artificial intelligence acceleration logic.

[0052] In various embodiments, the 3D pipeline 312 includes fixed-function and programmable logic to process one or more shader programs (e.g., vertex shader, geometry shader, pixel shader, fragment shader, compute shader, or other shader programs) by processing instructions and dispatching execution threads to the graphics core array 414. The graphics core array 414 provides a unified block of execution resources for use in processing these shader programs. The multi-purpose execution logic (e.g., execution units) within the graphics cores 415A - 414B of the graphics core array 414 includes support for various 3D API shader languages and can execute multiple simultaneously-executing threads associated with multiple shaders.

[0053] In some embodiments, the graphics core array 414 further includes execution logic for performing media functions (e.g., video and / or image processing). In one embodiment, the execution units additionally include general-purpose logic programmable to perform parallel general-purpose computing operations in addition to graphics processing operations. The general-purpose logic can perform processing operations in parallel with or in combination with the processor core 107 of Figure 1 or the general-purpose logic within the core 202A - 202N as in Figure 2 .

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

[0055] In some embodiments, the graphics core array 414 is scalable such that the array includes a variable number of graphics cores, and each graphics core has a variable number of execution units based on the target power and performance levels of the GPE 410. In one embodiment, the execution resources are dynamically scalable such that the execution resources can be enabled or disabled as needed.

[0056] The graphics core array 414 is coupled to the shared function logic 420, which includes multiple resources shared among the graphics cores in the graphics core array. The shared functions within the shared function logic 420 are hardware logic units that provide dedicated complementary functions to the graphics core array 414. In various embodiments, the shared function logic 420 includes, but is not limited to, a sampler 421, a math unit 422, and inter-thread communication (ITC) 423 logic. Additionally, some embodiments implement one or more caches 425 within the shared function logic 420.

[0057] In cases where the demand for a given specialized function is not sufficient to be included within the graphics core array 414, a shared function is implemented. Instead, a single instantiation of the specialized function is implemented as a separate entity within the shared function logic 420 and shared among the execution resources within the graphics core array 414. The exact set of functions that are shared among and included within the graphics core arrays 414 varies with the embodiment. In some embodiments, certain shared functions that are widely used by the graphics core arrays 414 within the shared function logic 420 may be included within the shared function logic 416 within the graphics core array 414. In various embodiments, the shared function logic 416 within the graphics core array 414 may include some or all of the logic within the shared function logic 420. In one embodiment, all of the logic elements within the shared function logic 420 may be replicated within the shared function logic 416 of the graphics core array 414. In one embodiment, the shared function logic 420 is excluded to support the shared function logic 416 within the graphics core array 414.

[0058] Figure 5 is a block diagram of the hardware logic of a graphics processor core 500 according to some embodiments described herein. Figure 5 Elements with the same reference numerals (or names) as elements in any other figure herein may operate or function in any manner similar to the ways described elsewhere herein, but are not limited thereto. The illustrated graphics processor core 500 is included within the Figure 4 graphics core array 414 in some embodiments. The graphics processor core 500 (sometimes referred to as a core slice) may be one or more graphics cores within a modular graphics processor. The graphics processor core 500 is an example of a graphics core slice, and a graphics processor as described herein may include multiple graphics core slices based on the target power and performance envelope. Each graphics core 500 may include a fixed function block 530 coupled to a plurality of sub-cores 501A - 501F (also referred to as sub-slices), where the sub-cores include modular blocks of general and fixed function logic.

[0059] In some embodiments, the fixed function block 530 includes a geometry / fixed function pipeline 536, which may be shared, for example, by all of the sub-cores within the graphics processor 500 in lower performance and / or lower power graphics processor implementations. In various embodiments, the geometry / fixed function pipeline 536 includes a 3D fixed function pipeline (e.g., the 3D pipeline 312 as in Figure 3 and Figure 4 ), a video front end unit, a thread generator and thread dispatcher, and a unified return buffer manager that manages a unified return buffer (e.g., Figure 4 's unified return buffer 418).

[0060] In one embodiment, the fixed function block 530 further includes a graphics SoC interface 537, a graphics microcontroller 538, and a media pipeline 539. The graphics SoC interface 537 provides an interface between the graphics core 500 and other processor cores within the system-on-chip integrated circuit. The graphics microcontroller 538 is a programmable sub-processor that can be configured to manage various functions of the graphics processor 500, including thread dispatch, scheduling, and preemption. The media pipeline 539 (e.g., Figure 3 and Figure 4 the media pipeline 316) includes logic for facilitating the decoding, encoding, preprocessing, and / or postprocessing of multimedia data, including image and video data. The media pipeline 539 implements media operations via requests to the computation or sampling logic within the sub-cores 501 - 501F.

[0061] In one embodiment, the SoC interface 537 enables the graphics core 500 to communicate with a general-purpose application processor core (e.g., a CPU) and / or other components within the SoC, including memory hierarchy elements (e.g., a shared last-level cache memory, system RAM, and / or embedded on-chip or package-on DRAM). The SoC interface 537 can also enable communication with fixed function devices within the SoC (e.g., a camera imaging pipeline), and enable the use and / or implementation of global memory atoms that can be shared between the graphics core 500 and the CPU within the SoC. The SoC interface 537 can also implement power management control for the graphics core 500 and enable an interface between the clock domain of the graphics core 500 and other clock domains within the SoC. In one embodiment, the SoC interface 537 enables receipt of a command buffer from a command streamer and global thread dispatcher configured to provide commands and instructions to each of one or more graphics cores within the graphics processor. The commands and instructions can be dispatched to the media pipeline 539 when a media operation is to be performed, or to the geometry and fixed function pipelines (e.g., geometry and fixed function pipeline 536, geometry and fixed function pipeline 514) when a graphics processing operation is to be performed.

[0062] The graphics microcontroller 538 can be configured to perform various scheduling and management tasks for the graphics core 500. In one embodiment, the graphics microcontroller 538 can execute graphics and / or compute workload scheduling on individual graphics parallel engines within the execution unit (EU) arrays 502A - 502F, 504A - 504F within the sub - cores 501A - 501F. In this scheduling model, host software executing on the CPU cores of the SoC, including the graphics core 500, can submit a workload to one of multiple graphics processor doorbells, which invokes a scheduling operation on the appropriate graphics engine. The scheduling operations include: determining which workload to run next; submitting the workload to the command streamer; preempting an existing workload running on the engine; monitoring the progress of the workload; and notifying the host software when the workload is complete. In one embodiment, the graphics microcontroller 538 can also facilitate the low - power or idle state of the graphics core 500, providing the ability to save and restore registers within the graphics core 500 across low - power state transitions, independent of the operating system and / or graphics driver software on the system.

[0063] The graphics core 500 can have more or fewer sub - cores than the shown sub - cores 501A - 501F, up to N modular sub - cores. For each set of N sub - cores, the graphics core 500 can also include shared functional logic 510, shared and / or cache memory 512, a geometry / fixed - function pipeline 514, and additional fixed - function logic 516 for accelerating various graphics and compute processing operations. The shared functional logic 510 can include logical units (e.g., samplers, math units, and / or inter - thread communication logic) associated with Figure 4 the shared functional logic 420, which can be shared by each N sub - cores within the graphics core 500. The shared and / or cache memory 512 can be the last - level cache for the set of N sub - cores 501A - 501F within the graphics core 500 and can also act as shared memory accessible by multiple sub - cores. The geometry / fixed - function pipeline 514, rather than the geometry / fixed - function pipeline 536, can be included within the fixed - function block 530 and can include the same or similar logical units.

[0064] In one embodiment, the graphics core 500 includes additional fixed function logic 516, which may include various fixed function acceleration logics used by the graphics core 500. In one embodiment, the additional fixed function logic 516 includes an additional geometry pipeline used in position-only shading. In position-only shading, there are two geometry pipelines: the full geometry pipeline within the geometry / fixed function pipelines 516, 536; and the culling pipeline, which is an additional geometry pipeline that may be included within the additional fixed function logic 516. In one embodiment, the culling pipeline is a reduced version of the full geometry pipeline. The full pipeline and the culling pipeline may execute different instances of the same application, each instance having a separate context. Position-only shading may hide long culling runs on discarded triangles, enabling shading to complete earlier in some cases. For example, and in one embodiment, the culling pipeline logic within the additional fixed function logic 516 may execute the position shader in parallel with the main application and generally generate key results faster than the full pipeline because the culling pipeline only fetches and shades the position attributes of the vertices and does not rasterize and render pixels to the frame buffer. The culling pipeline may use the generated key results to calculate the visibility information for all triangles, regardless of whether those triangles are culled. The full pipeline (which may be referred to as the playback pipeline in this instance) may use the visibility information to skip the culled triangles to only shade the visible triangles that ultimately make it to the rasterization stage.

[0065] In one embodiment, the additional fixed function logic 516 may further include machine learning acceleration logic (e.g., fixed function matrix multiplication logic for implementations optimized for machine learning training or inference).

[0066] Each graphics sub-core 501A - 501F includes a set of execution resources that can be used to perform graphics, media, and compute operations in response to requests made by the graphics pipeline, media pipeline, or shader program. The graphics sub-cores 501A - 501F include multiple EU arrays 502A - 502F, 504A - 504F, thread dispatch and inter-thread communication (TD / IC) logic 503A - 503F, 3D (e.g., texture) samplers 505A - 505F, media samplers 506A - 506F, shader processors 507A - 507F, and shared local memory (SLM) 508A - 508F. The EU arrays 502A - 502F, 504A - 504F each include multiple execution units, which are general-purpose graphics processing units capable of performing floating-point and integer / fixed-point logic operations (including graphics, media, or compute shader programs) in the service of graphics, media, or compute operations. The TD / IC logic 503A - 503F performs local thread dispatch and thread control operations for the execution units within the sub-core and facilitates communication between the threads executing on the execution units of the sub-core. The 3D samplers 505A - 505F can read texture or other 3D graphics-related data into memory. The 3D samplers can read texture data differently based on the configured sampling state and the texture format associated with a given texture. The media samplers 506A - 506F can perform similar read operations based on the type and format associated with media data. In one embodiment, each graphics sub-core 501A - 501F may alternatively include a unified 3D and media sampler. Threads executing on the execution units within each of the sub-cores 501A - 501F can use the shared local memory 508A - 508F within each sub-core so that threads executing within a thread group can execute using a common pool of on-chip memory.

[0067] Execution unit

[0068] Figures 6A - 6B Illustrates thread execution logic 600 according to an embodiment described herein, which includes an array of processing elements employed in a graphics processor core. Figures 6A - 6B Elements with the same reference numerals (or names) as elements in any other figure herein may operate or function in any manner similar to the manner described elsewhere herein, but are not limited thereto. Figure 6A Illustrates an overview of thread execution logic 600, which may include Figure 5 a variation of the hardware logic shown for each of the sub-cores 501A - 501F. Figure 6B Illustrates exemplary internal details of an execution unit.

[0069] As Figure 6AAs shown, in some embodiments, the thread execution logic 600 includes a shader processor 602, a thread dispatcher 604, an instruction cache 606, a scalable execution unit array including a plurality of execution units 608A - 608N, a sampler 610, a data cache 612, and a data port 614. In one embodiment, the scalable execution unit array can be dynamically scaled by enabling or disabling one or more execution units (e.g., any one of execution units 608A, 608B, 608C, 608D through 608N - 1 and 608N) based on the computational requirements of the workload. In one embodiment, the included components are interconnected via an interconnect fabric linked to each component. In some embodiments, the thread execution logic 600 includes one or more connections to memory (e.g., system memory or cache memory) through the instruction cache 606, the data port 614, the sampler 610, and one or more of the execution units 608A - 608N. In some embodiments, each execution unit (e.g., 608A) is a separate programmable general - purpose computing unit capable of executing multiple simultaneous hardware threads while processing multiple data elements in parallel for each thread. In various embodiments, the array of execution units 608A - 608N can be scaled to include any number of individual execution units.

[0070] In some embodiments, the execution units 608A - 608N are primarily used to execute shader programs. The shader processor 602 can process various shader programs and dispatch execution threads associated with the shader programs via the thread dispatcher 604. In one embodiment, the thread dispatcher includes logic for arbitrating thread initiation requests from the graphics and media pipelines and instantiating the requested threads on one or more of the execution units 608A - 608N. For example, the geometry pipeline can dispatch vertex shaders, tessellation shaders, or geometry shaders to the thread execution logic for processing. In some embodiments, the thread dispatcher 604 can also handle runtime thread spawn requests from executing shader programs.

[0071] In some embodiments, execution units 608A - 608N support an instruction set that includes native support for many standard 3D graphics shader instructions, enabling shader programs from graphics libraries (e.g., Direct3D and OpenGL) to be executed with minimal translation. The execution units support vertex and geometry processing (e.g., vertex programs, geometry programs, vertex shaders), pixel processing (e.g., pixel shaders, fragment shaders), and general - purpose processing (e.g., compute and media shaders). Each of the execution units 608A - 608N is capable of multiple - issue single - instruction multiple - data (SIMD) execution, and multi - threading operations enable an efficient execution environment in the face of higher - latency memory accesses. Each hardware thread within each execution unit has a dedicated high - bandwidth register file and associated independent thread state. Execution is multiple - issue per clock for pipelines capable of integer, single - precision, and double - precision floating - point operations, SIMD branch capabilities, logical operations, transcendental operations, and other miscellaneous operations. While waiting for data from one of the memories or shared functions, the dependency logic within execution units 608A - 608N puts the waiting threads to sleep until the requested data has been returned. While the waiting threads are sleeping, the hardware resources can be contributed to process other threads. For example, during the latency associated with vertex shader operations, the execution units can perform operations for pixel shaders, fragment shaders, or other types of shader programs (including different vertex shaders).

[0072] Each of the execution units 608A - 608N operates on an array of data elements. The number of data elements is the "execution size" or the number of lanes for the instruction. Execution lanes are the logical units for data - element access, masking, and flow - control execution within an instruction. The number of lanes can be independent of the number of physical arithmetic - logic units (ALUs) or floating - point units (FPUs) for a particular graphics processor. In some embodiments, execution units 608A - 608N support integer and floating - point data types.

[0073] The execution - unit instruction set includes SIMD instructions. Various data elements can be stored in registers as packed data types, and the execution units will process the various elements based on the data size of the elements. For example, when operating on a 256 - bit - wide vector, the 256 bits of the vector are stored in a register, and the execution unit operates on the vector 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.

[0074] In one embodiment, one or more execution units may be combined into fused execution units 609A - 609N, which have thread control logic (607A - 607N) shared for the fused EUs. Multiple EUs may be fused into EU groups. Each EU in a fused EU group may be configured to execute a separate SIMD hardware thread. The number of EUs in a fused EU group may vary according to the embodiment. Additionally, various SIMD widths may be executed per EU, including but not limited to SIMD8, SIMD16, and SIMD32. Each fused graphics execution unit 609A - 609N includes at least two execution units. For example, fused execution unit 609A includes a first EU 608A, a second EU 608B, and thread control logic 607A shared for the first EU 608A and the second EU 608B. Thread control logic 607A controls the threads executed on fused graphics execution unit 609A, thereby allowing each EU within fused execution units 609A - 609N to execute using a common instruction pointer register.

[0075] One or more internal instruction caches (e.g., 606) are included in thread execution logic 600 to cache thread instructions for the execution units. In some embodiments, one or more data caches (e.g., 612) are included to cache thread data during thread execution. In some embodiments, a sampler 610 is included to provide texture sampling for 3D operations and media sampling for media operations. In some embodiments, sampler 610 includes dedicated texture or media sampling functionality to process texture or media data during the sampling process and then provide the sampled data to the execution units.

[0076] During execution, the graphics and media pipeline send thread initiation requests to the thread execution logic 600 via the thread generation and dispatch logic. Once a set of geometric objects have been processed and rasterized into pixel data, the pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within the shader processor 602 is called to further compute output information and write the results to an output surface (e.g., color buffer, depth buffer, stencil buffer, etc.). In some embodiments, the pixel shader or fragment shader computes the values of various vertex attributes to be interpolated over the rasterized objects. In some embodiments, the pixel processor logic within the shader processor 602 then executes a pixel or fragment shader program provided by an application programming interface (API). To execute the shader program, the shader processor 602 dispatches threads to execution units (e.g., 608A) via the thread dispatcher 604. In some embodiments, the shader processor 602 uses the texture sampling logic in the sampler 610 to access texture data in a texture map stored in memory. Arithmetic operations on the texture data and the input geometric data compute the pixel color data for each geometric fragment, or discard one or more pixels from further processing.

[0077] In some embodiments, the data port 614 provides a memory access mechanism for the thread execution logic 600 to output processed data to memory for further processing on the graphics processor output pipeline. In some embodiments, the data port 614 includes or is coupled to one or more cache memories (e.g., the data cache 612) to cache data for memory access via the data port.

[0078] As Figure 6B shown, the graphics execution unit 608 can include an instruction fetch unit 637, a general register file array (GRF) 624, an architectural register file array (ARF) 626, a thread arbiter 622, a send unit 63, a branch unit 632, a set of SIMD floating-point units (FPU) 634, and in one embodiment, also includes a set of dedicated integer SIMD ALUs 635. The GRF 624 and ARF 626 include a collection of general register files and architectural register files associated with each simultaneously active hardware thread that may be in the graphics execution unit 608. In one embodiment, the per-thread architectural state is saved in the ARF 626, while the data used during thread execution is stored in the GRF

[0079] In one embodiment, the graphics execution unit 608 has an architecture that is a combination of simultaneous multithreading (SMT) and fine-grained interleaved multithreading (IMT). This architecture has a modular configuration that can be finely adjusted at design time based on the target number of simultaneous threads and the number of registers per execution unit, where the execution unit resources are partitioned logically for executing multiple simultaneous threads.

[0080] In one embodiment, the graphics execution unit 608 can issue multiple instructions concurrently, and the multiple instructions can each be a different instruction. The thread arbiter 622 of the graphics execution unit 608 can dispatch an instruction to one of the send unit 630, the branch unit 642, or the SIMD FPU 634 for execution. Each execution thread can access 128 general-purpose registers within the GRF 624, where each register can store 32 bytes and can be accessed as a SIMD8 element vector of 32-bit data elements. In one embodiment, each execution unit thread can access 4 kilobytes within the GRF 624, but the embodiments are not limited thereto, and more or fewer register resources can be provided in other embodiments. In one embodiment, up to seven threads can execute simultaneously, but the number of threads per execution unit can also vary according to the embodiment. In an embodiment where seven threads can access 4 kilobytes, the GRF 624 can store a total of 28 kilobytes. Flexible addressing modes can allow registers to be addressed together to efficiently construct wider registers or represent strided rectangular block data structures.

[0081] In one embodiment, "send" instructions executed via the messaging send unit 630 dispatch memory operations, sampler operations, and other longer-latency system communications. In one embodiment, branch instructions are dispatched to a dedicated branch unit 632 to facilitate SIMD divergence and eventual convergence.

[0082] In one embodiment, the graphics execution unit 608 includes one or more SIMD floating-point units (FPUs) 634 to perform floating-point operations. In one embodiment, the FPU 634 also supports integer computations. In one embodiment, the FPU 634 can perform up to M number of 32-bit floating-point (or integer) operations SIMD, or perform up to 2M of 16-bit integer or 16-bit floating-point operations SIMD. In one embodiment, at least one FPU provides extended mathematical capabilities to support high-throughput transcendental mathematical functions and double-precision 64-bit floating point. In some embodiments, there is also a set of 8-bit integer SIMD ALUs 635, and they can be specifically optimized to perform operations associated with machine learning computations.

[0083] In one embodiment, an array of multiple instances of the graphics execution unit 608 can be instantiated in a graphics sub-core group (e.g., a sub-slice). For scalability, the product architect can select the exact number of execution units per sub-core group. In one embodiment, the execution unit 608 can execute instructions on multiple execution channels. In another embodiment, each thread executed on the graphics execution unit 608 executes on a different channel.

[0084] Figure 7 FIG. 4 is a block diagram showing a graphics processor instruction format 700 according to some embodiments. In one or more embodiments, the graphics processor execution unit supports an instruction set with instructions of multiple formats. The solid boxes show components that are typically included in the execution unit instructions, while the dashed boxes include optional or components only included in a subset of the instructions. In some embodiments, the described and shown instruction format 700 is a macro-instruction, as they are the instructions provided to the execution unit, different from the micro-operations obtained from decoding the instructions once the instructions are processed.

[0085] In some embodiments, the graphics processor execution unit natively supports instructions in the 128-bit instruction format 710. Based on the selected instructions, instruction options, and the number of operands, a 64-bit compressed instruction format 730 is available for some instructions. The native 128-bit instruction format 710 provides access to all instruction options, while some options and operations are restricted in the 64-bit format 730. The native instructions available in the 64-bit format 730 vary by embodiment. In some embodiments, a set of index values in the index field 713 is used in part to compress the instructions. The execution unit hardware references a set of compression tables based on the index values and uses the compression table output to reconstruct the native instructions in the 128-bit instruction format 710.

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

[0087] Some execution unit instructions have up to three operands, which include two source operands src0720, src1 722, and one destination operand 718. In some embodiments, the execution unit supports dual-destination operand instructions, where one of the destination operands 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 the instruction may be an immediate (e.g., hard-coded) value passed with the instruction.

[0088] In some embodiments, the 128-bit instruction format 710 includes an access / address mode field 726 that indicates, for example, whether to use direct register addressing mode or indirect register addressing mode. When using direct register addressing mode, the register addresses of one or more operands are provided directly by bits in the instruction.

[0089] In some embodiments, the 128-bit instruction format 710 includes an access / address mode field 726 that indicates the address mode and / or access mode for 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 alignment access mode and 1-byte alignment access mode, where the byte alignment of the access mode determines the access alignment of the instruction operands. For example, when in the first mode, the instruction may use byte-aligned addressing for source and destination operands, and when in the second mode, the instruction may use 16-byte-aligned addressing for all source and destination operands.

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

[0091] In some embodiments, instructions are grouped based on the 712-bit opcode field to simplify opcode decoding 740. For an 8-bit opcode, bits 4, 5, and 6 allow the execution unit to determine the type of opcode. The exact opcode grouping shown is merely an example. In some embodiments, the move and logic opcode group 742 includes data move and logic instructions (e.g., move (mov), compare (cmp)). In some embodiments, the move and logic group 742 shares the five most significant bits (MSBs), where the move (mov) instruction is in the form of 0000xxxxb, and the logic instruction is in the form of 0001xxxxb. The flow control instruction group 744 (e.g., call, jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 746 includes a mix of instructions, including synchronization instructions (e.g., wait, send) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group 748 includes component arithmetic instructions (e.g., add, multiply (mul)) in the form of 0100xxxxb (e.g., 0x40). The parallel math group 748 performs arithmetic operations in parallel on data channels. The vector math group 750 includes arithmetic instructions (e.g., dp4) in the form of 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic (e.g., dot product calculation) on vector operands.

[0092] Graphics pipeline

[0093] Figure 8 is a block diagram of another embodiment of the graphics processor 800. Figure 8 Elements with the same reference numerals (or names) as elements in any other figure herein can operate or function in any manner similar to those described elsewhere herein, but are not limited thereto.

[0094] In some embodiments, the graphics processor 800 includes a geometry pipeline 820, a media pipeline 830, a display engine 840, thread execution logic 850, and a render 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 writing to registers of one or more control registers (not shown) or by commands issued via the ring interconnect 802 to the graphics processor 800. In some embodiments, the ring interconnect 802 couples the graphics processor 800 to other processing components (e.g., other graphics processors or general-purpose processors). Commands from the ring interconnect 802 are interpreted by a command streamer 803, which provides instructions to the components of the geometry pipeline 820 or the media pipeline 830.

[0095] In some embodiments, command streamer 803 directs the operation of vertex fetcher 805, which reads vertex data from memory and executes vertex processing commands provided by command streamer 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 execution units 852A - 852B via thread dispatcher 831.

[0096] In some embodiments, execution units 852A - 852B are an array of vector processors having an instruction set for performing graphics and media operations. In some embodiments, execution units 852A - 852B have attached L1 caches 851, which are specific to each array or shared between the arrays. The cache can be configured as a data cache, an instruction cache, or a single cache partitioned to contain data and instructions in different partitions.

[0097] In some embodiments, geometry pipeline 820 includes a tessellation component to perform hardware - accelerated tessellation of 3D objects. In some embodiments, programmable hull shader 811 configures the tessellation operation. Programmable domain shader 817 provides back - end evaluation of the tessellation output. Tessellator 813 operates under the guidance of hull shader 811 and includes dedicated logic to generate a set of detailed geometric objects based on a coarse geometric model provided as input to geometry pipeline 820. In some embodiments, if tessellation is not used, the tessellation components (e.g., hull shader 811, tessellator 813, and domain shader 817) can be bypassed.

[0098] In some embodiments, all geometric objects can be processed by geometry shader 819 via one or more threads dispatched to execution units 852A - 852B, or can go directly into clipper 829. In some embodiments, the geometry shader can operate on entire geometric objects rather than vertices or vertex patches in the previous stages of the graphics pipeline. If tessellation is disabled, geometry shader 819 receives input from vertex shader 807. In some embodiments, geometry shader 819 can be programmed by a geometry shader program to perform geometric tessellation when the tessellation unit is disabled.

[0099] Before rasterization, the clipper 829 processes vertex data. The clipper 829 can be a fixed-function clipper or a programmable clipper with clipping and geometry shader functionality. In some embodiments, the rasterizer and depth test component 873 in the render output pipeline 870 dispatches pixel shaders to convert geometric objects into per-pixel representations. In some embodiments, the pixel shader logic is included in the thread execution logic 850. In some embodiments, an application can bypass the rasterizer and depth test component 873 and access the un-rasterized vertex data via the stream output unit 823.

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

[0101] 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. Associated render cache 878 and depth cache 879 are also available in some embodiments. The pixel operation component 877 performs pixel-based operations on the data, but in some instances, pixel operations associated with 2D operations (e.g., bit-block blitting in blending scenarios) are performed by the 2D engine 841 or by the display controller 843 using an overlay display plane during display. In some embodiments, the shared L3 cache 875 is available to all graphics components, allowing data to be shared without using the main system memory.

[0102] In some embodiments, the graphics processor 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 streamer 803. In some embodiments, the media pipeline 830 includes a separate command streamer. In some embodiments, the video front end 834 processes media commands before sending them to the media engine 837. In some embodiments, the media engine 837 includes a thread generation function to generate threads for dispatch to the thread execution logic 850 via the thread dispatcher 831.

[0103] In some embodiments, the graphics processor 800 includes a display engine 840. In some embodiments, the display engine 840 is external to the processor 800 and is coupled to the graphics processor via a ring interconnect 802 or some other interconnect bus or fabric. In some embodiments, the display engine 840 includes a 2D engine 841 and a display controller 843. In some embodiments, the display engine 840 includes 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 may be a system integrated display device in a laptop computer or an external display device attached via a display device connector.

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

[0105] Graphics Pipeline Programming

[0106] Figure 9A is a block diagram showing a graphics processor command format 900 according to some embodiments. Figure 9B is a block diagram showing a graphics processor command sequence 910 according to an embodiment. Figure 9A The solid boxes in show components that are typically included in a graphics command, while the dashed boxes include optional or components that are only included in a subset of graphics commands. Figure 9A An exemplary graphics processor command format 900 includes a data field for identifying a client 902, a command opcode (opcode) 904, and data 906 for the command. A sub-opcode 905 and a command size 908 are also included in some commands.

[0107] In some embodiments, client 902 designates the client unit of the graphics device that processes command data. In some embodiments, the graphics processor command parser examines the client field of each command to condition further processing of the command and routes the command data to the appropriate client unit. In some embodiments, the graphics processor client units include 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 client unit receives a command, the client unit reads the opcode 904 and (if present) sub-opcode 905 to determine the operation to be performed. The client unit executes the command using the information in the data field 906. For some commands, an explicit command size 908 is expected to indicate the size of the command. In some embodiments, the command parser automatically determines the size of at least some commands based on the command opcode. In some embodiments, commands are aligned by multiples of a double word.

[0108] Figure 9B The flowchart in shows an exemplary graphics processor command sequence 910. In some embodiments, software or firmware of a data processing system characterized by an embodiment of the graphics processor uses a version of the shown command sequence to set up, execute, and terminate a set of graphics operations. The sampled command sequence is shown and described only for purposes of example, as embodiments are not limited to these particular commands or this command sequence. Additionally, commands may be issued as batch commands in a command sequence such that the graphics processor will process the sequence of commands at least partially in parallel.

[0109] In some embodiments, the graphics processor command sequence 910 may begin with a pipeline flush command 912 to cause any active graphics pipeline to complete the current outstanding commands for the pipeline. In some embodiments, the 3D pipeline 922 and the media pipeline 924 do not operate in parallel. The pipeline flush is performed to cause the active graphics pipeline to complete any outstanding commands. In response to the pipeline flush, the command parser for the graphics processor will suspend command processing until the active drawing engine has completed the outstanding operations and the associated read caches have been invalidated. Optionally, any data marked "dirty" in the render cache may be flushed to memory. In some embodiments, the pipeline flush command 912 may be used for pipeline synchronization or before placing the graphics processor in a low power state.

[0110] In some embodiments, a pipeline select command 913 is used when the command sequence requires the graphics processor to explicitly switch between pipelines. In some embodiments, only one pipeline select command 913 is required within an execution context before issuing pipeline commands, unless commands are to be issued for two pipelines in the context. In some embodiments, a pipeline flush command 912 is required immediately prior to switching pipelines via the pipeline select command 913.

[0111] 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 the pipeline state of the active pipeline. In one embodiment, pipeline control commands 914 are used for pipeline synchronization and to flush data from one or more cache memories within the active pipeline before processing a batch of commands.

[0112] In some embodiments, return buffer status commands 916 are used to configure a set of return buffers for each pipeline to write data. Some pipeline operations require allocating, selecting, or configuring one or more return buffers to 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 status 916 includes selecting the size and number of return buffers to be used for a set of pipeline operations.

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

[0114] The commands used to configure the 3D pipeline state 930 include 3D state setup commands for vertex buffer state, vertex element state, constant color state, depth buffer state, and other state variables to be configured before processing 3D primitive commands. The values of these commands are determined 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 specific pipeline elements if those elements are not to be used.

[0115] In some embodiments, the 3D primitive 932 command is used to submit 3D primitives for processing by the 3D pipeline. The commands and associated parameters passed to the graphics processor via the 3D primitive 932 command are forwarded to the vertex fetch function in the graphics pipeline. The vertex fetch function uses the 3D primitive 932 command data to generate vertex data structures. The vertex data structures are stored in one or more return buffers. In some embodiments, the 3D primitive 932 command is used to perform vertex operations on the 3D primitives via the vertex shader. To process the vertex shader, the 3D pipeline 922 dispatches a shader execution thread to the graphics processor execution unit.

[0116] In some embodiments, the 3D pipeline 922 is triggered via the execution of a 934 command or an 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 one embodiment, a pipeline synchronization command is used to trigger command execution to flush the command sequence of the entire graphics pipeline. The 3D pipeline will perform geometric processing on 3D primitives. Once the operation is complete, the resulting geometric object is rasterized, and the pixel engine colors the resulting pixels. For those operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0117] In some embodiments, when performing media operations, the graphics processor command sequence 910 follows the media pipeline 924 path. Generally, the specific use and programming of the media pipeline 924 depend on the media or compute operation to be performed. Specific media decoding operations may be offloaded to the media pipeline during media decoding. In some embodiments, the media pipeline may also be bypassed, and media decoding may be performed in whole or in part using the resources provided by one or more general-purpose processing cores. In one embodiment, the media pipeline also includes elements for general-purpose graphics processing unit (GPGPU) operations, where 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.

[0118] In some embodiments, the media pipeline 924 is configured in a manner similar to the 3D pipeline 922. A set of commands for configuring the media pipeline state 940 are dispatched or placed into the command queue, 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 object. This includes data for configuring video decoding and video encoding logic within the media pipeline (e.g., 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 a batch of state settings.

[0119] In some embodiments, the media object commands 942 provide pointers to the media objects for processing by the media pipeline. The media objects include memory buffers that contain the video data to be processed. In some embodiments, all media pipeline states must be valid before issuing the media object commands 942. Once the pipeline state is configured and the media object commands 942 are queued, the media pipeline 924 is triggered via the execution of a 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.

[0120] Graphics Software Architecture

[0121] Figure 10 An exemplary graphics software architecture of a data processing system 1000 is shown in accordance with some embodiments. In some embodiments, the software architecture includes a 3D graphics application 1010, an operating system 1020, and at least one processor 1030. In some embodiments, the processor 1030 includes a graphics processor 1032 and one or more general-purpose processor cores 1034. Both the graphics application 1010 and the operating system 1020 are executed in the system memory 1050 of the data processing system.

[0122] In some embodiments, the 3D graphics application 1010 includes one or more shader programs including shader instructions 1012. The shader language instructions can be a high-level shader language (e.g., High-Level Shader Language (HLSL) or OpenGL Shading Language (GLSL)). The application also includes executable instructions 1014 in machine language suitable for execution by the general-purpose processor cores 1034. The application also includes graphics objects 1016 defined by vertex data.

[0123] In some embodiments, the operating system 1020 is an operating system from Microsoft Corporation, a private UNIX-like operating system, or an open-source UNIX-like operating system using a variant of the Linux kernel. The operating system 1020 can support a graphics API 1022 (e.g., Direct3D API, OpenGL API, or 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 in HLSL into a lower-level shader language. The compilation can be Just-In-Time (JIT) compilation, or the application can perform shader pre-compilation. In some embodiments, high-level shaders are compiled into low-level shaders during the compilation of the 3D graphics application 1010. In some embodiments, the shader instructions 1012 are provided in an intermediate form (e.g., a version of the Standard Portable Intermediate Representation (SPIR) used by the Vulkan API).

[0124] In some embodiments, the user-mode graphics driver 1026 includes a backend shader compiler 1027 to convert shader instructions 1012 into a hardware-specific representation. When the OpenGL API is in use, the shader instructions 1012 of 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 functionality 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.

[0125] IP core implementation

[0126] One or more aspects of at least one embodiment can be implemented by representative code stored on a machine-readable medium that represents and / or defines logic within an integrated circuit (e.g., a processor). For example, the machine-readable medium can include instructions representing various logics within the processor. When read by a machine, the instructions can cause the machine to fabricate logic to perform the techniques described herein. Such a representation (referred to as an "IP core") is a reusable logic unit of an integrated circuit and can be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model can be provided to various consumers or manufacturing facilities, which load the hardware model onto a construction machine for manufacturing the integrated circuit. The integrated circuit can be constructed such that the circuit performs operations described in association with any of the embodiments described herein.

[0127] Figure 11A is a block diagram showing an IP core development system 1100 that can be used to fabricate an integrated circuit to perform operations. The IP core development system 1100 can be used to generate modular, reusable designs that can be incorporated into larger designs or used to build an entire integrated circuit (e.g., an 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 generated or synthesized from the simulation model 1112. The RTL design 1115 is an abstraction of the behavior of an integrated circuit (including the associated logic executed using the modeled digital signals) that models the digital signal flow between hardware registers. In addition to the RTL design 1115, lower-level designs at the logic level or transistor level can also be generated, designed, or synthesized. Thus, the specific details of the initial design and simulation can vary.

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

[0129] Figure 11B A cross-sectional side view of an integrated circuit package assembly 1170 is shown in accordance with some embodiments described herein. The integrated circuit package assembly 1170 shows an implementation of one or more processor 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 can be implemented at least in part in configurable logic or fixed-function logic hardware and can include one or more portions of any of a processor core, a graphics processor, or other accelerator devices described herein. Each logic unit 1172, 1174 can be implemented within a semiconductor die and is coupled to the substrate 1180 via an interconnect structure 1173. The interconnect structure 1173 can be configured to route electrical signals between the logic 1172, 1174 and the substrate 1180 and can include interconnects (e.g., but not limited to bumps or posts). In some embodiments, the interconnect structure 1173 can be configured to route electrical signals (e.g., input / output (I / O) signals and / or power signals or ground signals associated with the operation of the logic 1172, 1174). In some embodiments, the substrate 1180 is an epoxy-based laminated substrate. In other embodiments, the package assembly 1170 can include other suitable types of substrates. The package assembly 1170 can be connected to other electrical devices via a 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 (e.g., a motherboard, other chip sets, or a multi-chip module).

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

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

[0132] Exemplary system-on-chip integrated circuit

[0133] Figures 12 - 1 FIG. 4 illustrates an exemplary integrated circuit and associated graphics processor that may be constructed using one or more IP cores, in accordance with various embodiments described herein. In addition to what is shown, other logic and circuitry may be included, including additional graphics processors / cores, peripheral interface controllers, or general purpose processor cores.

[0134] Figure 12 is a block diagram illustrating an exemplary system-on-chip integrated circuit 1200 that may be constructed using one or more IP cores, in accordance with 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, any of which may be modular IP cores from the same 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 2 S / I 2 C controller 1240. Additionally, 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 a flash memory and a flash memory controller. A memory interface may be provided via a memory controller 1265 for accessing SDRAM or SRAM memory devices. Some integrated circuits additionally include an embedded security engine 1270.

[0135] Figures 13A - 13B is a block diagram illustrating an exemplary graphics processor used within an SoC, in accordance with an embodiment described herein. Figure 13A Illustrates an exemplary graphics processor 1310 of a system-on-chip integrated circuit that may be constructed using one or more IP cores, in accordance with an embodiment. Figure 13BShows an additional exemplary graphics processor 1340 of a system-on-chip integrated circuit that can be constructed using one or more IP cores according to an embodiment. Figure 13A The graphics processor 1310 is an example of a low-power graphics processor core. Figure 13B The graphics processor 1340 is an example of a higher-performance graphics processor core. Each of the graphics processors 1310, 1340 can be a Figure 12 variant of the graphics processor 1210.

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

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

[0138] As Figure 13B shown, the graphics processor 1340 includes Figure 13A one or more MMUs 1320A - 1320B, caches 1325A - 1325B, and circuit interconnects 1330A - 1330B of the graphics processor 1310. The graphics processor 1340 includes one or more shader cores 1355A - 1355N (e.g., 1355A, 1355B, 1355C, 1355D, 1355E, 1355F to 1355N - 1, and 1355N), which provide a unified shader core architecture, in which a single core or 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 exact number of shader cores present can vary between embodiments and implementations. Additionally, the graphics processor 1340 includes an inter - core task manager 1345, which acts as a thread dispatcher to dispatch execution threads to one or more shader cores 1355A - 1355N and a tiling unit 1358 to accelerate tiling operations for tile - based rendering, in which rendering operations for a scene are subdivided in image space (e.g., to take advantage of local spatial coherence within the scene or to optimize the use of internal caches).

[0139] Figures 14A - 14B Shows additional exemplary graphics processor logic according to the embodiments described herein. Figure 14A Shows a graphics core 1400, which can be included within Figure 12 the graphics processor 1210 and can be a unified shader core 1355A - 1355N as in Figure 13B above. Figure 14B Shows a highly parallel general - purpose graphics processing unit 1430 suitable for deployment on a multi - chip module.

[0140] As Figure 14AAs shown, the graphics core 1400 includes a shared instruction cache 1402, texture units 1418, and cache / shared memory 1420, which are shared among the execution resources within the graphics core 1400. The graphics core 1400 may include multiple slices 1401A - 1401N or partitions for each core, and the graphics processor may include multiple instances of the graphics core 1400. The slices 1401A - 1401N may include support logic, which includes local instruction caches 1404A - 1404N, thread schedulers 1406A - 1406N, thread dispatchers 1408A - 1408N, and a set of registers 1410A. To perform logical operations, the slices 1401A - 1401N may include a set of additional functional units (AFU 1412A - 1412N), floating - point units (FPU 1414A - 1414N), integer arithmetic logic units (ALU 1416 - 1416N), address calculation units (ACU 1413A - 1413N), double - precision floating - point units (DPFPU 1415A - 1415N), and matrix processing units (MPU 1417A - 1417N).

[0141] Some of the computing units operate at specific precisions. For example, the FPU 1414A - 1414N may perform single - precision (32 - bit) and half - precision (16 - bit) floating - point operations, while the DPFPU 1415A - 1415N performs double - precision (64 - bit) floating - point operations. The ALU 1416A - 1416N may perform variable - precision integer operations at 8 - bit, 16 - bit, and 32 - bit precisions and may be configured for mixed - precision operations. The MPU 1417A - 1417N may also be configured for mixed - precision matrix operations, including half - precision floating - point operations and 8 - bit integer operations. The MPU 1417 - 1417N may perform various matrix operations to accelerate machine - learning application frameworks, including enabling support for accelerated general matrix - to - matrix multiplication (GEMM). The AFU 1412A - 1412N may perform additional logical operations not supported by the floating - point or integer units, including trigonometric operations (e.g., sine, cosine, etc.).

[0142] As Figure 14BAs shown, the General-Purpose Processing Unit (GPGPU) 1430 can be configured to enable highly parallel computing operations to be performed by an array of graphics processing units. Additionally, the GPGPU 1430 can be directly linked to other instances of the GPGPU to form a multi-GPU cluster to boost the training speed for a particular deep neural network. The GPGPU 1430 includes a host interface 1432 to enable connection to a host processor. In one embodiment, the host interface 1432 is a PCI Express interface. However, the host interface can also be a vendor-specific communication interface or communication fabric. The GPGPU 1430 receives commands from the host processor and uses a global scheduler 1434 to distribute execution threads associated with those commands to a set of compute clusters 1436A - 1436H. The compute clusters 1436A - 1436H share a cache memory 1438. The cache memory 1438 can act as a higher-level cache for the cache memories within the compute clusters 1436A - 1436H.

[0143] The GPGPU 1430 includes memories 1434A - 1434B coupled to the compute clusters 1436A - 1436H via a set of memory controllers 1442A - 1442B. In various embodiments, the memories 1434A - 1434B can include various types of memory devices, including dynamic random access memory (DRAM) or graphics random access memory (e.g., synchronous graphics random access memory (SGRAM), including graphics double data rate (GDDR) memory).

[0144] In one embodiment, each of the compute clusters 1436A - 1436H includes a set of graphics cores (e.g., Figure 14A graphics cores 1400) that can include various types of integer and floating-point logic units that can perform computing operations at a range of precisions, including precisions suitable for machine learning computations. For example, and in one embodiment, at least one subset of the floating-point units in each of the compute clusters 1436A - 1436H can be configured to perform 16-bit or 32-bit floating-point operations, while a different subset of the floating-point units can be configured to perform 64-bit floating-point operations.

[0145] Multiple instances of GPGPU 1430 can be configured to operate as compute clusters. The communication mechanisms for synchronization and data exchange in the compute clusters vary by embodiment. In one embodiment, multiple instances of GPGPU 1430 communicate via host interface 1432. In one embodiment, GPGPU 1430 includes an I / O hub 1439 that couples GPGPU 1430 to GPU link 1440, which enables direct connections to other instances of the GPGPU. In one embodiment, GPU link 1440 is coupled to a dedicated GPU-to-GPU bridge that enables communication and synchronization between multiple instances of GPGPU 1430. In one embodiment, GPU link 1440 is coupled to a high-speed interconnect to send and receive data to and from other GPGPUs or parallel processors. In one embodiment, multiple instances of GPGPU 1430 are located in separate data processing systems and communicate via network devices accessible via host interface 1432. In one embodiment, in addition to or as an alternative to host interface 1432, GPU link 1440 can also be configured to enable a connection to a host processor.

[0146] While the illustrated configuration of GPGPU 1430 can be configured to train neural networks, one embodiment provides an alternative configuration of GPGPU 1430 that can be configured for deployment within a high-performance or low-power inference platform. In the inference configuration, GPGPU 1430 includes fewer compute clusters 1436A-1436H relative to the training configuration. Additionally, the memory technology associated with memories 1434A-1434B can differ between the inference configuration and the training configuration, with higher bandwidth memory technology dedicated to the training configuration. In one embodiment, the inference configuration of GPGPU 1430 can support inference-specific instructions. For example, the inference configuration can provide support for one or more 8-bit integer dot product instructions that are commonly used during inference operations for deployed neural networks.

[0147] As discussed above, the optimal configurations (e.g., RC1, RC1e, RC6, CPG, RPx) can be calculated by a computing engine (or configuration logic) based on state characteristics and / or workload metrics. Additionally, while traditional solutions may make reasonable workload decisions between these states and frequencies for most workloads, further energy optimization can be achieved for workloads with a relatively high wake-up rate by considering the leakage and / or dynamic power of the workload as well as the power gating efficiency of the power gates (or power gating logic) and the entry / exit latency of possible power states (e.g., RC1e state, coarse power gating state, and RC6 state). Further, embodiments utilize a hardware finite state machine to perform the calculations to determine the optimal state. In different embodiments, a (e.g., small hardware) programmable computing engine / logic can easily calculate the optimal hardware configuration or implement a small set of decision rules that are optimal for most workloads. Such calculations can even be performed on a general-purpose processor (e.g., IA( architecture) or GuC) (assuming the overhead is low enough to allow timely calculations).

[0148] In one embodiment, the computing engine / logic calculates the best way to determine the power state based on measurements taken about the workload (or received from one or more metrics / sensors) and / or fixed parameters, die characteristics, and / or some design parameters that describe power delivery. Traditional solutions may provide a solution that is independent of the actual die leakage, power gating efficiency, and dynamic power. However, traditional solutions need to be adjusted to determine the appropriate state for the most important workloads; while one or more embodiments are able to calculate different generated settings without readjustment once the parameters (e.g., {leakage, Cdyn, latency} per state) are set.

[0149] Figure 15 Shows the information flow between the various components of the graphics system 1500 according to an embodiment. The system 1500 includes a user-mode driver 1502 that interacts with a user and / or host system to provide information about applications (e.g., media transcoding, OCL (or OpenCL TM) etc.), the kernel mode driver 1504 (which determines the frame rate, the workload type GPGPU (e.g., media, 3D, UI, touch, etc.), the turbo policy, etc.) and the graphics logic (GT) 1506. The kernel mode driver 1504 can also determine the adaptive burst turbo operation based on various information (including, for example, the power budget, QoS expectations, DCC / DCT status, EU / SS PG status, IBC / PG1 status, etc.), where DCC refers to duty cycle control, DCT refers to duty cycle throttling, EU refers to execution unit, SS refers to sub-slice, PG refers to power gating, IBC refers to intelligent bias control, and PG1 refers to frequency limit.

[0150] In addition, the compute engine / logic can easily perform spreadsheet calculations. In fact, some existing GPUs already include a compute engine called GuC (Global Microcontroller) that can perform these calculations. In an embodiment, the use of GuC does not change the division of responsibilities between the PCU and the driver code (e.g., regardless of whether the driver resides on a general-purpose processor or GuC).

[0151] Refer to Figure 15 , the GT logic 1506 includes GuC (also referred to herein as power configuration logic), GT PM (or GT power management) logic, a GT metric unit (which can provide GT metrics based on various information detected by one or more sensors, as discussed herein), and one or more metric finite state machines (FSMs). Figure 15 The "Ints (integers)" link metric FSM and GuC in refer to the interrupt signal for GuC. The GT logic 1506 receives the various settings discussed above from the user mode driver and / or the kernel mode driver, and uses the GuC logic to generate status information (e.g., RCx, RPx, and / or PGx) for the GT PM logic based on the data to be received from the GT metric unit and / or the metric FSM. As shown, the RP status request information is then provided to the system power unit 1508 (e.g., via a mailbox interface utilizing DCC / DCT).

[0152] In addition, the wake-up time is typically workload-dependent, so the initial configuration may be temporarily (for a few clock cycles) incorrect until the power configuration logic catches up with more applicable correct data. In various embodiments, the optimal configuration can be identified by various selected states (e.g., RC1, RC1e, CPG, RPx, etc.). As discussed herein, "RPx" generally refers to the graphics frequency x, and "RPe" generally refers to the most energy-efficient graphics or GFX (graphics) frequency. "RC1" generally refers to the idle state (e.g., the graphics logic / GPU is not processing any data) at the frequency of RPe (or the maximum efficiency frequency), and "RC1e" generally refers to the idle state at RPe.

[0153] Accordingly, some embodiments calculate the results or ROI (return on investment) for each hardware option, as Figures 16 - 17 shown in the example of Figure 16 . The first spreadsheet ( Figure 16 ) shows an excerpt of the total projected energy results comparing RC6, RCle with (RC1e+CPG), and how the columns are calculated. Generally, RC0*DCC indicates the active power. For Figure 17 a particular workload and state characteristic, it can be easily determined that RC6 is the best choice. Figures 16 - 17 The same calculations are performed for different workloads. In Figure 17 , "V" refers to voltage, "f" refers to frequency, "fps" refers to frames per second, and "vp" refers to the voltage required to execute when the logic needs to run. For the last particular workload and state characteristic (

[0154] ), it can be easily determined that (RCle+CPG) is the best choice.

[0155]

[0156]

[0157]

[0158]

[0159]

[0160] The following examples are further embodiments. Example 1 includes an apparatus that includes: power configuration logic, at least a portion of which is in hardware, the power configuration logic for determining a power state configuration for a portion of a processor, wherein the power state configuration corresponds to a plurality of power state settings for operation of the portion of the processor during an idle period, and wherein the power configuration logic is for determining the power state configuration at least in part based on one or more runtime workload measurements. Example 2 includes the apparatus of Example 1, wherein the one or more runtime workload measurements correspond to one or more of the following: leakage power of one or more workloads, dynamic power of the one or more workloads, power gating efficiency of power gating logic coupled to the one or more workloads, and the entry or exit latency of the power gating logic from one or more reduced power consumption states. Example 3 includes the apparatus of Example 1, wherein the power configuration logic is for determining the power state configuration at least in part based on the one or more runtime workload measurements and one or more reduced power consumption state characteristics. Example 4 includes the apparatus of Example 1, wherein the logic includes a general purpose processor or a global microcontroller. Example 5 includes the apparatus of Example 1, further including one or more sensors for detecting the one or more runtime workload measurements. Example 6 includes the apparatus of Example 5, further including one or more finite state machines for processing the detected one or more runtime workload measurements. Example 7 includes the apparatus of Example 1, wherein the power state configuration includes a plurality of selected power states. Example 8 includes the apparatus of Example 1, wherein the portion of the processor includes graphics logic. Example 9 includes the apparatus of Example 1, wherein the processor includes a graphics processing unit (GPU) having one or more graphics processing cores. Example 10 includes the apparatus of Example 1, wherein the processor includes one or more processor cores. Example 11 includes the apparatus of Example 1, wherein one or more of the processor, the logic, and the memory are on a single integrated circuit die.

[0161] Example 12 includes a method that includes: at power configuration logic, determining a power state configuration for a portion of a processor, where the power state configuration corresponds to a plurality of power state settings for operation of the portion of the processor during an idle period, and where the power configuration logic is to determine the power state configuration based at least in part on one or more runtime workload measurements. Example 13 includes the method of Example 12, where the one or more runtime workload measurements correspond to one or more of: leakage power of one or more workloads, dynamic power of the one or more workloads, power gating efficiency of power gating logic coupled to the one or more workloads, and entry or exit latency of the power gating logic from one or more reduced power consumption states. Example 14 includes the method of Example 12, further including: the power configuration logic determining the power state configuration based at least in part on the one or more runtime workload measurements and one or more reduced power consumption state characteristics. Example 15 includes the method of Example 12, further including: one or more sensors detecting the one or more runtime workload measurements. Example 16 includes the method of Example 15, further including: one or more finite state machines processing the detected one or more runtime workload measurements. Example 17 includes the method of Example 12, where the power state configuration includes a plurality of selected power states.

[0162] Example 18 includes one or more computer-readable media including one or more instructions that, when executed on at least one processor, configure the at least one processor to perform one or more operations: causing at a power configuration logic, a power state configuration for a portion of a processor to be determined, where the power state configuration corresponds to a plurality of power state settings for operation of the portion of the processor during an idle period, and where the power configuration logic determines the power state configuration based at least in part on one or more runtime workload measurements. Example 19 includes the computer-readable media of Example 18, where the one or more runtime workload measurements correspond to one or more of: leakage power of one or more workloads, dynamic power of the one or more workloads, power gating efficiency of power gating logic coupled to the one or more workloads, and entry or exit latency of the power gating logic from one or more reduced power consumption states. Example 20 includes the computer-readable media of Example 18, further including one or more instructions that, when executed on at least one processor, configure the at least one processor to perform one or more operations: causing the power configuration logic to determine the power state configuration based at least in part on the one or more runtime workload measurements and one or more reduced power consumption state characteristics. Example 21 includes the computer-readable media of Example 18, further including one or more instructions that, when executed on at least one processor, configure the at least one processor to perform one or more operations: causing one or more sensors to detect the one or more runtime workload measurements. Example 22 includes the computer-readable media of Example 18, further including one or more instructions that, when executed on at least one processor, configure the at least one processor to perform one or more operations: causing one or more finite state machines to process the detected one or more runtime workload measurements. Example 23 includes the computer-readable media of Example 18, where the power state configuration includes a plurality of selected power states. Example 24 includes the computer-readable media of Example 18, where the portion of the processor includes graphics logic. Example 25 includes the computer-readable media of Example 18, where the processor includes a graphics processing unit (GPU) having one or more graphics processing cores.

[0163] Example 26 includes a computing system that includes: a processor having one or more processor cores; a memory coupled to the processor for storing one or more bits of data; and power configuration logic, at least a portion of which is in hardware, for determining a power state configuration for a portion of the processor, wherein the power state configuration corresponds to a plurality of power state settings for operation of the portion of the processor during an idle period, and wherein the power configuration logic is for determining the power state configuration at least in part based on one or more runtime workload measurements. Example 27 includes the system of Example 26, wherein the one or more runtime workload measurements correspond to one or more of: leakage power of one or more workloads, dynamic power of the one or more workloads, power gating efficiency of power gating logic coupled to the one or more workloads, and entry or exit latency of the power gating logic from one or more reduced power consumption states. Example 28 includes the system of Example 26, wherein the power configuration logic is for determining the power state configuration at least in part based on the one or more runtime workload measurements and one or more reduced power consumption state characteristics. Example 29 includes the system of Example 26, wherein the logic includes a general purpose processor or a global microcontroller. Example 30 includes the system of Example 26, further including one or more sensors for detecting the one or more runtime workload measurements. Example 31 includes the system of Example 30, further including one or more finite state machines for processing the detected one or more runtime workload measurements. Example 32 includes the system of Example 26, wherein the power state configuration includes a plurality of selected power states. Example 33 includes the system of Example 26, wherein the portion of the processor includes graphics logic. Example 34 includes the system of Example 26, wherein the processor includes a graphics processing unit (GPU) having one or more graphics processing cores. Example 35 includes the system of Example 26, wherein the processor includes one or more processor cores. Example 36 includes the system of Example 26, wherein one or more of the processor, the logic, and the memory are on a single integrated circuit die.

[0164] Example 37 includes an apparatus that includes modules for performing the methods described in any of the preceding examples. Example 38 includes machine-readable storage including machine-readable instructions that, when executed, implement or perform the methods or apparatuses described in any of the preceding examples.

[0165] In various embodiments, herein (e.g., with reference to Figure 1The operations discussed (e.g., etc.) can be implemented as hardware (e.g., logic circuits), software, firmware, or combinations thereof, which can be provided as a computer program product, e.g., including one or more tangible (e.g., non-transitory) machine-readable or computer-readable media having instructions (or software programs) stored thereon for programming a computer to perform the processes discussed herein. Machine-readable media can include storage devices such as those discussed with respect to Figure 1 etc.

[0166] Additionally, such computer-readable media can be downloaded as a computer program product, where the program can be transmitted from a remote computer (e.g., a server) to a requesting computer (e.g., a client) via a communication link (e.g., a bus, a modem, or a network connection) by data signals provided in a carrier wave or other propagated medium.

[0167] References in the specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, and / or characteristic described in connection with the embodiment can be included in at least one implementation. The phrase "in one embodiment" appearing in various places in the specification may or may not all refer to the same embodiment.

[0168] Also, in the specification and claims, the terms "coupled" and "connected" and their derivatives may be used. In some embodiments, "connected" can be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" can mean that two or more elements are in direct physical or electrical contact. However, "coupled" can also mean that two or more elements may not be in direct contact with each other, but can still cooperate or interact with each other.

[0169] Thus, although embodiments have been described in language specific to structural features and / or method acts, it is to be understood that the subject matter claimed may not be limited to the specific features or acts described. Rather, the specific features and acts are disclosed as sample forms of implementing the claimed subject matter.

[0170] Furthermore, the foregoing specification and drawings are to be considered illustrative rather than restrictive. Those skilled in the art will understand that various modifications and changes can be made to the embodiments described herein without departing from the broader spirit and scope of the invention as set forth in the appended claims.

Claims

1. An apparatus for determining an idle power state, the apparatus comprising: Power configuration logic, at least a portion of which is in hardware, the power configuration logic for determining a power state configuration for a portion of a processor, wherein the power state configuration corresponds to a plurality of power state settings for operation of the portion of the processor during an idle period, wherein the power configuration logic is for: determining the power state configuration at least in part based on one or more runtime workload measurements and one or more settings from a user mode driver or a kernel mode driver, wherein the one or more runtime workload measurements at least correspond to an entry latency or an exit latency of the power gating logic from one or more reduced power consumption states, wherein the power configuration logic determines the power state configuration based on received metric information corresponding to the one or more runtime workload measurements and one or more settings from the user mode driver or the kernel mode driver.

2. The device according to claim 1, wherein The one or more runtime workload measurements correspond to an entry latency or an exit latency of the power gating logic from one or more reduced power consumption states and one or more of the following: leakage power of one or more workloads, dynamic power of the one or more workloads, and power gating efficiency of power gating logic coupled to the one or more workloads.

3. The device according to claim 1, wherein, The power configuration logic is for: determining the power state configuration at least in part based on the one or more runtime workload measurements and one or more reduced power consumption state characteristics.

4. The device according to claim 1, wherein, The logic includes a general-purpose processor or a global microcontroller.

5. The apparatus according to claim 1, further comprising one or more sensors for detecting the one or more runtime workload measurements.

6. The apparatus according to claim 5, further comprising one or more finite state machines for processing the detected one or more runtime workload measurements.

7. The apparatus according to claim 1, wherein The power state configuration includes a plurality of selected power states.

8. The device according to claim 1, wherein The portion of the processor includes graphics logic.

9. The device according to claim 1, wherein, The processor includes a graphics processing unit (GPU) having one or more graphics processing cores.

10. The device according to claim 1, wherein, The processor includes one or more processor cores.

11. The device according to claim 1, wherein, One or more of the processor, the logic, and the memory are on a single integrated circuit die.

12. A method for determining an idle power state, the method comprising: at a power configuration logic, determining a power state configuration for a portion of a processor, wherein the power state configuration corresponds to a plurality of power state settings for operation of the portion of the processor during an idle period, wherein the power configuration logic is for: determining the power state configuration at least in part based on one or more runtime workload measurements and one or more settings from a user mode driver or a kernel mode driver, wherein the one or more runtime workload measurements at least correspond to an entry latency or an exit latency of the power gating logic from one or more reduced power consumption states, Wherein, the power configuration logic determines a power state configuration based on metric information received corresponding to the one or more runtime workload measurements and one or more settings from the user mode driver or the kernel mode driver.

13. The method according to claim 12, wherein, The one or more runtime workload measurements correspond to the entry latency or exit latency of the power gating logic from one or more reduced power consumption states and one or more of the following: the leakage power of one or more workloads, the dynamic power of the one or more workloads, and the power gating efficiency of the power gating logic coupled to the one or more workloads.

14. The method according to claim 12, further comprising: The power configuration logic determines the power state configuration at least in part based on the one or more runtime workload measurements and one or more reduced power consumption state characteristics.

15. The method according to claim 12, further comprising: One or more sensors detect the one or more runtime workload measurements.

16. The method according to claim 15, further comprising: One or more finite state machines process the detected one or more runtime workload measurements.

17. The method according to claim 12, wherein, The power state configuration includes a plurality of selected power states.

18. A machine-readable medium comprising code which, when executed, causes the machine to perform the method according to any one of claims 12-17.

19. An apparatus comprising modules for performing the method according to any one of claims 12-17.

Images