Workload scheduling and distribution on a distributed graphics device

Abstract

The embodiments described herein provide a graphics, media, and computing device having a tile structure composed of a plurality of tiles of a smaller graphics device. Workloads can be distributed across multiple tiles of the device through the work distribution infrastructure of such a device. Work items can be submitted to any one or more of the tiles. Additionally, when a work item is completed, the graphics, media, and / or computing engine within the device can easily acquire a new work item to execute with minimal latency.

Description

Background Technology

[0001] A computing system may include a graphics processor that performs graphics processing and parallel computing workloads such as linear interpolation, tessellation, rasterization, texture mapping, and depth testing. Traditionally, graphics processors used fixed-function compute units to process graphics data. However, modern graphics processors include programmable parts, which enable these processors to support a wide range of operations for processing vertex and fragment data and general-purpose parallel computing workloads. These processors include interfaces through which programmable workloads can generally be scheduled to run on the processor. Brief explanation of the drawing

[0002] In a manner that allows the features of the embodiments mentioned above to be understood in detail, a more specific description of the embodiments briefly summarized above may be provided with reference to the embodiments, some of which are illustrated in the accompanying drawings, and the drawings are as follows. FIG. 1 is a block diagram of a processing system according to one embodiment. FIG. 2 is a block diagram of a processor according to one embodiment. FIG. 3 is a block diagram of a graphics processor according to one embodiment. FIG. 4 is a block diagram of a graphics processing engine of a graphics processor according to some embodiments. FIG. 5 is a block diagram of the hardware logic of a graphics processor core according to some embodiments described in this specification. FIGS. 6a and 6b illustrate thread execution logic including an array of processing elements employed in a graphics processor core according to an embodiment described in this specification. FIG. 7 is a block diagram showing a graphics processor instruction format according to some embodiments. FIG. 8 is a block diagram of a graphics processor according to another embodiment. FIGS. 9a and 9b illustrate a graphics processor instruction format and command sequence according to some embodiments. FIG. 10 illustrates an exemplary graphic software architecture for a data processing system according to some embodiments. FIG. 11a is a block diagram showing an IP core development system according to one embodiment. FIG. 11b illustrates a side cross-sectional view of an integrated circuit package assembly according to some embodiments described in this specification. FIG. 12 is a block diagram showing an exemplary SoC integrated circuit according to one embodiment. FIGS. 13a and 13b are block diagrams illustrating an exemplary graphics processor for use in an SoC according to the described embodiments. FIGS. 14a and 14b illustrate additional exemplary graphics processor logic according to the embodiments described herein. FIG. 15 is a block diagram of a data processing system according to one embodiment. FIGS. 16a to 16c illustrate a graphics processing system implementing multi-tile task scheduling according to an embodiment. FIG. 17 illustrates a tile work partitioning and scheduling system according to embodiments described in this specification. FIG. 18 illustrates a system that enables load balancing in a multi-tile graphics processing system according to an embodiment. FIG. 19 illustrates a flowchart of a multi-tile workload scheduling method according to one embodiment. FIG. 20 illustrates a flowchart of a method for executing a multi-tile workload according to one embodiment. FIG. 21 illustrates a flowchart of a method for migrating a workload between tiles according to one embodiment. FIG. 22 is a block diagram of a computing device including a graphics processor according to one embodiment. Specific details for implementing the invention

[0003] The embodiments described herein provide graphics, media, and computing devices having a tile architecture composed of multiple tiles of a smaller graphics device. Such devices may be scaled to include more or fewer tiles depending on the power and / or performance objectives of the device. The scaled devices described herein can efficiently distribute workloads across multiple tiles using a specially customized workload distribution infrastructure. The workload distribution infrastructure described herein enables workload dispatch scaled across a variable number of multiple tiles. Work items may be submitted to one or more of the tiles, and workloads may be distributed across multiple tiles. Additionally, when a work item is completed, the graphics, media, and / or computing engine within the device can easily obtain a new work item to execute with minimal latency.

[0004] In graphics, media, and / or computing devices known in this art field, one or more software layers are used to distribute work items to various engines within the device. This software monitors the load on the various engines and attempts to efficiently distribute or redistribute the workload to these engines. Such software may be part of a device driver or device support framework running on one or more host processors (e.g., CPU cores) of a data processing system or computing device, including graphics, media, and / or computing devices. However, relying on host software to monitor and distribute workloads introduces various inefficiencies. For example, command buffer repacketization may be required, which introduces additional CPU cycles, increasing latency and power consumption for device operation.

[0005] One embodiment provides a job scheduling and submission infrastructure in which software can create an integrated command buffer for a workload that includes workload partitioning constructs. The software can then submit a job item directly to a tile, and a local hardware scheduler within the tile can schedule the workload to the appropriate engine within the tile. Each engine can execute the same command buffer. When an engine is ready to execute a new job item, the engine can dynamically and atomically acquire the next job chunk (e.g., partition) for execution. In one embodiment, the integrated command buffer includes a synchronization command that is synchronized when the execution of the distributed partitioned workload ends.

[0006] During operation, an application or user-mode graphics driver (UMD) can submit workload commands in a format that facilitates distributed execution. Workload commands are inserted into a command buffer with a unified command buffer format. Commands within the command buffer are partitioned to enable distributed execution across multiple tiles. Engines in graphics, media, and computing devices include mechanisms to atomically acquire workload partitions for execution and execute commands associated with those partitions. The device's high-level scheduler does not need to intervene to monitor the engine's execution status. Rather than the high-level scheduler providing partitions to the engine, the engine can acquire workload partitions if necessary.

[0007] For illustrative purposes, various specific details are provided to provide a thorough understanding of the various embodiments described below. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are illustrated in the form of block diagrams to avoid obscuring the basic principles and to facilitate a more thorough understanding of the embodiments. Although some of the embodiments below have been described with reference to a graphics processor, the techniques and teachings described herein may be applicable to various types of circuits or semiconductor devices, including general-purpose processing units or graphics processing units. In this specification, references to "one embodiment" or "an embodiment" indicate that specific features, structures, or characteristics described in association with or in connection with the embodiment may be included in at least one of such embodiments. However, the phrase "in one embodiment" appearing in various places in the specification does not necessarily refer to the same embodiment.

[0008] In the following description and claims, the terms "coupled" and "connected" may be used together with their derivatives. It should be understood that these terms are not synonyms for one another. "Coupled" is used to indicate that two or more elements cooperate or interact with each other, which may or may not be in direct physical or electrical contact. "Connected" is used to indicate that communication is established between two or more elements that are coupled together.

[0009] In the following description, FIGS. 1 through 14 provide an overview of exemplary data processing systems and graphics processor logic that include or relate to various embodiments. FIGS. 15 through 22 provide specific details of various embodiments. Some aspects of the embodiments below are described with reference to graphics processors, while other aspects are described with reference to general-purpose processors such as central processing units (CPUs). Similar techniques and teachings may be applied to other types of circuits or semiconductor devices, including but not limited to many-core processors, GPU clusters, or one or more instances of Field Programmable Gate Arrays (FPGAs). In general, these teachings are applicable to any processor or machine that manipulates or processes images (e.g., samples, pixels), vertex data, or geometry data.

[0010] System Overview

[0011] FIG. 1 is a block diagram of a processing system (100) according to an embodiment. In various embodiments, the system (100) includes one or more processors (102) and one or more graphics processors (108), and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors (102) or processor cores (107). In one embodiment, the system (100) is a processing platform incorporated within a System-on-a-Chip (SoC) integrated circuit for use in mobile, handheld, or embedded devices.

[0012] In one embodiment, the system (100) may be integrated into or include a server-based gaming platform, a game console (including a game and media console), a mobile gaming console, a handheld game console, or an online game console. In some embodiments, the system (100) is a mobile phone, a smartphone, a tablet computing device, or a mobile Internet device. The processing system (100) may also be integrated into, coupled with, or include a wearable device, such as a smart watch wearable device, a smart eyewear 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 a graphics interface generated by one or more graphics processors (108) and one or more processors (102).

[0013] In some embodiments, one or more processors (102) each include one or more processor cores (107) that process instructions that perform operations for system and user software when executed. In some embodiments, each of the one or more processor cores (107) is configured to process a specific instruction set (109). In some embodiments, the instruction set (109) may enable Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC), or computing through Very Long Instruction Words (VLIW). Multiple processor cores (107) may each process different instruction sets (109), which may include instructions that enable emulation of different instruction sets. A processor core (107) may also include other processing devices, such as a Digital Signal Processor (DSP).

[0014] In some embodiments, the processor (102) includes a cache memory (104). Depending on the architecture, the processor (102) may have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared among 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 processor cores (107) using known cache coherency techniques. A register file (106) is additionally included within the processor (102), which may include different types of registers (e.g., an integer register, a floating-point register, a status register, and an instruction pointer register) for storing different types of data. Some registers may be general-purpose registers, while others may be specific to the design of the processor (102).

[0015] In some embodiments, one or more processor(s) (102) are coupled with one or more interface bus(s) (110) to transmit communication signals, such as addresses, data, or control signals, between the processor(s) (102) and other components within the system (100). In one embodiment, the interface bus (110) may be a version of a processor bus, for example, a Direct Media Interface (DMI) bus. However, the processor bus is not limited to a DMI bus and may include one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express), memory buses, or other types of interface buses. In one embodiment, the processor(s) (102) include an integrated memory controller (116) and a platform controller hub (130). The memory controller (116) enables communication between the memory devices and other components of the system (100), while the platform controller hub (PH) (130) provides a connection to I / O devices via a local I / O bus.

[0016] The memory device (120) may be a Dynamic Random Access Memory (DRAM) device, a Static Random Access Memory (SRAM) device, a flash memory device, a phase-change memory device, or any other memory device having the performance suitable to serve as a process memory. In one embodiment, the memory device (120) may operate as a system memory for the system (100) to store instructions (121) and data (122) for use when one or more processors (102) execute an application or process. The memory controller hub (116) is also coupled with an optional external graphics processor (112), which may communicate with one or more graphics processors (108) within the processor (102) to perform graphics and media operations. In some embodiments, a display device (111) may be connected to the processor(s) (102). The display device (111) may be one or more of an internal display device, such as within a mobile electronic device or a laptop device, or an external display device attached via a display interface (e.g., DisplayPort). In one embodiment, the display device (111) may be a head-mounted display (HMD), such as a stereoscopic display device for use in a virtual reality (VR) application or an augmented reality (AR) application.

[0017] In some embodiments, the platform controller hub (130) enables peripherals to be connected to the memory device (120) and the processor (102) via a high-speed I / O bus. I / O peripherals include, but are not limited to, an audio controller (146), a network controller (134), a firmware interface (128), a wireless transceiver (126), a touch sensor (125), and a data storage device (124) (e.g., a hard disk drive, flash memory, etc.). The data storage device (124) may be connected via a peripheral bus, such as a Peripheral Component Interconnect bus (e.g., PCI, PCI Express), or via a storage interface (e.g., SATA). The touch sensor (125) may include a touch screen sensor, a pressure sensor, or a fingerprint sensor. The wireless transceiver (126) may be a Wi-Fi transceiver, a Bluetooth transceiver, a mobile network transceiver, for example, a 3G, 4G, or Long Term Evolution (LTE) transceiver. The firmware interface (128) enables communication with system firmware and may be, for example, a Unified Extensible Firmware Interface (UEFI). The network controller (134) may enable 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, in one embodiment, a multi-channel high-definition audio controller.In one embodiment, the system (100) includes an optional legacy I / O controller (140) for coupling a legacy (e.g., Personal System 2: PS / 2) device to the system. The platform controller hub (130) may also connect input devices, such as a keyboard and mouse (143) combination, a camera (144), or other USB input devices, to one or more Universal Serial Bus (USB) controllers (142).

[0018] It will be recognized that the illustrated system (100) is exemplary and non-limiting, as other types of data processing systems configured differently may also be used. For example, instances of the memory controller (116) and the platform controller hub (130) may be integrated within a separate external graphics processor, such as an external graphics processor (112). In one embodiment, the platform controller hub (130) and / or the memory controller (160) may be located outside of one or more processor(s) (102). For example, the system (100) may include an external memory controller (116) and a platform controller hub (130), which may be configured as a memory controller hub and a peripheral controller hub within a system chipset that communicates with the processor(s) (102).

[0019] FIG. 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). Components of FIG. 2 having the same reference number (or name) as components of any other drawings in this document may operate or function in a manner similar to that described in other parts of this document, but are not necessarily so. The processor (200) may include additional cores, including additional cores (202N) represented by dashed boxes. Each of the processor cores (202A-202N) includes one or more internal cache units (204A-204N). In some embodiments, each processor core may also access one or more shared cached units (206).

[0020] Internal cache units (204A-204N) and shared cache units (206) represent a cache memory hierarchy within the processor (200). The cache memory hierarchy may include at least one level of instruction and data cache within each processor core and one or more levels of a shared mid-level cache, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other levels of cache, wherein the highest level of cache prior to external memory is classified as LLC. In some embodiments, cache consistency logic maintains consistency among the various cache units (206 and 204A-204N).

[0021] In some embodiments, the processor (200) may also include a set of one or more bus controller units (216) and a system agent core (210). The one or more bus controller units (216) manage a set of one or more peripheral buses, such as 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) that manage access to various external memory devices (not shown).

[0022] In some embodiments, one or more of the processor cores (202A-202N) include support for simultaneous multi-threading. In such embodiments, the system agent core (210) includes components for coordinating and operating the cores (202A-202N) during multi-threaded processing. The system agent core (210) may additionally include a Power Control Unit (PCU), which includes logic and components for regulating the power state of the processor cores (202A-202N) and the graphics processor (208).

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

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

[0025] An exemplary I / O link (213) represents at least one of several types of I / O interconnects, including an on-package I / O interconnect that enables communication between various processor components and a high-performance embedded memory module (218), such as an eDRAM module. In some embodiments, the graphics processor (208) and the processor core (202A-202N) each use the embedded memory module (218) as a shared last-level cache.

[0026] In some embodiments, the processor cores (202A-202N) are homogeneous cores executing the same instruction set architecture. In other embodiments, the processor cores (202A-202N) are heterogeneous in terms of Instruction Set Architecture (ISA), such that 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, such that one or more cores having relatively higher power consumption are coupled with one or more power cores having lower power consumption. Additionally, the processor (200) may be implemented as an SoC integrated circuit having the illustrated components, in addition to other components, or on one or more chips.

[0027] FIG. 3 is a block diagram of a graphics processor (300) which may be an individual graphics processing unit or a graphics processor integrated with a plurality of processing cores. In some embodiments, the graphics processor communicates with registers on the graphics processor through a memory-mapped I / O interface and as commands placed in processor memory. In some embodiments, the graphics processor (300) includes a memory interface (314) for accessing memory. The memory interface (314) may be an interface to local memory, one or more internal caches, one or more shared external caches and / or system memory.

[0028] In some embodiments, the graphics processor (300) also includes a display controller (302) that drives display output data to a display device (320). The display controller (302) includes hardware for one or more overlay planes for configuring and displaying multiple layers of video or user interface elements. The display device (320) may be an internal or external display device. In one embodiment, the display device (320) is a head-mounted display (HMD), such as a virtual reality (VR) display device or an augmented reality (AR) display device. In some embodiments, the graphics processor (300) includes a video codec engine (306) that encodes, decodes, or transcodes media to, from, or between one or more media encoding formats, including but not limited to the Moving Picture Experts Group (MPEG) format, e.g., MPEG-2, Advanced Video Coding (AVC) format, e.g., H.264 / MPEG-4 AVC, and Society of Motion Picture & Television Engineers (SMPTE) 421M / VC-1, and Joint Photographic Experts Group (JPEG) format, e.g., JPEG and Motion JPEG (MJPEG) format.

[0029] In some embodiments, the graphics processor (300) includes a Block Image Transfer (BLIT) engine (304) that performs two-dimensional (2D) rasterizer operations, such as bit-boundary block transfer. 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 compute engine for performing graphics operations and media operations, including three-dimensional (3D) graphics operations.

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

[0031] In some embodiments, the media pipeline (316) includes a fixed-function logic unit or a programmable logic unit that performs one or more specialized media operations, such as video decode acceleration, video de-interlacing, and video encode acceleration, on behalf of or on behalf of the video codec engine (306). In some embodiments, the media pipeline (316) additionally includes a thread spawning unit that spawns threads for execution on the 3D / media subsystem (315). The spawned threads perform calculations for media operations on one or more graphics execution units included in the 3D / media subsystem (315).

[0032] In some embodiments, the 3D / media subsystem (315) includes logic for executing threads spawned by the 3D pipeline (312) and the media pipeline (316). In one embodiment, the pipeline sends a thread execution request to the 3D / media subsystem (315), which includes thread dispatch logic for arbitrating and dispatching various requests to available thread execution resources. The execution resources include an array of graphics execution units that handle 3D and media threads. In some embodiments, the 3D / media subsystem (315) includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory including registers and addressable memory that shares data between threads and stores output data.

[0033] graphics processing engine

[0034] FIG. 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 a version of the GPE (310) shown in FIG. 3. Any component of FIG. 4 having the same reference number (or name) as any component of any other figure in this document may operate or function in any manner similar to that described in other parts of this document, but is not necessarily so. For example, the 3D pipeline (312) and the media pipeline (316) of FIG. 3 are illustrated. 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).

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

[0036] In various embodiments, the 3D pipeline (312) includes fixed functions and programmable logic that process one or more shader programs, such as a 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 unit) within the graphics core(s) (415A-415B) of the graphics core array (414) includes support for various 3D API shader languages ​​and can execute multiple concurrent execution threads associated with multiple shaders.

[0037] In some embodiments, the graphics core array (414) also includes execution logic that performs media functions such as video and / or image processing. In one embodiment, the execution unit additionally includes general-purpose logic that is programmable to perform general-purpose computation operations in parallel, in addition to graphics processing operations. The general-purpose logic may perform processing operations in parallel with or in conjunction with the general-purpose logic within the processor core(s) (107) of FIG. 1 or the core (202A-202N) as in FIG. 2.

[0038] Output data generated by a thread running on the graphics core array (414) can be output to memory within a 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 running on the graphics core array (414). In some embodiments, the URB (418) can additionally be used for synchronization between the fixed function logic within the shared function logic (420) and the threads on the graphics core array.

[0039] In some embodiments, the graphics core array (414) is scalable, so the array includes a variable number of graphics cores, each having a variable number of execution units based on the target power and performance level of the GPE (410). In one embodiment, the execution resources are dynamically scalable, so the execution resources can be enabled or disabled as needed.

[0040] A graphics core array (414) is coupled with shared function logic (420) that includes various resources shared among the graphics cores within the graphics core array. A shared function within the shared function logic (420) is a hardware logic unit that provides specialized supplementary functions to the graphics core array (414). In various embodiments, the shared function logic (420) includes, but is not limited to, sampler (421), math (422), and inter-thread communication (ITC) (423) logic. Additionally, some embodiments implement one or more cache(s) (425) within the shared function logic (420).

[0041] A shared function is implemented when the demand for a given specialized function is insufficient to be contained within the graphics core array (414). Instead, a single instantiation of such specialized function is implemented as a stand-alone entity within the shared function logic (420) and shared among the execution resources within the graphics core array (414). The exact set of functions shared among the graphics core arrays (414) and contained within the graphics core array (414) varies by embodiment. In some embodiments, a specific shared function within the shared function logic (420) that is extensively used by the graphics core array (414) may be contained 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 contain some or all of the logic within the shared function logic (420). In one embodiment, all logic elements within the shared function logic (420) may be duplicated within the shared function logic (416) of the graphics core array (414). In one embodiment, the shared function logic (420) is excluded and the shared function logic (416) within the graphics core array (414) becomes dominant.

[0042] FIG. 5 is a block diagram of the hardware logic of a graphics processor core (500) according to some embodiments described in this document. Components of FIG. 5 having the same reference number (or name) as components of any other drawings in this document may operate or function in any manner similar to those described in other parts of this document, but are not necessarily so. In some embodiments, the illustrated graphics processor core (500) is contained within the graphics core array (414) of FIG. 4. A graphics processor core (500), sometimes referred to as a core slice, may be one or more graphics cores within a modular graphics processor. A graphics processor core (500) is an example of a single graphics core slice, and a graphics processor as described in this document may include multiple graphics core slices based on target power and performance envelopes. Each graphics processor core (500) may include a fixed-function block (530) coupled with several sub-cores (501A-501F), also referred to as sub-slices, which include modular blocks of general-purpose and fixed-function logic.

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

[0044] In one embodiment, the fixed function block (530) also includes a graphics SoC interface (537), a graphics microcontroller (538), and a media pipeline (539). The graphics SoC interface (537) provides an interface between a graphics processor core (500) and other processor cores within a system-on-a-chip integrated circuit. The graphics microcontroller (538) is a programmable subprocessor configurable to manage various functions of the graphics processor core (500), including thread dispatch, scheduling, and pre-emption. The media pipeline (539) (e.g., the media pipeline (316) of FIGS. 3 and 4) includes logic that enables decoding, encoding, preprocessing, and / or postprocessing of multimedia data, including image and video data. The media pipeline (539) implements media operations through requests to compute or sampling logic within the subcore (501-501F).

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

[0046] A graphics microcontroller (538) may be configured to perform various scheduling and management tasks for a graphics processor core (500). In one embodiment, the graphics microcontroller (538) may perform graphics and / or compute workload scheduling for various graphics parallel engines within an array of Execution Units (EUs) (502A-502F, 504A-504F) within a sub-core (501A-501F). In this scheduling model, host software running on a CPU core of an SoC containing a graphics processor core (500) submits the workload to one of several graphics processor doorbells, which calls a scheduling operation for the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting the workload to a command streamer, preempting existing workloads running on the engine, monitoring the progress of the workload, and notifying the host software when the workload is completed. In one embodiment, the graphics microcontroller (538) may also provide the graphics processor core (500) with the ability to save and restore registers within the graphics processor core (500) over low-power state transitions, regardless of the operating system and / or graphics driver software on the system, thereby enabling a low-power or idle state for the graphics processor core (500).

[0047] The graphics processor core (500) may have up to N modular subcores, more or fewer than the exemplified subcores (501A-501F). For each set of N subcores, the graphics processor core (500) may also include shared function logic (510), shared and / or cache memory (512), geometry / fixed function pipeline (514), and additional fixed function logic (516) that accelerates various graphics and compute processing operations. The shared function logic (510) may include a logic unit associated with the shared function logic (420) of FIG. 4, which can be shared by each of the N subcores within the graphics processor core (500) (e.g., sampler, math and / or inter-thread communication logic). The shared and / or cache memory (512) may be a last-level cache for a set of N subcores (501A-501F) within the graphics processor core (500) and may also serve as shared memory accessible by multiple subcores. The geometry / fixed-function pipeline (514) may be included within the fixed-function block (530) instead of the geometry / fixed-function pipeline (536) and may include the same or similar logic unit.

[0048] In one embodiment, the graphics processor core (500) includes additional fixed-function logic (516) that may include various fixed-function acceleration logic for use by the graphics processor core (500). In one embodiment, the additional fixed-function logic (516) includes an additional geometry pipeline for use in position-only shading. In position-only shading, there are two geometry pipelines: a full geometry pipeline within the geometry / fixed-function pipeline (516, 536), and a cull pipeline, which is an additional geometry pipeline that may be included within the additional fixed-function logic (516). In one embodiment, the cull pipeline is a trimmed-down version of the full geometry pipeline. The full pipeline and the cull pipeline may run different instances of the same application, each instance having a distinct context. Position-only shading can hide long cull runs of discarded triangles, allowing shading to be completed earlier in some instances. For example, in one embodiment, the cull pipeline logic within additional fixed-function logic (516) can run the position shader in parallel with the main application and, generally, generates a criterion result faster than the canonical pipeline as the cull pipeline fetches and shades only the position attributes of the vertices without performing rasterization and rendering of pixels into the frame buffer. The cull pipeline can use the generated criterion result to calculate visibility information for all triangles, regardless of whether the triangle is culled.The canonical pipeline (which may be referred to as the replay pipeline in this instance) can use visibility information to skip culled triangles in order to shade only the visible triangles that are ultimately passed to the rasterization phase.

[0049] In one embodiment, additional fixed-function logic (516) may also include machine learning acceleration logic, such as fixed-function matrix multiplication logic, for an implementation that includes optimization for machine learning training or inference.

[0050] Each graphics subcore (501A-501F) includes a set of execution resources that can be used to perform graphics, media, and compute operations in response to requests from a graphics pipeline, a media pipeline, or a shader program. The graphics subcore (501A-501F) includes 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 contain multiple execution units, which are general-purpose graphics processing units capable of performing floating-point and integer / fixed-point logic operations for graphics, media, or compute operations, including graphics, media, or compute shader programs. The TD / IC logic (503A-503F) performs local thread dispatch and thread control operations for execution units within the subcore and enables communication between threads running on the execution units of the subcore. The 3D sampler (505A-505F) can read textures or other 3D graphics-related data into memory. The 3D sampler can read texture data differently based on the texture format associated with a given texture and the configured sample state. The media sampler (506A-506F) can perform similar read operations based on the type and format associated with the media data. In one embodiment, each graphics subcore (501A-501F) may alternatively include a unified 3D and media sampler.A thread executed on an execution unit within each subcore (501A-501F) can use shared local memory (508A-508F) within each subcore to enable a thread executed within a thread group to use a common pool of on-chip memory.

[0051] Execution unit

[0052] FIGS. 6a and 6b illustrate thread execution logic (600) comprising an array of processing elements used within a graphics processor core according to an embodiment described herein. Elements of FIGS. 6a and 6b having the same reference number (or name) as elements of any other figure in this document may operate or function in any manner similar to, but not limited to, those described in other parts of this document. FIG. 6a shows an overview of thread execution logic (600) that may include variations of the hardware logic exemplified as each subcore (501A-501F) of FIG. 5. FIG. 6b shows exemplary internal details of an execution unit.

[0053] As illustrated in FIG. 6a, 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 comprising 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 may be dynamically scaled by enabling or disabling one or more execution units (e.g., any of execution units (608A, 608B, 608C, 608D, to 608N-1 and 608N)) based on the computational requirements of the workload. In one embodiment, the included components are interconnected through an interconnect fabric linked to each component. In some embodiments, the thread execution logic (600) includes one or more connections to memory, such as system memory or cache memory, through one or more of the instruction cache (606), data port (614), sampler (610), and execution units (608A-608N). In some embodiments, each execution unit (e.g., 680A) is a standalone programmable general-purpose computing unit capable of executing multiple concurrent hardware threads while processing multiple data elements in parallel for each thread. In various embodiments, an array of execution units (608A-608N) is scalable to include any number of individual execution units.

[0054] In some embodiments, the execution units (608A-608N) are primarily used to execute shader programs. The shader processor (602) processes various shader programs and dispatches execution threads associated with the shader programs through the thread dispatcher (604). In one embodiment, the thread dispatcher includes logic to mediate a request for thread initiation from the graphics and media pipeline and to instantiate the requested thread on one or more execution units within the execution units (608A-608N). For example, the geometry pipeline may dispatch a vertex, tessellation, or geometry shader to the thread execution logic for processing. In some embodiments, the thread dispatcher (604) may also process a runtime thread spawning request from the running shader program.

[0055] In some embodiments, the execution units (608A-608N) support instruction sets that include native support for graphics shader instructions from many 3D graphics shader standards, so that shader programs from graphics libraries (e.g., Direct 3D and OpenGL) are 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 multi-issue Single Instruction Multiple Data (SIMD) execution, and multi-threaded operation enables an efficient execution environment even when faced with higher latency memory access. Each hardware thread within each execution unit has a dedicated high-bandwidth register file and an associated independent thread state. Execution is multiple issuances per clock to a pipeline capable of integer, single-precision and double-precision floating-point operations, SIMD branching capabilities, logical operations, transcendental operations, and various other operations. While waiting for one of the shared functions or data from memory, the dependency logic within the execution unit (608A-608N) causes the waiting thread to sleep until the requested data is returned. While the waiting thread is sleeping, hardware resources can be dedicated to processing other threads.For example, during a delay associated with a vertex shader operation, the execution unit may perform operations for a pixel shader, a fragment shader, or other types of shader programs including different vertex shaders.

[0056] Each execution unit within the execution unit (608A-608N) operates on an array of data elements. The number of data elements is the "execution size," or the number of channels for an instruction. An execution channel is a logical unit of execution for flow control, masking, and data element access within an instruction. The number of channels may be independent of the number of physical Arithmetic Logic Units (ALUs) or Floating Point Units (FPUs) for a particular graphics processor. In some embodiments, the execution unit (608A-608N) supports integer and floating-point data types.

[0057] The execution unit instruction set includes SIMD instructions. Various data elements can be stored in registers as packed data types, and the execution unit 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 registers, and the execution unit operates on the vector as four individual 64-bit packed data elements (Quad-Word (QW) size data elements), eight individual 32-bit packed data elements (Double-Word (DW) size data elements), sixteen individual 16-bit packed data elements (Word (W) size data elements), or thirty-two individual 8-bit data elements (Byte (B) size data elements). However, different vector widths and register sizes are possible.

[0058] In one embodiment, one or more execution units may be combined into a fused execution unit (609A-609N) (having thread control logic (607A-607N) common to the fused EU). Multiple EUs may be fused into an EU group. Each EU within the fused EU group may be configured to execute an individual SIMD hardware thread. The number of EUs within the fused EU group may vary depending on the embodiment. Additionally, various SIMD widths may be performed 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, a fused execution unit (609A) includes a first EU (608A), a second EU (608B), and thread control logic (609A) (which is common to the first EU (608A) and the second EU (608B)). The thread control logic (608A) controls the threads executed on the fused graphics execution unit (609A), allowing each EU within the fused execution unit (609A-609N) to be executed using a common instruction pointer register.

[0059] One or more internal instruction caches (e.g., 606) are included in the thread execution logic (600) to cache thread instructions for the execution unit. 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 motion and media sampling for media motion. In some embodiments, the sampler (610) includes a specialized texture or media sampling function that processes texture or media data during the sampling process before providing the sampled data to the execution unit.

[0060] During execution, the graphics and media pipeline sends a thread start request to the thread execution logic (600) via thread spawning and dispatch logic. Once a group of geometric objects has been processed and rasterized into pixel data, pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within the shader processor (602) is called to further calculate output information and cause the result to be written to an output surface (e.g., color buffer, depth buffer, stencil buffer, etc.). In some embodiments, the pixel shader or fragment shader calculates the values ​​of various vertex attributes to be interpolated across the rasterized objects. In some embodiments, the pixel processor logic within the shader processor (602) subsequently executes an application programming interface (API)-supplied pixel or fragment shader program. To execute a shader program, the shader processor (602) dispatches a thread to an execution unit (e.g., 608A) via a thread dispatcher (604). In some embodiments, the pixel processor (602) uses texture sampling logic within a sampler (610) to access texture data within a texture map stored in memory. Arithmetic operations on the texture data and input geometry data calculate pixel color data for each geometric fragment or discard one or more pixels from further processing.

[0061] In some embodiments, the data port (614) provides a memory access mechanism in which the thread execution logic (600) outputs the 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., data cache (612)) that cache data for memory access through the data port.

[0062] As illustrated in FIG. 6b, the graphics execution unit (608) may 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 (630), a branch unit (632), a set of SIMD floating point units (FPU) (634), and in one embodiment, a set of dedicated integer SIMD ALUs (635). The GRF (624) and ARF (626) include sets of general register files and architectural register files associated with each concurrent hardware thread that may be active within the graphics execution unit (608). In one embodiment, the architecture state per thread is maintained within the ARF (626), while data used during thread execution is stored within the GRF (624). The execution state of each thread, including instruction pointers for each thread, may be held within thread-specific registers within the ARF (626).

[0063] In one embodiment, the graphics execution unit (608) has an architecture that is a combination of Simultaneous Multi-Threading (SMT) and fine-grained Interleaved Multi-Threading (IMT). The architecture has a modular configuration that can be fine-tuned at design based on the target number of simultaneous threads and the number of registers per execution unit, and the execution unit resources are divided across the logic used to execute multiple simultaneous threads.

[0064] In one embodiment, the graphics execution unit (608) may co-issue multiple instructions, each of which may be different instructions. The thread arbiter (622) of the graphics execution unit thread (608) may dispatch instructions for execution to the dispatch unit (630), the branch unit (632), or the SIMD PFU(s) (634). Each execution thread may access 128 general-purpose registers within the GRF (624), each register may store 32 bytes accessible as a SIMD 8 element vector of 32-bit data elements. In one embodiment, each execution unit thread has access to 4 kilobytes within the GRF (624), but the embodiment is not so limited, and more or fewer register resources may be provided in other embodiments. In one embodiment, up to 7 threads may be executed simultaneously, but the number of threads per execution unit may also vary depending on the embodiment. In an embodiment where 7 threads can access 4 kilobytes, the GRF (624) can store a total of 28 kilobytes. The flexible addressing mode allows registers to be addressed together to effectively construct a wider register or represent a stride-type rectangular block data structure.

[0065] In one embodiment, memory operations, sampler operations, and other system communications with longer latency are dispatched via a “send” instruction executed by a message delivery sending unit (630). In one embodiment, branch instructions are dispatched to a dedicated branch unit (632) to enable SIMD diversion and ultimate convergence.

[0066] In one embodiment, the graphics execution unit (608) includes one or more SIMD floating point units (PFU)(s) (634) that perform floating point operations. In one embodiment, the FPU(s) (634) also support integer calculations. In one embodiment, the FPU(s) (634) may SIMD execute up to M 32-bit floating point (or integer) operations or SIMD execute up to 2M 16-bit integer or 16-bit floating point operations. In one embodiment, at least one of the FPU(s) provides extended mathematical capabilities supporting high-throughput transcendental mathematical functions and double-precision 64-bit floating point. In some embodiments, a set of 8-bit integer SIMD ALUs (635) is also present and may be specifically optimized to perform operations associated with machine learning calculations.

[0067] In one embodiment, an array of multiple instances of a graphics execution unit (608) may be instantiated within a graphics sub-core grouping (e.g., a sub-slice). For scalability, the product planner may select the exact number of execution units per sub-core grouping. In one embodiment, the execution unit (608) may execute instructions across multiple execution channels. In additional embodiments, each thread executed on the graphics execution unit (608) is executed on a different channel.

[0068] FIG. 7 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 having instructions in various formats. Solid boxes generally show components included in the execution unit instruction, while dotted lines include optional components or components included only in a subset of instructions. In some embodiments, the instruction format (700) described and illustrated is a macro instruction in that it is an instruction supplied to the execution unit as opposed to the micro-operation resulting from the instruction decode once the instruction is processed.

[0069] In some embodiments, the graphics processor execution unit natively supports instructions in the 128-bit instruction format (710). A 64-bit compacted instruction format (740) is available for some instructions based on the selected instruction, instruction options, and the number of operands. While the native 128-bit instruction format (710) provides access to all instruction options, some options and operations are limited to the 64-bit format (730). The native instructions available in the 64-bit format (730) vary by embodiment. In some embodiments, instructions are partially compressed using a set of index values ​​within the index field (713). The execution unit hardware refers to 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).

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

[0071] Some execution unit instructions have up to three operands, including two source operands (src0 (720), src1 (722)) and one destination (718). In some embodiments, the execution unit supports dual destination instructions, one of which is implied. Data manipulation instructions may have a third source operand (e.g., SRC2 (724)), and 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 along with the instruction.

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

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

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

[0075] In some embodiments, instructions are grouped based on the opcode (712) bit field to simplify opcode decoding (740). For an 8-bit opcode, bits 4, 5, and 6 allow the execution unit to determine the type of the opcode. The opcode grouping as illustrated 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 five Most Significant Bits (MSB), with the move(mov) instruction in the form 0000xxxxb and the logic instruction in the form 0001xxxxb. The flow control instruction group (744) (e.g., call, jump(jmp)) includes instructions in the form 0010xxxxb (e.g., 0x20). The other instruction group (746) includes a mixture of instructions including synchronization instructions (e.g., wait, send) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group (748) includes component-specific 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 across data channels. The vector math group (750) includes arithmetic instructions (e.g., dp4) in the form of 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic operations such as calculating a dot product on vector operands.

[0076] Graphics Pipeline

[0077] FIG. 8 is a block diagram of another embodiment of a graphics processor (800). An element of FIG. 8 having the same reference number (or name) as an element of any other drawing in this document may operate or function in any manner similar to that described in other parts of this document, but is not limited to such.

[0078] 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 multicore processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writing to one or more control registers (not shown) or by commands issued to the graphics processor (800) through a ring interconnect (802). In some embodiments, the ring interconnect (802) couples the graphics processor (800) to other processing components, such as other graphics processors or general-purpose processors. Commands from the ring interconnect (802) are interpreted by a command streamer (803), which supplies instructions to individual components of the geometry pipeline (820) or the media pipeline (830).

[0079] In some embodiments, the command streamer (803) directs the operation of a vertex fetcher (805) to read vertex data from memory and execute a vertex processing command provided by the command streamer (803). In some embodiments, the vertex fetcher (805) provides vertex data to a vertex shader (807), which performs coordinate space transformation and lighting operations for each vertex. In some embodiments, the vertex fetcher (805) and the vertex shader (807) execute vertex processing commands by dispatching an execution thread to an execution unit (852A-852B) through a thread dispatcher (831).

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

[0081] In some embodiments, the geometry pipeline (820) includes a tessellation component that performs hardware-accelerated tessellation of 3D objects. In some embodiments, a programmable hull shader (811) configures the tessellation operation. A programmable domain shader (817) provides back-end evaluation of the tessellation output. A tessellator (813) operates under the direction of the hull shader (811) and includes special purpose logic that generates a set of detailed geometric objects based on a coarse geometric model provided as input to the geometry pipeline (820). In some embodiments, when tessellation is not used, the tessellation component (e.g., hull shader (811), tessellator (813), and domain shader (817)) may be bypassed.

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

[0083] Before rasterization, a clipper (829) can process vertex data. The clipper (829) may be a fixed-function clipper or a programmable clipper having clipping and geometry shader functions. In some embodiments, a rasterizer and depth test component (873) within the render output pipeline (870) dispatches a pixel shader 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, the application can bypass the rasterizer and depth test component (873) and access the unrasterized vertex data through a stream out unit (823).

[0084] The graphics processor (800) has an interconnection bus, an interconnection fabric, or other interconnection mechanism that enables data and messages to pass between the main components of the processor. In some embodiments, execution units (852A-852B) and associated logic units (e.g., L1 cache (851), sampler (854), texture cache (858), etc.) are interconnected via a data port (856) to perform memory access and communicate with the render output pipeline components of the processor. 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) may also be configured as a sampler cache.

[0085] In some embodiments, the render output pipeline (870) includes a rasterizer and a depth test component (873) that convert vertex-based objects into associated pixel-based representations. In some embodiments, the rasterizer logic includes a windower / masker unit that performs fixed-function triangle and line rasterization. An associated render cache (878) and a depth cache (879) are also available in some embodiments. A pixel action component (877) performs pixel-based actions on the data, and in some cases, pixel actions associated with 2D actions (e.g., bit-block image transfer as blending) are performed by a 2D engine (841) or replaced at display time by a display controller (843) using an overlay display plane. In some embodiments, a shared L3 cache (875) is available to all graphics components, enabling data sharing without using main system memory.

[0086] 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 a command streamer (803). In some embodiments, the media pipeline (830) includes a separate command streamer. In some embodiments, the video front end (834) processes the media commands before sending the commands to the media engine (837). In some embodiments, the media engine (837) includes a thread spawning function that spawns threads for dispatch to thread execution logic (850) via a thread dispatcher (831).

[0087] In some embodiments, the graphics processor (800) includes a display engine (840). In some embodiments, the display engine (840) is outside the processor (800) and is coupled to the graphics processor via a ring interconnect (802) or any 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, such as in a laptop computer, or an external display device attached via a display device connector.

[0088] In some embodiments, the geometry pipeline (820) and the media pipeline (830) can be configured to perform operations based on various graphics and media programming interfaces and are not specific to any single Application Programming Interface (API). In some embodiments, driver software for the graphics processor converts 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), Open Computing Language (OpenCL), and / or Vulkan graphics and compute APIs, all of which are from the Khronos Group. In some embodiments, support for the Direct3D library from Microsoft Corporation may also be provided. In some embodiments, a combination of these libraries may be supported. Support for the Open Source Computer Vision Library (OpenCV) may also be provided. Future APIs with compatible 3D pipelines will also be supported if mapping from the pipeline of the future API to the pipeline of the graphics processor can be performed.

[0089] Graphics Pipeline Programming

[0090] FIG. 9a is a block diagram showing a graphics processor command format (900) according to some embodiments. FIG. 9b is a block diagram showing a graphics processor command sequence (910) according to an embodiment. In FIG. 9a, solid boxes generally show components included in a graphics command, while dotted lines include optional components or components included only in a subset of graphics commands. An exemplary graphics processor command format (900) of FIG. 9a includes a client (902), a command operation code (opcode) (904), and a data field identifying related data (906) for the command. A sub-opcode (905) and a command size (908) are also included in some commands.

[0091] In some embodiments, the client (902) specifies a client unit of a graphics device that processes command data. In some embodiments, a 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 unit includes a memory interface unit, a render unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline that processes the command. Once the command is received by the client unit, the client unit reads the opcode (904) and, if present, the sub-opcode (905) to determine the action to be performed. The client unit performs the command using information within the data field (906). For some commands, an explicit command size (908) is expected to specify the size of the command. In some embodiments, the command parser automatically determines the size of at least some of the commands based on the command opcode. In some embodiments, the command is arranged through multiple double words.

[0092] The flowchart of FIG. 9b shows an exemplary graphics processor command sequence (910). In some embodiments, software or firmware of a data processing system featuring an embodiment of a graphics processor uses a version of the command sequence shown to set up, execute, and terminate a set of graphics operations. A sample command sequence is shown and described only for example, and embodiments are not limited to these specific commands or this command sequence. Furthermore, commands may be issued as a batch of commands within a command sequence so that the graphics processor will process the sequence of commands at least partially concurrently.

[0093] In some embodiments, the graphics processor command sequence (910) begins with a pipeline flush command (912) to cause any active graphics pipeline to complete any currently pending command for the pipeline. In some embodiments, the 3D pipeline (922) and the media pipeline (924) do not operate simultaneously. A pipeline flush is performed to cause the active graphics pipeline to complete any pending command. In response to the pipeline flush, the command parser for the graphics processor will pause command processing until the active drawing engine completes the pending operation and the associated read cache is invalidated. Optionally, any data in the render cache marked as 'dirty' 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.

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

[0095] In some embodiments, the pipeline control command (914) configures the graphics pipeline for operation and is used to program the 3D pipeline (922) and the media pipeline (924). In some embodiments, the pipeline control command (914) configures the pipeline state for the active pipeline. In one embodiment, the pipeline control command (914) is used for pipeline synchronization and is used to clear data from one or more cache memories within the active pipeline before processing a batch of commands.

[0096] In some embodiments, the return buffer status command (916) is used to configure a set of return buffers for each pipeline to write data. Some pipeline operations require the allocation, selection, or configuration of one or more return buffers during processing, for which the operation writes intermediate data. 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, the return buffer status (916) includes selecting the size and number of return buffers to use for a set of pipeline operations.

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

[0098] Commands that configure the 3D pipeline state (930) include 3D state setting commands for vertex buffer state, vertex element state, constant color state, depth buffer state, and other state variables to be configured before the 3D primitive command is processed. The values ​​of these commands are determined at least partially based on the specific 3D API being used. In some embodiments, the 3D pipeline state (930) command may also optionally disable or bypass any pipeline element if such element is not to be used.

[0099] In some embodiments, the 3D primitive (932) command is used to submit a 3D primitive to be processed by the 3D pipeline. The command and associated parameters passed to the graphics processor via the 3D primitive (932) command are forwarded to a vertex fetch function within the graphics pipeline. The vertex fetch function uses the 3D primitive (932) command data to create a vertex data structure. The vertex data structure is stored in one or more return buffers. In some embodiments, the 3D primitive (932) command is used to perform vertex operations on the 3D primitive through a vertex shader. To process the vertex shader, the 3D pipeline (922) dispatches a shader execution thread to the graphics processor execution unit.

[0100] In some embodiments, the 3D pipeline (922) is triggered via an execute (934) command or event. In some embodiments, a register write triggers the command execution. In some embodiments, the execution is triggered via a 'go' or 'kick' command within the command sequence. In one embodiment, the command execution is triggered using a pipeline synchronization command that flushes the command sequence through the graphics pipeline. The 3D pipeline will perform geometry processing for the 3D primitives. Once the operation is complete, the resulting geometric object is rasterized, and the pixel engine colors the resulting pixels. Additional commands controlling pixel shading and pixel back-end operations may also be included for such operations.

[0101] In some embodiments, the graphics processor command sequence (910) follows the media pipeline (924) path when performing a media operation. Generally, the specific use and method of programming for the media pipeline (924) depends on the media or compute operation to be performed. Specific media decode operations may be offloaded to the media pipeline during media decode. In some embodiments, the media pipeline may also be bypassed, and media decode may be performed wholly or partially using resources provided by one or more general-purpose processing cores. In one embodiment, the media pipeline also includes elements for General-Purpose Graphics Processor Unit (GPGPU) operations, where the graphics processor is used to perform SIMD vector operations using compute shader programs that are not explicitly involved in the rendering of graphics primitives.

[0102] In some embodiments, the media pipeline (924) is configured in a manner similar to the 3D pipeline (922). A set of commands that constitute the media pipeline state (940) is placed in a command queue or dispatched before the media object command (942). In some embodiments, the command for the media pipeline state (940) includes data that constitutes the media pipeline element to be used to process the media object. This includes data that constitutes the video decode and video encode logic within the media pipeline, for example, the encode or decode format. In some embodiments, the command for the media pipeline state (940) also supports the use of one or more pointers to "indirect" state elements that include the placement of state settings.

[0103] In some embodiments, the media object command (942) provides a pointer to a media object for processing by the media pipeline. The media object contains a memory buffer containing video data to be processed. In some embodiments, all media pipeline states must be valid before issuing the media object command (942). Once the pipeline state is configured and the media object command (942) is queued, the media pipeline (924) is triggered by an execution command (944) or an equivalent execution event (e.g., a register write). The output from the media pipeline (924) may then be post-processed by the 3D pipeline (922) or by an operation provided by the media pipeline (924). In some embodiments, the GPGPU operation is configured and executed in a manner similar to the media operation.

[0104] Graphics software architecture

[0105] FIG. 10 shows an exemplary graphics software architecture for a data processing system (1000) according to 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 core(s) (1034). The graphics application (1010) and the operating system (1020) are each executed within the system memory (1050) of the data processing system.

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

[0107] In some embodiments, the operating system (1020) is a Microsoft® Windows® operating system from Microsoft Corporation, a proprietary UNIX-like operating system, or an open source UNIX-like operating system using a variant of the Linux kernel. The operating system (1020) may support graphics APIs (1022) such as the 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 instruction (1012) within HLSL into a low-level shader language. Compilation may be Just-In-Time (JIT) compilation, or the application may 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, shader instructions (1012) are provided in an intermediate form, for example, a version of the Standard Portable Intermediate Representation (SPIR) used by the Vulkan API.

[0108] In some embodiments, the user mode graphics driver (1026) includes a backend shader compiler (1027) that converts shader instructions (1012) into a hardware-specific representation. When the OpenGL API is in use, shader instructions (1012) in the GLSL high-level language are passed to the user mode graphics driver (1026) for compilation. In some embodiments, the user mode graphics driver (1026) uses an operating system kernel mode function (1028) to communicate with the kernel mode graphics driver (1029). In some embodiments, the kernel mode graphics driver (1029) communicates with the graphics processor (1032) to dispatch commands and instructions.

[0109] IP Core Implementation

[0110] At least one aspect of at least one embodiment may be implemented by representational code stored on a machine-readable medium that represents and / or defines logic within an integrated circuit, such as a processor. For example, the machine-readable medium may contain instructions representing various logic within a processor. When read by a machine, the instructions may cause the machine to produce logic that performs the techniques described in this document. Such a representation known as an "IP core" is a reusable unit of logic for an integrated circuit that can be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model may be supplied to various customers or manufacturing facilities that load the hardware model onto a manufacturing machine for manufacturing the integrated circuit. The integrated circuit may be manufactured so that it performs the operations described in association with any of the embodiments described in this document.

[0111] FIG. 11a is a block diagram showing an IP core development system (1100) that can be used to manufacture an integrated circuit that performs operations according to an embodiment. The IP core development system (1100) can be used to create a modular, reusable design that can be integrated into a larger design, or to build an entire integrated circuit (e.g., an SOC integrated circuit). A 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) may include function, behavior, and / or timing simulations. Then, a Register Transfer Level (RTL) design (1115) can be generated or synthesized from the simulation model (1112). The RTL design (1115) is an abstraction of the behavior of an integrated circuit that models the flow of digital signals between hardware registers, including associated logic performed using the modeled digital signals. In addition to the RTL design (1115), lower-level designs at the logic level or transistor level may also be created, designed, or synthesized. Therefore, specific details of the initial design and simulation may vary.

[0112] The RTL design (1115) or equivalent may further be synthesized into a hardware model (1120) by a design facility, which may be in Hardware Description Language (HDL) or any other representation of physical design data. The HDL may also be simulated or tested to verify the IP core design. The IP core design may be stored in non-volatile memory (1140) (e.g., hard disk, flash memory, or any non-volatile storage medium) for transfer to a third-party manufacturing facility (1165). Alternatively, the IP core design may be transmitted over a wired connection (1150) or a wireless connection (1160) (e.g., via the Internet). The manufacturing facility (1165) may then manufacture an integrated circuit based at least partially on the IP core design. The manufactured integrated circuit may be configured to perform operations according to at least one embodiment described in this document.

[0113] FIG. 11b shows a cross-sectional side view of an integrated circuit package assembly (1170) according to 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 several units of hardware logic (1172, 1174) connected to a substrate (1180). The logic (1172, 1174) may be implemented at least partially as configurable logic or fixed-function logic hardware and may include one or more parts of any of processor core(s), graphics processor(s), or other accelerator devices described herein. Each unit of the logic (1172, 1174) may be implemented within a semiconductor die and coupled to the substrate (1180) through an interconnection structure (1173). The interconnect structure (1173) may be configured to route electrical signals between the logic (1172, 1174) and the substrate (1180) and may include interconnects such as, but not limited to, bumps or pillars. In some embodiments, the interconnect structure (1173) may be configured to route electrical signals, for example, input / output (I / O) signals and / or power or ground signals associated with the operation of the logic (1172, 1174). In some embodiments, the substrate (1180) is an epoxy-based laminate substrate. The package substrate (1180) may include other suitable types of substrates in other embodiments. The package assembly (1170) may be connected to other electrical devices through the package interconnect (1183).The package interconnect (1183) can be coupled to the surface of the substrate (1180) to route electrical signals to other electrical devices, for example, a motherboard, another chipset, or a multi-chip module.

[0114] In some embodiments, units of logic (1172, 1174) are electrically coupled to a bridge (1182) configured to route electrical signals between the logic (1172, 1174). The bridge (1182) may be a dense interconnect structure that provides a path for electrical signals. The bridge (1182) may include a bridge substrate made of glass or a suitable semiconductor material. Electrical routing features may be formed on the bridge substrate to provide a chip-to-chip connection between the logic (1172, 1174).

[0115] Two units of logic (1172, 1174) and a bridge (1182) are exemplified, but the embodiments described herein may include more or fewer logic units on one or more dies. One or more dies may be connected by zero or more bridges, so that if the logic is contained on a single die, the bridge (1182) may be excluded. Alternatively, multiple dies or units of logic may be connected by one or more bridges. Additionally, multiple logic units, dies, and bridges may be connected together in other possible configurations, including three-dimensional configurations.

[0116] Exemplary System-on-Chip Integrated Circuit

[0117] FIGS. 12 through 14 show exemplary integrated circuits and associated graphics processors that may be fabricated using one or more IP cores according to various embodiments described herein. In addition to those illustrated, other logic and circuits may be included, including additional graphics processors / cores, peripheral interface controllers, or general-purpose processor cores.

[0118] FIG. 12 is a block diagram showing an exemplary system-on-chip integrated circuit (1200) that can be fabricated using one or more IP cores according to an embodiment. The exemplary integrated circuit (1200) includes one or more application processor(s) (1205) (e.g., CPU), 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 a modular IP core from the same or a number of 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 I2S / I2C 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 (1225). 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 access to an SDRAM or SRAM memory device. Some integrated circuits additionally include an embedded security engine (1270).

[0119] FIGS. 13a and 13b are block diagrams showing exemplary graphics processors for use within an SoC according to embodiments described herein. FIG. 13a shows an exemplary graphics processor (1310) of a system-on-chip integrated circuit that can be fabricated using one or more IP cores according to embodiments. FIG. 13b shows an additional exemplary graphics processor (1340) of a system-on-chip integrated circuit that can be fabricated using one or more IP cores according to embodiments. The graphics processor (1310) of FIG. 13a is an example of a low-power graphics processor core. The graphics processor (1340) of FIG. 13b is an example of a higher-performance graphics processor core. Each of the graphics processors (1310, 1340) may be a variation of the graphics processor (1210) of FIG. 12.

[0120] As illustrated in FIG. 13a, the graphics processor (1310) includes a vertex processor (1305) and one or more fragment processor(s) (1315A-1315N) (e.g., 1315A, 1315B, 1315C, 1315D through 1315N-1 and 1315N). The graphics processor (1310) can execute different shader programs through separate logic, so that the vertex processor (1305) is optimized to execute operations for a vertex shader program, whereas one or more fragment processor(s) (1315A-1315N) execute fragment (e.g., pixel) shading operations for a fragment or pixel shader program. The vertex processor (1305) performs the vertex processing stage of the 3D graphics pipeline and generates primitive and vertex data. Fragment processor(s) (1315A-1315N) use primitive and vertex data generated by vertex processor (1305) to produce a frame buffer to be displayed on a display device. In one embodiment, the fragment processor(s) (1315A-1315N) are optimized to execute a fragment shader program as made possible by the OpenGL API, which can be used to perform a similar operation as a pixel shader program as made possible by the Direct 3D API.

[0121] The graphics processor (1310) additionally includes one or more Memory Management Units (MMUs) (1320A-1320B), cache(s) (1325A-1325B), and circuit interconnect(s) (1330A-1330B). One or more MMU(s) (1320A-1320B) enable virtual to physical address mapping for the graphics processor (1310), including a vertex processor (1305) and / or fragment processor(s) (1315A-1315N) capable of referencing vertex or image / texture data stored in memory, in addition to vertex or image / texture data stored in one or more cache(s) (1325A-1325B). In one embodiment, one or more MMU(s) (1320A-1320B) may be synchronized with other MMUs in the system, including one or more MMUs associated with one or more application processor(s) (1205) of FIG. 12, an image processor (1215), and / or a video processor (1220), so that each processor (1205-1220) may participate in a shared or unified virtual memory system. One or more circuit interconnect(s) (1330A-1330B) enable the graphics processor (1310) to interface with other IP cores in the SoC, either through the internal bus of the SoC or through a direct connection, depending on the embodiment.

[0122] As illustrated in FIG. 13b, the graphics processor (1340) includes one or more MMU(s) (1320A-1320B), a cache (1325A-1325B), and circuit interconnects (1330A-1330B) of the graphics processor (1310) of FIG. 13a. The graphics processor (1340) includes one or more shader core(s) (1355A-1355N) (e.g., 1455A, 1355B, 1355C, 1355D, 1355E, 1355F through 1355N-1 and 1355N), which enables a unified shader core architecture in which all types of programmable shader code, including shader program code implementing vertex shaders, fragment shaders and / or workload command shaders, can be executed by a single core or a single type of core. The exact number of shader cores present may vary between embodiments and implementations. Additionally, the graphics processor (1340) includes an inter-core task manager (1345), which acts as a thread dispatcher that dispatches execution threads to one or more shader cores (1355A-1355N) and a tiling unit (1358) that accelerates tiling operations for granular tile-based rendering in image space, for example, to utilize local spatial coherence within the scene or to optimize the use of an internal cache.

[0123] FIGS. 14a and 14b illustrate additional exemplary graphics processors according to embodiments described herein. FIG. 14a shows a graphics core (1400) which may be included within the graphics processor (1210) of FIG. 12 and may be a unified shader core (1355A-1355N) as in FIG. 13b. FIG. 14b shows a highly-parallel general-purpose graphics processing unit (1430) suitable for placement on a multi-chip module.

[0124] As illustrated in FIG. 14a, the graphics core (1400) includes a shared instruction cache (1402), a texture unit (1418), and a cache / shared memory (1420) that are common to 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 processor core (1400). The slices (1401A-1401N) may include support logic including a local instruction cache (1401A-1401N), a thread scheduler (1406A-1406N), a thread dispatcher (1408A-1408N), and a set of registers (1410A-1410N). To perform logic operations, slices (1401A-1401N) may include a set of Additional Function Units (AFU) (1412A-1412N), Floating Point Units (FPU) (1414A-1414N), Arithmetic Logic Units (ALU) (1416-1416N), Address Computational Units (ACU) (1413A-1413N), Double-Precision Floating-Point Units (DPFPU) (1415A-1415N) and Matrix Processing Units (MPU) (1417A-1417N).

[0125] Some of the compute units operate at specific precisions. For example, the FPU (1414A-1414N) can 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) can perform variable-precision integer operations with 8-bit, 16-bit, and 323-bit precisions and can be configured for mixed-precision operations. The MPU (1417A-1417N) can also be configured for mixed-precision matrix operations, including half-precision floating-point and 8-bit integer operations. The MPU (1417-1417N) can 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) can perform additional logic operations not supported by the floating-point or integer unit, including trigonometric operations (e.g., sine, cosine, etc.).

[0126] As illustrated in FIG. 14b, a general-purpose processing unit (GPGPU) (1430) can be configured to enable highly parallel compute 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 create a multi-GPU cluster to improve training speeds, particularly for deep neural networks. The GPGPU (1430) includes a host interface (1432) that enables connection with a host processor. In one embodiment, the host interface (1432) is a PCI Express interface. However, the host interface may 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 such commands to a set of compute clusters (1436A-1436H). The compute clusters (1436A-1436H) share the cache memory (1438). The cache memory (1438) can serve as a higher-level cache for the cache memory within the compute clusters (1436A-1436H).

[0127] The GPGPU (1430) includes memory (1444A-1444B) coupled to the compute cluster (1436A-1436H) through a set of memory controllers (1442A-1442B). In various embodiments, the memory (1444A-1444B) may include various types of memory devices, such as Dynamic Random Access Memory (DRAM) or Graphics Random Access Memory, for example, Synchronous Graphics Random Access Memory (SGRAM) (including Graphics Double Data Rate (GDDR) memory).

[0128] In one embodiment, each of the compute clusters (1436A-1436H) includes a set of graphics cores, such as the graphics core (1400) of FIG. 14a, which may include various types of integer and floating-point logic units capable of performing computational operations in a range of precision suitable for machine learning computation. For example, in one embodiment, at least a subset of floating-point units within each of the compute clusters (1436A-1436H) may be configured to perform 16-bit or 32-bit floating-point operations, while a different subset of floating-point units may be configured to perform 64-bit floating-point operations.

[0129] Multiple instances of the GPGPU (1430) may be configured to operate as a compute cluster. The communication mechanism used by the compute cluster for synchronization and data exchange varies according to the embodiment. In one embodiment, multiple instances of the GPGPU (1430) communicate through a host interface (1432). In one embodiment, the GPGPU (1430) includes an I / O hub (1439) that couples the GPGPU (1430) to a GPU link (1440) that enables direct connection to other instances of the GPGPU. In one embodiment, the GPU link (1440) is coupled to a dedicated GPU-to-GPU bridge that enables communication and synchronization between multiple instances of the GPGPU (1430). In one embodiment, the GPU link (1440) is coupled to a high-speed interconnection unit to transmit and receive data to and from other GPGPUs or parallel processors. In one embodiment, multiple instances of the GPGPU (1430) are located within individual data processing systems and communicate through network devices accessible via a host interface (1432). In one embodiment, a GPU link (1440) may be configured to enable a connection to a host processor in addition to or as an alternative to the host interface (1432).

[0130] The illustrated configuration of the GPGPU (1430) may be configured to train a neural network, but one embodiment provides an alternative configuration of the GPGPU (1430) that may be configured for deployment within a high-performance or low-power inference platform. In the inference configuration, the GPGPU (1430) includes fewer of the compute clusters (1436A-1436H) compared to the training configuration. Additionally, memory technology associated with memory (1434A-1434B) may differ between the inference and training configurations, with higher bandwidth memory technology allocated to the training configuration. In one embodiment, the inference configuration of the GPGPU (1430) may support inference-specific instructions. For example, the inference configuration may provide support for one or more 8-bit integer dot product instructions that are typically used during inference operations for a deployed neural network.

[0131] Workload scheduling and distribution on distributed graphics devices

[0132] The embodiments described herein provide a graphics, media, and computing device having a tile structure composed of a plurality of tiles of a smaller graphics device. Such a device may be scaled to include more or fewer tiles depending on the power and / or performance objectives of the device. Such a device may enable efficient distribution of workloads across multiple tiles using a specially scaled workload distribution infrastructure. The workload distribution infrastructure described herein enables workload dispatch scaled across a variable number of multiple tiles. Work items may be submitted to one or more of the tiles, and workloads may span across multiple tiles. Additionally, when a work item is completed, the graphics, media, and / or computing engine within the device can easily obtain a new work item to execute with minimal latency.

[0133] FIG. 15 is a block diagram of a data processing system (1500) according to one embodiment. The data processing system (1500) is a heterogeneous processing system having a processor (1502), integrated memory (1510), and a GPGPU (1520) including machine learning acceleration logic. The processor (1502) and the GPGPU (1520) may be any of the processor and GPGPU / parallel processor as described herein. The processor (1502) may execute instructions for a compiler (1515) stored in system memory (1512). The compiler (1515) is executed on the processor (1502) to compile source code (1514A) into compiled code (1514B). The compiled code (1514B) may include instructions that can be executed by the processor (1502) and / or instructions that can be executed by the GPGPU (1520). During compilation, the compiler (1515) may perform an action of inserting metadata, including hints regarding the level of data parallelism present in the compiled code (1514B) and / or hints regarding the data location associated with the thread to be dispatched based on the compiled code (1514B). The compiler (1515) may include information necessary to perform such an action, or the action may be performed with the help of a runtime library (1516). The runtime library (1516) may also assist the compiler (1515) during the compilation of the source code (1514A) and may also include instructions that are linked with the compiled code 1514B at runtime to facilitate the execution of the compiled instructions on the GPGPU (1520).

[0134] The integrated memory (1510) represents an integrated address space that can be accessed by the processor (1502) and the GPGPU (1520). The integrated memory may include system memory (1512) and GPGPU memory (1518). GPGPU memory (1518) is memory within the address space of the GPGPU (1520) and may include part or all of the system memory (1512). In one embodiment, GPGPU memory (1518) may also include at least a portion of any memory dedicated to be used exclusively by the GPGPU (1520). In one embodiment, compiled code (1514B) stored in system memory (1512) may be mapped to GPGPU memory (1518) for access by the GPGPU (1520).

[0135] The GPGPU (1520) comprises a plurality of engine block tiles (1524A-1524N), which may include one or more of the various computational units or execution elements described herein. In one embodiment, the GPGPU (1520) further comprises a matrix accelerator (1523), which may include one or more special function computational units designed to accelerate a subset of matrix operations (e.g., dot product, etc.). The GPGPU (1520) may comprise a resource set that can be shared by the engine block tiles (1524A-1524N), the resource set including, but not limited to, a global register set (1525), a power and performance module (1526), ​​and a shared cache (1527). In one embodiment, the global register (1525) includes registers that are directly or indirectly accessible. The power and performance module (1526) may be configured to adjust the power delivery and clock frequencies for the engine block tiles (1524A-1524N) to modulate the power consumption of the components within the engine block tiles (1524A-1524N). For example, in one embodiment, the power delivered to the components within the engine block tiles (1524A-1524N) may be dynamically switched (e.g., gated) based on power or performance targets for the data processing system (1500). In various embodiments, the shared cache (1527) includes an instruction cache and / or a lower-level data cache.

[0136] In one embodiment, each engine block tile (1524A-1524N) includes a set of graphics processing engines that can operate independently or in cooperation to execute a plurality of workloads or a single distributed workload. Each tile includes various engines that perform different activities. The various engines can process commands provided in a batch buffer, which is a memory buffer containing a batch of commands, and can execute these commands using execution units within the engine block tile (1524A-1524N). Software running on the host processor can submit work items to a global scheduler (1522), and the global scheduler can distribute the various work items to one or more engine block tiles (1524A-1524N). Optionally, software can submit work items directly to a tile, and scheduling hardware within the tile can schedule the workload to the appropriate engine within the tile.

[0137] FIGS. 16a through 16c illustrate a graphics processing system (1600) implementing multi-tile task scheduling according to an embodiment. FIG. 16a illustrates an overview of a graphics processing system (1600) according to one embodiment. FIG. 16b illustrates an example of a system graphics interface (1602). FIG. 16c illustrates an example of an engine block tile (1605).

[0138] As illustrated in FIG. 16a, the graphics processing system (1600) includes an application and / or graphics driver (app / driver (1601)) capable of transmitting a workload (1604A-1604D) to one or more engine block tiles (1605A-1605D), which may be identical to or a variation of the engine block tiles (1524A-1524N) of FIG. 15. The workload (1604A-1604D) may be parts of the same workload or separate workloads. The workload (1604A-1604D) may be executed in cooperation with one another or independently depending on the relationship (or lack thereof) between the workloads. The application of the app / driver (1601) may be any application capable of submitting a workload to the graphics processing system or configured to submit one. The driver can be a user-mode driver, through which the application can submit workloads via the associated kernel-mode driver.

[0139] In some embodiments and / or implementations, a global scheduler (e.g., the global scheduler (1522) of FIG. 15) dispatches a workload to the engine block tiles. In other embodiments, the workload may be submitted directly to the engine block tiles (1605A-1605D) via a doorbell (1603A-1603D) within the system graphic interface (1602A-1602D) associated with each individual engine block tile (1605A).

[0140] The system graphics interfaces (1602A-1602D) associated with each engine block tile (1605A-1604D) provide an interface between the host system and the graphics system in which the engine block tile resides. The system graphics interfaces (1602A-1602D) include graphics device logic that provides the graphics processing system to the host system as a device, and include PCIe configuration space data that enables communication with the graphics device via the PCIe bus. In other embodiments, different bus interfaces may be used for different types of host or device interface buses, such as processor interface buses (e.g., processor ring or mesh bus, CoreLink or AMBA bus, etc.), or for another type of mesh or fabric interface (e.g., NVLink). In one embodiment, interrupt generation is handled through the system graphics interfaces (1602A-1602D). For interrupt generation, one of the system graphics interfaces (1602A-1602D) may operate as the master interface of the graphics system. In one embodiment, the system graphics interface (1602A-1602D) can perform a conversion from host address space to local address space for the graphics processing system.

[0141] In one embodiment, the system graphic interface (1602A-1602D) each includes a doorbell (1604A-1604D), and a workload (1604A-1604D) can be submitted through the doorbell. In one embodiment, each doorbell (1604A-1604D) is a doorbell block supporting 256 doorbells, but the doorbell block may include any number of doorbells. A doorbell may be assigned to an application, and an affinity to an application tile may be managed through a graphic driver. One or more doorbells may be assigned to an application, and doorbell assignments may be cross-tile assignments. To submit a workload, the application or driver software may ring an appropriate doorbell depending on the type of work the application is submitting. When the software rings a doorbell associated with a tile, scheduling may be managed locally within the tile. For example, the system graphic interface associated with a tile can schedule requested workloads to a local engine using a local scheduler within the tile.

[0142] FIG. 16b illustrates a system graphics interface (1602) according to one embodiment. The system graphics interface (1602) includes an interrupt unit (1612), a device interface (1614), a doorbell (1603), a system / device address converter (1616), and a batch buffer submitter (1618). The interrupt unit (1612) may be configured as a remote or master interrupt unit and may transmit a message signaled interrupt (MSI) generated according to a value stored in an interrupt register within the interrupt unit (1612). The device interface (1614) may include hardware that enables the graphics system to be provided as a whole or as individual tiles as devices on an interface bus (including, but not limited to, a PCIe bus). The doorbell (1603) is one of a plurality of doorbell interfaces (through which a workload (1604) can be submitted), and the workload (1604) may be any one of the workloads (1604A-1604D) of FIG. 16a. The doorbell (1603) may be a doorbell structure or register that can be used to notify the relevant engine block tile that a work request is available for processing. In one embodiment, the work request is provided in the form of a batch command buffer (e.g., a batch buffer). The batch buffer may be processed through a batch buffer submitter (1618). In one embodiment, the batch buffer submitter (1618) may use a system / device address converter (1616) to convert a system address to a device local address for the engine block tile. Then, the command of the batch buffer may be submitted to the relevant engine block tile.

[0143] FIG. 16c illustrates an engine block tile (1605) capable of receiving workloads from an application or driver through a system graphic interface. The engine block tile (1605) includes a plurality of engines capable of processing commands received from a host system. The engines perform various operations and can execute basic instructions for these commands through one or more execution unit blocks (1629A-1629N). The engine block tile (1605) also includes a scheduler (1621), which acts as a local scheduler for the engine block tile (1605) to schedule commands to be processed by various tiles and / or schedule instructions to be executed on the execution units (1629A-1629N). In one embodiment, the engine of the engine block tile comprises an RCS (render command streamer, 1623), a POCS (position only command streamer, 624), a CCS (compute command streamer, 1625), a copy engine (1622), and one or more media engine slices (1626), and the media engine slice comprises one or more video command streamers (VCSn, 1627) for performing video decoding operations and a video encode command streamer (VECSn, 1628) for performing video encoding operations. The incoming batch buffer may contain commands that can be processed by any one or more of the illustrated engines and other engines not illustrated.

[0144] The embodiments described herein allow an application or graphics driver to explicitly submit a workload distributed across multiple tiles. Additionally, load balancing between tiles can be performed after the workload is submitted. In one embodiment, to enable cross-tile workloads, the same batch buffer containing a superset of work items to be executed is submitted to each tile included within the tile workload group. All commands are submitted to all tiles to execute commands, even if a given tile is not intended to execute all submitted workloads. Instead, each tile executes only one subset of the submitted workload. In one embodiment, a given tile may execute one specific subset of the workload based on an identifier provided in the hardware context associated with the tile.

[0145] FIG. 17 illustrates a tile task partitioning and scheduling system (1700) according to embodiments described herein. The tile task partitioning and scheduling system (1700) enables the workload to be distributed across a plurality of GPUs (1730A-1730D), each of which may be an instance of an engine block tile (1605A-1605D) as in FIG. 16A. The GPUs (1730A-1730D) may be listed as one or more devices based on the configuration of the individual system graphics interfaces of the GPUs (1730A-1730D).

[0146] To enable the execution of GPU-spanning workloads, individual hardware contexts (1720A-1720D) may be created and associated with individual GPUs (1730A-1730D). In one embodiment, the hardware context and batch buffer (1708) may be created by a user-mode driver running on a processor of the host system. Such a batch buffer (1708) includes a command that defines the execution state in which the command is to be executed, and a GPGPU walker command that causes the GPU to dispatch an execution thread to perform the workload. Each hardware context (1720A-1720D) defines additional execution states for the individual GPUs (1730A-1730D) of the hardware context. In one embodiment, the execution states defined within the hardware context may specify a tile group offset (TG_OFFSET) and a tile group step (TG_STEP) for each GPU. The tile group offset specifies the starting position within the batch buffer (1708) for the command to be executed by the individual GPU. The tile group step may specify the number of partitions for the workload. The batch buffer start command is inserted into the command ring buffer (1710A-1710D) associated with the individual GPU (1730A-1730D). The GPU (1730A-1730D) will execute the command associated with the GPU and enter a waiting state (1702A-1702D) upon completion of these commands. In one embodiment, it enters the waiting state (1702A-1702D) based on an explicit semaphore wait or other synchronization / wait command inserted at the end of the command for the GPU. In another embodiment, an automatic synchronization system is used to synchronize the GPU (1720A-1720D).

[0147] FIG. 18 illustrates a system (1800) that enables load balancing in a multi-tile graphics processing system according to an embodiment. The same batch buffer (1810) may contain commands (1812A-1812C) provided to a plurality of virtual engines within a set of physical engine block tiles (1822A-1822C). The physical engines within the engine block tiles (1822A-1822C) may be virtualized so that the commands refer to a virtual engine that may physically reside within any of the physical tiles. In one embodiment, an app / driver (1601) may divide the workload among N sets of virtual engines by generating N local render context addresses (LRCAs). Each LRCA (1802A-1802C) includes a workload partition identifier (WPARID, 1801) that identifies the workload partition associated with the LRCA. Each LRCA is submitted to different engines within physical engine block tiles (1822A-1822C) to enable parallel execution of workloads. During the execution of a workload, the engine uses the WPARID provided to its LRCA to identify the portion of the workload to execute.

[0148] For example, the WPARID of X may be assigned to the LRCA (1802A) associated with the physical tile (1822A). The LRCA (1802A) may refer to a portion of the batch buffer (1810) containing commands to be executed by the virtual engine X that may be associated with physical tile 0 (physical engine tile (1822A)). Physical tile 0 may now execute the virtual engine X command (1812A) as a workload (1814A). The LRCA (1802B) may refer to a portion of the batch buffer (1810) containing commands to be executed by the virtual engine Y that may be associated with physical tile 1 (physical engine tile (1822B)). Physical tile 1 may now execute the virtual engine Y command (1812B) as a workload (1814B). LRCA (1802C) may refer to a portion of a batch buffer (1810) containing a command to be executed by virtual engine Z that can be associated with physical tile 2 (physical engine tile (1822C)). Physical tile 2 can now execute the virtual engine Z command (1812C) as a workload (1814C).

[0149] In one embodiment, WPARID (1801) is a whitelisted parameter that a user mode driver can modify to enable dynamic load balancing. Modifications to WPARID can be performed during workload execution. Modifications are performed atomically so that other engines running concurrently cannot claim ownership of the same WPARID. In one embodiment, WPARID is saved and restored as part of the hardware context save and restore.

[0150] By dynamically obtaining a WPARID ID from an LRCA, the context can be transparently migrated to any physical tile. During execution, regardless of the physical tile on which the workload is executed, a subset of the same command for a given WPARID is executed. In one embodiment, multiple LRCAs may be submitted to the same engine to serialize the execution of commands. For example, if both a virtual engine X command (1812A) and a virtual engine Y command (1812B) are submitted to a physical engine tile (1822B), both sets of commands will be executed in a serialized manner.

[0151] In one embodiment, the execution of a virtual engine command is handled using scheduled execution logic within a physical engine tile (1822A-1822C). If a portion of the batch buffer provided to the hardware matches a WPARID provided by an LRCA associated with a physical tile and / or virtual engine set, commands and / or instructions for the engine may be conditionally executed. In one embodiment, if conditional execution is possible, a separate batch buffer start location may not be required because the tile will automatically bypass the execution of commands that do not match the WPARID provided by the LRCA. In one embodiment, when dynamic load balancing is performed by migrating WPARIDs between tiles, the tile may rescan the batch buffer to find commands and reset the conditional execution unit within the tile to execute commands for the new WPARID. When a WPARID is removed, the tile may stop the execution of commands associated with the removed WPARID.

[0152] FIG. 19 illustrates a flowchart of a method (1900) for multi-tile workload scheduling according to one embodiment. The method (1900) may be performed by an application or driver of a host processing system including a multi-tile, multi-core, or multi-GPU graphics processing system as described herein. Where reference to a tile of a graphics processing engine is made, a similar technique may be applied to a multi-GPU or multi-core GPU, wherein the multi-GPU or multiple GPU cores are or include the multi-tile graphics processor architecture described herein. For example, a multi-tile GPU may be configured to be provided to a host desktop as a single graphics processor or one or more graphics processor devices depending on the configuration of the system graphics interface.

[0153] As illustrated in block (1902), in one embodiment, the method (1900) includes performing an operation to generate a command set of a workload to be executed by a graphics processor having a plurality of graphics processing engine tiles. In block (1904), the operation partitions the command set into a first partition and a second partition. In block (1906), the operation may assign a first partition identifier to the first partition and a second partition identifier to the second partition. In block (1908), the operation additionally associates the first partition identifier with a first hardware context associated with the first graphics processing engine tile among the plurality of graphics processing engine tiles, and associates the second partition identifier with a second hardware context associated with the second graphics processing engine tile among the plurality of graphics processing engine tiles. In block (1910), the operation submits the first partition and the second partition to the first graphics processing engine tile and the second graphics processing engine tile, respectively. In block (1912), the operation additionally executes the first partition through the first graphics processing engine tile and executes the second partition through the second graphics processing engine tile.

[0154] Partitioning of the command set can be performed as illustrated in FIGS. 17 and 18. Commands of each partition can be loaded into a batch buffer, and the same batch buffer can be submitted to each tile of the graphics processing engine. The hardware context for each tile can configure the batch buffer start position corresponding to the start of the command to be processed by the tile. In one embodiment, the partition identifier can also be associated with the partition of the command. The tile can then be configured to conditionally execute commands in the batch buffer for the associated partition while bypassing commands of other partitions.

[0155] FIG. 20 illustrates a flowchart of a method (2000) for executing a multi-tile workload according to one embodiment. The method (2000) may be executed by a multi-tile, multi-core, or multi-GPU graphics processing system as described herein. Where reference is made to a graphics processing engine tile, a similar technique may be applied to a multi-GPU or multi-core GPU, wherein the multi-GPU or multi-GPU core includes the aforementioned multi-tile graphics processor architecture.

[0156] As illustrated in block (2002), the method (2000) includes a graphics processor receiving a command set. The command set represents a workload having a first partition and a second partition, and the graphics processor includes a plurality of graphics processing engine tiles. In block (2004), the graphics processor may associate a first graphics processing engine tile with a first hardware context and a second graphics processing engine tile with a second hardware context. In block (2006), the graphics processor may read a first partition identifier from the first hardware context by the first graphics processing engine tile and read a second partition identifier from the second hardware context by the second graphics processing engine tile. The first partition identifier is associated with the first partition, and the second partition identifier is associated with the second partition. In block (2008), the graphics processor may configure the first graphics processing engine tile and the second graphics processing engine tile to conditionally execute a command having a partition identifier associated with each tile. Then, in block (2010), the graphics processor can execute the commands of the first partition while bypassing the commands of the second partition in the first graphics processing engine tile, and execute the commands of the second partition while bypassing the commands of the first partition in the second graphics processing engine tile.

[0157] FIG. 21 illustrates a flowchart of a method (2100) for migrating a workload between tiles according to one embodiment. The method (2100) may be executed by a multi-tile, multi-core, or multi-GPU graphics processing system as described herein. Where reference is made to a graphics processing engine tile, a similar technique may be applied to a multi-GPU or multi-core GPU, wherein the multi-GPU or multi-GPU core includes a multi-tile graphics processor architecture as described above.

[0158] The method (2100) illustrated in block (2102) includes a graphics processor receiving a command set. The command set represents a workload having a first partition and a second partition. In block (2104), the graphics processor may configure a first graphics processing engine tile to execute the first partition. In block (2106), the graphics processor may configure a second graphics processing engine tile to execute the second partition. In block (2108), before the execution of the first partition is completed, the graphics processor may receive a trigger to migrate the execution of the first partition from the first graphics processing engine tile to a third graphics processing engine tile. Then, the graphics processor may migrate the first partition to the third tile and, as illustrated in block (2110), execute at least a portion of the first partition through the third graphics processing engine tile. In one embodiment, a trigger for migrating the execution of the first partition to the third tile includes an atomic update of the partition identifier (WPARID) of the workload on the first and third partitions to move the identifier of the first partition from the first tile to the third tile. Then, the third tile may conditionally execute a batch buffer command associated with the WPARID of the first partition, and the first tile will no longer execute a batch buffer command associated with the WPARID of the first partition.

[0159] FIG. 22 is a block diagram of a computing device (2200) including a graphics processor (2204) according to one embodiment. The computing device (2200) may be a computing device described herein, such as the data processing system (100) of FIG. 1. The computing device (2200) may also be a communication device, such as a set-top box (e.g., an internet-based cable television set-top box, etc.) or a GPS (global positioning system) based device, and may be included therein. The computing device (2200) may also be a mobile computing device, such as a mobile phone, smartphone, PDA (personal digital assistants), tablet computer, laptop computer, e-reader, smart television, television platform, wearable device (e.g., glasses, watch, bracelet, smart card, jewelry, clothing item, etc.), media player, etc., and may be included therein. For example, in one embodiment, the computing device (2200) includes a mobile computing device that utilizes an integrated circuit ("IC") such as a system-on-chip ("SoC" or "SOC") that integrates various hardware and / or software components of the computing device (2200) onto a single chip.

[0160] The computing device (2200) includes a graphics processor (2204). The graphics processor (2204) represents any graphics processor described herein. The graphics processor includes one or more graphics engine(s), a graphics processor core, and other graphics execution resources described herein. These graphics execution resources may be provided in a form including, but not limited to, an execution unit, a shader engine, a fragment processor, a vertex processor, a streaming multiprocessor, a graphics processor cluster, or any set of computing resources suitable for processing graphics and image resources.

[0161] In one embodiment, the graphics processor (2204) may be a single cache or may be divided into multiple segments of cache memory, including but not limited to any number of L1, L2, L3, or L4 caches, rendering cache, depth cache, sampler cache, and / or shader unit cache. The graphics processor (2204) may also include multiple GPGPU tiles (2204), each comprising multiple graphics processor engines and execution units, as illustrated in FIG. 16c, for example. The GPGPU tiles (2204) may be similar or identical in architecture. Each GPGPU tile may include a set of virtualized graphics processor engines. Using virtualized engines allows for the configuration of a command stream that is agnostic to the physical GPGPU tile executing the command. Additionally, commands can be dynamically migrated within a physical tile or between virtual engines on a physical tile. In various embodiments, the GPGPU engine tile (2240) may include a barrier / sync unit (2242) and a conditional execution unit (2244). The barrier / sync unit (2242) may be used to synchronize the GPGPU engine tile (2240) upon completion of a workload partition. The conditional execution unit (2442) may be used to enable conditional and / or scheduled execution of a batch buffer command based on a match between a workload partition identifier associated with a command and a workload partition identifier associated with the GPGPU engine tile.

[0162] As illustrated, in one embodiment, in addition to the graphics processor (2204), the computing device (2200) may further include any number and type of hardware components and / or software components, including but not limited to an application processor (2206), memory (2208), and an input / output (I / O) source (2210). The application processor (2206) may interact with a hardware graphics pipeline, illustrated with reference to FIG. 3, to share graphics pipeline functions. Processed data is stored in a buffer of the hardware graphics pipeline, and state information is stored in memory (2208). The resulting data may be transmitted to a display controller for output through a display device, such as the display device (323) of FIG. 3. The display device may have various types, such as a cathode ray tube (CRT), a thin-film transistor (TFT), a liquid crystal display (LCD), an organic light-emitting diode (OLED) array, etc., and may be configured to display information to a user through a graphical user interface.

[0163] The application processor (2206) may include one or more processors such as the processor(s) (102) of FIG. 1 and may be a central processing unit (CPU) used at least partially to run an operating system (OS) (2202) for a computing device (2200). The OS (2202) may function as an interface between the hardware and / or physical resources of the computing device (2200) and one or more users. The OS (2202) may include graphics driver logic (2222), such as a user mode driver (UMD 2223) and a kernel mode driver (KMD 2224), which may be a variation of the user mode graphics driver (1026) and / or kernel mode graphics driver (1029) of FIG. 10. The UMD (2223) can interface with an application running on a computing device and can enable such application to submit a workload distributed to a number of GPGPU engine tiles (2224) of the graphics processor (2204).

[0164] In some embodiments, the graphics processor (2204) may exist as part of the application processor (2206) (e.g., part of a physical CPU package), in which case at least part of the memory (2208) may be shared by the application processor (2206) and the graphics processor (2204), but at least part of the memory (2208) may be exclusively owned by the graphics processor (2204) or the graphics processor (2204) may have a separate memory storage. The memory (2208) may include a pre-allocated area of ​​a buffer (e.g., a frame buffer), but a person skilled in the art should understand that embodiments are not limited thereto and any memory accessible to the underlying graphics pipeline may be used. The memory (2208) may include various forms of random access memory (RAM) (e.g., SDRAM, SRAM, etc.) including an application that uses the graphics processor (2204) to render a desktop or 3D graphics scene. For memory pipeline processing, a memory controller may be used to access data in memory (2208) and transfer data to a graphics processor (2204). Memory (2208) may be made available to other components within the computing device (2200). For example, any data (e.g., input graphics data) received from various I / O sources (2210) of the computing device (2200) may be temporarily queued in memory (2208) before being processed by one or more processor(s) (e.g., application processor (2206)) during the implementation of a software program or application. Similarly, data that a software program determines should be transmitted from the computing device (2200) to an external entity or stored in an internal storage element through one of the computing system interfaces is often temporarily queued in memory (2208) before being transmitted or stored.

[0165] The I / O source may include devices such as a touch screen, touch panel, touchpad, virtual or standard keyboard, virtual or standard mouse, port, connector, network device, etc. Additionally, the I / O source (2210) may include one or more I / O devices implemented for transmitting data to / from the computing device (2200) (e.g., networking adapter) or for large non-volatile storage within the computing device (2200) (e.g., hard disk drive). User input devices including alphanumeric keys and other keys may be used to transmit information and command selections to the graphics processor (2204). Other types of user input devices, such as cursor controls like a mouse, trackball, touch screen, touchpad, or cursor direction keys, transmit directional information and command selections to the GPU and control cursor movement on the display device. Camera and microphone arrays of the computing device (2200) may be used to observe gestures, record audio and video, and receive and transmit visual and audio commands.

[0166] An I / O source (2210) configured as a network interface may provide access to a network such as a LAN, WAN (wide area network), MAN (metropolitan area network), PAN (personal area network), Bluetooth, cloud network, cellular or mobile network (e.g., third generation (3G), fourth generation (4G)), intranet, the internet, etc. The network interface(s) may include, for example, a wireless network having one or more antennas (e). The network interface(s) may include a wired network interface for communicating with a remote device through a network cable that may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

[0167] Network interface(s) may provide access to a LAN according to, for example, the IEEE 802.11 standard, and wireless network interfaces may provide access to a PAN according to, for example, the Bluetooth standard. Other wireless network interfaces and / or protocols, including earlier and later versions of standards, may also be supported. In addition to or instead of communication via wireless LAN standards, network interface(s) may provide wireless communication using, for example, the Time Division, Multiple Access (TDMA) protocol, the Global Systems for Mobile Communications (GSM) protocol, the Code Division, Multiple Access (CDMA) protocol, and / or other types of wireless communication protocols.

[0168] It should be understood that a system equipped with fewer or more than the examples described above may be desirable for a particular implementation. Accordingly, the configuration of the computing device (2200) may vary from implementation to implementation depending on various factors such as price constraints, performance requirements, technological improvements, or other circumstances. Examples (but not limitations) include mobile devices, PDAs, mobile computing devices, smartphones, mobile phones, handsets, one-way pagers, two-way pagers, messaging devices, computers, personal computers (PCs), desktop computers, laptop computers, notebook computers, handheld computers, tablet computers, servers, server arrays or server farms, web servers, network servers, internet servers, workstations, minicomputers, mainframe computers, supercomputers, network devices, web devices, distributed computing systems, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, televisions, digital televisions, set-top boxes, wireless access points, base stations, subscriber stations, mobile subscriber centers, wireless network controllers, routers, hubs, gateways, bridges, switches, machines, or combinations thereof.

[0169] The embodiment may be implemented using one or more microchips or integrated circuits interconnected using a parent-board, hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, and any combination of an application-specific integrated circuit (ASIC) and / or a Field Programmable Gate Array (FPGA). The term "logic" may include, by example, software or hardware and / or a combination of software and hardware.

[0170] An embodiment may be provided as a computer program product comprising one or more machine-readable media storing machine-executable instructions that, when executed by one or more machines such as, for example, a computer, a computer network, or other electronic device, enable one or more machines to perform operations according to the embodiment described herein. The machine-readable media may include, but are not limited to, floppy diskettes, optical discs, CD-ROMs (Compact Disc-Read Only Memories) and optical-magnetic discs, ROM, RAM, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetic or optical cards, flash memory, or other types of media / machine-readable media suitable for storing machine-executable instructions.

[0171] Additionally, the embodiment may be downloaded as a computer program product, wherein the program may be transmitted from a remote computer (e.g., server) to a requesting computer (e.g., client) by one or more data signals modulated and / or implemented by a carrier wave or other propagation medium via a communication link (e.g., modem and / or network connection).

[0172] The following sections and / or examples relate to specific embodiments or examples thereof. Specific details in the embodiments may be used in any of one or more embodiments. Various features of different embodiments or examples may be combined in various ways with some included features, and other features are excluded to suit various different applications. Examples may include objects of the invention such as a method, means for performing a step (act) of the method, at least one machine-readable medium comprising instructions that cause a machine to perform a step of the method when performed by a machine, or an apparatus or system according to the embodiments and examples described herein. Various components may be means for performing the described operation or function.

[0173] One embodiment provides a graphics processor comprising a first graphics processing engine tile, a second graphics processing engine tile, and an interface between a host system and a graphics processor. The interface may be configured to receive a command set for a workload having a first partition and a second partition, submit the command set to the first graphics processing engine tile, and submit the command set to the second graphics processing engine tile. The first graphics processing engine tile may read a first partition identifier associated with the first partition from a first hardware context. Then, the first tile may conditionally execute a command of the first partition while bypassing a command of the second partition. The second graphics processing engine tile may read a second partition identifier associated with the second partition from a second hardware context. Then, the second tile may conditionally execute a command of the second partition while bypassing a command of the first partition.

[0174] One embodiment provides a non-transient machine-readable medium storing instructions that cause one or more processors to perform an operation when executed by one or more processors, wherein the operation includes generating a command set of a workload to be executed by a graphics processor having a plurality of graphics processing engine tiles, partitioning the command set into a first partition and a second partition, associating a first partition identifier for identifying the first partition with a first render context, associating a second partition identifier for identifying the second partition with a second render context, submitting the first partition and the second partition to each of the first graphics processing engine tile and the second graphics processing engine tile among the plurality of graphics processing engine tiles, executing the first partition through the first graphics processing engine tile, and executing the second partition through the second graphics processing engine tile.

[0175] One embodiment provides a data processing system comprising a graphics processor including a first graphics processing engine tile and a second graphics processing engine tile. The graphics processor receives a command set for a workload having a first partition and a second partition, configures the first graphics processing engine tile to execute the first partition, and configures the second graphics processing engine tile to execute the second partition simultaneously with the execution of the first partition. In one embodiment, before the execution of the first partition is completed, the graphics processor receives a trigger to migrate the execution of the first partition from the first graphics processing engine tile to a third graphics processing engine tile and can execute at least a portion of the first partition through the third graphics processing engine tile. Migrating the execution of the first partition includes atomically reassigning the partition identifier of the first partition from the first graphics processing engine tile to the third graphics processing engine tile. In one embodiment, the first partition is migrated before the execution of the first partition begins.

[0176] One embodiment provides a method, the method comprising the steps of: receiving a command set from a graphics processor—wherein the command set represents a workload having a first partition and a second partition, and the graphics processor comprises a plurality of graphics processing engine tiles—reading a first partition identifier associated with the first partition from a first hardware context by means of a first graphics processing engine tile; reading a second partition identifier associated with the second partition from a second hardware by means of a second graphics processing engine tile; configuring the first graphics processing engine tile and the second graphics processing engine tile to conditionally execute a command having a partition identifier associated with each tile; executing a command of the first partition on the first graphics processing engine tile while bypassing a command of the second partition; and executing a command of the second partition on the second graphics processing engine tile while bypassing a command of the first partition. In one embodiment, the method further comprises the steps of associating the first graphics processing engine tile with a first hardware context and associating the second graphics processing engine tile with a second hardware context.

[0177] Those skilled in the art will understand from the foregoing description that the broad scope of the embodiments may be implemented in various forms. Accordingly, although the embodiments have been described in relation to specific examples, the true scope of the embodiments should not be limited thereto, as it will be clearly understood by those skilled in the art that other modifications are possible based on a study of the drawings, the specification, and the following claims.

Claims

Claim 1 A graphics processor comprising a first graphics processing engine tile, a second graphics processing engine tile, and an interface between a host system and the graphics processor—the interface receiving a command set for a workload having a first partition and a second partition, submitting the command set to the first graphics processing engine tile, and submitting the command set to the second graphics processing engine tile—the first graphics processing engine tile reads a first partition identifier associated with the first partition from a first hardware context and conditionally executes a command of the first partition while bypassing a command of the second partition, and the second graphics processing engine tile reads a second partition identifier associated with the second partition from a second hardware context and conditionally executes a command of the second partition while bypassing a command of the first partition. Claim 2 In claim 1, the interface to the host system further receives a command for associating the first graphics processing engine tile with the first hardware context, a graphics processor. Claim 3 In paragraph 2, the interface to the host system further receives a command to configure the first hardware context based on the first logical render context, a graphics processor. Claim 4 In paragraph 3, the interface to the host system further receives a command for associating the second graphics processing engine tile with the second hardware context, a graphics processor. Claim 5 In paragraph 4, the interface to the host system further receives a command to configure the second hardware context based on the second logic render context, a graphics processor. Claim 6 In paragraph 5, the interface is a graphics processor that receives a set of commands for the workload through a memory buffer containing commands to be executed for the workload. Claim 7 A graphics processor according to claim 6, wherein the first hardware context includes a first offset in the memory buffer associated with the start of the first partition, and the second hardware context includes a second offset in the memory buffer associated with the start of the second partition, and each of the first hardware context and the second hardware context includes a step value associated with a plurality of partitions of the workload. Claim 8 In claim 7, the graphics processor, wherein the first graphics processing engine tile starts the execution of a command for the first partition with a command stored at the first offset in the memory buffer. Claim 9 In claim 7, the graphics processor, wherein the second graphics processing engine tile starts the execution of a command for the second partition with a command stored at the second offset in the memory buffer. Claim 10 A graphics processor according to claim 7, wherein when the execution of the first partition and the second partition is completed, the first graphics processing engine tile is synchronized with the second graphics processing engine tile. Claim 11 A non-transient machine-readable medium storing instructions that cause a graphics processor to perform an operation, wherein the operation comprises receiving a command set for a workload having a first partition and a second partition; submitting the command set to a first graphics processing engine tile of the graphics processor; submitting the command set to a second graphics processing engine tile of the graphics processor; at the first graphics processing engine tile, reading a first partition identifier associated with the first partition from a first hardware context and conditionally executing a command of the first partition while bypassing a command of the second partition; and at the second graphics processing engine tile, reading a second partition identifier associated with the second partition from a second hardware context and conditionally executing a command of the second partition while bypassing a command of the first partition. Claim 12 A non-transient machine-readable medium, wherein, in paragraph 11, the operation further comprises receiving a first command for associating the first hardware context with the first graphics processing engine tile and receiving a second command for associating the second hardware context with the second graphics processing engine tile. Claim 13 A non-transient machine-readable medium, wherein the operation further comprises receiving a third command to configure the first hardware context based on the first logic render context and receiving a fourth command to configure the second hardware context based on the second logic render context. Claim 14 A non-transient machine-readable medium, wherein the operation further comprises receiving a set of commands for the workload through a memory buffer containing commands to be executed for the workload. Claim 15 A non-transient machine-readable medium according to claim 14, wherein the first hardware context includes a first offset in the memory buffer associated with the start of the first partition, and the second hardware context includes a second offset in the memory buffer associated with the start of the associated second partition, and each of the first hardware context and the second hardware context includes a step value associated with a plurality of partitions of the workload. Claim 16 A data processing system comprising a graphics processor—the graphics processor comprises a first graphics processing engine tile and a second graphics processing engine tile, and the graphics processor is configured to be provided as a single device to a host processor of the data processing system—and the graphics processor comprises a hardware circuit that receives a command set for a workload having a first partition and a second partition, submits the command set to the first graphics processing engine tile of the graphics processor, submits the command set to the second graphics processing engine tile of the graphics processor, and at the first graphics processing engine tile, reads a first partition identifier associated with the first partition from a first hardware context and conditionally executes a command of the first partition while bypassing a command of the second partition, and at the second graphics processing engine tile, reads a second partition identifier associated with the second partition from a second hardware context and conditionally executes a command of the second partition while bypassing a command of the first partition. Claim 17 In paragraph 16, the graphics processor also receives a first command for associating the first hardware context with the first graphics processing engine tile and a second command for associating the second hardware context with the second graphics processing engine tile, a data processing system. Claim 18 In claim 17, the graphics processor also receives a third command to configure the first hardware context based on the first logic render context, and a fourth command to configure the second hardware context based on the second logic render context, a data processing system. Claim 19 A data processing system according to claim 18, wherein the graphics processor also receives a set of commands for the workload through a memory buffer containing commands to be executed for the workload, the first hardware context includes a first offset in the memory buffer associated with the start of the first partition, the second hardware context includes a second offset in the memory buffer associated with the start of the second partition, the first graphics processing engine tile starts the execution of commands for the first partition with a command stored in the first offset in the memory buffer, and the second graphics processing engine tile starts the execution of commands for the second partition with a command stored in the second offset in the memory buffer. Claim 20 A data processing system according to claim 19, wherein when the execution of the first partition and the second partition is completed, the first graphics processing engine tile is synchronized with the second graphics processing engine tile.

Images