Tessellation redistribution reduces latency within the processor.

Abstract

To perform tessellation redistribution for reducing latencies in processors.SOLUTION: A processing system 100 includes a processor to provide a parallel interconnected geometry fixed-function unit with separate front ends and back ends. The front ends perform patch culling and transmission, and the back ends perform patch reception from the front ends and tessellation. A tessellation redistribution central engine to redistribute patches among the back ends using a redistribution bus is provided, which receives, from the front ends in parallel, patches marked for distribution. The tessellation redistribution engine processes the patches in order. In response to receiving a synchronization barrier packet from one of the front ends, the tessellation redistribution central engine broadcasts the synchronization barrier packet to the back ends for causing one of the back ends to process tessellation work locally.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This specification generally relates to data processing, and more particularly to tessellation redistribution for reducing latency within a processor.

Background Art

[0002] Current parallel graphic data processing includes systems and methods developed to perform specific operations on graphic data such as, for example, linear interpolation, tessellation, rasterization, texture mapping, depth testing, and the like. Traditionally, graphic processors use fixed-function computing units to process graphic data, but recently, parts of graphic processing have become programmable, and such processors are capable of supporting various operations for processing vertex and fragment data.

[0003] To further improve performance, graphic processors typically implement processing techniques such as pipelines that attempt to process as much graphic data in parallel as possible through different parts of the graphic pipeline. Parallel graphic processors having single instruction, multiple data (SIMD) or single instruction, multiple thread (SIMT) architectures are designed to maximize the amount of parallel processing within the graphic pipeline. In a SIMD architecture, a computer having multiple processing elements attempts to execute the same operation simultaneously on multiple data points. In a SIMT architecture, a group of parallel threads attempts to execute program instructions in synchronization and together as frequently as possible to improve processing efficiency.

[0004] Providing competitive geometry processing performance in graphics processing units (GPUs) typically involves multiple, parallel, and simultaneous geometry processing fixed-function pipelines (GPPs). These GPPs (sometimes also called SMMs, geometry and configuration fixed-function pipelines, or pre-tessellation and post-tessellation pipelines) include a mixture of programmable shaders and fixed-function stages in the OpenGL rendering pipeline (RP). In computer graphics, tessellation is used to manage polygonal datasets (also called vertex sets) representing objects in a scene and to divide them into a suitable structure for rendering. The advantage of tessellation over real-time graphics is that details can be dynamically added and subtracted from 3D polygonal meshes and their silhouette edges based on control parameters (e.g., camera distance). Tessellation involves subdividing patch primitives (also called "objects") and calculating the vertex values ​​of their vertices. The tessellation control shader may determine the amount of tessellation to be performed by specifying a tessellation coefficient. The number of vertices per patch may be defined at the application level. Patch objects may be triangles or quadrilaterals (squares).

[0005] Tessellation involves subdividing the parameter domain associated with an input patch primitive into triangular primitives and calculating the vertices at the tessellated domain points (which coincide with the angles of those triangular primitives). The input patch primitive may be associated with a triangular or quadrilateral parameter domain. A tessellation control shader may determine how finely the domain is subdivided into triangles by specifying a set of tessellation coefficients for each patch. A tessellation evaluation shader may then calculate the vertex values ​​using the set of input control points associated with the input patch primitive and the domain parameters at the tessellated domain points. The number of input control points associated with the patch primitive may be defined at the application level.

[0006] The challenge in parallel rendering graphics architectures is how to utilize parallel GPP and rendering and rasterization pipelines (RPs) while maintaining a strictly sequential 3D pipeline rendering model. A key challenge is the arbitrary mapping of application-supplied "object-space" geometry primitives to the rendered image during the rendering process. This is where the "Sort-Middle" architecture is more effectively used by the industry. In this approach, the GPU first performs complete geometry processing on an arbitrarily distributed subset ("batch") of object-space primitives using parallel GPP. The resulting screen-space primitives are then correctly rendered (i.e., sorted in time) and distributed to the RPs by a rasterization crossbar based on the screen-space region owned by each PR.

[0007] Increasing the number (N) of GPPs in the design typically involves using deeper buffers at the output of each GPP to provide sufficient GPP output buffers while the GPPs "wait their turn" to output to the rasterized crossbar. Here, the size of the GPP output buffer may be determined to match the average time it takes for the other (N-1) GPPs to discharge their batches to the crossbar. If sufficient buffers are not provided, the "waiting their turn" GPPs will quickly stall because they will not discharge, and when it is their turn they will output to the crossbar at the GPP processing rate (which is slower than the crossbar rate), so the overall geometry throughput tends to drop to the throughput of a single GPP. [Brief explanation of the drawing]

[0008] To allow for a detailed understanding of the above-described features of this embodiment, a more specific description of the embodiments briefly summarized above can be obtained by referring to the embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings merely illustrate typical embodiments and should therefore not be considered as limiting the scope of this application.

[0009] [Figure 1] This is a block diagram of the processing system.

[0010] [Figure 2A] This shows a computing system and a graphics processor. [Figure 2B] This shows a computing system and a graphics processor. [Figure 2C] This shows a computing system and a graphics processor. [Figure 2D] This shows a computing system and a graphics processor.

[0011] [Figure 3A] This shows a block diagram of the additional graphics processor and compute accelerator architecture. [Figure 3B] shows a block diagram of an additional graphics processor and a compute accelerator architecture. [Figure 3C] shows a block diagram of an additional graphics processor and a compute accelerator architecture.

[0012] [Figure 4] It is a block diagram of the graphics processing engine of a graphics processor.

[0013] [Figure 5A] shows thread execution logic including an array of processing elements utilized within a graphics processor core. [Figure 5B] shows thread execution logic including an array of processing elements utilized within a graphics processor core.

[0014] [Figure 6] shows additional execution units.

[0015] [Figure 7] It is a block diagram showing a graphics processor instruction format.

[0016] [Figure 8] It is a block diagram of an additional graphics processor architecture.

[0017] [Figure 9A] shows a graphics processor command format and command sequence. [Figure 9B] shows a graphics processor command format and command sequence.

[0018] [Figure 10] shows an exemplary graphics software architecture of a data processing system.

[0019] [Figure 11A] It is a block diagram showing an IP core development system.

[0020] [Figure 11B] It shows a cross-sectional side view of an integrated circuit package assembly.

[0021] [Figure 11C] It shows a package assembly including a plurality of units of a hardware logic chiplet connected to a substrate (e.g., a base die).

[0022] [Figure 11D] It shows a package assembly including interchangeable chiplets.

[0023] [Figure 12] It is a block diagram showing an exemplary system-on-chip integrated circuit.

[0024] [Figure 13A] It is a block diagram showing an exemplary graphics processor for use within a SoC. [Figure 13B] It is a block diagram showing an exemplary graphics processor for use within a SoC.

[0025] [Figure 14] It is a block diagram showing an integrated circuit graphics processor having a fixed-function tessellation stage for tessellation redistribution that reduces latency, according to an embodiment.

[0026] [Figure 15] It is a block diagram showing a tessellation redistribution system having a tessellation engine for tessellation redistribution that reduces latency, according to an embodiment.

[0027] [Figure 16] It is a flowchart showing an embodiment of a method for tessellation redistribution that reduces latency within a processor.

[0028] [Figure 17] This flowchart illustrates an embodiment of a method for a tessellation engine front-end (TEFE) that performs tessellation redistribution to reduce latency within the processor.

[0029] [Figure 18] This flowchart illustrates an embodiment of a method for a tessellation engine backend (TEBE) that performs tessellation redistribution to reduce latency within the processor. [Modes for carrying out the invention]

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

[0031] In the following description, many specific details are described in order to provide a more complete understanding. However, it will be obvious to those skilled in the art that the embodiments described in this specification may be carried out without having one or more of these specific details. In other examples, well-known features are not described in order to avoid obscuring the details of the embodiments of the invention.

[0032] <System Overview> Figure 1 is a block diagram of a processing system 100 according to an embodiment. System 100 may be used in a single-processor desktop system, a multi-processor workstation system, or a server system having multiple processors 102 or processor cores 107. In one embodiment, system 100 is a processing platform embedded in a system-on-a-chip (SoC) integrated circuit for use in mobile, handheld, or embedded devices, such as within the Internet of Things (IoT) with wired or wireless connectivity to a local or wide area network.

[0033] In one embodiment, System 100 includes, or may be coupled to, a game console including a server-based game platform, a game and media console, a mobile game console, a handheld game console, or an online game console. In some embodiments, System 100 is part of a mobile internet-connected device such as a mobile phone, a smartphone, a tablet computing device, or a laptop with low internal storage capacity. Processing System 100 also includes, or may be coupled to, a wearable device such as a smartwatch wearable device, smart glasses, or clothing, other augmented reality (AR) devices, or other virtual reality (VR) devices, which are enhanced by augmented reality (AR) or virtual reality (VR) capabilities that provide visual, auditory, or haptic output to augment real-world visual, auditory, or haptic experiences, or to provide text, voice, graphics, video, holographic images or videos, or haptic feedback. In some embodiments, Processing System 100 includes or is part of a television or set-top box. In one embodiment, the system 100 includes, and may be coupled to or integrated into, an autonomous vehicle such as a bus, tractor, trailer, automobile, motor or electric bicycle, airplane or glider (or any combination thereof). The autonomous vehicle may use the system 100 to process the sensed environment around the vehicle.

[0034] In some embodiments, one or more processors 102 each include one or more processor cores 107 that, when executed, process instructions that perform actions for the system or user software. In some embodiments, at least one of the one or more processor cores 107 is configured to process a specific instruction set 109. In some embodiments, the instruction set 109 may implement computation using CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), or VLIW (Very Long Instruction Word). One or more processor cores 107 may process different instruction sets 109 that may include instructions to facilitate the emulation of other instruction sets. The processor cores 107 may also include other processing units, such as a DSP (Digital Signal Processor).

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

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

[0037] The memory device 120 may be a DRAM (dynamic random-access memory) device, an SRMA (static random-access memory) device, a flash memory device, a phase-shift memory device, or any other memory device having the appropriate performance to function as process memory. In one embodiment, the memory device 120 may operate as the system memory of the system 100 and store data 122 and memory 121 for use when one or more processors 102 execute applications or processes. The memory control unit 116 also couples with an optional external graphics processor 118 that can communicate with one or more graphics processors 108 in the processor 102 to perform graphics and media operations. In some embodiments, graphics, media, and / or computation operations may be supported by an accelerator 112, which is a coprocessor that can be configured to perform a dedicated set of graphics, media, or computation operations. For example, in one embodiment, the accelerator 112 is a matrix multiplication accelerator used to optimize machine learning or computation operations. In one embodiment, accelerator 112 is a ray tracing accelerator that can be used in conjunction with graphics processor 108 to perform ray tracing operations. In one embodiment, external accelerator 119 may be used instead of or in conjunction with accelerator 112n.

[0038] In some embodiments, the display device 111 can be connected to the processor 102. The display device 111 may be one or more internal display devices, such as in a mobile electronic device or laptop device or in 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 used in a virtual reality (VR) or augmented reality (AR) application.

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

[0040] System 100 is shown exemplarily and is not limited to other types of data processing systems configured in different ways. For example, instances of the memory control unit 116 and the platform control hub 130 may be integrated into a separate external graphics processor, such as an external graphics processor 118. In one embodiment, the platform control hub 130 and / or the memory control unit 116 may be external to one or more processors 102. For example, System 100 may include an external memory control unit 116 and a platform control hub 130, which may be configured as a memory control hub and peripheral control unit within a system chipset that communicates with the processor 102.

[0041] For example, a circuit board ("sled") on which components such as the CPU, memory, and other components are arranged is designed to improve thermal performance. In some examples, processing components such as the processor are placed on the upper side of the sled, and nearby memory such as DIMMs are placed on the lower side of the sled. As a result of the improved airflow provided by this design, the components operate at higher frequencies and higher power levels than in a standard system, thereby improving performance. Furthermore, the sled is configured to blindly mate with power and data communication cables in the rack, thereby improving their ability to be quickly removed, upgraded, reinstalled, and / or replaced. Similarly, individual components arranged on the sled, such as the processor, accelerator, memory, and data storage drives, are configured to be easily upgraded by being further apart from each other. In the embodiments for illustrative purposes, the components also include hardware attestation capabilities to verify their authenticity.

[0042] A data center can utilize a single network architecture ("fabric") that supports multiple other network architectures, including Ethernet and Omni-Path. Threads can be coupled to switches via optical fiber, which provides higher bandwidth and lower latency than standard twisted-pair cables (e.g., Category 5, Category 5e, Category 6, etc.). The high-bandwidth, low-latency interconnection and network architecture allows a data center to pool resources such as memory, accelerators (e.g., GPUs, graphics accelerators, FPGAs, ASICs, neural networks, and / or artificial intelligence accelerators), and physically non-aggregated data storage drives during use, and provide them to computing resources (e.g., processors), enabling computing resources to access the pooled resources as if they were locally located.

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

[0044] Figures 2A–2D show computing systems and graphics processors provided by embodiments described herein. Elements in Figures 2A–2D having the same reference numerals (or names) as elements in any other figures of this specification may, but are not limited to, operate or function in any manner similar to those described elsewhere in this specification.

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

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

[0047] In some embodiments, one or more of the processor cores 202A to 202N include support for simultaneous multithreading. In such embodiments, the system agent core 210 includes components for coordinating and operating the cores 202A to 202N during multithreading. The system agent core 210 may further include a power control unit (PCU) which includes logic and components for coordinating the power states of the processor cores 202A to 202N and the graphics processor 208.

[0048] In some embodiments, the processor 200 further includes a graphics processor 208 for performing graphics processing operations. In some embodiments, the graphics processor 208 is coupled to a system agent core 210 which includes a set of shared cache units 206 and one or more integrated memory control units 214. In some embodiments, the system agent core 210 also includes a display control unit 211 for driving graphics processor outputs to one or more coupled displays. In some embodiments, the display control unit 211 may also include a separate module coupled to the graphics processor via at least one interconnect, or it may be integrated within the graphics processor 208.

[0049] In some embodiments, a ring-based interconnection unit 212 is used to connect the internal components of the processor 200. However, alternative interconnection units, such as point-to-point interconnection, switching interconnection, or other techniques including conventionally known techniques, may be used. In some embodiments, the graphics processor 208 is connected to the ring interconnection 212 via an I / O link 213.

[0050] An example I / O link 213 represents at least one of several types of I / O interconnects, including package I / O interconnects that facilitate communication between various processor components and high-performance internal memory modules 218, such as eDRAM modules. In some embodiments, each of the processor cores 202A-202N and the graphics processor 208 can use the internal memory module 218 as a shared Last Level Cache.

[0051] In some embodiments, the processor cores 202A to 202N are homogeneous cores that execute the same instruction set architecture. In other embodiments, the processor cores 202A to 202N are heterogeneous in terms of instruction set architecture, with one or more of the processor cores 202A to 202N executing 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 to 202N are heterogeneous in terms of microarchitecture, with one or more cores having relatively high power consumption coupling and one or more power cores having lower power consumption. In one embodiment, the processor cores 202A to 202N are heterogeneous in terms of computing power. Furthermore, the processor 200 can be implemented on one or more chips, or as an SoC integrated circuit having the illustrated components in addition to other components.

[0052] Figure 2B is a block diagram of the hardware logic of a graphics processor core 219 according to several embodiments described in this specification. Elements in Figure 2B having the same reference numerals (or names) as elements in any other figures of this specification may operate or function in any way similar to those described elsewhere in this specification, but are not limited to such operations. The graphics processor core 219 is sometimes referred to as a core slice and may be one or more graphics cores in a modular graphics processor. The graphics processor core 219 is an example of a single graphics core slice, and the graphics processor described in this specification may include multiple graphics core slices based on target power and performance envelopes. Each graphics processor core 219 may include a fixed-function block 230 coupled with a plurality of subcores 221A to 221F, also called sub-slices, which include modular blocks of general-purpose and fixed-function logic.

[0053] In some embodiments, the fixed-function block 230 includes a geometry / fixed-function pipeline 231 that can be shared by all subcores within the graphics processor core 219, for example in a low-performance and / or low-power graphics processor implementation. In various embodiments, the geometry / fixed-function pipeline 231 includes a 3D fixed-function pipeline (e.g., a 3D pipeline 312 as shown in Figures 3 and 4 below), a video front-end unit, a thread spawner and thread dispatcher, and an integrated return buffer manager that manages an integrated return buffer (e.g., an integrated return buffer 418 as shown in Figure 4 below).

[0054] In one embodiment, the fixed-function block 230 also includes a graphics SoC interface 232, a graphics microcontroller 233, and a media pipeline 234. The graphics SoC interface 232 provides an interface between the graphics processor core 219 and other processor cores in the system-on-chip integrated circuit. The graphics microcontroller 233 is a programmable subprocessor configurable to manage various functions of the graphics processor core 219, including thread dispatching, scheduling, and pre-emption. The media pipeline 234 (e.g., media pipeline 316 in FIG3 and FIG4) includes logic to facilitate decoding, encoding, pre-processing, and / or post-processing of multimedia data, including image and video data. The media pipeline 234 performs media operations in response to requests to computation or sampling logic in subcores 221A-221F.

[0055] In one embodiment, the SoC interface 232 enables the graphics processor core 219 to communicate with a general-purpose application processor core (e.g., CPU) and / or other components within the SoC, including memory hierarchy elements such as shared last-level cache memory, system RAM, and / or built-in on-chip or on-package DRAM. The SoC interface 232 also enables communication with fixed-function devices within the SoC, such as a camera image pipeline, and allows the use and / or implementation of a global memory atomic that may be shared between the graphics processor core 219 and the CPU within the SoC. The SoC interface 232 can also implement power management controls for the graphics processor core 219 and enables facilitating between the clock domain of the graphics core 219 and other clock domains within the SoC. In one embodiment, the SoC interface 232 enables the reception of command buffers from a command streamer and a global thread dispatcher configured to provide commands and instructions to each of one or more graphics cores within the graphics processor. Commands and instructions may be dispatched to the media pipeline 234 when media operations are performed, or to the geometry and fixed function pipelines (e.g., geometry and fixed function pipeline 231, geometry and fixed function pipeline 237) when graphics processing operations are performed.

[0056] The graphics microcontroller 233 may be configured to perform various scheduling and management tasks for the graphics processor core 219. In one embodiment, the graphics microcontroller 233 can perform graphics and / or computational workload scheduling for various graphics parallel engines in the execution unit (EU) arrays 221A-221F and 224A-224F within the subcores 221A-221F. In this scheduling model, host software running on the CPU core of the SoC, including the graphics processor core 219, can submit a workload to one of several graphics processor doorbells, which invokes scheduling operation on the appropriate graphics engine. The scheduling operation includes determining the next workload to be executed, submitting the workload to the command streamer, pre-empting existing workloads running on the engine, monitoring the progress of the workload, and notifying the host software when the workload is complete. In one embodiment, the graphics microcontroller 233 can also facilitate low-power or idle states for the graphics processor core 219, providing the graphics processor core 219 with the ability to conserve and recover registers within the graphics processor core 219 during low-power state transitions, independently of the operating system and / or graphics driver software on the system.

[0057] The graphics processor core 219 may have up to N modular subcores, more or less than the subcores 221A to 221F shown in the figure. For each set of N subcores, the graphics processor core 219 may also include shared function logic 235, shared and / or cache memory 236, geometry / fixed function pipeline 237, and additional fixed function logic 238 for accelerating various graphics and computational operations. The shared function logic 235 may include logic (e.g., sampler, arithmetic, and / or inter-thread communication logic) associated with the shared function logic 420 of FIG4, which can be shared by each of the N subcores in the graphics processor core 219. The shared and / or cache memory 236 can be a final-level cache for the set of N subcores 221A to 221F in the graphics processor core 219 and can also function as shared memory accessible by multiple subcores. The geometry / fixed function pipeline 237 is included in place of the geometry / fixed function pipeline 231 within the fixed function block 230 and may contain the same or similar logic units.

[0058] In one embodiment, the graphics processor core 219 includes additional fixed-function logic 238 which may include various fixed-function acceleration logic for use by the graphics processor core 219. In one embodiment, the additional fixed-function logic 238 includes an additional geometry pipeline for use with position-only shading. In position-only shading, there are two geometry pipelines: a full geometry pipeline in geometry / fixed-function pipelines 238, 231, and a cull pipeline, which is an additional geometry pipeline that may be included in the additional fixed-function logic 238. In one embodiment, the cull pipeline is a subdivided version of the full geometry pipeline. The full pipeline and the cull pipeline can run different instances of the same application, each instance having a separate context. Position-only shading can hide long culls of discarded triangles and complete shading faster than in some instances. For example, in one embodiment, the cull pipeline logic in the additional fixed-function logic 238 can run the position shader in parallel with the main application and typically produce results faster than the full pipeline. This is because the culling pipeline fetches and shades only the vertex position attributes without performing pixel rasterization and rendering on the frame buffer. Using the generated results, the culling pipeline can calculate the visibility information for all triangles, whether or not they are culled. The complete pipeline (which in this example may be called the replay pipeline) can consume the visibility information, skip the culled triangles, and shade only the visible triangles that are ultimately passed to the rasterization stage.

[0059] In one embodiment, the additional process function logic 238 may also include machine learning acceleration logic, such as fixed function matrix multiplication logic, for implementations that include machine learning training or estimation optimization.

[0060] Each graphics subcore 221A-221F contains a set of execution resources that can be used to perform graphics, media, and computational operations in response to requests from the graphics pipeline, media pipeline, or shader program. The graphics subcores 221A-221F include multiple EU arrays 222A-222F, 224A-224F, thread dispatch and inter-thread communication (TD / IC) logic 223A-223F, 3D (e.g., texture) samplers 225A-225F, media samplers 206A-206F, shader processors 227A-227F, and shared local memory (SLM) 228A-228F. Each EU array 222A-222F and 224A-224F includes multiple execution units, which are general-purpose graphics processing units capable of performing floating-point and integer / fixed-point logic operations during the service of graphics, media, or computation operations, including graphics, media, or computation shader programs. The TD / IC logic 223A-223F performs local thread dispatch and thread control operations for the execution units within the subcore and facilitates communication between threads running on the subcore's execution units. The 3D samplers 225A-225F can read textures or other 3D graphics-related data into memory. The 3D samplers can read texture data in different ways based on the configured sample state and the texture format associated with a given texture. The media samplers 206A-206F can perform similar read operations based on the type and format associated with the media data. In one embodiment, each graphics subcore 221A-221F may, alternatively, include an integrated 3D and media sampler. Threads running on the execution units within each of the subcores 221A to 221F can utilize the shared local memory 228A to 228F within each subcore, enabling threads running within a thread group to use a common pool of on-chip memory.

[0061] Figure 2C shows a graphics processing unit (GPU) 239 containing a dedicated set of graphics processing resources configured in multicore groups 240A to 240N. While details for only one multicore group 240A are provided, it should be understood that the other multicore groups 240B to 240N may have the same or similar sets of graphics processing resources.

[0062] As shown in the figure, the multicore group 240A may include a set of graphics cores 243, a set of tensor cores 244, and a set of ray tracing cores 245. The scheduler / dispatcher 241 schedules and dispatches graphics threads for execution on various cores 243, 244, and 245. The set of register files 242 stores operand values ​​used by cores 243, 244, and 245 when the graphics threads are executed. These may include, for example, integer registers for storing integer values, floating-point registers for storing floating-point values, vector registers for storing packed data elements (integer and / or floating-point data elements), and tile registers for storing tensor / matrix values. In one embodiment, the tile registers are implemented as a combined set of vector registers.

[0063] One or more combined Level 1 (L1) cache and shared memory units 247 locally store graphics data such as texture data, vertex data, pixel data, ray data, boundary volume data, etc., within each multicore group 240A. One or more texture units 247 can also be used to perform texture operations such as texture mapping and sampling. A Level 2 (L2) cache 253 shared by all or a subset of multicore groups 240A to 240N stores graphics data and / or instructions for multiple concurrent graphics threads. As shown in the figure, the L2 cache 253 may be shared across multiple multicore groups 240A to 240N. One or more memory control units 248 connect the GPU 239 to memory 249, which may be system memory (e.g., DRAM) and / or dedicated graphics memory (e.g., GDDR6 memory).

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

[0065] In one implementation, the IOMMU251 supports virtualization. In this case, the IOMMU3770 may manage a first page table set that maps guest / graphic virtual addresses to guest / graphic physical addresses, and a second page table set that maps guest / graphic physical addresses to system / host physical addresses (e.g., in system memory 249). The base addresses of each of the first and second page table sets are stored in a control register and may be swapped out in a context switch (e.g., the new context is then provided with access to the associated page table sets). Although not shown in Figure 2C, each of the cores 243, 244, 245 and / or multicore groups 240A-240N may include a translation lookaside buffer (TLB) that caches guest virtual translations to guest physical translations, guest physical translations to host physical translations, and guest virtual translations to host physical translations.

[0066] In one embodiment, the CPU 246, GPU 239, and I / O device 252 are integrated into a single semiconductor chip and / or chip package. The illustrated memory 249 may be integrated into the same chip or coupled to the memory control unit 248 via an off-chip interface. In one implementation, the memory 249 includes GDDR6 memory that shares the same virtual address space as other physical system-level memory, but the principles discussed in this specification are not limited to this particular implementation.

[0067] In one embodiment, the TensorCore 244 includes multiple execution units specifically designed to perform matrix operations, which are fundamental computational operations used to perform deep learning operations. For example, concurrent matrix multiplication may be used for neural network training and estimation. The TensorCore 244 may perform matrix operations using various operand precisions, including single-precision floating-point (e.g., 32 bits), half-precision floating-point (e.g., 16 bits), integer word (16 bits), byte (8 bits), and half-byte (4 bits). In one embodiment, the neural network implementation extracts features from each rendered scene and, possibly, combines details from multiple frames to construct a high-quality final image.

[0068] In deep learning implementations, parallel matrix multiplication operations may be scheduled for execution on the TensorCore 244. Neural network training, in particular, utilizes a significant number of matrix dot product operations. To process the dot product of an N×N×N matrix multiplication, the TensorCore 244 may include at least N dot product processing elements. Before starting matrix multiplication, an entire matrix is ​​loaded into a tile register, and at least one column of a second matrix is ​​loaded in each of the N cycles. Each cycle has N dot products to be processed.

[0069] Matrix elements may be stored with different precisions, depending on the specific implementation, including 16-bit words, 8-bit bytes (e.g., INT8), and 4-bit half-bytes (e.g., INT4). Different precision modes may be specified for the tensor core 244 to ensure that the most efficient precision is used for different workloads (e.g., estimation workloads that can withstand quantization to bytes and half-bytes).

[0070] In one embodiment, the ray tracing core 245 accelerates ray tracing operations in both real-time and non-real-time ray tracing implementations. Specifically, the ray tracing core 245 includes a ray traverse / crossover circuit that performs ray traverse using a bounding volume hierarchy (BVH) and identifies intersections between rays and primitives confined within the BVH volume. The ray tracing core 245 may also include a circuit that performs depth testing and culling (e.g., using a Z-buffer or similar configuration). In one embodiment, the ray tracing core 245 performs traverse and crossover operations in cooperation with image denoising techniques described herein, which may be at least partially performed on the tensor core 244. For example, in one embodiment, the tensor core 244 implements a deep learning neural network to perform denoising of frames generated by the ray tracing core 245. However, the CPU 246, graphics core 243, and / or ray tracing core 245 may implement all or part of the denoising and / or deep learning algorithms.

[0071] Furthermore, as described above, a distributed approach to denoising may be used, where the GPU239 is located in a computing system that is coupled to other computing devices via a network or high-speed interconnect. In this embodiment, the interconnected computing devices share neural network training data to improve the speed at which the entire system learns to perform denoising for different types of image frames and / or different graphics applications.

[0072] In one embodiment, the ray tracing core 245 handles all BVH traverses and ray primitive intersections to prevent the graphics core 243 from being overloaded with thousands of instructions per ray. In one embodiment, each ray tracing core 245 includes a first dedicated circuit set that performs bounding box tests (e.g., for traverse operations) and a second dedicated circuit set that performs ray triangle intersection tests (e.g., intersecting traversed rays). Thus, in one embodiment, the multicore group 240A can simply send out ray probes, and the ray tracing cores 245 independently perform ray traverses and intersections and return hit data (e.g., hit, no hit, multiple hits, etc.) to the thread context. The other cores 243, 244 are free to perform other graphics or computational tasks, while the ray tracing cores 245 perform traverse and intersection operations.

[0073] In one embodiment, each ray tracing core 245 includes a traverse unit for performing BVH test operations and a crossing unit for performing ray primitive crossing tests. The crossing unit generates "hit," "no hit," or "multiple hit" responses and provides them to the appropriate thread. During traverse and crossing operations, the execution resources of other cores (e.g., graphics core 243 and tensor core 244) are freed up to perform other forms of graphics work.

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

[0075] In one embodiment, the ray tracing core 245 (and / or other cores 243, 244) includes hardware support for a ray tracing instruction set such as Microsoft's DirectX Ray Tracing (DXR), which enables the assignment of a set of shaders and textures per object, including the DispatchRays command and ray generation, nearest hit, arbitrary hit, and miss shaders. Another ray tracing platform that may be supported by the ray tracing core 245, graphics core 243, and tensor core 244 is Vulkan 1.1.85. However, it should be noted that the principles discussed in this specification are not limited to any particular ray tracing ISA.

[0076] In general, various cores 245, 244, and 243 may support a set of ray tracking instructions that include instructions / functions for ray generation, nearest hit, arbitrary hit, ray primitive intersection, primitive-specific and substructure bounding box configuration, miss, visit, and exception. More specifically, one embodiment includes ray tracking instructions to perform the following functions:

[0077] Ray Generation: Ray generation commands may be executed for each pixel, sample, or other user-defined task assignment.

[0078] Closest Hit: The Closest Hit command may be executed to determine the location of the closest intersection of a ray with a primitive in the scene.

[0079] Any Hit: The Any Hit command identifies multiple intersections between a ray and a primitive in the scene, and in some cases identifies a new nearest intersection.

[0080] Intersection: The Intersection command performs a ray primitive crossover test and outputs the results.

[0081] Per-primitive Bounding Box Construction: This instruction constructs a bounding box around a given primitive or group of primitives (for example, when constructing a new BVH or other accelerated data structure).

[0082] Miss: Indicates that the light ray misses all geometry in the scene or a specific area of ​​the scene.

[0083] Visit: Indicates a subvolume traversed by a ray.

[0084] Exceptions: Includes handling of various types of exceptions (for example, those called for various error conditions).

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

[0086] The GPGPU 270 includes multiple cache memories, including an L2 cache 253, an L1 cache 254, an instruction cache 255, and shared memory 256, at least a portion of which may be partitioned as cache memory. The GPGPU 270 also includes multiple compute units 260A to 260N. Each compute unit 260A to 260N includes a set of vector registers 261, a scalar register 262, a vector logic unit 263, and a scalar logic unit 264. The compute units 260A to 260N may also include local shared memory 256 and a program counter 266. The compute units 260A to 260N can be coupled to a constant cache 267, which can be used to store constant data that does not change during the execution of a kernel or shader program running on the GPGPU 270. In one embodiment, the constant cache 267 is a scalar data cache, and the cached data can be fetched directly into a scalar register 262.

[0087] During operation, one or more CPUs 246 can write commands mapped to an accessible address space to registers or memory within the GPGPU 270. The command processor 257 can read the commands from the registers or memory and determine how these commands will be processed within the GPGPU 270. The thread dispatcher 258 can then use these commands to dispatch threads to the compute units 260A-260N. Each compute unit 260A-260N can execute threads independently of the other compute units. Furthermore, each compute unit 260A-260N can independently configure conditional computations and conditionally output the computation results to memory. The command processor 257 can interrupt one or more CPUs 246 once a submitted command has completed.

[0088] Figures 3A–3C show block diagrams of additional graphics processors and computing accelerators provided by embodiments described in this specification. Elements in Figures 2A–2D having the same reference numerals (or names) as elements in any other figures of this specification may, but are not limited to, operate or function in any way similar to those described elsewhere in this specification.

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

[0090] In some embodiments, the graphics processor 300 also includes a display control unit 302 that drives display output data to a display device 318. The display control unit 302 includes hardware for one or more overlay planes for the display and for compositing multiple layers of video or user interface elements. The display device 318 may be an internal or external display device. In one embodiment, the display device 318 is a head-mounted display device such as a virtual reality (VR) display device or an augmented reality (AR) display device. In some embodiments, the graphics processor 300 includes a video codec engine 306 for encoding, decoding, or converting media to, or between, one or more media encoding formats, including, but not limited to, MPEG (Moving Picture Experts Group) formats such as MPEG2, AVC (Advanced Video Coding) formats such as H.264 / MPEG-4 AVC and H.265 / HEVC, AOMedia (Alliance for Open Media) VP8, VP9, ​​and SMPTE (Society of Motion Picture & Television Engineers) 421M / VC-1, and JPEG (Joint Photographic Experts Group) formats such as JPEG and MJPEG (Motion JPEG) format.

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

[0092] In some embodiments, the GPE310 includes a 3D pipeline 312 that performs 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 and fixed function elements that perform various tasks within the element and / or generate execution threads to the 3D / media subsystem 315. While the 3D pipeline 312 can be used to perform media operations, embodiments of the GPE310 also include a media pipeline 316 which is specifically used to perform media operations such as video post-processing and image augmentation.

[0093] In some embodiments, the media pipeline 316 includes fixed functions or programmable logic units that perform one or more specific media operations, such as video decoding acceleration, video deinterlacing, and video encoding acceleration, on behalf of or on behalf of the video codec engine 306. In some embodiments, the media pipeline 316 further includes a thread generation unit that generates threads to run on the 3D / media subsystem 315. The generated threads perform calculations for media operations on one or more graphics execution units included in the 3D / media subsystem 315.

[0094] In some embodiments, the 3D / media subsystem 315 includes logic for executing threads generated by the 3D pipeline 312 and the media pipeline 316. In one embodiment, the pipelines send thread execution requests to the 3D / media subsystem 315. The 3D / media subsystem 315 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 for processing 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, for sharing data between threads and for storing output data.

[0095] Figure 3B shows a graphics processor 320 having a tile architecture according to an embodiment described in this specification. In one embodiment, the graphics processor 320 includes a graphics processing engine cluster 322 having multiple instances of the graphics processing engine 310 of Figure 3A within graphics engine tiles 310A to 310D. Each graphics engine tile 310A to 310D can be interconnected via a set of tile interconnects 323A to 323F. Each graphics engine tile 310A to 310D can also be connected to a memory module or memory device 326A to 326D via memory interconnects 325A to 325D. The memory devices 326A to 326D can use any graphics memory technology. For example, the memory devices 326A to 326D may be GDDR (graphics double data rate) memory. In one embodiment, memory devices 326A to 326D are high-bandwidth memory (HBM) modules located on the die together with their respective graphics engine tiles 310A to 310D. In one embodiment, memory devices 326A to 326D are stackable memory devices that can be stacked on top of their respective graphics engine tiles 310A to 310D. In one embodiment, each graphics engine tile 310A to 310D and its associated memory 326A to 326D reside on individual chiplets coupled to a base die or base substrate, as detailed in Figures 11B to 11D.

[0096] The graphics processor 320 may be configured with a non-uniform memory access (NUMA) system in which memory devices 326A-326D are coupled to associated graphics engine tiles 310A-310D. A given memory device may be accessed by graphics engine tiles other than those to which it is not directly connected. However, the access delay to memory devices 326A-326D can be minimized when accessing local tiles. In one embodiment, a cache-coherent NUMA (ccNUMA) system uses tile interconnects 323A-323F to enable communication between cache control units within graphics engine tiles 310A-310D, maintaining a consistent memory image when one or more caches store the same memory location.

[0097] The graphics processing engine cluster 322 can be connected to an on-chip or on-package fabric interconnect 324. The fabric interconnect 324 enables communication between the graphics engine tiles 310A-310D and components such as the video codec 306 and one or more copy engines 304. The copy engines 304 can be used to move data to, to, and between memory devices 326A-326D and memory outside the graphics processor 320 (e.g., system memory). The fabric interconnect 324 can also be used to interconnect the graphics engine tiles 310A-310D. The graphics processor 320 may optionally include a display control unit 302 to enable connection with an external display device 318. The graphics processor may be configured as a graphics or computing accelerator. In an accelerator configuration, the display control unit 302 and the display device 318 may be omitted.

[0098] The graphics processor 320 can be connected to the host system via the host interface 328. The host interface 328 can enable communication between the graphics processor 320, system memory, and / or other system components. The host interface 328 may be, for example, a PCI Express bus or another type of host system interface.

[0099] Figure 3C shows a computation accelerator 330 according to an embodiment described in this specification. The computation accelerator 330 includes architectural similarities with the graphics processor 320 in Figure 3B and is optimized for computation acceleration. The computation engine cluster 332 may include a set of computation engine tiles 340A to 340D that include execution logic optimized for parallel or vector-based general-purpose computations. In some embodiments, the computation engine tiles 340A to 340D do not include fixed-function graphics processing logic, but in one embodiment, one or more of the computation engine tiles 340A to 340D may include logic for performing media acceleration. The computation engine tiles 340A to 340D can be connected to memories 326A to 326D via memory interconnects 325A to 325D. The memories 326A to 326D and the memory interconnects 325A to 325D may be similar to or different from those in the graphics processor 320. The graphics computing engine tiles 340A to 340D may also be interconnected via tile interconnects 323A to 323F, and may be connected to and / or interconnected by a fabric interconnect 324. In one embodiment, the computing accelerator 330 includes a large L3 cache 336 which may be configured as a device-wide cache. The computing accelerator 330 may also be connected to a host processor and memory via a host interface 328 in a similar manner to the graphics processor 320 in Figure 3B.

[0100] <Graphics processing engine> Figure 4 is a block diagram of a graphics processing engine 410 of a graphics processor according to several embodiments. In one embodiment, the graphics processing engine (GPE) 410 is a version of the GPE 310 shown in Figure 3A and may represent the graphics engine tiles 310A to 310F in Figure 3B. Elements in Figure 4 having the same reference numerals (or names) as elements in any other figures of this specification may operate or function in any manner similar to those described elsewhere in this specification, but are not limited to such manner. For example, the 3D pipeline 312 and media pipeline 316 are shown in Figure 3A. The media pipeline 316 is optional in some embodiments of the GPE 410 and does not have to be explicitly included within the GPE 410. For example, in at least one embodiment, individual media and / or image processors are coupled to the GPE 410.

[0101] In some embodiments, the GPE 410 is coupled to or includes a command streamer 403 that provides a command stream to the 3D pipeline 312 and / or 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 the commands to the 3D pipeline 312 and / or media pipeline 316. A command is an instruction fetched from a ring buffer that stores commands for the 3D pipeline 312 and media pipeline 316. In one embodiment, the ring buffer may further include a batch command buffer that stores batches of multiple commands. Commands for the 3D pipeline 312 may also include, but are not limited to, references to data stored in memory, such as 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 subsystem 316 process commands and data by dispatching one or more execution threads to the graphics core array 414 by executing operations according to the logic within their respective pipelines. In one embodiment, the graphics core array 414 includes one or more blocks of graphics cores (e.g., graphics core 415A, graphics core 415B). Each block includes one or more graphics cores. Each graphics core includes a set of graphics execution resources, including general-purpose and graphics-specific execution logic for performing graphics and computational operations, as well as fixed-function texture processing and / or machine learning and artificial intelligence acceleration logic.

[0102] In various embodiments, the 3D pipeline 312 may include fixed-function and programmable logic that processes one or more shader programs, such as vertex shaders, geometry shaders, pixel shaders, fragment shaders, compute shaders, or other shader programs, by processing instructions and dispatching execution threads to the graphics core array 414. The graphics core array 414 provides an integrated block of execution resources for use when processing these shader programs. The multi-purpose execution logic (e.g., execution units) within the graphics cores 415A-414B of the graphics core array 414 includes support for various 3D API shader languages ​​and can execute multiple concurrent execution threads associated with multiple shaders.

[0103] In some embodiments, the graphics core array 414 includes execution logic to perform media functions such as video and / or image processing. In one embodiment, the execution unit includes general-purpose logic to perform parallel general-purpose computing operations in addition to graphics processing operations. The general-purpose logic can perform processing operations in parallel with or in conjunction with the general-purpose logic in the processor core 107 in Figure 1 or in cores 202A to 202N as in Figure 2A.

[0104] Output data generated by threads running on the graphics core array 414 can be output to memory in the integrated return buffer (URB) 418. The URB 418 can store data from multiple threads. In some embodiments, the URB 418 may be used to transmit data between different threads running on the graphics core array 414. In some embodiments, the URB 418 may be further used for synchronization between threads on the graphics core array and fixed-function logic in the shared-function logic 420.

[0105] In some embodiments, the graphics core array 414 is scalable. As a result, the array includes a variable number of graphics cores, each graphics core 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. As a result, the execution resources may be enabled or disabled.

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

[0107] Shared functions are implemented at least when a given dedicated function is insufficient to be included within the graphics core array 414. Instead, a single instance of this dedicated function is implemented as a standalone entity within the shared function logic 420 and shared among the execution resources within the graphics core array 414. The exact set of functions included within the graphics core array 414 that are shared among the graphics core arrays 414 varies by embodiment. In some embodiments, certain shared functions within the shared function logic 420 that are used extensively by the graphics core array 414 may be included in the shared function logic 416 within the graphics core array 414. In various embodiments, the shared function logic 416 within the graphics core array 414 may include some or all of the logic within the shared function logic 420. In one embodiment, all the logical 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 removed, with the shared function logic 416 within the graphics core array 414 being chosen.

[0108] <Execution Unit> Figures 5A–5B show thread execution logic 500, which includes an array of processing elements used in a graphics processor core according to the embodiments described herein. Elements in Figures 5A–5B having the same reference numerals (or names) as elements in any other figures of this specification may, but are not limited to, operate or function in any way similar to those described elsewhere in this specification. Figures 5A–5B show schematics of thread execution logic 500 which may represent hardware logic shown together with each subcore 221A–221F in Figure 2B. Figure 5A represents an execution unit in a general-purpose graphics processor, and Figure 5B represents an execution unit which may be used in a compute accelerator.

[0109] As shown in Figure 5A, in some embodiments, the thread execution logic 500 includes a shader processor 502, a thread dispatcher 504, an instruction cache 506, a scalable execution unit array including multiple execution units 508A-508N, a sampler 510, a shared local memory 511, a data cache 512, and a data port 514. In one embodiment, the scalable execution unit array is dynamically scalable by enabling or disabling one or more execution units (e.g., any of execution units 508A, 508B, 508C, 508D-508N-1, and 508N) based on the computational requirements of the workload. In one embodiment, the included components are interconnected via an interconnect fabric that links to each component. In some embodiments, the thread execution logic 500 includes one or more connections to memory, such as system memory or cache memory, through the instruction cache 506, the data port 514, the sampler 510, and one or more of the execution units 508A-508N. In some embodiments, each execution unit (e.g., 508A) is an independent, programmable, general-purpose computing unit capable of executing multiple concurrent hardware threads while processing multiple data elements in parallel with each thread. In various embodiments, the array of execution units 508A to 508N is scalable to include any number of individual execution units.

[0110] In some embodiments, execution units 508A to 508N are primarily used to execute shader programs. The shader processor 502 processes various shader programs and dispatches execution threads associated with the shader programs via the thread dispatcher 504. In one embodiment, the thread dispatcher includes logic for mediating thread start requests from the graphics and media pipelines and instantiating the requested threads on one or more execution units within the execution units 508A to 508N. For example, the geometry pipeline can dispatch vertex, tessellation, or geometry shaders to the thread execution logic for processing. In some embodiments, the thread dispatcher 504 can also process runtime thread creation requests from the execution shader programs.

[0111] In some embodiments, execution units 508A–508N support instruction sets that include native support for many standard 3D graphics shader instructions. As a result, shader programs from graphics libraries (e.g., Direct3D and OpenGL) are executed with minimal conversion. 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., computation and media shaders). Each of the execution units 508A–508N is capable of SIMD (multi-issue single instruction multiple data) execution, and multithreaded operation enables an efficient execution environment despite higher latency memory access. Each hardware thread within each execution unit has its own dedicated high-bandwidth register file and associated independent thread state. Execution is multi-issue per clock for a wide variety of arithmetic pipelines, including integer, single and double-precision floating-point arithmetic, SIMD branching capability, logical operations, transcendental operations, and more. While waiting for data from memory or one of the shared functions, the dependent logic within execution units 508A-508N puts the waiting thread to sleep until the required data is returned. While the waiting thread is sleeping, hardware resources may be dedicated to other threads that are processing. For example, during the delay associated with a vertex shader operation, the execution unit can perform operations for a pixel shader, a fragment shader, or another type of shader program, including a different vertex shader. Various embodiments can be adapted to use execution using SIMT (Single Instruction Multiple Thread) as an alternative to or in addition to the use of SIMD. References to SIMD cores or operations can also apply to SIMT, or to SIMD in combination with SIMT.

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

[0113] The execution unit instruction set includes SIMD instructions. Various data elements can be stored in registers as packed data types, and the execution unit processes the elements in various ways based on their data size. For example, when operating on a 256-bit wide vector, the 256-tail and t vector are stored in registers, and the execution unit operates on the vector as four distinct 54-bit packed data elements (QW (Quad-Word) size data elements), eight distinct 32-bit packed data elements (DW (Double-Word) size data elements), sixteen distinct 16-bit packed data elements (W (Word) size data elements), or thirty-two distinct 8-bit packed data elements (B (Byte) size data elements). However, different vector widths and register sizes are possible.

[0114] In one embodiment, one or more execution units can be coupled to coupled execution units 509A to 509N having thread control logic (507A to 507N) common to the coupled EUs. Multiple EUs can be coupled to an EU group. Each EU in a coupled EU group can be configured to execute a separate SIMD hardware thread. The number of EUs in a coupled EU group may vary depending on the embodiment. Furthermore, various SIMD widths can be executed per EU, including, but not limited to, SIMD8, SIMD16, and SIMD32. Each coupled graphics execution unit 509A to 509N includes at least two execution units. For example, coupled execution unit 509A includes a first EU 508A, a second EU 508B, and a third thread control logic 507A common to the first EU 508A and the second EU 508B. The thread execution logic 507A controls the threads that run on the combined graphics execution unit 509A, enabling each EU in the combined execution units 509A to 509N to execute using a common instruction pointer register.

[0115] One or more internal instruction caches (e.g., 506) are included in the thread execution logic 500 to cache thread instructions for the execution unit. In some embodiments, one or more data caches (e.g., 512) are included to cache thread data during thread execution. Threads running on the execution logic 500 may also store explicitly managed data in shared local memory 511. In some embodiments, a sampler 510 is included to provide texture sampling for 3D operations and media sampling for media operations. In some embodiments, the sampler 510 includes dedicated texture or media sampling functions to process texture or media data during the sampling process before providing the sampled data to the execution unit.

[0116] During execution, the graphics and media pipeline sends a thread start request to the thread execution logic 500 via the thread creation and dispatch logic. When a group of geometric objects is processed and rasterized into pixel data, the pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) in the shader processor 502 is called to further calculate output information and write the results to the output surfaces (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 object. In some embodiments, the pixel processor logic in the shader program 502 then executes the pixel or fragment shader program supplied by the API (application programming interface). To execute the shader program, the shader processor 502 dispatches a thread to the execution unit (e.g., 508A) via the thread dispatcher 504. In some embodiments, the shader processor 502 accesses texture data in a texture map stored in memory using the texture sampling logic in the sampler 510. Arithmetic operations on texture data and input geometry data calculate the pixel color data for each geometry fragment, or discard one or more pixels from future processing.

[0117] In some embodiments, the data port 514 provides a memory access mechanism to the thread execution logic 500 for outputting processed data to memory for future processing on the graphics processor output pipeline. In some embodiments, the data port 514 includes or is coupled to one or more cache memories (e.g., data cache 512) for caching data for memory access by the data port.

[0118] In one embodiment, the execution logic 500 may also include a ray tracing unit 505 that can provide ray tracing acceleration functionality. The ray tracing unit 505 can support a ray tracing instruction set that includes instructions / functions for ray generation. The ray tracing instruction set may be similar to or different from the ray tracing instruction set supported by the ray tracing core 245 in Figure 2C.

[0119] Figure 5B shows illustrative internal details of an execution unit 508 according to an embodiment. The graphics execution unit 508 may include an instruction fetch unit 537, a general register file array (GRF) 524, an architectural register file array (ARF) 526, a thread arbitration unit 522, a transmit unit 530, a branch unit 532, SIMD floating-point units (FPU) 534, and, in one embodiment, a set of dedicated registers SIMD ALU 535. The GRF 524 and ARF 526 include a general register file and a set of architectural register files associated with each concurrent hardware thread that may be active in the graphics execution unit 508. In one embodiment, an ARF 256 is maintained for each thread architecture state, while data used during thread execution is stored in the GRF 524. The execution state of each thread, including the instruction pointer for each thread, may be held in thread-specific registers within the ARF 256.

[0120] In one embodiment, the graphics execution unit 508 has an architecture that combines SMT (Simultaneous Multi-Threading) and fine-grained IMT (Interleaved Multi-Threading). The architecture has a modular configuration that can be fine-tuned at design time based on the target number of concurrent threads and the number of registers per execution unit. Here, the execution unit resources are divided among the logic used to execute multiple concurrent threads. The number of logical threads that can be executed by the graphics execution unit 508 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread.

[0121] In one embodiment, the graphics execution unit 508 can co-issue multiple instructions, each of which may be a different instruction. The thread arbitration unit 522 of the graphics execution unit thread 508 can dispatch instructions for execution to one of the following: the transmit unit 530, the branch unit 532, or the SIMD FPU 534. Each execution thread has access to 128 general-purpose registers in the GRF524, where each register can store 32 bytes, accessible as a SIMD8 element vector of 32-bit data elements. In one embodiment, each execution unit thread has access to 4K bytes in the GRF524, but embodiments are not limited to this, and other embodiments may provide more or fewer register resources. In one embodiment, the graphics execution unit 508 is partitioned into 7 hardware threads that can independently perform computational operations. However, the number of threads per execution unit can also vary depending on the embodiment; for example, in one embodiment, up to 16 hardware threads are supported. In one embodiment, seven threads may access 4K bytes, and the GRF524 can store a total of 28K bytes. Sixteen threads may access 4K bytes, and the GRF524 can store a total of 64K bytes. The flexible addressing mode allows registers to be addressed together to efficiently construct wide registers or to represent strided rectangular block data structures.

[0122] In one embodiment, memory operations, sampler operations, and other longer-latency system communications are dispatched by a “transmit” command executed by a message pass-through transmission unit 530. In one embodiment, branch commands are dispatched to a dedicated branch unit 532 to facilitate SIM divergence and final convergence.

[0123] In one embodiment, the graphics execution unit 508 includes one or more SIMD floating-point units (FPUs) 534 for performing floating-point arithmetic. In one embodiment, the FPU 534 also supports integer arithmetic. In one embodiment, the FPU 534 can perform up to M 32-bit floating-point (or integer) arithmetic SIMD operations, or up to 2M 16-bit integer or 16-bit floating-point arithmetic SIMD operations. In one embodiment, at least one of the FPUs provides extended computing power to support high-throughput transcendental mathematical functions and double-precision 54-bit floating-point. In some embodiments, a set of 8-bit integer SIMD ALUs 535 also exist and may be specifically optimized for performing operations associated with machine learning computations.

[0124] In some embodiments, an array of multiple instances of the graphics execution unit 508 can be instantiated within a graphics subcore group (e.g., a subslice). For scalability, the product architecture can select an exact number of execution units for each subcore group value. In one embodiment, the execution unit 508 can execute instructions across multiple execution channels. In further embodiments, each thread running on the graphics execution unit 508 runs on a different channel.

[0125] Figure 6 shows an additional execution unit 600 according to one embodiment. The execution unit 600 may be, for example, a computationally optimized execution unit for use in computation engine tiles 340A to 340D as shown in Figure 3C, but is not limited to this. A variation of the execution unit 600 may be used in the graphics engine tiles 310A to 310D in Figure 3B. In one embodiment, the execution unit 600 includes a thread control unit 601, a thread state unit 602, an instruction fetch / prefetch unit 603, and an instruction decoding unit 604. The execution unit 600 further includes a register file 606 that stores registers that can be allocated to hardware threads within the execution unit. The execution unit 600 further includes a transmit unit 607 and a branch unit 608. In one embodiment, the transmit unit 607 and the branch unit 608 can operate similarly to the transmit unit 530 and the branch unit 532 of the graphics execution unit 508 in Figure 5B.

[0126] The execution unit 600 also includes a compute unit 610 which includes several different types of functional units. In one embodiment, the compute unit 610 includes an ALU unit 611 which includes an array of arithmetic logic units. The ALU unit 611 can be configured to perform 64-bit, 32-bit, and 16-bit integer and floating-point operations. Integer and floating-point operations may be performed simultaneously. The compute unit 610 may also include a systolic array 612 and an arithmetic unit 613. The systolic array 612 includes a W-width and D-depth data processing unit network which can be used to perform vector or other data parallel operations in a systolic manner. In one embodiment, the systolic array 612 can be configured to perform matrix operations such as matrix dot products. In one embodiment, the systolic array 612 supports 16-bit floating-point operations and 8-bit and 4-bit integer operations. In one embodiment, the systolic array 612 can be configured to accelerate machine learning operations. In such embodiments, the systolic array 612 can be configured to support the b-float 16-bit floating-point format. In one embodiment, an arithmetic unit 613 may be included to perform a specific subset of arithmetic operations in a more efficient and low-power manner than the ALU unit 611. The arithmetic unit 613 may include variations of the arithmetic logic found in the shared function logic of the graphics processing engine provided in other embodiments (e.g., the arithmetic logic 422 of the shared function logic 420 in Figure 4). In one embodiment, the arithmetic unit 613 can be configured to perform 32-bit and 64-bit floating-point operations.

[0127] The thread control unit 601 includes logic for controlling the execution of threads within the execution unit. The thread control unit 601 may include thread arbitration logic for starting, stopping, and preempting the execution of threads within the execution unit 600. The thread state unit 602 can be used to store the thread state of threads assigned to run on the execution unit 600. Storing the thread state within the execution unit 600 allows for fast preemption of threads when they become blocked or idle. The instruction fetch / prefetch unit 603 can fetch instructions from higher-level execution logic (e.g., the instruction cache 506 in Figure 5A). The instruction fetch / prefetch unit 603 can also issue prefetch requests for instructions that should be loaded into the instruction cache, based on an analysis of currently running threads. The instruction decoding unit 604 can be used to decode instructions that should be executed by the compute units. In one embodiment, the instruction decoding unit 604 can be used as a secondary decoder to decode complex instructions into component microoperations.

[0128] The execution unit 600 further includes a register file 606 that is available to hardware threads running on the execution unit 600. The registers in the register file 606 can be divided among the logic used to execute multiple concurrent threads within the compute unit 610 of the execution unit 600. The number of logical threads that can be executed by the graphics execution unit 600 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread. The size of the register file 606 may vary depending on the embodiment, based on the number of supported hardware threads. In one embodiment, register renaming may be used to dynamically assign registers to hardware threads.

[0129] Figure 7 is a block diagram showing graphics processor instruction formats 700 according to several embodiments. In one or more embodiments, the graphics processor execution unit supports an instruction set having instructions in multiple formats. Solid boxes typically indicate components included in an execution unit instruction, while dashed lines indicate components included in any or only a subset of instructions. In some embodiments, the described and illustrated instruction formats 700 are macroinstructions in that they are instructions supplied to the execution unit, as opposed to microoperations resulting from instruction decoding when the instructions are processed.

[0130] In some embodiments, the graphics processor execution unit natively supports instructions in the 128-bit instruction format 710. The 64-bit compact instruction format 730 is available for some instructions, depending on the selected instructions, instruction options, and the number of operands. The native 128-bit instruction format 710 provides access to all instruction options, while some options and behaviors are restricted in the 64-bit format 730. The native instructions available in the 64-bit format 730 vary by embodiment. In some embodiments, instructions are partially compacted using a set of index values ​​in an index file 713. The execution unit hardware references a set of compaction tables based on the index values ​​and uses the output of the compaction tables to reconstruct the native instructions in the 128-bit instruction format 710. Instructions of other sizes and formats are available.

[0131] For each format, the instruction opcode 712 defines the operation that the execution unit should perform. 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 addition across each color channel representing a texture or 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 specific execution options, such as channel selection (e.g., prediction) and data channel order (e.g., swizzle). For instructions in the 128-bit instruction format 710, the execution size (exec-size) field 716 limits the number of data channels executed in parallel. In some embodiments, the execution size field 716 is unavailable for use in the 64-bit small instruction format 730.

[0132] Some execution unit instructions have up to three operands, including two source operands, src0 720 and src1 722, and one destination 718. In some embodiments, the execution unit supports dual-destination instructions in which one of the destinations 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 an instruction may be an intermediate (e.g., hardcoded) value passed with the instruction.

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

[0134] In some embodiments, the 128-bit instruction format 710 includes an access / address mode field 726 that specifies the instruction's address mode and / or access mode. In one embodiment, the access mode is used to determine the instruction's data access alignment. Some embodiments support access modes including 16-byte aligned access modes and 1-byte aligned access modes, 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 the source and destination operands, while in the second mode, the instruction may use 16-byte aligned addressing for all source and destination operands.

[0135] In one embodiment, the address mode portion of the access / address mode field 726 determines whether the instruction should use direct or indirect addressing. When direct register addressing mode is used, the bits in 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 may be calculated based on the address register values ​​and the address intermediate field in the instruction.

[0136] In some embodiments, instructions are grouped based on the bit field of the opcode 712 to simplify the opcode decoder 740. In an 8-bit opcode, bits 4, 5, and 6 allow the execution unit to determine the type of opcode. The detailed opcode groupings shown are merely examples. In some embodiments, the move and logic opcode group 724 includes data move and logic instructions (e.g., move (mov), compare (comp)). In some embodiments, the move and logic group 742 shares five most significant bits (MSB), with move (mov) instructions in the format 0000xxxxb and logic instructions in the format 0001xxxxb. The flow control instruction group 744 (e.g., call, jump (jmp)) includes instructions in the format 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 746 includes synchronous instructions in the form of 0011xxxxb (e.g., ox30) (e.g., wait, send). The parallel arithmetic instruction group 748 includes component-related calculation instructions in the form of 0100xxxxb (e.g., 0x40) (e.g., add, multiply (mul)). The parallel arithmetic group 748 performs calculation operations in parallel across data channels. The vector arithmetic group 750 includes calculation instructions in the form of 0101xxxxb (e.g., 0x50) (e.g., dp4). The vector arithmetic group performs calculations such as dot product calculations on vector operands. The illustrated opcode decode 740 can be used in one embodiment to determine which part of the execution unit is used to execute the decoded instructions. For example, some instructions may be designed as systolic instructions executed by a systolic array. Other instructions, such as ray tracing instructions (not shown), can be routed to ray tracing cores or ray tracing logic within slices or partitions of the execution unit.

[0137] <Graphics pipeline> Figure 8 is a block diagram of another embodiment of the graphics processor 800. Elements in Figure 8 having the same reference numerals (or names) as elements in any other figures of this specification may, but are not limited to, operate or function in any way similar to those described elsewhere in this specification.

[0138] 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 writes to one or more control registers (not shown) or by commands issued to the graphics processor 800 via a ring interconnect 802. In some embodiments, the ring interconnect 802 connects 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 that supplies instructions to individual components of the geometry pipeline 820 or the media pipeline 830.

[0139] In some embodiments, the command streamer 803 instructs the vertex fetcher 805 to read vertex data from memory and execute vertex processing commands provided by the command streamer 803. In some embodiments, the vertex fetcher 805 provides the vertex data to the vertex shader 807. The vertex shader 807 performs coordinate space transformations and lighting operations on each vertex. In some embodiments, the vertex fetcher 805 and the vertex shader 807 execute vertex processing instructions by dispatching execution threads to execution units 852A-852B via the thread dispatcher 831.

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

[0141] 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 constitutes the tessellation operation. A programmable domain shader 817 provides backend evaluation of the tessellation output. A tessellator 813, operating under the direction of the hull shader 811, includes dedicated logic to generate a set of detailed geometry objects based on a coarse geometry model provided as input to the geometry pipeline 820. In some embodiments, if tessellation is not used, the tessellation component (e.g., the hull shader 811, the tessellator 813, and the domain shader 817) can be bypassed. The tessellation component can operate based on data received from the vertex shader 807.

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

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

[0144] The graphics processor 800 has an interconnection bus, an interconnection fabric, or some other interconnection mechanism that allows data and messages to be passed between the processor's assertive components. In some embodiments, the execution units 852A-852B and associated logical units (e.g., L1 cache 851, sampler 854, texture cache 858, etc.) interconnect via data port 856 to perform memory access and communicate with the processor's render output pipeline. 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.

[0145] In some embodiments, the render output pipeline 870 includes a rasterizer and depth test component 873 that translates vertex-based objects into associated pixel-based representations. In some embodiments, the rasterizer logic includes a windower / masker unit to perform fixed-function triangle and line rasterization. Associated render caches 878 and depth caches 879 are also available in some embodiments. The pixel operation component 877 performs pixel-based operations on the data. However, in some instances, pixel operations associated with 2D operations (e.g., bitblock image transfer by blending) are performed by the 2D engine 841 or substituted by the display control unit 843 using an overlay display plane during display. In some embodiments, a shared L3 cache 875 is available to all graphics components, enabling data sharing without using main system memory.

[0146] In some embodiments, the graphics processor media pipeline 830 includes a media engine 837 and a video frontend 834. In some embodiments, the video frontend 834 receives pipeline commands from a command streamer 803. In some embodiments, the media pipeline 830 includes individual command streamers. In some embodiments, the video frontend 834 processes media commands before sending them to the media engine 837. In some embodiments, the media engine 837 includes a thread generation function that generates threads to be dispatched to the thread execution logic 850 via a thread dispatcher 831.

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

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

[0149] <Graphics Pipeline Programming> Figure 9A is a block diagram showing graphics processor command formats 900 according to several embodiments. Figure 9B is a block diagram showing graphics processor command sequences 910 according to one embodiment. In Figure 9A, solid boxes typically indicate components included in a graphics command, while dashed lines indicate components included in any or only a subset of graphics commands. The exemplary graphics processor command format 900 in Figure 9A includes a client 902, a command arithmetic code (opcode) 904, and data fields for identifying the data 906 for the command. Sub-opcodes 905 and command size 908 are also included in some commands.

[0150] In some embodiments, client 902 specifies a client unit of the 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 for processing commands. When a command is received by a 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 executes the command using the information in 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, commands are aligned by multiples of double words. Other command formats are available.

[0151] The flowchart in Figure 9B shows an exemplary graphics processor command sequence. In some embodiments, software or firmware of a data processing system characterizing one embodiment of the graphics processor uses the versions of the command sequences shown to set up, execute, and terminate a set of graphics operations. The exemplary command sequences are shown and described for illustrative purposes only, and embodiments are not limited to or exclusive to these specific commands. Furthermore, commands may be issued as batches of commands within a command sequence. As a result, the graphics processor processes the sequence of commands at least partially simultaneously.

[0152] In some embodiments, the graphics processor command sequence 910 may be initiated by a pipeline flush command 912, causing any active graphics pipeline to complete any currently pending commands in the pipeline. In some embodiments, the 3D pipeline 922 and the media pipeline 924 do not operate simultaneously. Pipeline flush is performed to allow any pending commands in the active graphics pipeline to complete. In response to the pipeline flush, the command parser for the graphics processor pauses command processing until the active drawing engine completes its pending operations and the associated read cache is invalidated. Optionally, any data in the render cache marked as "dirty" may be flushed into memory. In some embodiments, the pipeline flush command 912 may be used for pipeline synchronization or before placing the graphics processor into a low-power state.

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

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

[0155] In some embodiments, the return buffer state command 916 is used to configure a set of return buffers for each pipeline to write data. Some pipeline operations utilize the allocation, selection, or configuration of one or more return buffers to which the operation writes intermediate data during processing. In some embodiments, the graphics processor also uses one or more return buffers to store output data and to perform inter-thread communication. In some embodiments, the return buffer state 916 includes selecting the size and number of return buffers to be used for a set of pipeline operations.

[0156] The remaining commands in the command sequence differ based on the active pipeline for operation. Based on pipeline determination 902, the command sequence is aligned to either the 3D pipeline 922, which starts in 3D pipeline state 930, or the media pipeline 924, which starts in media pipeline state 940.

[0157] Commands for configuring the 3D pipeline state 930 include 3D state setting commands that set commands for vertex buffer state, string element state, constant color state, depth buffer state, and other state variables that should be configured before 3D primitive commands are processed. The values ​​of these commands are determined based at least partially on the specific 3D API being used. In some embodiments, the 3D pipeline state 930 commands may also selectively disable or bypass specific pipeline elements if those elements are not being used.

[0158] 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 the vertex fetch function in the graphics pipeline. The vertex fetch function uses the 3D primitive 932 command data to generate a vertex data structure. The vertex data structure is stored in one or more return buffers. In some embodiments, the 3D primitive 932 command is used to perform vertex operations on the 3D primitive via a vertex shader. To process the vertex shader, the 3D pipeline 922 dispatches a shader execution thread to the graphics processor execution unit.

[0159] In some embodiments, the 3D pipeline 922 is triggered by an execution command 934 or event. In some embodiments, a register write triggers a command execution. In some embodiments, execution is triggered by a "go" or "kick" command in a command sequence. In one embodiment, command execution is triggered using a pipeline synchronization command to flush the command sequence through the graphics pipeline. The 3D pipeline performs geometry processing on 3D primitives. Once the operation is complete, the resulting geometry object is rasterized, and the pixel engine colors the resulting pixels. Additional commands and pixel backend operations to control pixel shading may also be included for these operations.

[0160] In some embodiments, a graphics processor command sequence 910 follows a media pipeline 924 when performing media operations. Typically, the specific use and programming method of the media pipeline 924 depends on the media or computational operation to be performed. Specific media decoding operations may be offloaded to the media pipeline during media decoding. In some embodiments, the media pipeline may also be bypassed, and media decoding may be performed entirely or partially using resources provided by one or more general-purpose processing cores. In one embodiment, the media pipeline also includes elements for GPGPU (general-purpose graphics processor unit) operation, where the graphics processor is used to perform SIMD vector operations using computational shader programs not explicitly related to rendering graphic primitives.

[0161] In some embodiments, the media pipeline 924 is configured in a similar manner to the 3D pipeline 922. A set of commands for configuring the media pipeline state 940 is dispatched before the media object command 942 and placed in the command queue. In some embodiments, the command for the media pipeline state 940 includes data for configuring the media pipeline elements used to process media objects. This includes data for configuring the video decoding and video coding logic within the media pipeline, such as the encoding or decoding 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, which include a batch of state settings.

[0162] In some embodiments, a media object command 942 provides a pointer to a media object for processing by the media pipeline. The media object includes 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 states are configured and the media object command 942 is queued, the media pipeline 924 is triggered via an execution command 944 or an equivalent execution event (e.g., a register write). The output from the media pipeline 924 may then be post-processed by the 3D pipeline 922 or by operations provided by the media pipeline 924. In some embodiments, GPGPU operations are configured and executed similarly to media operations.

[0163] <Graphics Software Architecture> Figure 10 shows an exemplary graphics software architecture of a data processing system 1000 according to several embodiments. In some embodiments, the software architecture includes a 3D graphics application 1010, an operating system 1020, and at least one processor 1030. In some embodiments, the processor 1030 includes a graphics processor 1032 and one or more general-purpose processor cores 1034. The graphics application 1010 and the operating system 1020 each run in the system memory 1050 of the data processing system.

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

[0165] In some embodiments, operating system 1020 is an open-source UNIX®-like operating system using Microsoft Corporation's Microsoft® Windows® operating system, a proprietary UNIX®-like operating system, or a variant of the Linux® kernel. Operating system 1020 can support graphics APIs 1022 such as the Direct3D API, OpenGL API, or Vulkan API. When the Direct3D API is used, operating system 1020 uses a front-end compiler 1024 to compile any HLSL shader instructions 1012 into a low-level shader language. Compilation may be JIT (just-in-time) 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, such as a version of SPIR (Standard Portable Intermediate Representation) used by the Vulkan API.

[0166] In some embodiments, the user-mode graphics driver 1026 includes a backend shader compiler 1027 for translating shader instructions 1012 into hardware-named representations. When the OpenGL API is used, the GLSL high-level language shader instructions 1012 are passed to the user-mode graphics driver 1026 for compilation. In some embodiments, the user-mode graphics driver 1026 communicates with the kernel-mode graphics driver 1029 using operating system kernel-mode functions 1028. In some embodiments, the kernel-mode graphics driver 1029 communicates with the graphics processor 1032 to dispatch commands and instructions.

[0167] <IP Core Implementation> One or more aspects of at least one embodiment may be implemented by representative code stored on a machine-readable medium (also referred to herein as a computer-readable medium or a non-transitory computer-readable medium) that represents and / or defines logic within an integrated circuit such as a processor. For example, the machine-readable medium may include instructions that represent various logics within the processor. When read by a machine, the instructions may cause the machine to perform the techniques described herein. Such representations, known as “IP cores,” are reusable units of logic for an integrated circuit that can be stored on a tangible machine-readable medium, such as a hardware model that describes the structure of the integrated circuit. The hardware model may be supplied to various customers or manufacturing facilities that load the hardware model into a manufacturing machine that manufactures the integrated circuit. The integrated circuit may be manufactured to perform the operations described in connection with any of the embodiments described herein.

[0168] Figure 11A is a block diagram showing an exemplary IP core development system 1100 that may be used to manufacture an integrated circuit for performing operation according to one embodiment. The IP core development system 1100 may be used to generate a modular, reusable design that can be incorporated into a larger design or used to constitute an entire integrated circuit (e.g., a System of Control (SOC) integrated circuit). The design equipment 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 functional, behavioral, and / or timing simulations. An RTL (register transfer level) design 1115 may then be generated or synthesized from the simulation model 1112. The RTL design 1115 is an abstraction of the behavior of the integrated circuit that models the flow of digital signals between hardware registers, including the associated logic executed using the modeled digital signals. In addition to the RTL design 1115, low-level designs at the logic or transistor level may also be generated, designed, or synthesized. Therefore, specific details of the initial design and simulation may vary.

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

[0170] Figure 11B shows a side cross-sectional view of an integrated circuit package component 1170 according to several embodiments described in this specification. The integrated circuit package component 1170 represents one implementation of one or more processors or accelerator devices as described in this specification. The package component 1170 includes a plurality of units of hardware logic 1172, 1174 connected to a substrate 1180. The logic 1172, 1174 may be implemented in at least partially configurable logic or fixed-function logic hardware and may include one or more parts of any of the processor cores, graphics processors, or other accelerator devices described in this specification. Each unit of logic 1172, 1174 may be implemented in a semiconductor die and coupled to the substrate 1180 via an interconnection structure 1173. The interconnection structure 1173 may be configured to route electrical signals between the logic 1172, 1174 and the substrate 1180 and may include, but is not limited to, an interconnection structure such as a bump or pillar. In some embodiments, the interconnect structure 1173 may be configured to route electrical signals, such as input / output (I / O) signals and / or power or ground signals, associated with the operation of logic 1172, 1174. In some embodiments, the substrate 1180 is a resin-based laminate. In other embodiments, the substrate 1180 may include other suitable types of substrates. The package component 1170 may be connected to other electrical devices via the package interconnect 1183. The package interconnect 1183 may be coupled to the surface of the substrate 1180 to route electrical signals to other electrical devices such as a motherboard, other chipsets, or multichip modules.

[0171] In some embodiments, units of logic 1172 and 1174 are electrically coupled to a bridge 1182 configured to route electrical signals between logic 1172 and 1174. The bridge 1182 may be a high-density interconnect structure that provides the route for electrical signals. The bridge 1182 may include a bridge substrate made of glass or a suitable semiconductor material. The electrical routing function can be formed on the bridge substrate to provide inter-chip connectivity between logic 1172 and 1174.

[0172] While one logic unit 1172, 1174, and bridge 1182 are shown, 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, and bridge 1182 may be omitted when the logic is contained on a single die. Alternatively, multiple dies or logic units may be connected by one or more bridges. Furthermore, multiple logic units, dies, and bridges may be connected together in other possible configurations, including a three-dimensional configuration.

[0173] Figure 11C shows a package component 1190 containing multiple units of hardware logic chiplets connected to a substrate 1180 (e.g., a base die). Graphics processing units, parallel processors, and / or computing accelerators as described in this specification may consist of a variety of individually manufactured silicon chiplets. In this context, a chiplet is at least partially packaged integrated circuit containing individual logic units that can be assembled with other chiplets into a larger package. A variety of sets of chiplets with different IP core logic can be assembled into a single device. Furthermore, chiplets can be pre-interposed to a base die or base chiplet using active interposer technology. The concepts described in this specification enable interconnection and communication between different forms of IP within a GPU. IP cores can be manufactured using different process technologies and configured during manufacturing. This avoids the complexity of combining multiple IPs, particularly on a large SoC with several types of IP, into the same manufacturing process. Enabling the use of multiple process technologies improves time to market and provides a cost-effective way to generate multiple product SKUs. Furthermore, decentralized IP can be further modified to allow for independent power control, and components not being used in a given workload can be powered off, reducing overall power consumption.

[0174] The hardware logic chiplet may include a dedicated hardware logic chiplet 1172, a logic or I / O chiplet 1174, and / or a memory chiplet 1175. The hardware logic chiplet 1172 and the logic or I / O chiplet 1174 may be implemented in at least partially configurable logic or fixed-function logic hardware and may include one or more parts of the processor core, graphics processor, parallel processor, or other accelerator device described herein. The memory chiplet 1175 may be DRAM (e.g., GDDR, HBM) memory or cache (SRMA) memory.

[0175] Each chiplet may be manufactured as an individual semiconductor die and coupled to a substrate 1180 via an interconnect structure 1173. The interconnect structure 1173 may be configured to route electrical signals between various chiplets and logic within the substrate 1180. The interconnect structure 1173 may include, but is not limited to, bumps or pillars. In some embodiments, the interconnect structure 1173 may be configured to route electrical signals such as input / output (I / O) signals and / or power or ground signals associated with the operation of logic, I / O, and memory chiplets, for example.

[0176] In some embodiments, the substrate 1180 is a resin-based laminated substrate. In other embodiments, the substrate 1180 may include other suitable types of substrates. The package component 1190 may be connected to other electrical devices via a package interconnect 1183. The package interconnect 1183 may be coupled to the surface of the substrate 1180 to route electrical signals to other electrical devices such as a motherboard, other chipsets, or multi-chip modules.

[0177] In some embodiments, a logic or I / O chiplet 1174 and a memory chiplet 1175 may be electrically coupled via a bridge 1187 configured to route electrical signals between the logic or I / O chiplet 1174 and the memory chiplet 1175. The bridge 1187 may be a high-density interconnect structure that provides the route for electrical signals. The bridge 1187 may include a bridge substrate made of glass or a suitable semiconductor material. The electrical routing function can be formed on the bridge substrate to provide inter-chip connectivity between the logic or I / O chiplet 1174 and the memory chiplet 1175. The bridge 1187 may also be called a silicon bridge or interconnect bridge. For example, in some embodiments, the bridge 1187 is an EMIB (Embedded Multi-die Interconnect Bridge). In some embodiments, the bridge 1187 may simply be a direct connection from one chiplet to another.

[0178] The board 1180 may include hardware components for I / O 1191, cache memory 1192, and other hardware logic 1193. The fabric 1185 may be embedded within the board 1180 to enable communication between various logic chiplets and logic 1191, 1193 within the board 1180. In one embodiment, I / O 1191, fabric 1185, cache, bridge, and other hardware logic 1193 may be integrated into a base die stacked on top of the board 1180. The fabric 1185 may be a network-on-chip interconnect or another form of packet switching fabric that switches data packets between components of a package assembly.

[0179] In various embodiments, the package component 1190 may include fewer or more components and chiplets interconnected by a fabric 1185 or one or more bridges 1187. The chiplets within the package component 1190 may be configured in a 3D or 2.5D configuration. Typically, a bridge structure 1187 may be used, for example, to facilitate point-to-point interconnection between logic or I / O chiplets and memory chiplets. The fabric 1185 may be used to interconnect various logic and / or I / O chiplets (e.g., chiplets 1172, 1174, 1191, 1193) with other logic and / or I / O chiplets. In one embodiment, the onboard cache memory 1192 can operate as a global cache for the package component 1190, a portion of a distributed global cache, or a dedicated cache for the fabric 1185.

[0180] Figure 11D shows a package component 1194 including an interconnectable chiplet 1195 according to one embodiment. The interconnectable chiplet 1195 can be assembled in a standardized slot on one or more basic chiplets 1196, 1198. The basic chiplets 1196, 1198 can be coupled via a bridge interconnect 1197, similar to other bridge interconnects described in this specification and which may be, for example, an EMIB. Memory chiplets may also be connected to logic or I / O chiplets via the bridge interconnect. I / O and logic chiplets can communicate via the interconnect fabric. Each basic chiplet can support one or more slots in a standardized format for one of logic or I / O or memory / cache.

[0181] In one embodiment, the SRMA and power distribution circuit may be manufactured in one or more of the basic chiplets 1196, 1198, which can be manufactured using different process technologies than the interconnectable chiplet 1195 that is stacked on top of the basic chiplet. For example, the basic chiplets 1196, 1198 can be manufactured using a larger process technology, while the interconnectable chiplets can be manufactured using a smaller process technology. One or more of the interconnectable chiplets 1195 may be memory (e.g., DRAM) chiplets. Different memory densities can be selected for the package component 1194 based on the target power and / or performance for the product using the package component 1194. Furthermore, logic chiplets having different numbers of basic unit types can be selected at assembly based on the target power and / or performance for the product. In addition, chiplets containing different types of IP logic cores can be inserted into the interconnectable chiplet slot, enabling hybrid processor designs that can mix and harmonize IP blocks of different technologies.

[0182] <Example System-on-a-Chip Integrated Circuit> Figures 12-13B show exemplary integrated circuits and associated graphics processors that may be manufactured using one or more IP cores according to various embodiments described in this specification. In addition to those shown, other logic and circuitry may be included, including additional graphics processors / cores, peripheral interface processors / cores, or general-purpose processor cores.

[0183] Figure 12 is a block diagram showing an exemplary system-on-chip integrated circuit 1200 that may be manufactured using one or more IP cores according to one embodiment. The exemplary integrated circuit 1200 includes one or more application processors 1205 (e.g., CPUs), at least one graphics processor 1210, and may further include an image processor 1215 and / or a video processor 1220, any of which may be modular IP cores from the same or more different design equipment. The integrated circuit 1200 includes peripherals or bus logic, including a USB control unit 1225, a UART control unit 1230, an SPI / SDIO control unit 1235, and an I2S / I2C control unit 1240. Furthermore, the integrated circuit includes a display device 1245 coupled to one or more of the HDMI (high-definition multimedia interface) control unit 1250 and a MIPI (mobile industry processor interface) display interface 1255. Storage may be provided by a flash memory subsystem 1260, which includes flash memory and a flash memory control unit. The memory interface may be provided by the memory control unit 1265 for access to an SDRAM or SRAM memory device. Some integrated circuits further include an internal security engine 1270.

[0184] Figures 13A and 13B are block diagrams illustrating typical graphics processors for use within a SoC according to embodiments described in this specification. Figure 13A shows an example graphics processor 1310 of a system-on-chip integrated circuit that may be manufactured using one or more IP cores according to one embodiment. Figure 13B shows an additional example graphics processor 1340 of a system-on-chip integrated circuit that may be manufactured using one or more IP cores according to one embodiment. Graphics processor 1310 in Figure 13A is an example of a low-power graphics processor core. Graphics processor 1340 in Figure 13B is an example of a high-power graphics processor core. Graphics processors 1310 and 1340 may each be a variation of graphics processor 1210 in Figure 12.

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

[0186] The graphics processor 1310 further includes one or more memory management units (MMUs) 1320A-1320B, caches 1325A-1325B, and circuit interconnects 1330A-1330B. One or more MMUs 1320A-1320B provide virtual-to-physical address mapping to the graphics processor 1310, which includes vertex processors 1305 and / or fragment processors 1315A-1315N that can reference vertex or image / texture data stored in memory in addition to vertex or image / texture data stored in one or more caches 1325A-1325B. In one embodiment, one or more MMUs 1320A-1320B may be synchronized with other MMUs in the system, including one or more MMUs associated with one or more application processors 1205, image processor 1215, and / or video processor 1220 in Figure 12. As a result, each processor 1205-1220 can participate in a shared or integrated virtual memory system. One or more circuit interconnects 1330A-1330B enable the graphics processor 1310 to interact with other IP cores in the SoC, according to the embodiment, via the SoC's internal bus or via a direct connection.

[0187] As shown in Figure 13B, the graphics processor 1340 includes one or more MMUs 1320A-1320B, caches 1325A-1325B, and circuit interconnects 1330A-1330B of the graphics processor 1310. The graphics processor 1340 includes one or more shader cores 1355A-1355N (e.g., 1455A, 1355B, 1355C, 1355D, 1355E, 1355F-1355N-1, 1355N) that provide a unified shader core architecture. In the unified shader core architecture, a single core or type or core can execute all types of programmable shader code, including shader program code for implementing vertex shaders, fragment shaders, and / or compute shaders. The exact number of shader cores present may vary between embodiments and implementations. Furthermore, the graphics processor 1340 includes an intercore task manager 1345 that acts as a thread dispatcher, dispatching execution threads to one or more shader cores 1355A-1355N, and a tiling unit 1358 that accelerates tiling operations for tile-based rendering. In tile-based rendering, the rendering operation of the scene is subdivided in image space, for example, by utilizing local spatial coherence within the scene or optimizing the use of an internal cache.

[0188] In some embodiments, processing resources represent GPGPU cores, ray tracing cores, tensor cores, execution resources, execution units (EUs), stream processors, streaming multiprocessors (SMs), and graphics multiprocessors, related to processing elements (e.g., graphics processors or graphics processor structures within a GPU as described in this specification (e.g., parallel processing units, graphics processing engines, multicore groups, compute units, and compute units of graphics core nexts)). For example, processing resources may be one of the following: GPGPU cores or tensor / ray tracing cores of a graphics multiprocessor, ray tracing cores, tensor cores, or GPGPU cores of a graphics multiprocessor, execution resources of a graphics multiprocessor, one of the GFX cores, tensor cores, or ray tracing cores of a multicore group, one of the vector logic units or scalar logic units of a compute unit, an execution unit or EU array having an EU array, an execution unit of execution logic, and / or an execution unit. Processing resources may include, for example, a graphics processing engine, a processing cluster, a GPGPU, a GPGPU, a graphics processing engine, a graphics processing engine cluster, and / or execution resources within a graphics processing engine. Processing resources may also include processing resources within a graphics processor, a graphics processor, and / or a graphics processor.

[0189] <Tessellation redistribution to reduce processing delays> Parallel computing is a type of computing in which a large number of calculations or processes are performed independently. Parallel computing can take various forms, including, but not limited to, SIMD or SIMT. SIMD refers to a computer with multiple processing elements performing the same operation on multiple data points simultaneously. As an example, Figures 5A-5B above represent SIMD, which is implemented in a general-purpose processor in terms of EU, FPU, and ALU. In a typical SIMD machine, data is packaged in registers, each register containing an array of channels. An instruction acts on data found in channel n of a register and data found in the same channel of another register. SIMD machines are advantageous in areas where a single sequence of instructions can be applied simultaneously to large amounts of data. For example, in one embodiment, a graphics processor (e.g., GPGPU, GPU, etc.) can be used to perform SIMD vector operations using a compute shader program.

[0190] Various embodiments can be adapted to use execution by SMIT (Single Instruction Multiple Thread) as an alternative to or in addition to the use of SIMD. References to SIMD cores or operations can also be applied to SIMT, or to SIMD in combination with SIMT. The following description will be discussed in terms of SIMD machines. However, the embodiments in this specification are not limited to the SIMD context and may be applied to other parallel computing frameworks such as SIMT. For the sake of ease of discussion and explanation, the following description will generally focus on SIMD implementations. However, the embodiments can be similarly applied to SIMT machines without modification of the techniques and methods described. With respect to SIMT machines, similar patterns to those discussed below can be followed for providing instructions to a systolic array and for executing instructions on a SIMT machine. Other types of parallel computing machines may similarly utilize the embodiments described in this specification.

[0191] As mentioned above, providing competitive geometry processing performance in graphics processing units (GPUs) typically involves multiple, parallel, and simultaneous geometry processing fixed-function pipelines (GPPs). These GPPs (sometimes also called SMMs, geometry and configuration fixed-function pipelines, or pretessellation and posttessellation pipelines) include a mixture of programmable shaders and fixed-function stages in the OpenGL rendering pipeline (RP). In computer graphics, tessellation is used to manage polygonal datasets (also called vertex sets) representing objects in a scene and to divide them into a suitable structure for rendering. The advantage of tessellation over real-time graphics is that details can be dynamically added and subtracted from 3D polygonal meshes and their silhouette edges based on control parameters (e.g., camera distance). Tessellation involves subdividing patch primitives (also called "objects") and calculating the vertex values ​​of their vertices. The tessellation control shader may determine the amount of tessellation to be performed by specifying a tessellation coefficient. The number of vertices per patch may be defined at the application level. Patch objects may be triangles or quadrilaterals (squares).

[0192] Tessellation involves subdividing the parameter domain associated with an input patch primitive into triangular primitives and calculating the vertices at the tessellated domain points (which coincide with the angles of those triangular primitives). The input patch primitive may be associated with a triangular or quadrilateral parameter domain. A tessellation control shader may determine how finely the domain is subdivided into triangles by specifying a set of tessellation coefficients for each patch. A tessellation evaluation shader may then calculate the vertex values ​​using the set of input control points associated with the input patch primitive and the domain parameters at the tessellated domain points. The number of input control points associated with the patch primitive may be defined at the application level.

[0193] The challenge in parallel rendering graphics architectures is how to utilize parallel GPP and rendering and rasterization pipelines (RPs) while maintaining a strictly sequential 3D pipeline rendering model. A key challenge is the arbitrary mapping of application-supplied "object-space" geometry primitives to the rendered image during the rendering process. This is where the "Sort-Middle" architecture is more effectively used by the industry. In this approach, the GPU first performs complete geometry processing on an arbitrarily distributed subset ("batch") of object-space primitives using parallel GPP. The resulting screen-space primitives are then correctly rendered (i.e., sorted in time) and distributed to the RPs by a rasterization crossbar based on the screen-space region owned by each PR.

[0194] Increasing the number (N) of GPPs in the design typically involves using deeper buffers at the output of each GPP to provide sufficient GPP output buffers while the GPPs "wait their turn" to output to the rasterized crossbar. Here, the size of the GPP output buffer may be determined to match the average time it takes for the other (N-1) GPPs to discharge their batches to the crossbar. If sufficient buffers are not provided, the "waiting their turn" GPPs will quickly stall because they will not discharge, and when it is their turn they will output to the crossbar at the GPP processing rate (which is slower than the crossbar rate), so the overall geometry throughput tends to drop to the throughput of a single GPP.

[0195] The GPU's tessellation processing rate can be improved using local (on-die) tessellation work redistribution. Tessellation work redistribution avoids large on-die buffers and, because the distribution is local, also avoids the performance and power penalties incurred by using off-chip memory access. Instead of writing pre-tessellation results to memory and then redistributing those results across the tessellation pipeline, tessellation redistribution capabilities are used to directly distribute patches across the GPP tessellation stages without consuming off-chip memory bandwidth.

[0196] Existing approaches to tessellation work redistribution may relate to TTEs in GPP communication using a tessellation redistribution bus (TRB) that connects tessellation engines (TEs) in a communicative manner. Here, the TRB supports the redistribution of tessellation work to parallel GPPs while maintaining order. A tessellation distribution central engine (TED) is also used to pass control to the TEs within the GPP, enabling control of the TRB. The TEs communicate with the TED, sending tessellation work to the TED and releasing the TRB, while passing information about the next GPP that should control the TRB.

[0197] However, in existing approaches, TEDs can be located physically separate from individual TEs (which reside within the GPP). Communications related to passing control from one GPP to another, or to TEs waiting for previous tessellation work to be sent to a TED to be redistributed (before the TE processes the next tessellation work itself), involve long paths and introduce delays. These long paths and delays create idle time across the GPP.

[0198] For example, round-trip delays from TE to TED are unacceptable for streaming during switching from one GPP to another. Such streaming cannot occur, for example, when a TE has tessellation work that should be performed by the TE itself and tessellation work that is marked for redistribution by an interleaved TED. This problem is amplified when the TE frequently switches between tessellation work marked for distribution and tessellation work marked to be processed locally in the TE. Thus, each time a TE with TRB control has tessellation work that should be processed locally in the TE followed by tessellation work that should be distributed (to TED), or vice versa, idle periods may increase. This falls into the existing approach to tessellation work redistribution, resulting in a decrease in the overall utilization of the GPP and performance loss.

[0199] The embodiments solve the aforementioned drawbacks by providing tessellation redistribution that reduces latency in the processor. The tessellation redistribution of the embodiments divides the interaction from the TE to the TED of a GPP into an interaction from the TE front end (TEFE) to the TED and an interaction from the TE back end (TEBE) to the TED. In some embodiments, each TEFE of all GPPs interacting with the TED can send packets to the TED in parallel, while the TED processes such packets sequentially. Embodiments of the present specification further introduce motivation based on a distribution barrier between the TE and the TED to enable pipeline processing of tessellation work.

[0200] The embodiment offers the technical advantage of reducing latency within a processor such as a GPU and improving processor performance across GPPs that perform tessellation work redistribution by scheduling tessellation work across all GPPs in a streamlined manner and avoiding switching penalties associated with such scheduling within each GPP. Since the embodiment reduces latency associated with long paths between and between TEDs, the embodiment provides scalability of tessellation work redistribution when adding additional GPPs in a large SoC or multi-die processor.

[0201] Figure 14 is a block diagram showing an integrated circuit graphics processor 1400 having a fixed-function tessellation stage for tessellation redistribution to reduce latency, according to an embodiment. In the tenth layer, the graphics processor 1400 may include a GPGPU or GPU, such as the exemplary GPGPU and / or GPU described in this specification with respect to Figures 1-13.

[0202] The graphics processor 1400 shown in Figure 14 may include one or more fixed-function tessellation stages, which are divided into tessellation front-end (TEFE) logic circuits 1410A to 1410N (collectively referred to as TEFE1410) that perform patch culling and patch transmission, and tessellation back-end (TEBE) logic circuits 1415A to 1415N (collectively referred to as TEBE1415) that perform patch reception and patch tessellation. The GPP tessellation engine (TE) may include a combination of TEFE1410 and TEBE1415. For example, the first TE of the GPP of graphics processor 1400 may include TEFE1 1410A and TEBE1 1415A, the second TE of the second GPP of graphics processor 1400 may include TEFE2 1410B and TEBE2 1415B, and so on, until the Nth TE includes TEFEN 1410N and TEBEN 1415N. The combination of the tessellation redistribution bus (TRB) 1420 and the tessellation redistribution central engine (TED) 1040 performs patch redistribution from TEFE11401 of the source GPP to TEBE1415 of one or more destination GPPs.

[0203] GPPs can be assigned sequential GPP identifiers (IDs) based on criteria such as their location within the floor plan. Alternatively, GPP IDs may be loaded with programmable values, for example, after a device reset. Each GPP may recognize its own GPP ID. In one implementation, these GPP IDs establish a sequential order of GPPs, which forms a cycle of GPP IDs encompassing the highest-numbered GPPs to the lowest-numbered GPPs. However, other ordering schemes can also be implemented.

[0204] In implementations, one or more or parts of TEFE1410, TEBE1415, TRB1420, and TED1440 can be implemented by processing resources such as execution units (EUs). Processing resources such as EUs may include programmable logic or circuitry, such as a logic core or multiple cores, which can provide a broad array of programmable logic functions. In implementations, one or more or parts of TEFE1410, TEBE1415, TRB1420, and TED1440 are implemented by dedicated hardware, such as fixed-function circuits. Fixed-function circuits may include dedicated logic or circuitry and may provide a set of fixed-function entry points that can be mapped to dedicated logic for a fixed purpose or function.

[0205] The tessellation redistribution provided by processor 1400 is expected to provide benefits by rebalancing the TEs before tessellation, as each patch and GPP may introduce a variable amount of work. To maintain the order of work, synchronous communication is used between TEFE1410 and TEBE1415 via TED1440. As mentioned above, in the case of large GPUs, delays from TEFE1410 to TED1440 and from TED1440 to TEBE1415 can be significant. This can result in performance loss if frequent switching is used. Also, if TEFE1410 has a batch of tessellation work that can be processed locally, it has the ability to send a control packet (containing information about the next TE) to TED1440 while processing that batch itself. Here again, performance can be improved if this control packet reaches TED1440 as quickly as possible.

[0206] In some embodiments, the tessellation redistribution provided by the processor 1400 allows each TEFE 1410 of all GPPs interacting with TED 1440 to send packets to TED 1440 in parallel. While packets may be received in parallel at TED 1440, TED 1440 processes such packets sequentially according to a sequence that determines the order of processing for the GPPs. In embodiments, one or more of TEFE 1410A-1410N may have tessellation work marked for distribution. These TEFE 1410A-1410N with tessellation work marked for distribution can communicate with TED 1440 in parallel with each other. TED 1440 is responsible for processing traffic from each TEFE 1410A-1410N sequentially. In conventional approaches, a TEFE 1410 had to wait until it received a signal that TED 1440 was ready to receive communication from a particular TEFE 1410. In contrast, the embodiment allows TEFE1410 to send tessellation work to TED1440, eliminating the need for TED1440 to wait for its turn in the TEFE sequence order it adheres to.

[0207] In some implementations, the TED1440 may include a queue-like memory structure used to queue received patch submissions (e.g., tessellation work) marked for distribution received from the TEFE1410. The TEFE1410 may process the queued patch submissions in a sequential order. This sequential order is defined by a determined sequence of parallel interconnect geometry fixed function units.

[0208] The embodiment further provides synchronization based on a distribution barrier between the TEs (including TEFE1410 and TEBE1415) and TED1440, enabling pipeline processing of tessellation work. Selection circuits 1430A-1430N (e.g., multiplexers (mux)) may be implemented by each TE as control logic that manages the processing of tessellation work by TEBE1415A-1415N. Selection lines 1435A-1435N for switching between patch traffic coming from TED1440 and patch traffic coming directly from TEFE1410 utilize communication from TEFE1410 to TED1440 and communication from TED1440 to TEBE1415.

[0209] In some embodiments, following the transmission of tessellation work marked for distribution to TED1440, if TEFE1410 receives additional tessellation work marked for local processing (e.g., to be sent directly to TEBE1415), TEFE1410 may push this tessellation work marked for local processing to intermediate storage (e.g., a first-in, first-out (FIFO) queue) along with a marker indicating that TEBE1415 should wait for a synchronous barrier packet to be received from TED1440 before processing this work.

[0210] When such tessellation work is sent to intermediate storage (for example, while other tessellation work is withheld from distribution to TED1440), TEFE1410 also sends a synchronous barrier packet to TED1440. Once the synchronous barrier packet is received and processed by TED1440, TED1440 may broadcast it to all TEBE1415s. This synchronous barrier packet is received by the TEBE1415 corresponding to its own TEFE1410, while other TEBE1415s drop it. In one implementation, the synchronous barrier packet contains an identifier (ID) of the TE that generated the synchronous barrier packet. TEBE1415 can use this ID in the synchronous barrier packet to decide whether to process or drop the synchronous barrier packet.

[0211] Regarding the operation of TEBE1415, TEBE1415 waits for communication from TED1440. TEBE1415 receives work from TED1440 that TEBE1415 can perform, or it receives control commands indicating that it can process traffic coming directly from TEFE1410. Furthermore, when TEBE1415 receives work from TEFE1410 with a marker indicating that it should wait for a synchronous barrier packet, TEBE1415 can read work or control packets from TED1440 until it receives a synchronous barrier packet. When TEBE1415 receives communication from TED1440 indicating that TEBE1415 should process local traffic, it begins processing the complete batch of work transferred from TEFE1410 to intermediate storage.

[0212] In some implementations, if all tessellation work in a batch processed by the TEFE1410 is marked as needing to be processed locally, the TEFE1410 can immediately send control cycles to the TED1440. The TEFE1410 may also have multiple such batches marked as local, and the TEFE1410 can immediately send the number of control cycles corresponding to each batch to the TED1440. In step 7, the TEFE1410 can begin moving the work to intermediate storage (e.g., a local FIFO queue).

[0213] Figure 15 is a block diagram showing a tessellation redistribution system 1500 having a tessellation engine for tessellation redistribution with reduced latency, according to an embodiment. In one implementation, the tessellation redistribution system 1500 may include a GPGPU or GPU, such as the exemplary GPGPU and / or GPU described in this specification with respect to Figures 1-13. In one implementation, the tessellation redistribution system 1500 includes a tessellation engine 1505 that is communicatively coupled to a TRB 1550 (communicating with TED) and has TEFE 1510 and TEBE 515. TEFE 1510 and TEBE 1515 may be the same as TEFE 1410A-N and TEBE 1415A-N described with respect to Figure 14, respectively. TRB 1550 may be the same as TRB 1420 described with respect to Figure 14.

[0214] As shown in the figure, TE1505 may include TEFE1510, front-end patch control selection circuit 1520, intermediate storage 1530, back-end patch control selection circuit 1540, TEBE1515, distribution storage 1570, and distribution circuit 1560. TE1505 may include more or fewer components than those described in this specification. In one implementation, the front-end patch control selection circuit 1520, the back-end patch control selection circuit 1540, and / or the distribution circuit 1560 may each implement a finite state machine (FSM). The front-end patch control selection circuit 1520 may manage forward transmission to TED by TRB1550 as described above.

[0215] In embodiments of this specification, the front-end patch control selection circuit 1520 may forward patch transmissions to TED via TRB 1550 as soon as they are received from TEFE 1510, without waiting to receive a signal from TED to forward such patch transmissions. These forwarded patch transmissions are queued by TED for later processing according to a determined order.

[0216] In some implementations, the intermediate storage 1530 may receive local tessellation work (e.g., marked for local processing) pushed to the intermediate storage 1530 by the front-end patch control selection circuit 1520. In one implementation, the intermediate storage 1530 may be the local FIFO of TE1505. As discussed with respect to Figure 14, tessellation work pushed to the intermediate storage may be marked by a synchronization barrier bit. This bit indicates that such work is related to a synchronization barrier packet sent to TED by TEFE1510 (or, in some implementations, the front-end patch control selection circuit 1520).

[0217] The backend patch control selection circuit 1540 manages control signals (for example, control selection lines for mux 1430A~N as described in Figure 14) based on messages received from TEFE 1410 / frontend patch control selection circuit 1520 and messages received from TED (for example, via the distribution circuit 1560 described later). Based on the received messages, the backend patch control selection circuit 1540 may toggle the control signals to cause TEBE 1515 to process tessellation work received from intermediate storage 1530 or from TED via distribution storage 1570.

[0218] In some implementations, the distribution memory 1570 may be a FIFO queue that receives and stores tessellation work transmitted by TED. The distribution circuit 1560 may operate to receive and process control messages, such as synchronous barrier packets, transmitted by TED (via TRB1550). For example, the distribution circuit 1560 may implement an FSM that accepts and passes synchronous barrier packets broadcast by TED having an ID corresponding to TE1505, while dropping synchronous barrier packets that do not contain the ID of TE1505. The distribution circuit 1560 may have the tessellation work distributed by TE push to the distribution memory 1570 for subsequent processing by TEBE1515. As described above, TEBE1515 retrieves and processes work from the distribution memory 1570 in response to a control signal from the backend patch control selection circuit that prompts TEBE1515 to start processing the tessellation work.

[0219] Figure 16 is a flowchart illustrating an embodiment of a method for tessellation redistribution to reduce latency within a processor. Method 1600 may be performed by processing logic that may include hardware (e.g., circuits, dedicated logic, programmable logic, etc.), software (e.g., instructions executed on the processing unit), or a combination thereof. The processing of Method 1600 is shown in a linear sequence for simplicity and clarity of representation. However, it is conceivable that any number of these can be executed in parallel, asynchronously, or in different orders. Furthermore, for simplicity, clarity, and ease of understanding, many of the components and processes discussed with reference to Figures 1-17 are repeated or not discussed below. In one implementation, a processor such as processor 1400 in Figure 14, or a processor including a tessellation engine (TE) 1505 in Figure 15, may perform Method 1600.

[0220] Method 1600 begins in processing block 1610, where the processor may provide a parallel interconnected geometry fixed function unit having separate front-end and back-end components. In one implementation, the front-end performs patch culling and transmission, while the back-end performs patch reception and patch tessellation from the front-end. In processing block 1620, the processor provides a tessellation redistribution central engine, which redistributes patches among the back-ends using a redistribution bus provided between the front-end and back-ends.

[0221] Next, in processing block 1630, the processor may receive patch transmissions marked for distribution from the frontends in parallel via the tessellation redistribution central engine. In one implementation, the tessellation redistribution engine processes the patch transmissions sequentially. Finally, in processing block 1640, the processor may broadcast via the tessellation redistribution central engine in response to receiving a synchronous barrier packet from one of the frontends. In one implementation, the synchronous barrier packet to the backend causes one of the backends to process the tessellation work locally.

[0222] Figure 17 is a flowchart illustrating an embodiment of Method 1700 of a TEFE that performs tessellation redistribution to reduce latency within a processor. Method 1700 may be performed by processing logic that may include hardware (e.g., circuits, dedicated logic, programmable logic, etc.), software (e.g., instructions executed on the processing unit), or a combination thereof. The processing of Method 1700 is shown in a linear sequence for simplicity and clarity of representation. However, it is conceivable that any number of these can be executed in parallel, asynchronously, or in different orders. Furthermore, for simplicity, clarity, and ease of understanding, many of the components and processes discussed with reference to Figures 1-17 are repeated or not discussed below. In one implementation, a processor's TEFE, such as TEFE1410 in Figure 14 or TEFE1510 in Figure 15, may perform Method 1700.

[0223] Method 1700 begins in processing block 1710, where the processing unit may receive a patch from TEFE 1410 for processing by the tessellation engine. In processing block 1720, TEFE may discard the patch in response to determining that the patch should be culled.

[0224] Next, in decision block 1730, the TEFE may decide whether the patch is to be processed locally. If so, method 1700 proceeds to processing block 1740, where the TEFE may send the patch to the tessellation engine's intermediate storage and mark the synchronization barrier bit in the entry corresponding to the patch in the intermediate storage. Subsequently, in processing block 1750, the TEFE may send a synchronization barrier packet with the ID of the tessellation engine to the tessellation redistribution central engine.

[0225] On the other hand, if in decision block 1730 TEFE 1410 determines that the patch will not be processed locally (for example, marked for distribution to TED), method 1700 may proceed to processing block 1760. In processing block 1760, TEFE may send the patch to the tessellation redistribution central engine via the redistribution bus.

[0226] Figure 18 is a flowchart illustrating an embodiment of Method 1800 of the TEBE, which performs tessellation redistribution to reduce latency within the processor. Method 1800 may be performed by processing logic that may include hardware (e.g., circuits, dedicated logic, programmable logic, etc.), software (e.g., instructions executed on the processing unit), or a combination thereof. The processing of Method 1800 is shown in a linear sequence for simplicity and clarity of representation. However, it is conceivable that any number of these can be executed in parallel, asynchronously, or in different orders. Furthermore, for simplicity, clarity, and ease of understanding, many of the components and processes discussed with reference to Figures 1-17 are repeated or not discussed below. In one implementation, a processor's TEBE, such as TEBE1415 in Figure 14 or TEBE1515 in Figure 15, may perform Method 1800.

[0227] Method 1800 begins in processing block 1810, where the processor may receive a patch marked for local processing in the tessellation engine, which has a marker indicating a synchronous barrier packet associated with the patch. In one implementation, the patch is maintained in the tessellation engine's intermediate storage. In processing block 1820, the TEBE reads from the front end any work not marked by a synchronous barrier packet or control packet from the tessellation redistribution central engine, while the received patch is held in intermediate storage.

[0228] Next, in processing block 1830, TEBE may receive a synchronous barrier packet from the tessellation redistribution central engine, marked by the ID of the tessellation engine. Finally, in processing block 1840, TEBE may process a patch from the intermediate storage in response to receiving the synchronous barrier packet.

[0229] The following examples relate to further embodiments. Example 1 is a device that performs tessellation redistribution to reduce latency within a processor. (Example 1) A device, Includes a processor, the processor is A parallel interconnect geometry fixing function unit is provided, having separate front-end and back-end components, the front-end performing patch culling and transmission, and the back-end performing patch reception and patch tessellation from the front-end. A tessellation redistribution central engine is provided that redistributes patches between the backends using a redistribution bus provided between the frontend and the backend. The tessellation redistribution central engine receives patch transmissions marked for distribution in parallel from the front end, and the tessellation redistribution engine processes the patch transmissions sequentially. A device that, in response to receiving a synchronous barrier packet from one of the frontends, broadcasts the synchronous barrier packet to the backends via the tessellation redistribution central engine, causing one of the backends to process the tessellation work locally.

[0230] (Example 2) The device according to Example 1, wherein optionally, the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read the tessellation work from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the tessellation work read from the intermediate storage.

[0231] (Example 3) The device according to Example 1 or 2, wherein the synchronous barrier packet optionally includes an identifier (ID) of the parallel interconnect geometry fixing function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process the synchronous barrier packet or drop it.

[0232] (Example 4) Optionally, the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronous barrier bit set in response to a tessellation operation stored in the entry associated with the synchronous barrier packet, as described in any of Examples 1 to 3.

[0233] (Example 5) Optionally, the front-end pushes tessellation work marked for local processing to the intermediate storage, as described in any of Examples 1 to 4.

[0234] (Example 6) Optionally, each of the parallel interconnect geometry fixed function units includes a corresponding intermediate memory, as described in any of Examples 1 to 5.

[0235] (Example 7) The apparatus according to any one of Examples 1 to 6, wherein each of the parallel interconnect geometry fixing function units optionally includes a selection circuit for switching a control signal to each of the corresponding backends to process tessellation work from either the intermediate storage or the redistribution bus.

[0236] (Example 8) Optionally, the tessellation redistribution central engine queues the patch transmissions marked for distribution received from the front end, processes the queued patch transmissions in order, the order of which is determined by a predetermined sequence of the parallel interconnect geometry fixed function units, as described in any of Examples 1 to 7.

[0237] (Example 9) Optionally, the processor is the device described in any of Examples 1 to 8, which includes a graphics processing unit (GPU).

[0238] (Example 10) Optionally, the device is at least one of a single-instruction multiple data (SIMD) machine or a single-instruction multiple thread (SIMT) machine, as described in any of Examples 1 to 9.

[0239] (Example 11) A method for performing tessellation redistribution to reduce latency within a processor, The processor provides a parallel interconnect geometry fixed function unit having separate front-end and back-end components, wherein the front-end performs patch culling and transmission, and the back-end performs patch reception and patch tessellation from the front-end. The steps include providing a tessellation redistribution central engine that redistributes patches among the backends of the parallel interconnect geometry fixing function unit using a redistribution bus provided between the frontend and the backend, The steps include: receiving patch transmissions marked for distribution from the front end in parallel by the tessellation redistribution central engine, wherein the tessellation redistribution engine processes the patch transmissions sequentially; In response to receiving a synchronous barrier packet from one of the frontends, the tessellation redistribution central engine broadcasts the synchronous barrier packet to the backends, the step of causing one of the backends to process the tessellation work locally. A method that includes this.

[0240] (Example 12) The method according to Example 11, optionally the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read the tessellation work from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the tessellation work read from the intermediate storage.

[0241] (Example 13) The device according to Example 11 or 12, optionally the synchronous barrier packet includes an identifier (ID) of the parallel interconnect geometry fixed function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process the synchronous barrier packet or drop it.

[0242] (Example 14) Optionally, the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronous barrier bit set in response to a tessellation operation stored in the entry associated with the synchronous barrier packet, as described in any of Examples 11 to 13.

[0243] (Example 15) The method according to any one of Examples 11 to 14, wherein each of the parallel interconnect geometry locking function units optionally includes a corresponding intermediate memory, and each of the parallel interconnect geometry locking function units includes a selection circuit for switching a control signal to each of the corresponding backends to process tessellation work from either the intermediate memory or the redistribution bus.

[0244] (Example 16) Optionally, the tessellation redistribution central engine queues the patch transmissions marked for distribution received from the front end, The steps include: processing the queued patch transmissions sequentially using the tessellation redistribution central engine, wherein the order is determined by a predetermined sequence of the parallel interconnect geometry fixing function units; The method described in Examples 11-15, which further includes the above.

[0245] Example 17 is a non-temporary computer-readable medium for performing tessellation redistribution to reduce latency within a processor. (Example 17) A non-temporary computer-readable medium capable of having instructions, wherein, when the instructions are executed by one or more processors, the processors A parallel interconnect geometry fixed function unit having separate front-end and back-end components is provided, the front-end performs patch culling and transmission, and the back-end performs patch reception and patch tessellation from the front-end. A tessellation redistribution central engine is provided that redistributes patches among the backends of the parallel interconnect geometry fixing function unit using a redistribution bus provided between the frontend and the backend. The tessellation redistribution central engine receives patch transmissions marked for distribution from the front end in parallel, and the tessellation redistribution engine processes the patch transmissions sequentially. A non-temporary computer-readable medium that, in response to receiving a synchronous barrier packet from one of the front-ends, causes the tessellation redistribution central engine to broadcast the synchronous barrier packet to the back-ends, causing one of the back-ends to process the tessellation work locally.

[0246] (Example 18) The non-temporary computer-readable medium according to Example 17, optionally the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read the tessellation work from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the tessellation work read from the intermediate storage.

[0247] (Example 19) Optionally, the synchronous barrier packet includes an identifier (ID) of the parallel interconnect geometry fixed function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process or drop the synchronous barrier packet, in the non-temporary computer-readable medium as in Example 17 or 18.

[0248] (Example 20) Optionally, the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronization barrier bit set in response to a tessellation operation stored in the entry associated with the synchronization barrier packet, as described in any of Examples 17-19.

[0249] Example 21 is a system that performs tessellation redistribution to reduce latency within the processor. (Example 21) A system, It includes memory and one or more processors of multiple GPUs, The one or more processors described above are: The memory is connected in a communicative manner, A parallel interconnect geometry fixing function unit is provided, having separate front-end and back-end components, the front-end performing patch culling and transmission, and the back-end performing patch reception and patch tessellation from the front-end. A tessellation redistribution central engine is provided that redistributes patches between the backends using a redistribution bus provided between the frontend and the backend. The tessellation redistribution central engine receives patch transmissions marked for distribution in parallel from the front end, and the tessellation redistribution engine processes the patch transmissions sequentially. In response to receiving a synchronous barrier packet from one of the frontends, the tessellation redistribution central engine broadcasts the synchronous barrier packet to the backends, causing one of the backends to process the tessellation work locally. system.

[0250] (Example 22) The system according to Example 21, wherein optionally, the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read the tessellation work from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the tessellation work read from the intermediate storage.

[0251] (Example 23) The system according to Example 21 or 22, wherein the synchronous barrier packet optionally includes an identifier (ID) of the parallel interconnect geometry fixed function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process the synchronous barrier packet or drop it.

[0252] (Example 24) Optionally, the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronous barrier bit set in response to a tessellation operation stored in the entry associated with the synchronous barrier packet, as described in any of Examples 21-23.

[0253] (Example 25) Optionally, the front-end pushes tessellation work marked for local processing to the intermediate storage, as described in any of Examples 21-24.

[0254] (Example 26) Optionally, each of the parallel interconnected geometry fixed function units includes a corresponding intermediate memory, as described in any of Examples 21-25.

[0255] (Example 27) The system according to any one of Examples 21 to 26, wherein each of the parallel interconnect geometry fixed function units optionally includes a selection circuit for switching a control signal to each of the corresponding backends to process tessellation work from either the intermediate storage or the redistribution bus.

[0256] (Example 28) Optionally, the tessellation redistribution central engine queues the patch transmissions marked for distribution received from the front end, processes the queued patch transmissions in order, the order of which is determined by a predetermined sequence of the parallel interconnect geometry fixed function units, as described in any of Examples 21-27.

[0257] (Example 29) Optionally, the system described in any of Examples 21 to 28, wherein the processor includes a graphics processing unit (GPU).

[0258] (Example 30) Optionally, the system according to any one of Examples 21 to 29, wherein the device is at least one of a single-instruction multiple data (SIMD) machine or a single-instruction multiple threads (SIMT) machine.

[0259] (Example 31) A device that performs tessellation redistribution to reduce latency within a processor, Means for providing a parallel interconnect geometry fixed function unit having separate front-end and back-end, wherein the front-end performs patch culling and transmission, and the back-end performs patch reception and patch tessellation from the front-end, A means for providing a tessellation redistribution central engine that redistributes patches among the backends of the parallel interconnect geometry fixing function unit using a redistribution bus provided between the frontend and the backend, Means for receiving, in parallel from the front end, patch transmissions marked for distribution by the tessellation redistribution central engine, the tessellation redistribution engine processing the patch transmissions in order, Means for broadcasting, by the tessellation redistribution central engine, a synchronization barrier packet to the back end in response to receiving the synchronization barrier packet from one of the front ends, causing one of the back ends to locally process a tessellation operation, A device including the above.

[0260] (Example 32) Optionally, the device of Example 31 is further configured to execute the method according to any one of Examples 12 to 16.

[0261] (Example 33) At least one machine-readable medium including a plurality of instructions, the instructions causing a computing device to execute the method according to any one of Examples 11 to 16 in response to being executed on the computing device.

[0262] (Example 34) A device performing tessellation redistribution to reduce latency in a processor, the device being configured to execute the method according to any one of Examples 11 to 16.

[0263] (Example 35) A device performing tessellation redistribution to reduce latency in a processor, the device including means for executing the method according to any one of Examples 11 to 16. Specific matters in the examples may be used anywhere in one or more embodiments.

[0264] The foregoing description and drawings should be considered in an illustrative rather than a limiting sense. Those skilled in the art will understand that various modifications and changes can be made to the embodiments described herein without departing from the broad spirit and scope of the features recited in the appended claims.

Description of Reference Numerals

[0265] 100 Processing System 102 Processor 104 Cache 106 Register File 107 Processor Core 108 Graphics Processor 109 Instruction Set 110 Interface Bus 111 Display Device 112 Accelerator 116 Memory Control Unit 118 External Graphics Processor 119 External Accelerator 120 Memory Device 121 Instruction 122 Data 124 Data Storage Device 125 Touch Sensor 126 Wireless Transceiver 128 Firmware Interface 130 Platform Control Hub 134 Network Control Unit 140 Legacy I / O Control Unit 142 USB Control Unit 143 Keyboard / Mouse 144 Camera 146 Audio Control Unit

Claims

1. It is a device, Includes a processor, the processor is Multiple parallel interconnect geometry fixing function units are provided, each having a separate front-end and back-end. The front-end performs patch culling and patch transmission, and the back-end performs patch reception and patch tessellation from the front-end. A tessellation redistribution central engine is provided that redistributes patches between the backends using a redistribution bus provided between the frontend and the backend. The tessellation redistribution central engine receives patch transmissions marked for distribution in parallel from the front end, and the tessellation redistribution central engine processes the patch transmissions sequentially. In response to receiving a synchronous barrier packet from one of the frontends, the tessellation redistribution central engine broadcasts the synchronous barrier packet to the backends, causing one of the backends to perform patch tessellation locally. device.

2. The device according to claim 1, wherein the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read a patch from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the patch read from the intermediate storage.

3. The apparatus according to claim 2, wherein the synchronous barrier packet includes an identifier (ID) of the parallel interconnect geometry fixing function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process the synchronous barrier packet or drop it.

4. The device according to claim 2, wherein the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronization barrier bit set in response to a patch stored in the entry associated with the synchronization barrier packet.

5. The apparatus according to claim 2, wherein the front end pushes patches marked for local processing to the intermediate storage.

6. The apparatus according to claim 1, wherein each of the parallel interconnect geometry fixing function units includes a corresponding intermediate storage.

7. The apparatus according to claim 6, wherein each of the parallel interconnect geometry fixing function units includes a selection circuit for switching a control signal to each of the backends to perform patch tessellation on a patch from either the intermediate storage or the redistribution bus.

8. The apparatus according to claim 1, wherein the tessellation redistribution central engine queues the patch transmissions marked for distribution received from the front end, processes the queued patch transmissions in order, the order of which is determined by a predetermined sequence of the parallel interconnect geometry fixing function units.

9. The apparatus according to claim 1, wherein the processor is a graphics processing unit (GPU).

10. The device according to claim 1, wherein the device is at least one of a single-instruction multiple data (SIMD) machine or a single-instruction multiple threads (SIMT) machine.

11. It is a method, The processor provides a plurality of parallel interconnect geometry fixed function units, each having a separate front-end and back-end, wherein the front-end performs patch culling and patch transmission, and the back-end performs patch reception and patch tessellation from the front-end. The steps include providing a tessellation redistribution central engine that redistributes patches among the backends of the parallel interconnect geometry fixing function unit using a redistribution bus provided between the frontend and the backend, The steps include: receiving patch transmissions marked for distribution from the front end in parallel by the tessellation redistribution central engine, wherein the tessellation redistribution central engine processes the patch transmissions sequentially; In response to receiving a synchronous barrier packet from one of the frontends, the tessellation redistribution central engine broadcasts the synchronous barrier packet to the backends, the step of causing one of the backends to perform patch tessellation locally. A method that includes this.

12. The method according to claim 11, wherein the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read a patch from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the patch read from the intermediate storage.

13. The method according to claim 12, wherein the synchronous barrier packet includes an identifier (ID) of the parallel interconnect geometry fixing function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process the synchronous barrier packet or drop it.

14. The method according to claim 12, wherein the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronization barrier bit set in response to a patch stored in the entry associated with the synchronization barrier packet.

15. The method according to claim 11, wherein each of the parallel interconnect geometry fixing function units includes a corresponding intermediate memory, and each of the parallel interconnect geometry fixing function units includes a selection circuit for switching a control signal to each of the backends to perform patch tessellation on a patch from either the intermediate memory or the redistribution bus.

16. The steps include: queuing the patch transmissions marked for distribution received from the front end by the tessellation redistribution central engine; The steps include: processing the queued patch transmissions sequentially using the tessellation redistribution central engine, wherein the order is determined by a predetermined sequence of the parallel interconnect geometry fixing function units; The method according to claim 11, further comprising:

17. A system that performs tessellation redistribution to reduce latency within the processor, It includes memory and one or more processors of multiple GPUs, The one or more processors described above are: The memory is connected in a communicative manner, Multiple parallel interconnect geometry fixing function units are provided, each having a separate front-end and back-end. The front-end performs patch culling and patch transmission, and the back-end performs patch reception and patch tessellation from the front-end. A tessellation redistribution central engine is provided that redistributes patches between the backends using a redistribution bus provided between the frontend and the backend. The tessellation redistribution central engine receives patch transmissions marked for distribution in parallel from the front end, and the tessellation redistribution central engine processes the patch transmissions sequentially. In response to receiving a synchronous barrier packet from one of the frontends, the tessellation redistribution central engine broadcasts the synchronous barrier packet to the backends, causing one of the backends to perform patch tessellation locally. system.

18. The system according to claim 17, wherein the synchronous barrier packet causes one of the backends corresponding to the synchronous barrier packet to read a patch from the intermediate storage corresponding to one of the backends, and one of the backends performs the patch tessellation on the patch read from the intermediate storage.

19. The system according to claim 17 or 18, wherein the synchronous barrier packet includes an identifier (ID) of the parallel interconnect geometry fixing function unit that generated the synchronous barrier packet, and the backend uses the ID to determine whether to process the synchronous barrier packet or drop it.

20. The system according to claim 18, wherein the intermediate storage is a first-in, first-out (FIFO) queue, and each entry in the FIFO queue includes a synchronization barrier bit set in response to a patch stored in the entry associated with the synchronization barrier packet.

21. The system according to claim 18 or 20, wherein the front end pushes patches marked for local processing to the intermediate storage.

22. The system according to any one of claims 17 to 21, wherein each of the parallel interconnect geometry fixing function units includes a corresponding intermediate memory.

23. The system according to any one of claims 18, 20, or 22, wherein each of the parallel interconnect geometry fixing function units includes a selection circuit for switching a control signal to each of the backends to perform patch tessellation on patches from either the intermediate storage or the redistribution bus.

24. A machine-readable storage medium comprising a plurality of instructions, wherein the instructions, in response to being executed on a computing device, cause the computing device to perform the method according to any one of claims 11 to 16.

25. A device for performing tessellation redistribution to reduce latency within a processor, comprising means for performing the method according to any one of claims 11 to 16.

Images