Zero clear scalar shift

Abstract

Techniques for zero clear scalar shift are described. For example, one or more instructions are supported that, when executed, are used to cause a scalar shift of a 16-bit or 32-bit floating point value from a source to a destination. When the destination is a vector register, all other data elements are to be zeroed.

Description

Background Art

[0001] Data is often moved from memory to registers to perform calculations. Some of those registers may hold multiple values, called vectors, or single data, called scalars, which may occupy a specified one of the vector elements, such as the lowest vector element of the register. These registers that may hold multiple values ​​may be referred to as packed data registers. When working with scalar values ​​in packed data registers, it is often convenient to know that the remaining vector elements have specific values, such as zero, so that vector operations will have predictable behavior. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples of the present disclosure will be described with reference to the accompanying drawings, in which:

[0003] Figure 1 An example of execution of a zero clear move instruction is illustrated.

[0004] Figure 2(A)-Figure 2(C) An example of execution of a zero clear move instruction is illustrated.

[0005] Figure 3 An example of execution circuitry for executing a move instruction is shown.

[0006] Figure 4 Figure 1 shows an example of a zero clear move instruction.

[0007] Figure 5 Illustrate examples of prefixes used by zero-clear move instructions.

[0008] Figure 6 An example method performed by a processor to process a zero clear move instruction is illustrated.

[0009] Figure 7 and Figure 8 An example of pseudo code for execution of a zero clear move instruction is illustrated.

[0010] Fig. 9 An example computing system is illustrated.

[0011] Fig.10 A block diagram illustrating an example processor and / or System on a Chip (SoC) that may have one or more cores and an integrated memory controller.

[0012] Fig.11 is a block diagram illustrating a computing system configured to implement one or more aspects of the examples described herein.

[0013] Fig. 12A Figure 1 shows an example of a parallel processor.

[0014] Fig. 12BAn example of a block diagram of a partition unit is illustrated.

[0014] Fig. 12C An example of a block diagram illustrating a processing cluster within a parallel processing unit.

[0016] Fig.12D An example of a graphics multiprocessor is illustrated, wherein the graphics multiprocessor is coupled with a pipeline manager of a processing cluster.

[0017] Figure 13A-13C Additional graphics multiprocessors are illustrated according to examples.

[0018] Fig.14 A parallel computing system according to some examples is shown.

[0019] Figure 15A-15B Illustrated is a hybrid logical / physical view of a factorized parallel processor according to examples described herein.

[0020] 16(A) is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example.

[0021] 16(B) is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example.

[0022] Fig.17 Examples of execution unit circuitry, such as execution unit circuitry, are illustrated.

[0023] Fig.18 is a block diagram of a register architecture according to some examples.

[0024] Fig.19 An example of the instruction format is shown.

[0025] Fig. 20 Figure 1 shows an example of an addressing information field.

[0026] Figure 21A-21B Thread execution logic including an array of processing elements employed in a graphics processor core is illustrated according to examples described herein.

[0027] Fig. 22 Additional execution units are illustrated according to an example.

[0028] Fig.23 is a block diagram illustrating a graphics processor instruction format according to some examples.

[0029] Fig.24 is a block diagram of another example of a graphics processor.

[0030] Fig.25A is a block diagram illustrating a graphics processor command format according to some examples.

[0031] Fig.25B is a block diagram illustrating a graphics processor command sequence according to an example.

[0032] Fig.26 is a block diagram illustrating converting binary instructions in a source ISA to binary instructions in a target ISA using a software instruction converter according to an example.

[0033] Fig. 27 is a block diagram illustrating an IP core development system 2700 that may be used to fabricate an integrated circuit to perform operations according to some examples. DETAILED DESCRIPTION

[0034] The present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for support of zero-clear move instructions. In some examples, the instruction is a scalar floating point value zero-clear move instruction.

[0034] In previous architectures, some move instructions behave differently when loading from memory than when moving from registers. For example, in some move instructions for scalar data, when both the source operand and the destination operand are packed data registers, only the lowest element of the destination is altered, while the remaining data elements of the destination operand remain unchanged. When the source operand is a memory location and the destination operand is a packed data register, the source scalar value is padded with zero elements so that the entire destination register can be altered.

[0036] Unfortunately, the inconsistency between memory and register operations is confusing to programmers who expect the results to be the same regardless of the source. It also adds complexity to compilation when working with data that has not yet been assigned a location in memory or registers. By removing this inconsistency, compilation is simplified and the programmer will have predictable results.

[0037] In some processors, it may be possible to emulate zero-clear move instructions using vector move instructions, but this is less efficient and more complex than instructions that do not require predication. Instructions that do require predication also require predication circuitry and predication on register encoding and storage.

[0038] Figure 1An example of hardware for processing of a zero-clear move instruction is illustrated. Execution of the zero-clear move instruction causes a single data element of a source to be copied to a destination. In some examples, when the source is a packed data (such as a single instruction, multiple data (SIMD) or vector) register, the data element to be copied is from the least significant data element position of the source packed data register. In some examples, when the source is a memory location, the data element in the memory location is copied to the destination.

[0039] In some examples, when the destination is a packed data (eg, single instruction multiple data (SIMD) or vector) register, the data elements are copied into the least significant data element position of the destination packed data register and all remaining data elements are zeroed.

[0040] In some examples, when the destination is a memory location, the data element is copied into the memory location.

[0041] In some examples, support for the zero-clear move instruction is indicated in a feature bit for a central processing unit identification (CPUID) instruction. Specifically, the feature flag specifies support for the instruction (e.g., leaf 8 with EDX

[19] indicates support for a convergent vector instruction set architecture). In some examples, the leaves of the CPUID instruction indicate what vector lengths are supported (e.g., leaf 0x24 and EBX

[16] - for indicating 128-bit vector support, EBX

[17] - for indicating 256-bit vector support, and EBX

[18] - for indicating 512-bit vector support).

[0042] In some examples, the data elements to be moved are floating point values. In some examples, the data elements to be moved are integer values. Since the data elements are not interpreted, and a zero integer value also represents a zero floating point value, the operation remains the same.

[0043] Decoder circuitry 101 decodes instructions to be executed by execution circuitry 113. Decoder circuitry 101 supports zero clear move instructions (shown as move instruction support 106), and supports other instructions 107. In some examples, instruction decode circuitry 105 decodes the instruction and generates as output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals decoded from, or otherwise reflecting, or derived from, the original instruction.

[0044] The instruction cache (icache) 102 is a backup storage area for instruction bytes. An instruction fetch is a lookup into the instruction translation lookaside buffer (iTLB) in icache 102.

[0045] In some examples, pre-decoding circuitry 103 estimates the length of instructions in the byte stream, decodes prefixes, and may mark various attributes of the instructions (such as "is a branch").

[0046] Instructions are queued in an instruction queue (IQ) 104 .

[0047] The instruction decoding circuit system 105 decodes instructions, which include support for one or more move instructions 106 and other instructions 107. In some examples, the instructions are decoded into one or more micro-operations (micro-ops, uops, etc.). The instruction decoding circuit system 105 can be implemented using various different mechanisms, including but not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memories (ROM), etc. In some examples, the instruction decoding circuit system 105 includes an address generation unit circuit system in some examples. The AGU generates a load / store unit (LSU) address using the forwarded register port, and can further perform branch forwarding (e.g., immediate offset branch forwarding, register branch forwarding, etc.).

[0048] In some examples, decoder circuitry 101 includes a microsequencer (microcode ROM 108 or other mechanism that stores microcode for certain macroinstructions). In some examples, microsequencer read-only-memory (ROM) 108 decodes some instructions into multiple micro-up (uop) streams.

[0049] In some examples, instruction decode circuitry 101 includes a micro-op operation cache (eg, data stream buffer 109 ) for storing / caching decoded operations, micro-tags, or micro-ops generated during decoding or other stages.

[0050] An instruction or uop may be selected by a selector 110 .

[0051] Decode circuitry 101 is coupled to register renaming / allocator / retirement / scheduler circuitry 111. Register renaming circuitry moves micro-ops from micro-op queues to bind to dispatch ports in the scheduler and execution resources. In some examples, zero-idiom, one-idiom, and zero-latency register move operations are performed by the renamer.

[0052] The allocator reads a queue (eg, a micro-op queue) and generates an ordered stream that is spliced ​​as needed across cluster boundaries within the same cycle.

[0053] The scheduler controls the dispatching of instructions (micro-ops) to their execution ports. It identifies which instructions (micro-ops) are ready, and where their source comes from: register file entry or bypass directly from the execution unit.

[0054] The retirement circuitry tracks when execution from both logical processors is ready to be retired. For each logical processor, it retires instructions in program order.

[0055] Execution circuitry 113 includes move circuitry 115 for executing zero-clear move instructions and other circuitry 117 for executing other instructions. In some examples, move circuitry 115 includes one or more circuits for zero-clear move instructions depending on the size of the data elements to be copied. For example, 4-bit size movement circuitry 121 is used to copy 4-bit data elements from a source to a destination (and zero the remainder of the data elements at the destination when the destination is a packed data register), 8-bit size movement circuitry 123 is used to copy 8-bit data elements from a source to a destination (and zero the remainder of the data elements at the destination when the destination is a packed data register), 16-bit size movement circuitry 125 is used to copy 16-bit data elements from a source to a destination (and zero the remainder of the data elements at the destination when the destination is a packed data register), 32-bit size movement circuitry 127 is used to copy 32-bit data elements from a source to a destination (and zero the remainder of the data elements at the destination when the destination is a packed data register), and / or 64-bit size movement circuitry 129 is used to copy 64-bit data elements from a source to a destination (and zero the remainder of the data elements at the destination when the destination is a packed data register). In some examples, if a particular data element size is not supported, the corresponding illustrated circuitry is not included in movement circuitry 115. In some examples, the move circuitry 115 used is the maximum size of data elements supported by the move instruction, and other move instructions will only use portions of the move circuitry 115. For example, if the move is for a 32-bit size data element, then the 32-bit size move circuitry 127 is used for 32-bit size data element copying, 16-bit size data element copying (where portions of the 32-bit size move circuitry 127 are not used for copying), etc. The specific circuitry used for execution of an instruction is determined by one or more control signals from the scheduler.

[0056] Coupled to the execution circuitry and / or register renaming / allocator / retirement / scheduler circuitry 111 is a register file 130 and / or memory 140. Register file 130 includes a plurality of registers and, in some examples, provides packed data source registers 131 and / or packed data destination registers 133 for zero-clear move instructions. In some examples, source memory location 141 provides source data elements for zero-clear move instructions. In some examples, destination memory location 143 will store data elements for zero-clear move instructions.

[0057] Figure 2(A)-Figure 2(C)An example of the execution of a zero clear move instruction is illustrated. In FIG2(A), the source is a packed data source register 131 having a plurality of data elements. The least significant packed data element position (position 0) stores a value to be stored in a corresponding data element position of a destination register 133. All other data elements of all other data element positions of the destination register 133 are zeroed.

[0058] 2(B), the source is a packed data source register 131 having multiple data elements. The least significant packed data element position (position 0) stores the value to be stored at the destination memory location 143.

[0059] 2(C), source memory location 141 stores a data element. This data element is copied to the least significant packed data element position (position 0) of destination register 133. All other data elements of all other data element positions of destination register 133 are zeroed.

[0060] Figure 3 An example of an execution circuit system for executing a move instruction is shown. As shown, the move circuit system 115 may include a copy circuit system 301 and, in some examples, may include a zeroing circuit system 303.

[0061] In this example illustration, replica circuitry 301 includes gates that allow input values ​​to pass through (shown here as AND gates, but other gates such as NAND, NOR, OR, etc. may be used with "wired" connections that allow inputs to pass through).

[0062] In this example illustration, zeroing circuitry 303 includes a data element-by-data element gate that zeroes the input value (shown here as an AND gate, but other gates such as NAND, NOR, OR, etc. may be used with a "wired" connection to output only zero values). In some examples, zeroing of the destination register data elements is performed by connecting to ground rather than using zeroing circuitry 303.

[0063] An example of a format for a zero-clear move execution is VMOD[B,D,W,DW,Q]DST,SRC. In some examples, VMOD[B,W,D,Q] is the opcode mnemonic for the instruction, where B, W, D, Q represent the data element size (byte (8 bits), word (16 bits), double word (32 bits), and quad word (64 bits), respectively). DST is one or more fields for the location of the destination operand (such as a packed data register or memory). SRC is one or more fields for the location of the source operand (such as a packed data register or memory). In some examples, the opcode is provided by fields 1903, 2312, or 2504. In some examples, the source and / or destination location is provided by one or more bits from: prefix 1901 (e.g., R bit, VVVV, etc.), addressing information 1905 (e.g., reg 2044, R / M 1946, SIB byte 2004, etc.), 1518, 1520, 1522, 1524, 1526, etc.

[0064] Figure 4 Examples of zero clear move instructions are illustrated. In these examples, XMM indicates a 128-bit packed data register, M16 indicates a memory location for storing a 16-bit value, and M32 indicates a memory location for storing a 32-bit value.

[0065] In some examples, the zero clear move instruction utilizes a prefix. Figure 5 Examples of prefixes used by clear-zero move instructions are illustrated. In some examples, prefix 501 is an example of an EVEX prefix. Prefix 501 is a four-byte prefix.

[0066] Prefix 501 may encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks (see reference to previous figures (such as, Fig.18 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control.

[0067] Prefix 501 may encode functionality specific to the instruction class (e.g., packed instructions with "load+op" semantics may support embedded broadcast functionality; floating-point instructions with rounding semantics may support static rounding functionality; floating-point instructions with non-rounding arithmetic semantics may support "suppress all exceptions" functionality; etc.).

[0068] The first byte of prefix 501 is format field 511 which in some examples has a value of 62H. Subsequent bytes are referred to as payload bytes 515-519 and together form a 24-bit value P[23:0] that provides specific capabilities in the form of one or more fields (described in detail herein).

[0069] In some examples, P[1:0] of payload byte 519 is identical to the two lower mm bits. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and MOD R / M reg field 2044. When SIB-type addressing is not required, P[6] may also provide access to the upper 16 vector registers. P[7:5] consists of R, X, and B, which are operand specifier modifiers for vector registers, general registers, and memory addressing, and when combined with MOD R / M register field 2044 and MOD R / MR / M field 2046, allows access to the next set of 8 registers beyond the 8 lower registers. P[9:8] provides opcode scalability equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). In some examples, P

[10] is a fixed value of 1. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand specified in inverted (1's complement) form and is valid for instructions with two or more source operands; 2) encode a destination register operand specified in 1's complement form for certain vector shifts; or 3) not encode any operands, the field is reserved and should contain a value such as 1111b.

[0070] P

[15] acts as an opcode extension bit or operand size increase.

[0071] P[18:16] specifies the index of a register in an operation mask (write mask) register (e.g., write mask / predicate register 1815). In some examples, a particular value aaa=000 has special behavior that implies that no operation mask is used for a particular instruction (this can be implemented in various ways, including using an operation mask that is hardwired to all instructions or hardware that bypasses the mask hardware). When merging, the vector mask allows any set of elements in the destination to be protected from update (specified by the base operation and the augmentation operation) during the execution of any operation; in some other examples, the old value of each element of the destination where the corresponding mask bit has 0 is maintained. In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed (specified by the base operation and the augmentation operation) during the execution of any operation; in some examples, the elements of the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span from the first to the last element to be modified), however, the elements being modified do not have to be consecutive. Thus, the operation mask field enables partial vector operations, including loads, stores, arithmetic, logical, etc. Although examples are described in which the contents of the operation mask field select one of a plurality of operation mask registers that contains an operation mask to be used (and thus the contents of the operation mask field indirectly identify the masking to be performed), alternative examples instead or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0072] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that uses P

[19] to access the 16 high vector registers. P

[20] encodes multiple functions that vary across different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge-write masking (e.g., when set to 0) or support for zeroing and merge-write masking (e.g., when set to 1).

[0073] An example of using prefix 501 to encode registers in instructions is detailed in the following table. Table 1: 32-register support in 64-bit mode Table 2: Encoding register designators in 32-bit mode Table 3: Operation Mask Register Specifier Encoding

[0074] In some examples, the LL bits (bits 21 and 22 of prefix 501) must be 00, otherwise the instruction will result in an undefined error indication.

[0075] In some examples, bits 11:14 (vvvv bits) must all be 1s, otherwise the instruction will result in an undefined error indication.

[0076] Execution of VMOVD copies a doubleword from the source operand (second operand) to the destination operand (first operand). The source operand and the destination operand can be 128-bit registers or 32-bit memory locations. This instruction can be used to move doublewords between two 128-bit registers or between a 128-bit register and a 32-bit memory location. This instruction cannot be used to transfer data between memory locations. When the source operand is a 128-bit register, the low doubleword is moved; when the destination operand is a 128-bit register, the doubleword is stored to the low doubleword of the register and the remaining bits are cleared to all 0s.

[0077] Execution of VMOVW copies a word from the source operand (second operand) to the destination operand (first operand). The source operand and the destination operand can be 128-bit registers or 16-bit memory locations. This instruction can be used to move a word between two 128-bit registers or between a 128-bit register and a 16-bit memory location. This instruction cannot be used to transfer data between memory locations. When the source operand is a 128-bit register, the low word is moved; when the destination operand is a 128-bit register, the word is stored to the low word of the register and the remaining bits are cleared to all 0s.

[0078] Figure 6 An example method executed by a processor to process a zero clear move instruction is shown. For example, a processor core as shown in FIG. 16(B), a pipeline as described in detail below, etc., executes the method.

[0079] At 601, an instance of a single instruction is obtained. For example, a move-zero-clear instruction is obtained. In some examples, the instance of the single instruction has a field for an opcode, one or more fields for indicating a source operand location, and one or more fields for indicating a destination operand location, wherein the opcode is used to indicate that a data element of a specific size (16 bits or 32 bits) is copied from the indicated source operand location to the indicated destination operand location, wherein: 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; 2) when the indicated source operand location is a packed data register and the indicated destination operand location is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand location and that data element is to be copied into the memory location; and / or 3) When the indicated source operand location is a memory location and the indicated destination operand location is a packed data register, data elements of the memory location are to be copied into the least significant data element positions of the indicated destination operand location, wherein all other data element positions of the indicated destination operand are to be zeroed.

[0080] The fetched instruction is decoded at 603. For example, the fetched zero clear move instruction is decoded by decoder circuitry, such as decoder circuitry 101 or decode circuitry 1640 described in detail herein.

[0081] At 605, when the decoded instruction is dispatched, data values ​​associated with the source operands of the decoded instruction are retrieved. For example, when one or more of the source operands are memory operands, data is retrieved from the indicated memory location.

[0082] At 607, the decoded instruction is executed by execution circuitry (hardware), such as execution circuitry 113, execution cluster(s) 1660 shown in FIG. 16(B), etc. For zero-clear move instructions, execution will cause the execution circuitry to perform the operations described in conjunction with the other figures. Figure 7 and Figure 8 An example of pseudo code for execution of a zero clear move instruction is illustrated.

[0083] In some examples, at 609 , the instruction is committed or retired.

[0084] Some examples utilize the instruction formats described herein. Some examples are implemented in one or more computer architectures, cores, accelerators, etc. Some examples are generated or are IP cores. Some examples utilize simulation and / or translation. Example Architecture

[0085] The description of the example computer architecture is described in detail below. Other system designs and configurations for laptops, desktop computers, handheld personal computers (PCs), personal digital assistants, engineering workstations, servers, separate servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices known in the art are also suitable. In general, various systems or electronic devices that can contain processors and / or other execution logic as disclosed herein are generally suitable. Example System

[0086] Fig. 9 An example computing system is illustrated. A multiprocessor system 900 is a system provided with an interface and includes a plurality of processors or cores, including a first processor 970 and a second processor 980 coupled via an interface 950 such as a point-to-point (PP) interconnect, a fabric, and / or a bus. In some examples, the first processor 970 and the second processor 980 are isomorphic. In some examples, the first processor 970 and the second processor 980 are heterogeneous. Although the example system 900 is shown as having two processors, the system may have three or more processors, or may be a single processor system. In some examples, the computing system is a system on a chip (SoC).

[0087] Processor 970 and processor 980 are shown as including integrated memory controller (IMC) circuitry 972 and 982, respectively. Processor 970 also includes interface circuitry 976 and 978; similarly, second processor 980 includes interface circuitry 986 and 988. Processors 970, 980 can exchange information via interface 950 using interface circuitry 978, 988. IMCs 972 and 982 couple processors 970, 980 to respective memories, namely memory 932 and memory 934, which may be portions of main memory locally attached to the respective processors.

[0088] Processors 970, 980 can each use interface circuits 976, 994, 986, 998 to exchange information with a network interface (NW I / F) 990 via separate interfaces 952, 954. Network interface 990 (e.g., one or more of an interconnect, bus, and / or fabric, and in some examples, a chipset) can optionally exchange information with a coprocessor 938 via interface circuit 992. In some examples, coprocessor 938 is a special-purpose processor such as, for example, a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a neural-network processing unit (NPU), an embedded processor, and the like.

[0089] A shared cache (not shown) may be included in either processor 970, 980, or external to both processors but connected to these processors via an interface (such as, the PP interconnect) so that if the processor is placed in a low power mode, local cache information of either or both processors can be stored in the shared cache.

[0090] The network interface 990 can be coupled to the first interface 916 via the interface circuit 996. In some examples, the first interface 916 can be an interface such as a peripheral component interconnect (PCI) interconnect, a PCI express interconnect, or another I / O interconnect. In some examples, the first interface 916 is coupled to a power control unit (PCU) 917, which may include circuit systems, software, and / or firmware for performing power management operations related to the processors 970, 980, and / or the coprocessor 938. The PCU 917 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 917 also provides control information to control the generated operating voltage. In various examples, the PCU 917 may include various power management logic units (circuitry systems) for performing hardware-based power management. Such power management may be entirely controlled by the processor (e.g., by various processor hardware, and which may be triggered by workload and / or power, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (such as a platform or power management source or system software).

[0091] PCU 917 is illustrated as existing as logic separate from processor 970 and / or processor 980. In other cases, PCU 917 may be executed on a given one or more cores (not shown) of the cores of processor 970 or 980. In some cases, PCU 917 may be implemented as a (dedicated or general purpose) microcontroller or other control logic configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other examples, the power management operations to be performed by PCU 917 may be implemented outside the processor, such as by means of a separate power management integrated circuit (PMIC) or another component external to the processor. In still other examples, the power management operations to be performed by PCU 917 may be implemented within BIOS or other system software.

[0092] Various I / O devices 914 may be coupled to the first interface 916 along with a bus bridge 918, which couples the first interface 916 to a second interface 920. In some examples, one or more additional processors 915 (such as a coprocessor, a high-throughput many integrated core (MIC) processor, a GPGPU, an accelerator (such as a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor) are coupled to the first interface 916. In some examples, the second interface 920 may be a low pin count (LPC) interface. Various devices may be coupled to the second interface 920, including, for example, a keyboard and / or mouse 922, a communication device 927, and a storage circuit system 928. The storage circuit system 928 may be one or more non-transitory machine-readable storage media as described below, such as a disk drive or other mass storage device, which in some examples may include instructions / codes and data 930 and may implement a storage device. Further, audio I / O 924 may be coupled to second interface 920. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 900 may implement a multi-drop interface or other such architectures instead of a point-to-point architecture. Exemplary Core Architectures, Processors, and Computer Architectures

[0093] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general-purpose in-order core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a special-purpose core intended primarily for graphics and / or scientific (throughput) computing. Different processor implementations may include: 1) a CPU that includes one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor that includes one or more special-purpose cores intended primarily for graphics and / or scientific (throughput) computing. Such different processors lead to different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor in the same package as the CPU but on a separate die; 3) a coprocessor on the same die as the CPU (in which case such a coprocessor is sometimes referred to as dedicated logic or as a dedicated core, such as integrated graphics and / or scientific (throughput) logic); and 4) a system on a chip (SoC), which may include the described CPU (sometimes referred to as application core(s) or application processor(s), the coprocessor described above, and additional functionality on the same die. An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0094] Fig.10 A block diagram of an example processor and / or SoC 1000 that may have one or more cores and an integrated memory controller is illustrated. The solid lined boxes illustrate the processor 1000 having a single core 1002(A), a system agent unit circuitry 1010, and a collection of one or more interface controller unit circuitry 1016, while the optional addition of dashed lined boxes illustrates an alternative processor 1000 having multiple cores 1002(A)-1002(N), a collection of one or more integrated memory controller units 1014 in the system agent unit circuitry 1010, and dedicated logic 1008 and a collection of one or more interface controller unit circuitry 1016. Note that the processor 1000 may be Fig. 9 one of the processors 970 or 980, or the coprocessors 938 or 915.

[0095] Thus, different implementations of processor 1000 may include: 1) a CPU, where the dedicated logic 1008 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1002(A)-1002(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two); 2) a coprocessor, where cores 1002(A)-1002(N) are a large number of dedicated cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor, where cores 1002(A)-1002(N) are a large number of general purpose in-order cores. Thus, processor 1000 may be a general purpose processor, a coprocessor, or a dedicated processor, such as, for example, a network or communications processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 1000 may be part of and / or implemented on one or more substrates using any of a variety of process technologies, such as, for example, complementary metal-oxide-semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0096] The memory hierarchy includes one or more levels of cache unit circuitry 1004A-1004N within the cores 1002(A)-1002(N), a set of one or more shared cache unit circuitry 1006, and external memory (not shown) coupled to a set of (one or more) integrated memory controller unit circuitry 1014. The set of one or more shared cache unit circuitry 1006 may include one or more intermediate levels of cache (such as level 2 (L2), level 3 (L3), level 4 (L4)) or other levels of cache (such as last level cache (LLC)) and / or combinations thereof. Although in some examples, an interface network circuitry 1012 (e.g., a ring interconnect) provides an interface to dedicated logic 1008 (e.g., integrated graphics logic), the set of (one or more) shared cache unit circuitry 1006, and the system agent unit circuitry 1010, alternative examples use any number of well-known techniques for providing interfaces to such units. In some examples, coherency is maintained between the shared cache unit circuitry 1006 and one or more of the cores 1002(A)-1002(N). In some examples, the interface controller unit circuitry 1016 couples the cores 1002(A)-1002(N) to one or more other devices 1018, such as one or more I / O devices, storage devices, one or more communication devices (e.g., a wireless network, a wired network, etc.), etc.

[0097] In some examples, one or more of the cores 1002(A)-1002(N) may be capable of multithreading. System agent unit circuitry 1010 includes those components that coordinate and operate cores 1002(A)-1002(N). System agent unit circuitry 1010 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may be, or may include, logic and components required to regulate the power state of cores 1002(A)-1002(N) and / or dedicated logic 1008 (e.g., integrated graphics logic). Display unit circuitry is used to drive one or more externally connected displays.

[0098] The cores 1002(A)-1002(N) may be homogeneous in terms of instruction set architecture (ISA). Alternatively, the cores 1002(A)-1002(N) may be heterogeneous in terms of ISA; that is, a subset of the cores 1002(A)-1002(N) may be capable of executing an ISA, while other cores may only be capable of executing a subset of that ISA or another ISA.

[0099] Fig.11 1 is a block diagram illustrating a computing system 1100 configured to implement one or more aspects of the examples described herein. The computing system 1100 includes a processing subsystem 1101 having one or more processors 1102 and a system memory 1104 communicating via an interconnect path, which may include a memory hub 1105. The memory hub 1105 may be a separate component within a chipset component, or may be integrated within one or more processors 1102. The memory hub 1105 is coupled to an I / O subsystem 1111 via a communication link 1106. The I / O subsystem 1111 includes an I / O hub 1107, which may enable the computing system 1100 to receive input from one or more input devices 1108. Additionally, the I / O hub 1107 may enable a display controller (which may be included in one or more processors 1102) to provide output to one or more display devices 1110A. In some examples, one or more display devices 1110A coupled to I / O hub 1107 may include local, internal, or embedded display devices.

[0100] The processing subsystem 1101 includes, for example, one or more parallel processors 1112 coupled to a memory hub 1105 via a bus or other communication link 1113. The communication link 1113 can be one of any number of standard-based communication link technologies or protocols, such as but not limited to PCI Express, or can be a vendor-specific communication interface or communication fabric. The one or more parallel processors 1112 can form a parallel or vector processing system in a computational concentration that can include a large number of processing cores and / or processing clusters, such as, for example, an integrated many-core (MIC) processor. For example, the one or more parallel processors 1112 form a graphics processing subsystem that can output pixels to one of the one or more display devices 1110A coupled via the I / O hub 1107. The one or more parallel processors 1112 may also include a display controller and a display interface (not shown) for enabling direct connection to one or more display devices 1110B.

[0101] Within the I / O subsystem 1111, a system storage unit 1114 may be connected to the I / O hub 1107 to provide a storage mechanism for the computing system 1100. An I / O switch 1116 may be used to provide an interface mechanism to enable connections between the I / O hub 1107 and other components, such as a network adapter 1118 and / or a wireless network adapter 1119 that may be integrated into the platform, and various other devices that may be added via one or more plug-in devices 1120. The plug-in device(s) 1120 may also include, for example, one or more external graphics processor devices, graphics cards, and / or computing accelerators. The network adapter 1118 may be an Ethernet adapter or another wired network adapter. The wireless network adapter 1119 may include one or more of the following: Wi-Fi, Bluetooth, near field communication (NFC), or other network devices including one or more wireless radio devices.

[0102] The computing system 1100 may include other components not explicitly shown, including USB or other port connections, optical storage drives, video capture devices, etc., which may also be connected to the I / O hub 1107. Fig.11 The communication paths for interconnecting the various components in the system may be implemented using any suitable protocol, such as a PCI (Peripheral Component Interconnect) based protocol (e.g., PCI Express), or any other bus or point-to-point communication interface and / or protocol(s), such as NVLink high-speed interconnect, Compute Express Link, or the like. TM (ComputeExpress Link TM , CXL TM) (e.g., CXL.mem), Infinity Fabric (IF), Ethernet (IEEE802.3), remote direct memory access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), quick UDP Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Intel Quick Path Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel On-Chip System Fabric (IOSF), Omnipath, HyperTransport, Advanced Microcontroller Bus Architecture (AMBA) interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators The data may be copied or stored to a virtualized storage node using protocols such as NVMe (non-volatile memory express over Fabrics, NVME-oF) or NVMe.

[0103] One or more parallel processors 1112 may include circuitry optimized for graphics and video processing (including, for example, video output circuitry) and constitute a graphics processing unit (GPU). Alternatively or additionally, as described in more detail herein, one or more parallel processors 1112 may include circuitry optimized for general-purpose processing while retaining the underlying computing architecture. The components of the computing system 1100 may be integrated on a single integrated circuit with one or more other system elements. For example, one or more parallel processors 1112, a memory hub 1105, (one or more) processors 1102, and an I / O hub 1107 may be integrated into a system-on-chip (SoC) integrated circuit. Alternatively, the components of the computing system 1100 may be integrated into a single package to form a system-in-package (SIP) configuration. In some examples, at least a portion of the components of the computing system 1100 may be integrated into a multi-chip module (MCM), which may be interconnected with other multi-chip modules into a modular computing system.

[0104] It will be appreciated that the computing system 1100 shown herein is illustrative, and variations and modifications are possible. The connection topology, including the number and arrangement of bridges, the number of (one or more) processors 1102, and the number of (one or more) parallel processors 1112, may be modified as desired. For example, the system memory 1104 may be connected to the (one or more) processors 1102 directly rather than through a bridge, while other devices communicate with the system memory 1104 via the memory hub 1105 and the (one or more) processors 1102. In other alternative topologies, the (one or more) parallel processors are connected to the I / O hub 1107 or directly to one of the one or more processors 1102, rather than to the memory hub 1105. In other examples, the I / O hub 1107 and the memory hub 1105 may be integrated into a single chip. It is also possible for two or more sets of processors 1102 to be attached via multiple slots, which may be coupled to two or more instances of (one or more) parallel processors 1112.

[0105] Some of the specific components shown herein are optional and may not be included in all implementations of the computing system 1100. For example, any number of plug-in cards or peripherals may be supported, or some components may be eliminated. In addition, some architectures may be specific to the Fig.11 Different terminology is used for components similar to those illustrated in FIG. 11. For example, memory hub 1105 may be referred to as a north bridge in some architectures, while I / O hub 1107 may be referred to as a south bridge.

[0106] Fig. 12A An example of a parallel processor 1200 is shown. The parallel processor 1200 may be a GPU, a GPGPU, etc. as described herein. The various components of the parallel processor 1200 may be implemented using one or more integrated circuit devices, such as a programmable processor, an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). The illustrated parallel processor 1200 may be Fig.11 One or more of the parallel processor(s) 1112 shown in FIG.

[0107] Parallel processor 1200 includes parallel processing unit 1202. Parallel processing unit includes I / O unit 1204 that enables communication with other devices, including other instances of parallel processing unit 1202. I / O unit 1204 can be directly connected to other devices. For example, I / O unit 1204 is connected to other devices via the use of a hub or switch interface (such as memory hub 1105). The connection between memory hub 1105 and I / O unit 1204 forms a communication link 1113. Within parallel processing unit 1202, I / O unit 1204 is connected to host interface 1206 and memory cross switch 1216, wherein host interface 1206 receives commands related to performing processing operations and memory cross switch 1216 receives commands related to performing memory operations.

[0108] When the host interface 1206 receives the command buffer via the I / O unit 1204, the host interface 1206 can direct the work operations for executing those commands to the front end 1208. In some examples, the front end 1208 is coupled with a scheduler 1210, which is configured to distribute commands or other work items to the processing cluster array 1212. The scheduler 1210 ensures that the processing cluster array 1212 is properly configured and in a valid state before the task is distributed to the processing clusters in the processing cluster array 1212. The scheduler 1210 can be implemented via firmware logic executed on a microcontroller. The microcontroller-implemented scheduler 1210 can be configured to perform complex scheduling and work distribution operations at coarse and fine granularity, thereby achieving fast preemption and context switching of threads executed on the processing cluster array 1212. Preferably, the host software can confirm the workload for scheduling on the processing cluster array 1212 via one of a plurality of graphics processing doorbells. In other examples, polling for new workloads or interrupts may be used to identify or indicate the availability of work to be performed. The workload may then be automatically distributed across the processing cluster array 1212 by the scheduler 1210 logic within the scheduler microcontroller.

[0109] The processing cluster array 1212 may include up to "N" processing clusters (e.g., cluster 1214A, cluster 1214B to cluster 1214N). Each cluster 1214A-1214N in the processing cluster array 1212 may execute a large number of concurrent threads. The scheduler 1210 may allocate work to the clusters 1214A-1214N in the processing cluster array 1212 using various scheduling and / or work distribution algorithms, which may vary depending on the workload generated for each type of program or calculation. Scheduling may be handled dynamically by the scheduler 1210, or may be partially assisted by compiler logic during the compilation of program logic configured for execution by the processing cluster array 1212. Optionally, different clusters 1214A-1214N in the processing cluster array 1212 may be allocated to process different types of programs or to perform different types of calculations.

[0110] Processing cluster array 1212 may be configured to perform various types of parallel processing operations. For example, processing cluster array 1212 is configured to perform general-purpose parallel computing operations. For example, processing cluster array 1212 may include logic for performing processing tasks including filtering of video and / or audio data, performing modeling operations including physical operations, and performing data transformations.

[0111] Processing cluster array 1212 is configured to perform parallel graphics processing operations. In such examples where parallel processor 1200 is configured to perform graphics processing operations, processing cluster array 1212 may include additional logic for supporting the execution of such graphics processing operations, including but not limited to texture sampling logic for performing texture operations, and tessellation logic and other vertex processing logic. In addition, processing cluster array 1212 may be configured to execute graphics processing related shader programs, such as but not limited to vertex shaders, tessellation shaders, geometry shaders, and pixel shaders. Parallel processing unit 1202 may transfer data from system memory via I / O unit 1204 for processing. During processing, the transferred data may be stored in on-chip memory (e.g., parallel processor memory 1222) during processing, and then the data may be written back to system memory.

[0112] In examples where parallel processing units 1202 are used to perform graphics processing, scheduler 1210 may be configured to divide the processing workload into tasks of approximately equal size to better enable distribution of graphics processing operations to multiple clusters 1214A-1214N in processing cluster array 1212. In some of these examples, portions of processing cluster array 1212 may be configured to perform different types of processing. For example, a first portion may be configured to perform vertex shading and topology generation, a second portion may be configured to perform tessellation and geometry shading, and a third portion may be configured to perform pixel shading or other screen space operations to produce a rendered image for display. Intermediate data generated by one or more of clusters 1214A-1214N may be stored in a buffer to allow the intermediate data to be transferred between clusters 1214A-1214N for further processing.

[0113] During operation, the processing cluster array 1212 may receive processing tasks to be executed via the scheduler 1210, which receives commands defining the processing tasks from the front end 1208. For graphics processing operations, the processing tasks may include data to be processed, such as surface (patch) data, primitive data, vertex data, and / or pixel data, and state parameters and commands defining how the data is to be processed (e.g., what program is to be executed). The scheduler 1210 may be configured to fetch an index corresponding to the task, or may receive the index from the front end 1208. The front end 1208 may be configured to ensure that the processing cluster array 1212 is configured to a valid state before a workload specified by an incoming command buffer (e.g., a batch buffer, a push buffer, etc.) is initiated.

[0114] Each of the one or more instances of the parallel processing unit 1202 can be coupled to a parallel processor memory 1222. The parallel processor memory 1222 can be accessed via a memory crossbar switch 1216, which can receive memory requests from the processing cluster array 1212 and the I / O unit 1204. The memory crossbar switch 1216 can access the parallel processor memory 1222 via a memory interface 1218. The memory interface 1218 can include a plurality of partition units (e.g., partition unit 1220A, partition unit 1220B, up to partition unit 1220N), each of which can be coupled to a portion (e.g., memory unit) of the parallel processor memory 1222. The number of partition units 1220A-1220N can be configured to be equal to the number of memory units, such that the first partition unit 1220A has a corresponding first memory unit 1224A, the second partition unit 1220B has a corresponding second memory unit 1224B, and the Nth partition unit 1220N has a corresponding Nth memory unit 1224N. In other examples, the number of partition units 1220A-1220N may not be equal to the number of memory devices.

[0115] The memory units 1224A-1224N may include various types of memory devices, including dynamic random-access memory (DRAM) or graphics random access memory, such as synchronous graphics random access memory (SGRAM), including graphics double data rate (GDDR) memory. Optionally, the memory units 1224A-1224N may also include 3D stacked memory, including but not limited to high bandwidth memory (HBM). Those skilled in the art will appreciate that the specific implementation of the memory units 1224A-1224N may vary and may be selected from one of a variety of conventional designs. Rendering targets such as frame buffers or texture maps may be stored across the memory units 1224A-1224N, allowing the partition units 1220A-1220N to write portions of each rendering target in parallel to efficiently use the available bandwidth of the parallel processor memory 1222. In some examples, local instances of parallel processor memory 1222 may be eliminated in favor of a unified memory design utilizing system memory in conjunction with local cache memory.

[0116] Optionally, any of the clusters 1214A-1214N in the processing cluster array 1212 has the capability to process data to be written to any of the memory units 1224A-1224N within the parallel processor memory 1222. The memory crossbar 1216 may be configured to transmit the output of each cluster 1214A-1214N to any partition unit 1220A-1220N or to another cluster 1214A-1214N, which may perform additional processing operations on the output. Each cluster 1214A-1214N may communicate with a memory interface 1218 via the memory crossbar 1216 to read from or write to various external memory devices. In one example with a memory crossbar switch 1216, the memory crossbar switch 1216 has connections to a memory interface 1218 to communicate with the I / O unit 1204 and has connections to a local instance of a parallel processor memory 1222, thereby enabling processing units within different processing clusters 1214A-1214N to communicate with system memory or other memory that is not local to the parallel processing unit 1202. In general, the memory crossbar switch 1216 may be able to separate traffic flows between the clusters 1214A-1214N and the partition units 1220A-1220N using virtual channels, for example.

[0117] Although a single instance of parallel processing unit 1202 is illustrated within parallel processor 1200, any number of instances of parallel processing unit 1202 may be included. For example, multiple instances of parallel processing unit 1202 may be provided on a single plug-in card, or multiple plug-in cards may be interconnected. For example, parallel processor 1200 may be a plug-in device, such as, Fig.11 Plug-in device 1120, which can be a graphics card (such as a discrete graphics card including one or more GPUs, one or more memory devices, and device-to-device or network or structure interfaces). Different instances of parallel processing unit 1202 can be configured to interoperate even if different instances have different numbers of processing cores, different amounts of local parallel processor memory, and / or other configuration differences. Optionally, some instances of parallel processing unit 1202 may include higher precision floating point units relative to other instances. Systems including one or more instances of parallel processing unit 1202 or parallel processor 1200 can be implemented in various configurations and form factors, including but not limited to desktop computers, laptop computers, or handheld personal computers, servers, workstations, game consoles, and / or embedded systems. The orchestrator can use one or more of the following to form a composite node for workload execution: decomposed processor resources, cache resources, memory resources, storage resources, and networking resources.

[0118] In some examples, the parallel processing unit 1202 can be partitioned into multiple instances. Those multiple instances can be configured to execute workloads associated with different clients in an isolated manner, so that a predetermined quality of service is provided for each client. For example, each cluster 1214A-1214N can be partitioned and isolated from other clusters, thereby allowing the processing cluster array 1212 to be divided into multiple computing partitions or instances. In such a configuration, the workload executed on the isolated partition is protected from errors or errors associated with different workloads executed on different partitions. Partition units 1220A-1220N can be configured to enable dedicated paths and / or isolated paths to the memory of the cluster 1214A-1214N associated with the corresponding computing partition. This data path isolation enables the computing resources within the partition to communicate with one or more assigned memory units 1224A-1224N without being interfered with by the activities of other partitions.

[0119] Fig. 12B is a block diagram of the partition unit 1220. The partition unit 1220 may be Fig. 12A 1220N. As illustrated, partition unit 1220 includes L2 cache 1221, frame buffer interface 1225, and ROP 1226 (raster operation unit). L2 cache 1221 is a read / write cache configured to perform load and store operations received from memory crossbar switch 1216 and ROP 1226. Read misses and urgent writeback requests are output by L2 cache 1221 to frame buffer interface 1225 for processing. Updates may also be sent to the frame buffer via frame buffer interface 1225 for processing. In some examples, frame buffer interface 1225 communicates with memory units in parallel processor memory (such as, for example, within parallel processor memory 1222). Fig. 12A Partition unit 1220 may also additionally or alternatively interface with one of the memory units in the parallel processor memory via a memory controller (not shown).

[0120] In graphics applications, ROP 1226 is a processing unit that performs raster operations such as stenciling, z-testing, blending, etc. ROP 1226 then outputs processed graphics data, which is stored in graphics memory. In some examples, ROP 1226 includes or is coupled to a codec (CODEC) 1227 that includes compression logic for compressing depth or color data written to memory or L2 cache 1221 and decompressing depth or color data read from memory or L2 cache 1221. The compression logic may be lossless compression logic that utilizes one or more of a variety of compression algorithms. The type of compression performed by CODEC 1227 may vary based on the statistical characteristics of the data to be compressed. For example, in some examples, delta color compression is performed on depth and color data on a slice-by-slice basis. In some examples, CODEC 1227 includes compression and decompression logic that can compress and decompress computational data associated with machine learning operations. CODEC 1227 can, for example, compress sparse matrix data for sparse machine learning operations. CODEC 1227 can also compress sparse matrix data encoded in a sparse matrix format (e.g., coordinate list encoding (COO), compressed sparse row (CSR), compressed sparse column (CSC), etc.) to generate compressed and encoded sparse matrix data. The compressed and encoded sparse matrix data can be decompressed and / or decoded before being processed by a processing element, or the processing element can be configured to consume compressed, encoded, or compressed and encoded data for processing.

[0121] ROP 1226 may be included in each processing cluster (e.g., Fig. 12A 1214A-1214N) rather than being included in partition unit 1220. In such examples, read and write requests for pixel data rather than pixel fragment data are transmitted through memory crossbar switch 1216. The processed graphics data may be displayed on a display device such as a Fig.11 110B), is routed for further processing by the processor(s) 1102, or is routed for processing by the processor(s) 1102. Fig. 12A One of the processing entities within the parallel processor 1200 further processes.

[0122] Fig. 12Cis a block diagram of a processing cluster 1214 within a parallel processing unit. For example, a processing cluster is Fig. 12A An instance of a processing cluster in the processing clusters 1214A-1214N. Processing cluster 1214 may be configured to execute many threads in parallel, wherein the term "thread" refers to an instance of a specific program executed on a set of specific input data. Optionally, a single-instruction, multiple-data (SIMD) instruction issuance technique may be used to support the parallel execution of a large number of threads without providing multiple independent instruction units. Alternatively, a single-instruction, multiple-thread (SIMT) technique may be used to support the parallel execution of a large number of threads that are generally synchronized using a common instruction unit configured to issue instructions to a set of processing engines within each processing cluster in the processing cluster. Unlike the SIMD execution mechanism in which all processing engines typically execute the same instruction, SIMT execution allows different threads to more easily follow the divergent execution path through a given thread program. Those skilled in the art will appreciate that the SIMD processing mechanism represents a functional subset of the SIMT processing mechanism.

[0123] The operation of the processing cluster 1214 may be controlled via a pipeline manager 1232 that distributes processing tasks to SIMT parallel processors. The pipeline manager 1232 receives Fig. 12A The graphics multiprocessor 1234 may be configured to receive instructions from the scheduler 1210 of the graphics multiprocessor 1234 and manage the execution of those instructions via the graphics multiprocessor 1234 and / or the texture unit 1236. The illustrated graphics multiprocessor 1234 is an exemplary instance of a SIMT parallel processor. However, various types of SIMT parallel processors of different architectures may be included in the processing cluster 1214. One or more instances of the graphics multiprocessor 1234 may be included in the processing cluster 1214. The graphics multiprocessor 1234 may process data, and the data crossbar 1240 may be used to distribute the processed data to one of a plurality of possible destinations, including other shader units. The pipeline manager 1232 may facilitate the distribution of processed data by specifying a destination for the processed data to be distributed via the data crossbar 1240.

[0124] Each graphics multiprocessor 1234 within a processing cluster 1214 may include an identical set of function execution logic (e.g., arithmetic logic units, load-store units, etc.). The function execution logic may be configured in a pipelined manner in which new instructions may be issued before previous instructions are completed. The function execution logic supports a variety of operations, including integer and floating point arithmetic, comparison operations, Boolean operations, bit shifts, and calculation of various algebraic functions. The same functional unit hardware may be utilized to perform different operations, and any combination of functional units may exist.

[0125] The instructions transmitted to the processing cluster 1214 constitute threads. A collection of threads executed across a collection of parallel processing engines is a thread group. A thread group executes the same program on different input data. Each thread within a thread group can be assigned to a different processing engine within the graphics multiprocessor 1234. A thread group may include fewer threads than the number of processing engines within the graphics multiprocessor 1234. When a thread group includes fewer threads than the number of processing engines, one or more of the processing engines may be idle during the cycle during which the thread group is being processed. A thread group may also include more threads than the number of processing engines within the graphics multiprocessor 1234. When a thread group includes more threads than the number of processing engines within the graphics multiprocessor 1234, processing may be performed in consecutive clock cycles. Optionally, multiple thread groups may be executed concurrently on the graphics multiprocessor 1234.

[0126] The graphics multiprocessor 1234 may include internal cache memory to perform load and store operations. Optionally, the graphics multiprocessor 1234 may abandon the internal cache and use cache memory (e.g., first level (level 1, L1) cache 1248) within the processing cluster 1214. Each graphics multiprocessor 1234 also has a partition unit (e.g., Fig. 12A 1220N), which are shared between all processing clusters 1214 and can be used to transfer data between threads. Graphics multiprocessor 1234 can also access off-chip global memory, which can include one or more of local parallel processor memory and / or system memory. Any memory external to parallel processing unit 1202 can be used as global memory. Embodiments in which processing cluster 1214 includes multiple instances of graphics multiprocessor 1234 can share common instructions and data, which can be stored in L1 cache 1248.

[0127] Each processing cluster 1214 may include an MMU 1245 (memory management unit) configured to map virtual addresses to physical addresses. In other examples, one or more instances of MMU 1245 may reside in Fig. 12A 1218. The MMU 1245 includes a set of page table entries (PTEs) for mapping virtual addresses to physical addresses of the slice, and optionally includes a cache line index. The MMU 1245 may include an address translation lookaside buffer (TLB) or cache that may reside within the graphics multiprocessor 1234 or L1 cache 1248 of the processing cluster 1214. The physical addresses are processed to distribute surface data access locality, thereby allowing efficient request interleaving between partition units. The cache line index can be used to determine whether a request for a cache line is a hit or a miss.

[0128] In graphics and compute applications, the processing clusters 1214 may be configured such that each graphics multiprocessor 1234 is coupled to a texture unit 1236 for performing texture mapping operations, such as determining texture sample locations, reading texture data, and filtering texture data. Texture data is read from an internal texture L1 cache (not shown), or in some examples, from an L1 cache within the graphics multiprocessor 1234 and retrieved from an L2 cache, local parallel processor memory, or system memory as needed. Each graphics multiprocessor 1234 outputs processed tasks to a data crossbar 1240 to provide the processed tasks to another processing cluster 1214 for further processing, or to store the processed tasks in an L2 cache, local parallel processor memory, or system memory via a memory crossbar 1216. A pre-raster operations unit 1242 is configured to receive data from the graphics multiprocessor 1234, direct the data to ROP units, which may be coupled to partition units (e.g., Fig. 12A The preROP 1242 unit may perform optimizations for color blending, organize pixel color data, and perform address translation.

[0129] It will be appreciated that the core architecture described herein is illustrative, and variations and modifications are possible. Any number of processing units (e.g., graphics multiprocessors 1234, texture units 1236, preROPs 1242, etc.) may be included within a processing cluster 1214. Further, while only one processing cluster 1214 is shown, a parallel processing unit as described herein may include any number of instances of a processing cluster 1214. Optionally, each processing cluster 1214 may be configured to operate independently of other processing clusters 1214 using separate and distinct processing units, L1 caches, L2 caches, etc.

[0130] Fig.12D An example of a graphics multiprocessor 1234 is shown, where the graphics multiprocessor 1234 is coupled to a pipeline manager 1232 of a processing cluster 1214. The graphics multiprocessor 1234 has an execution pipeline that includes, but is not limited to, an instruction cache 1252, an instruction unit 1254, an address mapping unit 1256, a register file 1258, one or more general purpose graphics processing unit (GPGPU) cores 1262, and one or more load / store units 1266. The GPGPU cores 1262 and the load / store units 1266 are coupled to a cache memory 1272 and a shared memory 1270 via a memory and cache interconnect 1268. The graphics multiprocessor 1234 may additionally include a tensor and / or ray tracing core 1263 that includes hardware logic for accelerating matrix and / or ray tracing operations.

[0131] The instruction cache 1252 may receive an instruction stream to be executed from the pipeline manager 1232. The instructions are cached in the instruction cache 1252 and dispatched for execution by the instruction unit 1254. The instruction unit 1254 may dispatch the instructions as a thread group (e.g., a unit group (warp)), wherein each thread in the thread group is assigned to a different execution unit within the GPGPU core 1262. The instruction may access any of the local address space, the shared address space, or the global address space by specifying an address within the unified address space. The address in the unified address space may be translated into different memory addresses that may be accessed by the load / store unit 1266 using the address mapping unit 1256.

[0132] The register file 1258 provides a collection of registers for the functional units of the graphics multiprocessor 1234. The register file 1258 provides temporary storage for operands of data paths connected to the functional units of the graphics multiprocessor 1234 (e.g., GPGPU core 1262, load / store unit 1266). The register file 1258 may be divided between each of the functional units so that each functional unit is assigned a dedicated portion of the register file 1258. For example, the register file 1258 may be divided between different groups of units executed by the graphics multiprocessor 1234.

[0133] The GPGPU cores 1262 may each include a floating point unit (FPU) and / or an integer arithmetic logic unit (ALU) for executing instructions of the graphics multiprocessor 1234. In some implementations, the GPGPU core 1262 may include hardware logic that may otherwise reside within the tensor and / or ray tracing core 1263. The GPGPU cores 1262 may be similar in architecture, or may be different in architecture. For example and in some examples, the first portion of the GPGPU core 1262 includes a single-precision FPU and an integer ALU, while the second portion of the GPGPU core includes a double-precision FPU. Optionally, the FPU may implement the IEEE 754-2008 standard for floating-point arithmetic, or enable variable-precision floating-point arithmetic. The graphics multiprocessor 1234 may additionally include one or more fixed-function or special-function units for performing specific functions, such as copying rectangles or pixel blending operations. One or more of the GPGPU cores in the GPGPU core may also include fixed-function or special-function logic.

[0134] GPGPU core 1262 may include SIMD logic capable of executing a single instruction to multiple sets of data. Optionally, GPGPU core 1262 may physically execute SIMD4, SIMD8 and SIMD16 instructions, and logically execute SIMD1, SIMD2 and SIMD32 instructions. SIMD instructions for GPGPU cores may be generated by a shader compiler at compile time, or automatically generated when executing a program written and compiled for a single program multiple data (SPMD) or SIMT architecture. Multiple threads of a program configured for a SIMT execution model may be executed via a single SIMD instruction. For example and in some examples, eight SIMT threads may be executed in parallel via a single SIMD8 logic unit, and these eight SIMT threads perform the same or similar operations.

[0135] The memory and cache interconnect 1268 is an interconnect network that connects each of the functional units of the graphics multiprocessor 1234 to the register file 1258 and to the shared memory 1270. For example, the memory and cache interconnect 1268 is a crossbar interconnect that allows the load / store unit 1266 to implement load and store operations between the shared memory 1270 and the register file 1258. The register file 1258 can operate at the same frequency as the GPGPU core 1262, so data transfers between the GPGPU core 1262 and the register file 1258 are very low latency. The shared memory 1270 can be used to enable communication between threads executed on the functional units within the graphics multiprocessor 1234. The cache memory 1272 can be used as a data cache, for example, to cache texture data passed between the functional unit and the texture unit 1236. The shared memory 1270 can also be used as a managed cached program. The shared memory 1270 and the cache memory 1272 can be coupled with the data crossbar 1240 to enable communication with other components of the processing cluster. Threads executing on GPGPU core 1262 can programmatically store data in shared memory in addition to the automatically cached data stored in cache memory 1272.

[0136] Figure 13A-13C An additional graphics multiprocessor is illustrated according to an example. Figure 13A-13B Graphics multiprocessors 1325 and 1350 are shown. Graphics multiprocessors 1325 and 1350 are Fig. 12C 1325, 1350. Fig. 13C A graphics processing unit (GPU) 1380 is illustrated, which includes a collection of dedicated graphics processing resources arranged as multi-core groups 1365A-1365N, which correspond to graphics multiprocessors 1325, 1350. The illustrated graphics multiprocessors 1325, 1350 and multi-core groups 1365A-1365N may be streaming multiprocessors (SMs) capable of executing a large number of execution threads simultaneously.

[0137] Fig.13A The graphics multiprocessor 1325 includes relative Fig.12DThe graphics multiprocessor 1325 may include multiple additional instances of execution resource units of the graphics multiprocessor 1234. For example, the graphics multiprocessor 1325 may include multiple instances of instruction units 1332A-1332B, register files 1334A-1334B, and (one or more) texture units 1344A-1344B. The graphics multiprocessor 1325 also includes multiple sets of graphics or compute execution units (e.g., GPGPU cores 1336A-1336B, tensor cores 1337A-1337B, ray tracing cores 1338A-1338B) and multiple sets of load / store units 1340A-1340B. The execution resource units have a common instruction cache 1330, texture and / or data cache memory 1342, and shared memory 1346.

[0138] The components may communicate via an interconnect structure 1327. The interconnect structure 1327 may include one or more crossbar switches to enable communication between the components of the graphics multiprocessor 1325. The interconnect structure 1327 is a separate, high-speed network fabric layer on which each component of the graphics multiprocessor 1325 is stacked. The components of the graphics multiprocessor 1325 communicate with remote components via the interconnect structure 1327. For example, the cores 1336A-1336B, 1337A-1337B, and 1338A-1338B may each communicate with the shared memory 1346 via the interconnect structure 1327. The interconnect structure 1327 may arbitrate communications within the graphics multiprocessor 1325 to ensure fair bandwidth allocation between components.

[0139] Fig. 13B The graphics multiprocessor 1350 includes a plurality of execution resource sets 1356A-1356D, wherein Fig.12D and Fig.13A As shown in FIG. 1 , each set of execution resources includes multiple instruction units, register files, GPGPU cores, and load storage units. Execution resources 1356A-1356D can work in conjunction with (one or more) texture units 1360A-1360D for texture operations while sharing instruction cache 1354 and shared memory 1353. For example, execution resources 1356A-1356D can share multiple instances of instruction cache 1354 and shared memory 1353 and texture and / or data cache memory 1358A-1358B. Each component can be connected to the CPU via the CPU. Fig.13A The interconnect structure 1327 communicates with a similar interconnect structure 1352 .

[0140] Those skilled in the art will understand that Figure 1 , Figures 12A-12D as well as Figure 13A-13BThe architecture described in is illustrative and not limiting in scope of the current examples. Thus, the techniques described herein may be implemented on any appropriately configured processing unit without departing from the scope of the examples described herein, including but not limited to: one or more mobile application processors; one or more desktop or server central processing units (CPUs), including multi-core CPUs; one or more parallel processor units, such as, Fig. 12A A parallel processing unit 1202 and one or more graphics processors or special processing units.

[0141] The parallel processor or GPGPU described herein can be communicatively coupled to a host / processor core to accelerate graphics operations, machine learning operations, pattern analysis operations, and various general-purpose GPU (GPGPU) functions. The GPU can be communicatively coupled to the host processor / core via a bus or another interconnect (e.g., a high-speed interconnect, such as PCIe, NVLink, or other known protocols, standardized protocols, or proprietary protocols). In other examples, the GPU can be integrated on the same package or chip as the core and communicatively coupled to the core via an internal processor bus / interconnect (i.e., inside the package or chip). Regardless of the manner in which the GPU is connected, the processor core can assign work to the GPU in the form of a sequence of commands / instructions contained in a work descriptor. The GPU then uses a dedicated circuit system / logic to efficiently process these commands / instructions.

[0142] Fig. 13C A graphics processing unit (GPU) 1380 is shown, which includes a dedicated set of graphics processing resources arranged as multi-core groups 1365A-1365N. Although details of only a single multi-core group 1365A are provided, it will be appreciated that other multi-core groups 1365B-1365N may be equipped with the same or similar set of graphics processing resources. The details described with respect to multi-core groups 1365A-1365N may also be applied to any of the graphics multiprocessors 1234, 1325, 1350 described herein.

[0143] As illustrated, multi-core group 1365A may include a set 1370 of graphics cores, a set 1371 of tensor cores, and a set 1372 of ray tracing cores. Scheduler / dispatcher 1368 schedules and dispatches graphics threads for execution on the respective cores 1370, 1371, 1372. A set 1369 of register files stores operand values ​​used by cores 1370, 1371, 1372 when executing graphics threads. These register files may include, for example, integer registers for storing integer values, floating point registers for storing floating point values, vector registers for storing packed data elements (integer and / or floating point data elements), and slice registers for storing tensor / matrix values. Slice registers may be implemented as a combined set of vector registers.

[0144] One or more combined first level (L1) caches and shared memory units 1373 store graphics data locally within each multi-core group 1365A, such as texture data, vertex data, pixel data, light data, bounding volume data, etc. One or more texture units 1374 may also be used to perform texture operations, such as texture mapping and sampling. A second level (L2) cache 1375 shared by all multi-core groups 1365A-1365N or a subset of multi-core groups 1365A-1365N stores graphics data and / or instructions for multiple concurrent graphics threads. As shown, the L2 cache 1375 may be shared across multiple multi-core groups 1365A-1365N. One or more memory controllers 1367 couple the GPU 1380 to a memory 1366, which may be a system memory (e.g., DRAM) and / or a dedicated graphics memory (e.g., GDDR6 memory).

[0145] Input / output (I / O) circuitry 1363 couples GPU 1380 to one or more I / O devices 1362, such as a digital signal processor (DSP), a network controller, or a user input device. On-chip interconnects may be used to couple I / O devices 1362 to GPU 1380 and memory 1366. One or more I / O memory management units (IOMMUs) 1364 of I / O circuitry 1363 directly couple I / O devices 1362 to system memory 1366. Optionally, IOMMU 1364 manages multiple sets of page tables used to map virtual addresses to physical addresses in system memory 1366. I / O devices 1362, CPU(s) 1361, and GPU(s) 1380 may then share the same virtual address space.

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

[0147] (One or more) CPU 1361, GPU 1380 and I / O device 1362 can be integrated on a single semiconductor chip and / or chip package. The illustrated memory 1366 can be integrated on the same chip, or can be coupled to a memory controller 1367 via an off-chip interface. In one implementation, memory 1366 includes GDDR6 memory that shares the same virtual address space as other physical system-level memory, but the basic principles described herein are not limited to this particular implementation.

[0148] Tensor core 1371 may include multiple execution units specifically designed to perform matrix operations, which are basic computational operations for performing deep learning operations. For example, synchronized matrix multiplication operations may be used for neural network training and inference. Tensor core 1371 may perform matrix processing using a variety of operand precisions, including single-precision floating point (e.g., 32 bits), half-precision floating point (e.g., 16 bits), integer words (16 bits), bytes (8 bits), and half bytes (4 bits). For example, a neural network implementation extracts features of each rendered scene, potentially combining details from multiple frames to build a high-quality final image.

[0149] In a deep learning implementation, parallel matrix multiplication work may be scheduled for execution on the tensor core 1371. The training of neural networks in particular requires a large number of matrix dot product operations. To handle the inner product formulation of an N x N x N matrix multiplication, the tensor core 1371 may include at least N dot product processing elements. Before the matrix multiplication begins, a complete matrix is ​​loaded into the slice register, and for each of the N cycles, at least one column of the second matrix is ​​loaded. For each cycle, there are N dot products that are processed.

[0150] Depending on the specific implementation, matrix elements can be stored with different precisions, including 16-bit words, 8-bit bytes (e.g., INT8), and 4-bit nibbles (e.g., INT4). Different precision modes can be specified for the Tensor Core 1371 to ensure that the most efficient precision is used for different workloads (e.g., such as inference workloads, which can tolerate quantization to bytes and nibbles). Supported formats additionally include 64-bit floating point (FP64) and non-IEEE floating point formats, such as the bfloat16 format (e.g., Brain floating point), a 16-bit floating point format with one sign bit, eight exponent bits, and eight significand bits (seven of which are explicitly stored). An example includes support for a reduced precision tensor floating point (TF32) mode that performs calculations using the range of FP32 (8 bits) and the precision of FP16 (10 bits). Reduced-precision TF32 operations can be performed on FP32 inputs and produce FP32 outputs with higher performance relative to FP32 and increased precision relative to FP16. In some examples, one or more 8-bit floating point formats (FP32) are supported.

[0151] In some examples, the tensor core 1371 supports sparse operation modes for matrices in which the vast majority of values ​​are zero. The tensor core 1371 includes support for sparse input matrices encoded in sparse matrix representations (e.g., coordinate list encoding (COO), compressed sparse rows (CSR), compressed sparse columns (CSC), etc.). The tensor core 1371 also includes support for compressed sparse matrix representations in the case where the sparse matrix representation can be further compressed. Compressed matrix data, encoded matrix data, and / or compressed and encoded matrix data and associated compression and / or encoding metadata can be read by the tensor core 1371, and non-zero values ​​can be extracted. For example, for a given input matrix A, non-zero values ​​can be loaded from at least a portion of the compressed and / or encoded representation of matrix A. Based on the position of the non-zero value in matrix A (which can be determined from the index or coordinate metadata associated with the non-zero value), the corresponding value in the input matrix B can be loaded. Depending on the operation to be performed (e.g., multiplication), loading values ​​from input matrix B may be bypassed if the corresponding value is a zero value. In some examples, the pairing of values ​​for certain operations (such as multiplication operations) may be pre-scanned by the scheduler logic, and only operations between non-zero inputs are scheduled. Depending on the dimensions of matrix A and matrix B and the operation to be performed, the output matrix C may be dense or sparse. In the case where the output matrix C is sparse and depending on the configuration of the tensor core 1371, the output matrix C may be output in a compressed format, sparse coding, or compressed sparse coding.

[0152] The ray tracing core 1372 can accelerate ray tracing operations for both real-time ray tracing implementations and non-real-time ray tracing implementations. Specifically, the ray tracing core 1372 may include a ray traversal / intersection circuit system that uses a bounding volume hierarchy (BVH) to perform ray traversals and identify intersections between rays and primitives enclosed within the BVH volume. The ray tracing core 1372 may also include circuit systems for performing depth testing and culling (e.g., using a Z buffer or similar arrangement). In one implementation, the ray tracing core 1372 performs traversal and intersection operations in conjunction with the image denoising techniques described herein, at least portions of which may be performed on the tensor core 1371. For example, the tensor core 1371 may implement a deep learning neural network to perform denoising on frames generated by the ray tracing core 1372. However, the CPU(s) 1361, graphics core 1370, and / or ray tracing core 1372 may also implement all or portions of the denoising and / or deep learning algorithms.

[0153] In addition, as described above, a distributed approach to denoising can be employed, wherein GPU 1380 is in a computing device coupled to other computing devices via a network or high-speed interconnect. According to the distributed approach, the interconnected computing devices can share neural network learning / training data to improve the speed at which the entire system learns to perform denoising for different types of image frames and / or different graphics applications.

[0154] The ray tracing core 1372 can handle all BVH traversals and / or ray-primitive intersections, thereby preventing the graphics core 1370 from being overloaded with thousands of instructions for each ray. For example, each ray tracing core 1372 includes a first set of specialized circuit systems for performing bounding box tests (e.g., for traversal operations) and / or a second set of specialized circuit systems for performing ray-triangle intersection tests (e.g., intersecting rays that have been traversed). Thus, for example, the multi-core group 1365A can simply start ray detection, and the ray tracing core 1372 independently performs ray traversals and intersections and returns hit data (e.g., hits, no hits, multiple hits, etc.) to the thread context. While the ray tracing core 1372 performs traversal and intersection operations, the other cores 1370, 1371 are freed up to perform other graphics or computational work.

[0155] Optionally, each ray tracing core 1372 may include a traversal unit for performing BVH test operations and / or an intersection unit for performing ray-primitive intersection tests. The intersection unit generates a "hit", "no hit", or "multiple hits" response, which it provides to the appropriate thread. During traversal and intersection operations, execution resources of other cores (e.g., graphics core 1370 and tensor core 1371) are freed up to perform other forms of graphics work.

[0156] In some examples described below, a hybrid rasterization / ray tracing approach is used in which the work is distributed between graphics core 1370 and ray tracing core 1372 .

[0157] The ray tracing core 1372 (and / or other cores 1370, 1371) may include hardware support for ray tracing instruction sets, such as Microsoft's DirectX Ray Tracing (DXR), which includes the DispatchRays command; and ray generation shaders, nearest hit shaders, any hit shaders, and miss shaders, which enable a unique set of shaders and textures to be assigned to each object. Another ray tracing platform that may be supported by the ray tracing core 1372, graphics core 1370, and tensor core 1371 is the Vulkan API (e.g., Vulkan version 1.1.85, or later). However, it should be noted that the basic principles described herein are not limited to any particular ray tracing ISA.

[0158] In general, each core 1372, 1371, 1370 may support a ray tracing instruction set including instructions / functions for one or more of the following: ray generation, nearest hit, any hit, ray-primitive intersection, per-primitive and hierarchy bounding box construction, misses, visits, and exceptions. More specifically, some examples include ray tracing instructions for performing one or more of the following functions: Ray Generation - Ray generation instructions can be executed for each pixel, sample, or other user-defined work assignment. Closest Hit - Closest hit instructions can be executed to locate the closest intersection of a ray with a primitive within the scene. Any Hit - The Any Hit directive identifies multiple intersections between rays and primitives within the scene, potentially identifying a new closest intersection point. Intersect - The Intersect command performs a ray-primitive intersection test and outputs the result. Per-primitive bounding box construction - This instruction builds a bounding box around a given primitive or group of primitives (e.g., when building a new BVH or other acceleration data structure). Miss - Indicates that the ray missed the scene or all geometry within a specified area of ​​the scene. Visits – Indicates the subvolumes that the ray will traverse. Exceptions - includes various types of exception handlers (eg, called for various error conditions).

[0159] In some examples, the ray tracing core 1372 may be adapted to accelerate general computing operations that can be accelerated using computing techniques similar to ray intersection tests. A computing framework may be provided that enables shader programs to be compiled into low-level instructions and / or primitives that perform general computing operations via the ray tracing core. Exemplary computing problems that may benefit from computing operations performed on the ray tracing core 1372 include calculations involving the propagation of beams, waves, rays, or particles within a coordinate space. Interactions associated with that propagation may be calculated relative to geometry or meshes within the coordinate space. For example, calculations associated with the propagation of electromagnetic signals through an environment may be accelerated using instructions or primitives that are executed via the ray tracing core. Refraction and reflection of signals through objects in the environment may be calculated as direct ray tracing simulations.

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

[0161] Building larger and larger silicon dies is challenging for various reasons. As silicon dies get larger, manufacturing yields become smaller, and process technology requirements for different components may vary. On the other hand, in order to have a high-performance system, key components should be interconnected through high-speed, high-bandwidth, low-latency interfaces. These conflicting requirements bring challenges to high-performance chip development.

[0162] The embodiments described herein provide techniques for separating the architecture of a system-on-chip integrated circuit into multiple different chiplets that can be packaged onto a common substrate. In some examples, a graphics processing unit or a parallel processor is composed of various silicon chiplets that are manufactured separately. A chiplet is an integrated circuit that is at least partially packaged, and the at least partially packaged integrated circuit includes different logic units that can be assembled into a larger package with other chiplets. Various chiplet collections with different IP core logic can be assembled into a single device. In addition, the chiplets can be integrated into a base die or base chiplet using active interposer technology. The concepts described herein enable interconnection and communication between different forms of IP within a GPU. IP development on different processes can be mixed. This avoids the complexity of converging multiple IPs to the same process, especially for large SoCs with several styles of IP.

[0163] Enabling the use of multiple process technologies improves time to market and provides a cost-effective way to create multiple product SKUs. For customers, this means getting a product that better suits their requirements in a cost-effective and timely manner. Additionally, the split IP is easier to modify to be independently power-gated, and components that are not in use for a given workload can be turned off, reducing overall power consumption.

[0164] Fig.14 A parallel computing system 1400 according to some examples is shown. In some examples, the parallel computing system 1400 includes a parallel processor 1420, which may be a graphics processor or a computing accelerator as described herein. The parallel processor 1420 includes a global logic unit 1401, an interface 1402, a thread dispatcher 1403, a media unit 1404, a set of computing units 1405A-1405H, and a cache / memory unit 1406. In some examples, the global logic unit 1401 includes global functions for the parallel processor 1420, including device configuration registers, a global scheduler, power management logic, and the like. The interface 1402 may include a front-end interface for the parallel processor 1420. The thread dispatcher 1403 may receive a workload from the interface 1402 and dispatch threads of the workload to the computing units 1405A-1405H. If the workload includes any media operations, at least part of those operations may be performed by the media unit 1404. The media unit may also migrate some operations to the compute units 1405A-1405H. The cache / memory unit 1406 may include cache memory (eg, L3 cache) and local memory (eg, HBM, GDDR) for the parallel processors 1420.

[0165] Figure 15A-15BIllustrate a hybrid logical / physical view of a split parallel processor according to examples described herein. Fig.15A A split parallel computing system 1500 is shown. Fig. 15B A chiplet 1530 of the split parallel computing system 1500 is shown.

[0166] like Fig.15A As shown in , the separated computing system 1500 may include a parallel processor 1520, wherein the components of the parallel processor SOC are distributed across multiple chiplets. Each chiplet may be a different IP core that is independently designed and configured to communicate with other chiplets via one or more common interfaces. The chiplets are not limited to computing chiplets 1505, media chiplets 1504, and memory chiplets 1506. Each chiplet can be manufactured separately using different process technologies. For example, the computing chiplet 1505 can be manufactured using the smallest or most advanced process technology available at the time of manufacturing, while the memory chiplet 1506 or other chiplets (e.g., I / O, networking, etc.) can be manufactured using larger or less advanced process technologies.

[0167] The individual chiplets may be bonded to a base die 1510 and configured to communicate with each other and logic within the base die 1510 via an interconnect layer 1512. In some examples, the base die 1510 may include a global logic 1501, which may include a scheduler 1511 and power management 1521 logic unit, an interface 1502, a dispatch unit 1503, and an interconnect fabric module 1508 coupled or integrated with one or more L3 cache blocks 1509A-1509N. The interconnect fabric 1508 may be an inter-chiplet fabric integrated into the base die 1510. The logic chiplets may use the fabric 1508 to relay messages between the individual chiplets. Additionally, the L3 cache blocks 1509A-1509N in the base die and / or the L3 cache blocks within the memory chiplet 1506 may cache data read from and transferred to the DRAM chiplets within the memory chiplet 1506 and to the system memory of the host.

[0168] In some examples, global logic 1501 is a microcontroller that can execute firmware to perform scheduler 1511 and power management 1521 functions for parallel processor 1520. The microcontroller that executes the global logic can be customized for the target use case of parallel processor 1520. Scheduler 1511 can perform global scheduling operations for parallel processor 1520. Power management 1521 functions can be used to enable or disable individual chiplets within a parallel processor when those chiplets are not in use.

[0169] The individual chiplets of parallel processor 1520 may be designed to perform specific functions that would be integrated into a single die in existing designs. A collection of compute chiplets 1505 may include a cluster of compute units (e.g., execution units, streaming multiprocessors, etc.) that include programmable logic for executing compute or graphics shader instructions. Media chiplets 1504 may include hardware logic for accelerating media encoding and decoding operations. Memory chiplets 1506 may include volatile memory (e.g., DRAM) and one or more SRAM cache memory blocks (e.g., L3 blocks).

[0170] like Fig. 15B As shown in , each chiplet 1530 may include common components and dedicated components. The chiplet logic 1536 within the chiplet 1530 may include specific components of the chiplet, such as an array of streaming multiprocessors, computing units, or execution units described herein. The chiplet logic 1536 may be coupled with an optional cache or shared local memory 1538, or a cache or shared local memory may be included within the chiplet logic 1536. The chiplet 1530 may include a fabric interconnect node 1542 that receives commands via an inter-chiplet fabric. Commands and data received via the fabric interconnect node 1542 may be temporarily stored in an interconnect buffer 1539. Data transmitted to and received from the fabric interconnect node 1542 may be stored in the interconnect cache 1540. Power control 1532 and clock control 1534 logic may also be included within the chiplet. The power control 1532 and clock control 1534 logic may receive configuration commands via the fabric and may configure dynamic voltage and frequency scaling for the chiplet 1530. In some examples, each chiplet can have independent clock and power domains and can be clock-gated and power-gated independently of other chiplets.

[0171] At least some of the components within the illustrated chiplet 1530 may also be included in a Fig.15A The base die 1510 may be within logic within the base die 1510. For example, logic within the base die that communicates with the fabric may include some version of the fabric interconnect node 1542. The base die logic that may be independently clock gated or power gated may include some version of the power control 1532 and / or clock control 1534 logic.

[0172] Thus, while various examples described herein use the term SOC to describe devices and systems having a processor and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, memory circuitry, etc.) monolithically integrated into a single integrated circuit (“Integrated Circuit”) die or chip, the present disclosure is not limited in this respect. For example, in various examples of the present disclosure, a device or system may have one or more processors (e.g., one or more processor cores) and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, etc.) arranged in a discrete collection of discrete dies, slices, and / or chiplets (e.g., one or more discrete processor core dies arranged adjacent to one or more other dies (such as a memory die, an I / O die, etc.)). In such discrete devices and systems, individual dies, slices, and / or chiplets may be physically and / or electrically coupled together by a packaging structure including, for example, individual packaging substrates, interposers, active interposers, photonic interposers, interconnect bridges, etc. A discrete collection of discrete dies, slices, and / or chiplets may also be part of a System-on-Package ("SoP").

[0173] Example Core Architecture - In-order and Out-of-order Core Block Diagram

[0174] Figure 16(A) is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example. Figure 16(B) is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example. Figure 16 (A) - Figure 16 (B) The solid line boxes in illustrate the in-order pipeline and in-order core, while the optionally added dashed line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0175] In FIG. 16(A), the processor pipeline 1600 includes a fetch stage 1602, an optional length decoding stage 1604, a decode stage 1606, an optional allocation (Alloc) stage 1608, an optional rename stage 1610, a dispatch (also called dispatch or issue) stage 1612, an optional register read / memory read stage 1614, an execute stage 1616, a write back / memory write stage 1618, an optional exception handling stage 1622, and an optional commit stage 1624. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1602, one or more instructions are fetched from the instruction memory, and during the decode stage 1606, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In some examples, decode stage 1606 and register read / memory read stage 1614 can be combined into one pipeline stage. In some examples, during execute stage 1616, decoded instructions can be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface can be performed, multiplication and addition operations can be performed, arithmetic operations with branch results can be performed, and the like.

[0176] As an example, the example register renaming, out-of-order issue / execution architecture core of FIG. 16(B) may implement pipeline 1600 by: 1) instruction fetch circuit system 1638 performs fetch and length decoding stages 1602 and 1604; 2) decoding circuit system 1640 performs decoding stage 1606; 3) renaming / allocator unit circuit system 1652 performs allocation stage 1608 and renaming stage 1610; 4) (one or more) scheduler circuit system 1656 performs scheduling stage 1612; 5) (one or more) physical registers The register stack circuit system 1658 and the memory unit circuit system 1670 perform the register read / memory read stage 1614; the execution cluster 1660 performs the execute stage 1616; 6) the memory unit circuit system 1670 and (one or more) physical register stack circuit systems 1658 perform the write back / memory write stage 1618; 7) various circuit systems may be involved in the exception handling stage 1622; and 8) the retirement unit circuit system 1654 and (one or more) physical register stack circuit systems 1658 perform the commit stage 1624.

[0177] 16(B) shows that processor core 1690 includes front end unit circuitry 1630 coupled to execution engine unit circuitry 1650, and both are coupled to memory unit circuitry 1670. Core 1690 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, core 1690 may be a special purpose core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0178] The front end unit circuit system 1630 may include a branch prediction circuit system 1632, which is coupled to an instruction cache unit circuit system 1634, which is coupled to an instruction translation lookaside buffer (TLB) 1636, which is coupled to an instruction fetch circuit system 1638, which is coupled to a decoding circuit system 1640. In some examples, the instruction cache circuit system 1634 is included in the memory unit circuit system 1670 instead of the front end circuit system 1630. The decoding circuit system 1640 (or decoder) can decode the instruction and generate one or more micro-operations, micro-code entry points, micro-instructions, other instructions or other control signals as output, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decoding circuit system 1640 may also include an address generation unit (AGU, not shown) circuit system. In some examples, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode circuit system 1640 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read only memory (ROM), and the like. In some examples, the core 1690 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit system 1640 or otherwise within the front-end circuit system 1630). In some examples, the decode circuit system 1640 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 1600. The decode circuit system 1640 may be coupled to the rename / allocator unit circuit system 1652 in the execution engine circuit system 1650.

[0179] Execution engine circuitry 1650 includes rename / allocator unit circuitry 1652, which is coupled to retirement unit circuitry 1654 and a set of one or more scheduler circuitry 1656. Scheduler circuitry 1656 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, scheduler circuitry(s) 1656 may include an arithmetic logic unit (ALU) scheduler / scheduling circuitry, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuitry, an AGU queue, and the like. Scheduler circuitry(s) 1656 are coupled to physical register file(s) circuitry 1658. Each of the (one or more) physical register file circuit systems 1658 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., instruction pointers, i.e., the address of the next instruction to be executed), etc. In some examples, the (one or more) physical register file circuit systems 1658 include vector register unit circuit systems, write mask register unit circuit systems, and scalar register unit circuit systems. These register units can provide architectural vector registers, vector mask registers, general registers, etc. The (one or more) physical register cell file circuit systems 1658 are coupled to the retirement unit circuit system 1654 (also called retirement queue) overlap to demonstrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROBs) and (one or more) retirement register files; using (one or more) future stacks, (one or more) history buffers, and (one or more) retirement register files; using register maps and pools of registers; etc.). Retirement unit circuitry 1654 and physical register file(s) circuitry 1658 are coupled to execution cluster(s) 1660. Execution cluster(s) 1660 include a set of one or more execution unit circuitry 1662 and a set of one or more memory access circuitry 1664. Execution unit circuitry 1662 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point).While some examples may include several execution units or execution unit circuit systems dedicated to a particular function or set of functions, other examples may include only one execution unit circuit system or multiple execution units / execution unit circuit systems that all perform all functions. (One or more) scheduler circuit systems 1656, (one or more) physical register file circuit systems 1658, and (one or more) execution clusters 1660 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipelines, and / or memory access pipelines, each of which has its own scheduler circuit system, (one or more) physical register file circuit systems, and / or execution clusters - and in the case of a separate memory access pipeline, only the execution cluster of that pipeline has (one or more) memory access unit circuit systems 1664 in some examples implemented). It should also be understood that in the case of using separate pipelines, one or more of these pipelines can be out-of-order issue / execution, while the rest are in-order.

[0180] In some examples, execution engine unit circuitry 1650 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0181] A set of memory access circuitry 1664 is coupled to memory cell circuitry 1670, which includes data TLB circuitry 1672, which is coupled to data cache circuitry 1674, which is coupled to level 2 (L2) cache circuitry 1676. In some examples, memory access circuitry 1664 may include load unit circuitry, store address unit circuitry, and store data unit circuitry, each of which is coupled to data TLB circuitry 1672 in memory cell circuitry 1670. Instruction cache circuitry 1634 is further coupled to level 2 (L2) cache unit circuitry 1676 in memory cell circuitry 1670. In some examples, instruction cache 1634 and data cache 1674 are combined into L2 cache circuitry 1676, level 3 (L3) cache circuitry (not shown), and / or a single instruction and data cache in main memory (not shown). The L2 cache circuitry 1676 is coupled to one or more other levels of cache and ultimately to main memory.

[0182] Core 1690 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions that have been added with newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions, such as NEON)) that include the instruction(s) described herein. In some examples, core 1690 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data. Example Execution Unit Circuitry

[0183] Fig.17 An example of (one or more) execution unit circuit systems is illustrated, such as (one or more) execution unit circuit systems 1662 of FIG. 16 (B). As shown, (one or more) execution unit circuit systems 1662 may include one or more ALU circuits 1701, optional vector / single instruction multiple data (SIMD) circuits 1703, load / store circuits 1705, branch / jump circuits 1707, and / or floating-point unit (FPU) circuits 1709. ALU circuits 1701 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1703 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 1705 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store circuits 1705 may also generate addresses. Branch / jump circuits 1707 cause branches or jumps to a certain memory address depending on the instruction. FPU circuits 1709 perform floating-point arithmetic. The width of execution unit circuitry 1662 varies depending on the example, and may range from 16 bits to 1024 bits, for example. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit). Example Register Architecture

[0184] Fig.181 is a block diagram of a register architecture 1800 according to some examples. As shown, the register architecture 1800 includes a vector / SIMD register 1810, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 1810 is physically 512 bits, and only some low-order bits are used depending on the mapping. For example, in some examples, the vector / SIMD register 1810 is a 512-bit ZMM register: the low-order 256 bits are used for the YMM register, and the low-order 128 bits are used for the XMM register. Therefore, there is an overlay of registers. In some examples, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either maintained as the same as before the instruction, or are zeroed, depending on the example.

[0185] In some examples, the register architecture 1800 includes a write mask / predicate register 1815. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 1815 can allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1815 corresponds to a data element position in the destination. In other examples, the write mask / predicate register 1815 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

[0186] The register architecture 1800 includes a plurality of general purpose registers 1825. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some examples, these registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0187] In some examples, register architecture 1800 includes a scalar floating point (FP) register file 1845, which is used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using x87 instruction set architecture extensions, or as MMX registers to perform operations on 64-bit packed integer data, and to store operands for some operations performed between MMX and XMM registers.

[0188] One or more flag registers 1840 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 1840 can store condition code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1840 are referred to as program status and control registers.

[0189] Segment registers 1820 contain segment points for accessing memory. In some examples, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0190] Model specific registers or machine-specific registers (MSRs) 1835 control and report processor performance. Most MSRs 1835 handle system-related functions and are not accessible to applications. For example, MSRs may provide control over one or more of the following: performance monitoring counters, debug extensions, memory type range registers, thermal management and power management, instruction-specific support, and / or processor feature / mode support. Machine check registers 1860 consist of control, status, and error reporting MSRs for detecting and reporting hardware errors. (One or more) control registers 1855 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 970, 980, 938, 918, and / or 1000) and the characteristics of the task currently being executed. In some examples, MSRs 1835 are a subset of control registers 1855.

[0191] One or more instruction pointer registers 1830 store instruction pointer values. Debug registers 1850 control and allow monitoring of debug operations of the processor or core.

[0192] Memory (mem) management registers 1865 specify the location of data structures used in protected mode memory management. These registers may include global descriptor table registers (GDTR), interrupt descriptor table registers (IDTR), task registers, and local descriptor table registers (LDTR) registers.

[0193] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer, or different register files and registers. The register architecture 1800 may be used, for example, in register file / memory 1608, or (one or more) physical register file circuitry 1658. Instruction Set Architecture

[0194] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because there are fewer included fields) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, the example ADD instruction has a specific opcode and instruction format, the instruction format includes an opcode field to specify the opcode, and includes an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field to select the specific operand. In addition, although the following description is made in the context of the x86 ISA, it is within the knowledge of those skilled in the art to apply the teachings of the present disclosure in another ISA. Example instruction format

[0195] The examples of the (one or more) instructions described herein may be implemented in different formats. In addition, example systems, architectures, and pipelines are described in detail below. The examples of (one or more) instructions may be executed on these systems, architectures, and pipelines, but are not limited to those described in detail.

[0196] Fig.19 An example of an instruction format is illustrated. As shown, an instruction may include multiple components, including, but not limited to, one or more fields for: one or more prefixes 1901, an opcode 1903, addressing information 1905 (e.g., a register identifier, memory addressing information, etc.), a displacement value 1907, and / or an immediate value 1909. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 1903 field. In some examples, the illustrated order is the order in which the fields are to be encoded, however, it should be understood that in other examples, the fields may be encoded in another order, combined, etc.

[0197] (One or more) prefix fields 1901 modify the instruction when used. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operation objects (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0198] The opcode field 1903 is used to at least partially define the operation to be performed when the instruction is decoded. In some examples, the length of the primary opcode encoded in the opcode field 1903 is one, two, or three bytes. In other examples, the primary opcode can be other lengths. The additional 3-bit opcode field is sometimes encoded in another field.

[0199] The addressing information field 1905 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Fig. 20An example of an addressing information field 1905 is illustrated. In this illustration, an optional MOD R / M byte 2002 and an optional Scale, Index, Base (SIB) byte 2004 are shown. The MOD R / M byte 2002 and SIB byte 2004 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that these two fields are optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 2002 includes a MOD field 2042, a register (reg) field 2044, and an R / M field 2046.

[0200] The content of MOD field 2042 distinguishes between memory access and non-memory access modes. In some examples, when MOD field 2042 has a binary value of 11 (11b), register direct addressing mode is utilized, otherwise register indirect addressing is used.

[0201] Register field 2044 may encode a destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The contents of register field 2044 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some examples, register field 2044 is supplemented with additional bits from a prefix (e.g., prefix 1901) to allow for greater addressing.

[0202] R / M field 2046 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 2046 may be combined with MOD field 2042 to specify an addressing mode.

[0203] SIB byte 2004 includes a scaling field 2052, an index field 2054, and a base address field 2056 for address generation. Scaling field 2052 indicates a scaling factor. Index field 2054 specifies the index register to be used. In some examples, index field 2054 is supplemented with extra bits from a prefix (e.g., prefix 1901) to allow for larger addressing. Base address field 2056 specifies the base address register to be used. In some examples, base address field 2056 is supplemented with extra bits from a prefix (e.g., prefix 1901) to allow for larger addressing. In practice, the contents of scaling field 2052 allow the contents of index field 2054 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0204] Some addressing forms use displacement values ​​to generate memory addresses. For example, 缩放 1905, which indicates a compressed displacement scheme for which the displacement value is calculated and stored in the displacement field 1907.

[0205] In some examples, the immediate value field 1909 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, and so on. Graphics Execution Unit

[0206] Figure 21A-21B Thread execution logic 2100 is illustrated including an array of processing elements employed in a graphics processor core according to examples described herein. Figure 21A-21B Elements having the same reference numeral (or name) as elements of any other figure herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto. Fig.21A represents an execution unit within a general-purpose graphics processor, and Fig.21B Represents an execution unit that can be used within a computing accelerator.

[0207] As in Fig.21AAs illustrated in , in some examples, thread execution logic 2100 includes a shader processor 2102, a thread dispatcher 2104, an instruction cache 2106, a scalable execution unit array including a plurality of execution units 2108A-2108N, a sampler 2110, a shared local memory 2111, a data cache 2112, and a data port 2114. In some examples, the scalable execution unit array can be dynamically scaled by enabling or disabling one or more execution units (e.g., any one of execution units 2108A, 2108B, 2108C, 2108D, up to 2108N-1 and 2108N) based on the computational requirements of the workload. In some examples, the included components are interconnected via an interconnect structure that links to each of the components. In some examples, thread execution logic 2100 includes one or more connections to a memory (such as system memory or cache memory) through instruction cache 2106, data port 2114, sampler 2110, and one or more of execution units 2108A-2108N. In some examples, each execution unit (e.g., 2108A) is a self-contained programmable general-purpose computing unit capable of executing multiple simultaneous hardware threads while processing multiple data elements in parallel for each thread. In various examples, the array of execution units 2108A-2108N is scalable to include any number of separate execution units.

[0208] In some examples, execution units 2108A-2108N are primarily used to execute shader programs. Shader processor 2102 can process various shader programs and can dispatch execution threads associated with shader programs via thread dispatcher 2104. In some examples, thread dispatcher includes logic for arbitrating thread initiation requests from graphics pipelines and media pipelines and instantiating the requested threads on one or more execution units in execution units 2108A-2108N. For example, a geometry pipeline can dispatch vertex shaders, tessellation shaders, or geometry shaders to thread execution logic for processing. In some examples, thread dispatcher 2104 can also handle runtime thread generation requests from executed shader programs.

[0209] In some examples, execution units 2108A-2108N support an instruction set including native support for many standard 3D graphics shader instructions, so that shader programs from graphics libraries (e.g., Direct 3D and OpenGL) are executed with minimal translation. These 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 processing (e.g., compute and media shaders). Each execution unit in execution units 2108A-2108N is capable of multi-issue single instruction multiple data (SIMD) execution, and multi-threaded operations enable efficient execution environments in the face of high latency memory accesses. Each hardware thread within each execution unit has a dedicated high-bandwidth register stack and an associated independent thread state. For pipelines capable of integer operations, single-precision floating-point operations, and double-precision floating-point operations, capable of SIMD branching capabilities, capable of logical operations, capable of transcendental operations, and capable of other miscellaneous operations, execution is multi-issued for each clock. While waiting for data from a shared function in memory or a shared function, the dependency logic within the execution unit 2108A-2108N puts the waiting thread to sleep until the requested data has been returned. While the waiting thread is sleeping, hardware resources can be dedicated to processing other threads. For example, during the delay period associated with the vertex shader operation, the execution unit can perform operations for a pixel shader, a fragment shader, or another type of shader program including different vertex shaders. Each example can be applied to use execution using single instruction multiple threads (Single Instruction Multiple Thread, SIMT) as an alternative to the use of SIMD, or as an addition to the use of SIMD. References to SIMD cores or operations can also be applied to SIMT, or to a combination of SIMD and SIMT.

[0210] Each of the execution units 2108A-2108N operates on an array of data elements. The number of data elements is the "execution size," or number of lanes for an instruction. An execution lane is a logical unit used for the execution of data element access, masking, and flow control within an instruction. The number of lanes may be independent of the number of physical arithmetic logic units (ALUs) or floating point units (FPUs) used for a particular graphics processor. In some examples, the execution units 2108A-2108N support integer and floating point data types.

[0211] The execution unit instruction set includes SIMD instructions. Various data elements can be stored in registers as compact data types, and the execution unit will process various elements based on the data size of the element. For example, when a 256-bit wide vector is operated, the 256 bits of the vector are stored in registers, and the execution unit operates the vector as four independent 64-bit compact data elements (quad-word (Quad-Word, QW) size data elements), eight independent 32-bit compact data elements (double-word (Double Word, DW) size data elements), sixteen independent 16-bit compact data elements (word (Word, W) size data elements) or thirty-two independent 8-bit data elements (byte (byte, B) size data elements). However, different vector widths and register sizes are possible.

[0212] In some examples, one or more execution units may be combined into a fused execution unit 2109A-2109N having a thread control logic (2107A-2107N) common to the fused EU. Multiple EUs may be fused into a EU group. Each EU in a fused EU group may be configured to execute a separate SIMD hardware thread. The number of EUs in a fused EU group may vary according to the example. Additionally, various SIMD widths may be executed EU by EU, including but not limited to SIMD8, SIMD16, and SIMD32. Each fused graphics execution unit 2109A-2109N includes at least two execution units. For example, a fused execution unit 2109A includes a first EU 2108A, a second EU 2108B, and a thread control logic 2107A common to the first EU 2108A and the second EU 2108B. Thread control logic 2107A controls threads executing on the fused graphics execution unit 2109A, allowing each EU within the fused execution units 2109A-2109N to execute using a common instruction pointer register.

[0213] One or more internal instruction caches (e.g., 2106) are included in the thread execution logic 2100 to cache thread instructions for the execution unit. In some examples, one or more data caches (e.g., 2112) are included to cache thread data during thread execution. Threads executed on the execution logic 2100 may also store explicitly managed data in the shared local memory 2111. In some examples, a sampler 2110 is included to provide texture sampling for 3D operations and media sampling for media operations. In some examples, the sampler 2110 includes specialized texture or media sampling functions to process texture data or media data during the sampling process before providing the sampled data to the execution unit.

[0214] During execution, the graphics pipeline and the media pipeline send thread initiation requests to the thread execution logic 2100 via the thread generation and dispatch logic. Once the group of geometric objects has been processed and rasterized into pixel data, the pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within the shader processor 2102 is called to further calculate output information and cause the results to be written to the output surface (e.g., color buffer, depth buffer, stencil buffer, etc.). In some examples, the pixel shader or fragment shader calculates the value of each vertex attribute, and the value of each vertex attribute is interpolated across the rasterized object. In some examples, the pixel processor logic within the shader processor 2102 then executes the pixel shader program or fragment shader program supplied by the application programming interface (API). To execute the shader program, the shader processor 2102 dispatches the thread to the execution unit (e.g., 2108A) via the thread dispatcher 2104. In some examples, the shader processor 2102 uses the texture sampling logic in the sampler 2110 to access the texture data in the texture map stored in the memory. Arithmetic operations on texture data and input geometry data compute pixel color data for each geometry fragment, or discard one or more pixels without further processing.

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

[0216] In some examples, the execution logic 2100 may also include a ray tracer 2105 that may provide ray tracing acceleration functionality. The ray tracer 2105 may support a ray tracing instruction set that includes instructions / functions for ray generation.

[0217] Fig.21B21. The graphics execution unit 2108 may include an instruction fetch unit 2137, a general register file array (GRF) 2124, an architectural register file array (ARF) 2126, a thread arbiter 2122, an issue unit 2130, a branch unit 2132, a set of SIMD floating point units (FPUs) 2134, and a set of dedicated integer SIMD ALUs 2135 in some examples. The GRF 2124 and ARF 2126 include a set of general register files and architectural register files associated with each simultaneous hardware thread that can be active in the graphics execution unit 2108. In some examples, a per-thread architectural state is maintained in the ARF 2126, while data used during thread execution is stored in the GRF 2124. The execution state of each thread, including the instruction pointer for each thread, can be saved in thread-specific registers in the ARF 2126.

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

[0219] In some examples, the graphics execution unit 2102 may issue multiple instructions in coordination, each of which may be a different instruction. The thread arbiter 2122 of the graphics execution unit thread 2108 may dispatch the instruction to one of the send unit 2130, the branch unit 2132, or (one or more) SIMD FPUs 2134 for execution. Each execution thread may access 128 general registers within the GRF 2124, wherein each register may store 32 bytes accessible as a SIMD 8 element vector with 32-bit data elements. In some examples, each execution unit thread has access to 4 kilobytes within the GRF 2124, but the examples are not limited thereto, and more or less register resources may be provided in other examples. In some examples, the graphics execution unit 2108 is partitioned into seven hardware threads that can independently perform computing operations, but the number of threads of each execution unit may also vary according to the example. For example, in some examples, up to 16 hardware threads are supported. In an example where seven threads can access 4 kilobytes, GRF 2124 can store a total of 28 kilobytes. Where 16 threads can access 4 kilobytes, GRF 2124 can store a total of 64 kilobytes. Flexible addressing modes can permit registers to be addressed together, effectively creating wider registers or representing strided rectangular block data structures.

[0220] In some examples, memory operations, sampler operations, and other longer latency system communications are dispatched via "send" instructions executed by the message passing send unit 2130. In some examples, branch instructions are dispatched to a dedicated branch unit 2132 to facilitate SIMD scatter and eventual convergence.

[0221] In some examples, graphics execution unit 2108 includes one or more SIMD floating point units (FPU(s)) 2134 for performing floating point operations. In some examples, FPU(s) 2134 also support integer computations. In some examples, FPU(s) 2134 can SIMD perform up to M 32-bit floating point (or integer) operations, or SIMD perform up to 2M 16-bit integer or 16-bit floating point operations. In some examples, at least one of the FPU(s) provides extended math capabilities that support high throughput transcendental math functions and double precision 64-bit floating point. In some examples, a set 2135 of 8-bit integer SIMD ALUs are also present and can be specifically optimized to perform operations associated with machine learning computations.

[0222] In some examples, an array of multiple instances of graphics execution unit 2108 may be instantiated in graphics sub-core groupings (e.g., sub-slices). For scalability, product architects may choose the exact number of execution units per sub-core grouping. In some examples, execution unit 2108 may execute instructions across multiple execution lanes. In further examples, each thread executed on graphics execution unit 2108 is executed on a different lane.

[0223] Fig. 22 An additional execution unit 2200 according to an example is illustrated. In some examples, the execution unit 2200 includes a thread control unit 2201, a thread state unit 2202, an instruction fetch / prefetch unit 2203, and an instruction decode unit 2204. The execution unit 2200 additionally includes a register file 2206 that stores registers that can be assigned to hardware threads within the execution unit. The execution unit 2200 additionally includes a dispatch unit 2207 and a branch unit 2208. In some examples, the dispatch unit 2207 and the branch unit 2208 can be used in conjunction with Fig.21B The send unit 2130 and branch unit 2132 of the graphics execution unit 2108 operate in a similar manner.

[0224] The execution unit 2200 also includes a computing unit 2210, which includes a plurality of different types of functional units. In some examples, the computing unit 2210 includes an ALU unit 2211, which includes an array of arithmetic logic units. The ALU unit 2211 can be configured to perform 64-bit, 32-bit, and 16-bit integer and floating-point operations. Integer and floating-point operations can be performed simultaneously. The computing unit 2210 may also include a systolic array 2212 and a mathematical unit 2213. The systolic array 2212 includes a wide W and deep D network of data processing units, which can be used to perform vector or other data parallel operations in a systolic manner. In some examples, the systolic array 2212 may be configured to perform matrix operations, such as matrix dot product operations. In some examples, the systolic array 2212 supports 16-bit floating-point operations and 8-bit and 4-bit integer operations. In some examples, the systolic array 2212 may be configured to accelerate machine learning operations. In such examples, systolic array 2212 may be configured with support for bfloat 16-bit floating point format. In some examples, math unit 2213 may be included to perform a specific subset of math operations in an efficient and lower power manner than ALU unit 2211. Math unit 2213 may include a variation of math logic that may be found in shared function logic of a graphics processing engine provided by other examples. In some examples, math unit 2213 may be configured to perform 32-bit and 64-bit floating point operations.

[0225] Thread control unit 2201 includes logic for controlling the execution of threads within execution units. Thread control unit 2201 may include thread arbitration logic for starting, stopping, and preempting the execution of threads within execution unit 2200. Thread state unit 2202 may be used to store thread states for threads assigned to execute on execution unit 2200. Storing thread states within execution unit 2200 enables quick preemption of threads when they become blocked or idle. Instruction fetch / prefetch unit 2203 may fetch instructions from instruction caches of higher level execution logic (e.g., Fig.21A The instruction fetch / prefetch unit 2203 may also issue a prefetch request for instructions to be loaded into the instruction cache based on an analysis of the currently executing thread. The instruction decode unit 2204 may be used to decode instructions to be executed by the computing unit. In some examples, the instruction decode unit 2204 may be used as a secondary decoder to decode complex instructions into constituent micro-operations.

[0226] The execution unit 2200 additionally includes a register file 2206 that can be used by hardware threads executing on the execution unit 2200. The registers in the register file 2206 can be divided across logic used to execute multiple simultaneous threads within the compute unit 2210 of the execution unit 2200. The number of logical threads that can be executed by the graphics execution unit 2200 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 2206 can vary across examples based on the number of hardware threads supported. In some examples, register renaming can be used to dynamically assign registers to hardware threads.

[0227] Fig.23 23 is a block diagram illustrating a graphics processor instruction format 2300 according to some examples. In one or more examples, a graphics processor execution unit supports an instruction set having instructions in a variety of formats. Solid line boxes illustrate components that are typically included in execution unit instructions, while dashed lines include components that are optional or included only in a subset of instructions. In some examples, instruction format 2300 are macroinstructions in that they are instructions supplied to the execution unit, as opposed to micro-operations that result from instruction decoding that is performed once the instruction is processed.

[0228] In some examples, the graphics processor execution unit may natively support instructions in a 128-bit instruction format 2310. Based on the selected instructions, instruction options, and the number of operands, a 64-bit compact instruction format 2330 may be used for some instructions. The native 128-bit instruction format 2310 provides access to all instruction options, while some options and operations are limited in the 64-bit format 2330. The native instructions available in the 64-bit format 2330 vary from example to example. In some examples, instructions are partially compressed using a set of index values ​​in an index field 2313. The execution unit hardware references a set of compression tables based on the index values ​​and uses the compression table output to reconstruct the native instructions of the 128-bit instruction format 2310. Instructions of other sizes and formats may be used.

[0229] For each format, the instruction opcode 2312 defines the operation to be performed by the execution unit. The execution unit executes each instruction in parallel across multiple data elements of each operand. For example, in response to an addition instruction, the execution unit performs a synchronous addition operation across each color channel representing a texture element or a picture element. By default, the execution unit executes each instruction across all data channels of the operand. In some examples, the instruction control field 2314 enables control of certain execution options (such as channel selection (e.g., predicates) and data channel order (e.g., swizzle)). For instructions in the 128-bit instruction format 2310, the execution size field 2316 limits the number of data channels that will be executed in parallel. In some examples, the execution size field 2316 is not available for the 64-bit compact instruction format 2330.

[0230] Some execution unit instructions have up to three operands, including two source operands src0 2320, src1 2322, and one destination 2318. In some examples, the execution unit supports dual destination instructions, where one of the destinations is implicit. Data manipulation instructions may have a third source operand (e.g., SRC2 2324), where the instruction opcode 2312 determines the number of source operands. The last source operand of an instruction may be an immediate (e.g., hard-coded) value passed with the instruction.

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

[0232] In some examples, the 128-bit instruction format 2310 includes an access / addressing mode field 2326, which specifies the addressing mode and / or access mode of the instruction. In some examples, the access mode can be used to limit the data access alignment of the instruction. Some examples support access modes including 16-byte aligned access modes and 1-byte aligned access modes, wherein the byte alignment of the access mode determines the access alignment of the instruction operand. For example, when in the first mode, the instruction can use byte-aligned addressing for source operands and destination operands, and when in the second mode, the instruction can use 16-byte aligned addressing for all source operands and destination operands.

[0233] In some examples, the addressing mode portion of the access / addressing mode field 2326 determines whether the instruction uses direct addressing or indirect addressing. When direct register addressing mode is used, the bits in the instruction directly provide the register address of one or more operands. When indirect register addressing mode is used, the register address of one or more operands can be calculated based on the address register value and the address immediate field in the instruction.

[0234] In some examples, instructions are grouped based on the opcode 2312 bit field to simplify opcode decoding 2340. For 8-bit opcodes, bit 4, bit 5, and bit 6 allow the execution unit to determine the type of opcode. The exact opcode grouping shown is only an example. In some examples, the move and logic opcode group 2342 includes data movement and logic instructions (e.g., move (mov), compare (cmp)). In some examples, the move and logic group 2342 shares five most significant bits (most significant bit, MSB), wherein the move (mov) instruction adopts the form of 0000xxxxb, and the logic instruction adopts the form of 0001xxxxb. The flow control instruction group 2344 (e.g., call (call), jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 2346 includes a mixture of instructions, including synchronization instructions (e.g., wait (wait), send (send)) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group 2348 includes component-by-component arithmetic instructions (e.g., addition, multiplication (mul)) of the form 0100xxxxb (e.g., 0x40). The parallel math group 2348 performs arithmetic operations in parallel across data channels. The vector math group 2350 includes arithmetic instructions (e.g., dp4) of the form 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic on vector operands, such as dot product calculations. In some examples, the illustrated opcode decode 2340 can be used to determine which portion of the execution unit will be used to execute the decoded instructions. For example, some instructions may be designated as systolic instructions to be executed by a systolic array. Other instructions, such as ray tracing instructions (not shown), may be routed to a ray tracing core or ray tracing logic within a slice or partition of the execution logic. Graphics Pipeline

[0235] Fig.24 is a block diagram of another example of a graphics processor 2400 . Fig.24 Elements having the same reference numeral (or name) as elements of any other figure herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0236] In some examples, graphics processor 2400 includes geometry pipeline 2420, media pipeline 2430, display engine 2440, thread execution logic 2450, and render output pipeline 2470. In some examples, graphics processor 2400 is a graphics processor within a multi-core processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writes to one or more control registers (not shown) or via commands issued to graphics processor 2400 through ring interconnect 2402. In some examples, ring interconnect 2402 couples graphics processor 2400 to other processing components (such as other graphics processors or general-purpose processors). Commands from ring interconnect 2402 are interpreted by command stream converter 2403, which supplies instructions to various components of geometry pipeline 2420 or media pipeline 2430.

[0237] In some examples, command stream converter 2403 directs the operation of vertex fetcher 2405, which reads vertex data from memory and executes vertex processing commands provided by command stream converter 2403. In some examples, vertex fetcher 2405 provides vertex data to vertex shader 2407, which performs coordinate space transformation and lighting operations on each vertex. In some examples, vertex fetcher 2405 and vertex shader 2407 can execute vertex processing instructions by dispatching execution threads to execution units 2452A-2452B via thread dispatcher 2431.

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

[0239] In some examples, the geometry pipeline 2420 includes a tessellation component for performing hardware-accelerated tessellation of 3D objects. In some examples, the programmable shell shader 2411 configures the tessellation operation. The programmable domain shader 2417 provides back-end evaluation of the tessellation output. The tessellation 2413 operates under the direction of the shell shader 2411 and contains dedicated logic for generating a detailed set of geometric objects based on a coarse geometric model that is provided as input to the geometry pipeline 2420. In some examples, if tessellation is not used, the tessellation components (e.g., the shell shader 2411, the tessellation 2413, and the domain shader 2417) can be bypassed.

[0240] In some examples, the complete geometric object may be processed by the geometry shader 2419 via one or more threads dispatched to execution units 2452A-2452B, or may proceed directly to the clipper 2429. In some examples, the geometry shader operates on the entire geometric object, rather than on vertices or patches of vertices as in previous stages of the graphics pipeline. If tessellation is disabled, the geometry shader 2419 receives input from the vertex shader 2407. In some examples, the geometry shader 2419 is programmable by a geometry shader program to perform geometry tessellation when the tessellation unit is disabled.

[0241] Before rasterization, the clipper 2429 processes the vertex data. The clipper 2429 can be a fixed function clipper or a programmable clipper with clipping and geometry shader functions. In some examples, the rasterizer and depth test component 2473 in the render output pipeline 2470 dispatches a pixel shader to convert the geometric object into a pixel-by-pixel representation. In some examples, the pixel shader logic is included in the thread execution logic 2450. In some examples, the application can bypass the rasterizer and depth test component 2473 and access the unrasterized vertex data via the outflow unit 2423.

[0242] The graphics processor 2400 has an interconnect bus, an interconnect structure, or some other interconnect mechanism that allows data and messages to be passed between the main components of the processor. In some examples, the execution units 2452A-2452B and associated logic units (e.g., L1 cache 2451, sampler 2454, texture cache 2458, etc.) are interconnected via data ports 2456 to perform memory accesses and communicate with the rendering output pipeline components of the processor. In some examples, the sampler 2454, cache 2451, 2458, and execution units 2452A-2452B each have a separate memory access path. In some examples, the texture cache 2458 can also be configured as a sampler cache.

[0243] In some examples, the render output pipeline 2470 includes a rasterizer and depth test component 2473 that converts vertex-based objects into associated pixel-based representations. In some examples, the rasterizer logic includes a windower / masker unit for performing fixed-function triangle and line rasterization. In some examples, an associated render buffer 2478 and depth buffer 2479 are also available. The pixel operation component 2477 performs pixel-based operations on data, but in some instances, pixel operations associated with 2D operations (e.g., using mixed bit block image transfers) are performed by the 2D engine 2441, or replaced by the display controller 2443 using an overlay display plane when displaying. In some examples, a shared L3 cache 2475 can be used for all graphics components, allowing data to be shared without using main system memory.

[0244] In some examples, the graphics processor media pipeline 2430 includes a media engine 2437 and a video front end 2434. In some examples, the video front end 2434 receives pipeline commands from the command stream converter 2403. In some examples, the media pipeline 2430 includes a separate command stream converter. In some examples, the video front end 2434 processes the media commands before sending them to the media engine 2437. In some examples, the media engine 2437 includes a thread generation function for generating threads for dispatching to the thread execution logic 2450 via the thread dispatcher 2431.

[0245] In some examples, the graphics processor 2400 includes a display engine 2440. In some examples, the display engine 2440 is external to the processor 2400 and is coupled to the graphics processor via a ring interconnect 2402, or some other interconnect bus or structure. In some examples, the display engine 2440 includes a 2D engine 2441 and a display controller 2443. In some examples, the display engine 2440 contains dedicated logic that can operate independently of the 3D pipeline. In some examples, the display controller 2443 is coupled to a display device (not shown), which can be a system-integrated display device such as in a laptop or an external display device attached via a display device connector.

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

[0247] Fig.25A is a block diagram of a graphics processor command format 2500 according to some examples. Fig.25B is a block diagram illustrating a graphics processor command sequence 2510 according to an example. Fig.25A The solid-line boxes in illustrate components that are generally included in the graphics commands, while the dashed lines include components that are optional or included only in a subset of the graphics commands. Fig.25A An exemplary graphics processor command format 2500 includes data fields for identifying the client 2502 of the command, a command operation code (opcode) 2504, and data 2506. Subopcodes 2505 and command sizes 2508 are also included in some commands.

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

[0249] Fig.25B 2510. In some examples, software or firmware of a data processing system featuring an example of a graphics processor may use a version of the command sequence shown to establish, execute, and terminate a set of graphics operations. The sample command sequence is shown and described for example purposes only, as the examples are not limited to these particular commands or command sequences. In addition, commands may be issued as batches of commands in a command sequence so that the graphics processor will process the command sequence in an at least partially concurrent manner.

[0250] In some examples, the graphics processor command sequence 2510 can begin with a pipeline flush command 2512 to cause any active graphics pipeline to complete currently pending commands for the pipeline. In some examples, the 3D pipeline 2522 and the media pipeline 2524 do not operate concurrently. The pipeline flush is performed to cause the active graphics pipeline to complete any pending commands. In response to the pipeline flush, the command parser for the graphics processor will suspend command processing until the active drawing engine completes pending operations and the associated read cache is invalidated. Optionally, any data marked as "dirty" in the rendering cache can be flushed to memory. In some examples, the pipeline flush command 2512 can be used for pipeline synchronization, or can be used before placing the graphics processor in a low power state.

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

[0252] In some examples, pipeline control commands 2514 configure the graphics pipeline for operation and are used to program 3D pipeline 2522 and media pipeline 2524. In some examples, pipeline control commands 2514 configure pipeline states for active pipelines. In some examples, pipeline control commands 2514 are used for pipeline synchronization and for clearing data from one or more cache memories within an active pipeline before processing a batch of commands.

[0253] In some examples, return buffer state commands 2516 are used to configure a set of return buffers for a corresponding pipeline for writing data. Some pipeline operations require the allocation, selection, or configuration of one or more return buffers into which the operation writes intermediate data during processing. In some examples, a graphics processor also uses one or more return buffers to store output data and perform cross-thread communication. In some examples, return buffer state 2516 includes selecting the size and number of return buffers to be used for a set of pipeline operations.

[0254] The remaining commands in the command sequence differ based on the active pipeline for operation.Based on pipeline decision 2520 , the command sequence is tailored for either the 3D pipeline 2522 starting at 3D pipeline state 2530 , or the media pipeline 2524 starting at media pipeline state 2540 .

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

[0256] In some examples, the 3D primitive 2532 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 2532 command are forwarded to the vertex acquisition function in the graphics pipeline. The vertex acquisition function uses the 3D primitive 2532 command data to generate a vertex data structure. The vertex data structure is stored in one or more return buffers. In some examples, the 3D primitive 2532 command is used to perform vertex operations on the 3D primitive via a vertex shader. In order to process the vertex shader, the 3D pipeline 2522 dispatches the shader execution thread to the graphics processor execution unit.

[0257] In some examples, the 3D pipeline 2522 is triggered via an execute 2534 command or event. In some examples, a register input triggers command execution. In some examples, execution is triggered via a "go" or "kick" command in a command sequence. In some examples, command execution is triggered using a pipeline synchronization command to flush the command sequence through the graphics pipeline. The 3D pipeline will perform geometry processing for 3D primitives. Once the operation is completed, the resulting geometric objects are rasterized and the pixel engine shades the resulting pixels. For those operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0258] In some examples, when performing media operations, the graphics processor command sequence 2510 follows the media pipeline 2524 path. In general, the specific purpose and manner of programming the media pipeline 2524 depends on the media or computing operations to be performed. During media decoding, specific media decoding operations can be migrated to the media pipeline. In some examples, the media pipeline can also be bypassed, and the media decoding can be performed in whole or in part using resources provided by one or more general processing cores. In some examples, the media pipeline also includes elements for general purpose graphics processor unit (GPGPU) operations, wherein the graphics processor is used to perform SIMD vector operations using compute shader programs that are not explicitly related to the rendering of graphics primitives.

[0259] In some examples, the media pipeline 2524 is configured in a similar manner as the 3D pipeline 2522. A set of commands for configuring the media pipeline state 2540 is dispatched or placed into a command queue before the media object commands 2542. In some examples, the commands for the media pipeline state 2540 include data for configuring the media pipeline elements that will be used to process the media objects. This includes data for configuring video decoding and video encoding logic within the media pipeline, such as encoding or decoding formats. In some examples, the commands for the media pipeline state 2540 also support the use of one or more pointers to an "indirect" state element that contains a batch of state settings.

[0260] In some examples, media object commands 2542 supply a pointer to a media object for processing by the media pipeline. The media object includes a memory buffer that contains video data to be processed. In some examples, all media pipeline states must be valid before issuing media object commands 2542. Once the pipeline state is configured and media object commands 2542 are queued, media pipeline 2524 is triggered via an execute command 2544 or an equivalent execution event (e.g., a register write). The output from media pipeline 2524 can then be post-processed by operations provided by 3D pipeline 2522 or media pipeline 2524. In some examples, GPGPU operations are configured and executed in a manner similar to media operations.

[0261] Program code can be applied to input information to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the present application, the processing system includes any system having a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor, or any combination thereof.

[0262] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0263] Examples of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of these implementation approaches. Examples can be implemented as computer programs or program codes, executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0264] These machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of items manufactured or formed by a machine or device, including storage media such as: hard disks, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM)), magnetic cards or optical cards, or any other type of medium suitable for storing electronic instructions.

[0265] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or design data, such as hardware description languages ​​(HDL), that define the structures, circuits, devices, processors and / or system features described herein. Such examples may also be referred to as program products. Emulation (including binary translation, code deformation, etc.)

[0266] In some cases, the instruction converter can be used to convert instructions from a source instruction set architecture to a target instruction set architecture. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0267] Fig.26The block diagram of using a software instruction converter to convert binary instructions in a source ISA into binary instructions in a target ISA according to an example is illustrated. In the illustrated example, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.26 It is shown that a program in a high-level language 2602 can be compiled using a first ISA compiler 2604 to generate first ISA binary code 2606 that can be natively executed by a processor having at least one first ISA core 2616. The processor having at least one first ISA core 2616 represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the first ISA or (2) a program that is natively executed by a processor having at least one first ISA core. The first ISA compiler 2604 represents a compiler operable to generate first ISA binary code 2606 (e.g., object code) that can be executed on a processor 2616 having at least one first ISA core with or without additional linking processing. Similarly, Fig.26 It is shown that a program in a high-level language 2602 can be compiled using an alternative ISA compiler 2608 to generate an alternative ISA binary code 2610, which can be executed natively by a processor 2614 without a first ISA core. An instruction converter 2612 is used to convert the first ISA binary code 2606 into code that can be executed natively by a processor 2614 without a first ISA core. This converted code is not necessarily the same as the alternative ISA binary code 2610; however, the converted code will implement the overall operation and be composed of instructions from the alternative ISA. Thus, the instruction converter 2612 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device that does not have a first ISA processor or core to execute the first ISA binary code 2606 through simulation, emulation, or any other process. IP core implementation

[0268] One or more aspects of at least some examples may be implemented by representative code stored on a machine-readable medium that represents and / or defines logic within an integrated circuit (such as a processor). For example, a machine-readable medium may include instructions representing various logic within a processor. When read by a machine, the instructions may cause the machine to manufacture logic for performing the techniques described herein. Such representations (referred to as "IP cores") are reusable units of logic for an integrated circuit that can be stored on a tangible, machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model may be supplied to each customer or manufacturing facility that loads the hardware model on a manufacturing machine that manufactures the integrated circuit. The integrated circuit may be manufactured so that the circuit performs the operations described in association with any of the examples described herein.

[0269] Fig. 27 27 is a block diagram illustrating an IP core development system 2700 that can be used to manufacture an integrated circuit to perform operations according to some examples. The IP core development system 2700 can be used to generate modular, reusable designs that can be incorporated into a larger design or used to build an entire integrated circuit (e.g., a SOC integrated circuit). The design facility 2730 can generate a software simulation 2710 of the IP core design in a high-level programming language (e.g., C / C++). The software simulation 2710 can be used to design, test, and verify the behavior of the IP core using a simulation model 2712. The simulation model 2712 can include functional simulation, behavioral simulation, and / or timing simulation. A register transfer level (RTL) design 2715 can then be created or synthesized from the simulation model 2712. The RTL design 2715 is an abstraction of the behavior of an integrated circuit (including associated logic executed using the modeled digital signals) that models the flow of digital signals between hardware registers. In addition to the RTL design 2715, a lower level design at the logic level or transistor level can also be created, designed, or synthesized. Thus, the specific details of the initial design and simulation can be different.

[0270] The RTL design 2715 or equivalent may be further synthesized by the design facility into a hardware model 2720, which may be in a hardware description language (HDL) or some other representation of physical design data. The HDL may be further simulated or tested to verify the IP core design. The IP core design may be stored using a non-volatile memory 2740 (e.g., a hard disk, flash memory, or any non-volatile storage medium) for delivery to a third-party manufacturing facility 2765. Alternatively, the IP core design may be transmitted via a wired connection 2750 or a wireless connection 2760 (e.g., via the Internet). The manufacturing facility 2765 may then manufacture an integrated circuit based at least in part on the IP core design. The manufactured integrated circuit may be configured to perform operations according to at least some of the examples described herein.

[0271] References to "some examples," "examples," etc. indicate that the examples described may include a particular feature, structure, or characteristic, but not every example may necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same example. In addition, when a particular feature, structure, or characteristic is described in conjunction with an example, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other examples, whether or not explicitly described.

[0272] Examples include, but are not limited to: 1. A device comprising: Decoder circuitry for decoding an instance of a single instruction, the instance of the single instruction comprising one or more fields for an opcode, one or more fields for indicating a source operand location, and one or more fields for indicating a destination operand location, wherein the opcode is for indicating that a data element of an indicated size of 16 bits or 32 bits is to be copied from the indicated source operand location to the indicated destination operand location, wherein: 1) when the indicated source operand location is a packed data register and the indicated destination operand location is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand location and the data element to be copied to the indicated destination operand location is the least significant data element position of the indicated source operand location; 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position, and the data element is to be copied into the memory location; and 2) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position, and the data element is to be copied into the memory location; and 3) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element of the memory location is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; and Execution circuitry for executing the decoded, single instruction instance in accordance with the opcode. 2. The apparatus of Example 1, wherein one or more fields indicate a source operand location for identifying a vector register. 3. The apparatus of Example 2, wherein the vector register is at least 128 bits and includes a plurality of data elements. 4. The apparatus of example 3, wherein support for 128-bit registers is indicated by a field in a CVISA leaf. 5. The apparatus of Example 1, wherein one or more fields indicate a source operation object location for identifying a memory location. 6. The apparatus of any one of Examples 1-5, wherein the instance of the single instruction further comprises a prefix, and bits 21 and 22 of the prefix are 0, and bits 11-14 of the prefix are 1. 7. An apparatus as described in any of Examples 1-6, wherein the data elements are integer values. 8. An apparatus as described in any of Examples 1-6, wherein the data elements are floating point values. 9. An apparatus as described in any of Examples 1-8, wherein the decoder circuit system and execution circuit are used to support other instructions. 10. The device of any one of Examples 1-9, further comprising: Scheduling circuitry is provided for scheduling execution of decoded instances of a single instruction. 11. A non-transitory machine-readable medium storing at least a single instance of an instruction, the single instance of the instruction being used when executed by a processor to cause a method to be performed, the method comprising: Decoding an instance of a single instruction, the instance of the single instruction including one or more fields for an opcode, one or more fields for indicating a source operand location, and one or more fields for indicating a destination operand location, wherein the opcode is used to indicate that a data element having an indicated size of 16 bits or 32 bits is to be copied from the indicated source operand to the indicated destination operand location, wherein: 1) when the indicated source operand location is a packed data register and the indicated destination operand location is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand location and the data element to be copied is the least significant data element position of the indicated destination operand location; 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position, and the data element is to be copied into the memory location; and 2) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position, and the data element is to be copied into the memory location; and 3) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element of the memory location is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; and An instance of a decoded, single instruction is executed according to the opcode. 12. The non-transitory machine-readable medium of example 11, wherein the one or more fields indicate a source operand location identifying a vector register. 13. The non-transitory machine-readable medium of example 12, wherein the vector register is at least 128 bits and includes a plurality of data elements. 14. The non-transitory machine-readable medium of example 13, wherein support for 128-bit registers is indicated by a field in a CVISA leaf. 15. The non-transitory machine-readable medium of example 11, wherein one or more fields indicate a source operand location identifying a memory location. 16. The non-transitory machine-readable medium of any of Examples 11-15, wherein the instance of the single instruction further comprises a prefix, and bits 21 and 22 of the prefix are 0, and bits 11-14 of the prefix are 1. 17. The non-transitory machine-readable medium of any of Examples 11-16, wherein the data elements are integer values. 18. The non-transitory machine-readable medium of any of Examples 11-16, wherein the data elements are floating point values. 19. A system comprising: A memory for storing instances of individual instructions; Decoder circuitry for decoding an instance of a single instruction, the instance of the single instruction comprising one or more fields for an opcode, one or more fields for indicating a source operand location, and one or more fields for indicating a destination operand location, wherein the opcode is for indicating that a data element of an indicated size of 16 bits or 32 bits is to be copied from the indicated source operand location to the indicated destination operand location, wherein: 1) when the indicated source operand location is a packed data register and the indicated destination operand location is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand location and the data element to be copied to the indicated destination operand location is the least significant data element position of the indicated source operand location; 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position, and the data element is to be copied into the memory location; and 2) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position, and the data element is to be copied into the memory location; and 3) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element of the memory location is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; and Execution circuitry for executing the decoded, single instruction instance in accordance with the opcode. 20. The system of example 19, wherein the instance of the single instruction further comprises a prefix, and bits 21 and 22 of the prefix are 0, and bits 11-14 of the prefix are 1.

[0273] Furthermore, in the examples described above, unless specifically noted otherwise, separating language such as phrases "at least one of A, B, or C" or "A, B and / or C" are intended to be understood to mean A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B and C).

[0274] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the claims.

Claims

1. A device comprising: A decoder circuit system for decoding an instance of a single instruction, the instance of the single instruction including one or more fields for an opcode, one or more fields for indicating a source operand location, and one or more fields for indicating a destination operand location, wherein the opcode is used to indicate that a data element of an indicated size of 16 bits or 32 bits is to be copied from the indicated source operand location to the indicated destination operand location, wherein: 1) when the indicated source operand location is a packed data register and the indicated destination operand location is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand location and the data element is to be copied to the least significant data element position of the indicated destination operand location; ) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and the data element is to be copied into the memory location; and 3) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element of the memory location is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; and Execution circuitry is provided for executing the decoded instance of the single instruction in accordance with the opcode.

2. The device according to claim 1, wherein: One or more fields indicate a source operand location that identifies a vector register.

3. The device as claimed in claim 2, wherein: The vector register is at least 128 bits and includes a plurality of data elements.

4. The device according to claim 3, wherein: Support for 128-bit registers is indicated by a field in the CVISA leaf.

5. The device according to claim 1, wherein: One or more fields indicate a source operand location identifying a memory location.

6. The device according to any one of claims 1 to 5, wherein: The instance of the single instruction further includes a prefix, and bits 21 and 22 of the prefix are 0, and bits 11-14 of the prefix are 1.

7. The device according to any one of claims 1 to 6, wherein: The data elements are integer values.

8. The device according to any one of claims 1 to 6, wherein: The data elements are floating point values.

9. The device according to any one of claims 1 to 8, wherein: The decoder circuitry and the execution circuitry are used to support other instructions.

10. The apparatus of any one of claims 1 to 9, further comprising: Scheduling circuitry is provided for scheduling execution of instances of the decoded, single instruction.

11. A non-transitory machine-readable medium storing at least a single instance of an instruction, the single instance of the instruction being used when processed by a processor to cause a method to be performed, the method comprising: decoding an instance of the single instruction, the instance of the single instruction comprising one or more fields for an opcode, one or more fields for indicating a source operand location, and one or more fields for indicating a destination operand location, wherein the opcode is used to indicate that a data element having an indicated size of 16 bits or 32 bits is to be copied from the indicated source operand to the indicated destination operand location, wherein: 1) when the indicated source operand location is a packed data register and the indicated destination operand location is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand location and the data element is to be copied to the least significant data element of the indicated destination operand location 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and the data element is to be copied into the memory location; and 2) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and the data element is to be copied into the memory location; and 3) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element of the memory location is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; and A decoded, single instruction instance is executed according to the opcode.

12. The non-transitory machine-readable medium of claim 11, wherein: One or more fields indicate a source operand location that identifies a vector register.

13. The non-transitory machine-readable medium of claim 12, wherein: The vector register is at least 128 bits and includes a plurality of data elements.

14. The non-transitory machine-readable medium of claim 13, wherein: Support for 128-bit registers is indicated by a field in the CVISA leaf.

15. The non-transitory machine-readable medium of claim 11, wherein: One or more fields indicate a source operand location identifying a memory location.

16. The non-transitory machine-readable medium of any one of claims 11-15, wherein: The instance of the single instruction further includes a prefix, and bits 21 and 22 of the prefix are 0, and bits 11-14 of the prefix are 1.

17. The non-transitory machine-readable medium of any one of claims 11 to 16, wherein: The data elements are integer values.

18. The non-transitory machine-readable medium of any one of claims 11-16, wherein: The data elements are floating point values.

19. A system comprising: A memory for storing instances of individual instructions; A decoder circuit system for decoding an instance of the single instruction, the instance of the single instruction including one or more fields for an opcode, one or more fields for indicating a source operand position, and one or more fields for indicating a destination operand position, wherein the opcode is used to indicate that a data element having an indicated size of 16 bits or 32 bits is to be copied from the indicated source operand to the indicated destination operand position, wherein: 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and the data element is to be copied to the least significant data element position of the indicated destination operand position; 1) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and the data element is to be copied into the memory location; and 2) when the indicated source operand position is a packed data register and the indicated destination operand position is a memory location, the data element to be copied is the data element in the least significant data element position of the indicated source operand position and the data element is to be copied into the memory location; and 3) when the indicated source operand position is a packed data register and the indicated destination operand position is a packed data register, the data element of the memory location is to be copied into the least significant data element position of the indicated destination operand position, wherein all other data element positions of the indicated destination operand are to be zeroed; and Execution circuitry is provided for executing the decoded instance of the single instruction in accordance with the opcode.

20. The system of claim 19, wherein: The instance of the single instruction further includes a prefix, and bits 21 and 22 of the prefix are 0, and bits 11-14 of the prefix are 1.

Images