Supporting processing of operation objects less than 512 bits

Abstract

The invention relates to processing supporting less than 512-bit operation objects. Techniques for providing an operation object of 512 bits or less are described. In some examples, a prefix of an instruction is utilized to define an operand (vector) length. For example, an instruction includes at least fields for prefixes, opcodes, and operand addressing information, where the prefixes and addressing information are used by decoder circuitry to determine support for a particular vector length of one or more operand for an instance of a single instruction, and the operation code indicates one or more operations to be performed on the one or more operation objects.

Description

Technical Field

[0001] The present disclosure relates to supporting processing of operands smaller than 512 bits. Background Art

[0002] Processors support vector instructions of many different sizes. For example, some processors in the late 1990s supported 64-bit packed data (Single Instruction, Multiple Data, SIMD or vector) registers. Later processors support 128-bit, 256-bit, etc. vector instructions, and some processors support predicate / write masking. Summary of the invention

[0003] One aspect of the present disclosure provides a device, comprising: a decoder circuit for decoding an instance of a single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and the addressing information are used by the decoder circuit to determine support for a specific vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands; and an execution circuit for executing the decoded instance of the single instruction according to the opcode to perform one or more operations on the one or more operands having the determined vector length.

[0004] Another aspect of the present disclosure provides a system comprising: a memory for storing at least an instance of a single instruction; and a processor core, the processor core comprising: a decoder circuit for decoding the instance of the single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and the addressing information are used by the decoder circuit to determine support for a specific vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands, and an execution circuit for executing the decoded instance of the single instruction according to the opcode to perform one or more operations on the one or more operands having the determined vector length.

[0005] Another aspect of the present disclosure provides a method, comprising: decoding an instance of a single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and the addressing information are used by a decoder circuit to determine support for a specific vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands; and executing the decoded instance of the single instruction according to the opcode to perform one or more operations on the one or more operands having the determined vector length. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0007] Figure 1 An example of a processor having multiple cores is illustrated;

[0008] Figure 2 An example of an instruction format is illustrated.

[0009] Figure 3 An example of an addressing information field is illustrated.

[0010] Figure 4 An example of the third prefix is ​​illustrated.

[0011] Figure 5 An example of the settings of bit 20 and bit 10 of the prefix and how this defines the vector length and / or embeds rounding control is illustrated.

[0012] Figure 6 is a block diagram of a register architecture according to some examples.

[0013] Figure 7 Examples of write mask / predicate registers of different sizes are illustrated.

[0014] Figure 8 An example of computing hardware that processes instructions is illustrated.

[0015] Fig. 9 Example execution circuitry supporting up to 512-bit vector execution is illustrated.

[0016] Fig.10 An example method performed by a processor to process instructions is illustrated.

[0017] Fig.11 One example method of processing instructions using emulation or binary translation is illustrated.

[0018] Fig.12 An example computing system is illustrated.

[0019] Fig.13 Illustrated is a block diagram of an example processor and / or system on a chip (SoC) that may have one or more cores and with an integrated memory controller.

[0020] Fig.14 The block diagram of illustrates a computing system configured to implement one or more aspects of the examples described herein.

[0021] Fig.15A An example of a parallel processor is illustrated.

[0022] Fig. 15B An example of a block diagram of a partition unit is illustrated.

[0023] Fig. 15C An example of a block diagram of a processing cluster within a parallel processing unit is illustrated.

[0024] Fig.15D An example of a graphics multiprocessor is illustrated, where the graphics multiprocessor is coupled with a pipeline manager of a processing cluster.

[0025] Figures 16A-16C Additional graphics multiprocessors are illustrated according to examples.

[0026] Fig.17 A parallel computing system according to some examples is shown.

[0027] Figures 18A-18B Illustrated is a hybrid logical / physical view of a factorized parallel processor according to examples described herein.

[0028] FIG. 19(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.

[0029] The block diagram of FIG. 19(B) illustrates 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.

[0030] Fig. 20 Examples of execution unit circuitry, such as execution unit circuitry, are illustrated.

[0031] Fig.21 An example of a prefix is ​​shown in the figure.

[0032] 22(A)-(D) illustrate examples of how the R, X, and B fields of the second prefix are used.

[0033] 23(A)-(B) illustrate examples of the second prefix.

[0034] Fig.24A and Fig. 24B Thread execution logic including an array of processing elements employed in a graphics processor core is illustrated according to examples described herein.

[0035] Fig.25 Additional execution units are illustrated according to one example.

[0036] Fig.26 The block diagram illustrates a graphics processor instruction format according to some examples.

[0037] Fig. 27 is a block diagram of another example of a graphics processor.

[0038] Fig.28A The block diagram illustrates a graphics processor command format according to some examples.

[0039] Fig.28B The block diagram illustrates a graphics processor command sequence according to one example.

[0040] Fig.29 The block diagram illustrates the use of a software instruction converter according to an example to convert binary instructions in a source ISA to binary instructions in a target ISA.

[0041] Fig.30 The block diagram illustrates an IP core development system according to some examples, which can be used to manufacture integrated circuits to perform operations. DETAILED DESCRIPTION

[0042] The present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for less than 512-bit vector processing.

[0043] While some modern processors support vector widths of 512 bits (or larger), not all processors or cores support these larger sizes. For some tasks, larger vector sizes may be considered less power efficient, physically too large, or unnecessary. However, instructions developed for these larger vector widths may still be desirable in processors or cores with smaller vector widths. In addition, the use of write mask / predicate instructions present in some processors or cores with larger vector widths may also be useful.

[0044] In some examples, processor cores that support 512-bit vector processing utilize prefixes that allow write masking and embedded rounding, while processor cores that do not support 512-bit vector processing do not support this functionality. In addition, many instructions were developed (and continue to be developed) for this prefix.

[0045] Embedded rounding allows the programmer, compiler, etc. to specify a type of rounding (e.g., round to nearest (even) - rounds the result to the nearest infinitely precise result, but if two values ​​are equally close, the result is even), round down (towards negative infinity) - rounds the result to the nearest but not greater than the infinitely precise result, round up (towards positive infinity) - rounds the result to the nearest but not less than the infinitely precise result, and round towards zero (truncation) - rounds the result to the nearest but not greater than the infinitely precise result in absolute value). In some processor cores that do not support 512-bit support prefixes, the rounding mode for all instructions is set in a control register (e.g., MXCSR), which requires that the control register be written (requiring instructions to do so) and that any time the rounding mode is changed, the control register must be rewritten with the desired rounding behavior.

[0046] In some examples, using embedded rounding also means suppressing all exceptions (SAE). The SAE effect is as if all control register mask bits are set, and all flags of the register are not updated based on the execution of the instruction.

[0047] Write masking support for some processor cores that support 512-bit vector processing utilizes 64-bit registers, which allows data elements of byte (8-bit) size or larger to be affected. To address all bytes in a 512-bit (or 64-byte) vector register, a 64-bit mask register is required, while to fully address all bytes in a 256-bit vector register, only a 32-bit mask register is required.

[0048] The examples detailed herein allow processor cores that do not support 512-bit vector processing to utilize prefixes that allow write masking (related to the vector width of the processor core (or the vector width enabled on the processor core)) and embedded rounding for 256-bit vector widths (or smaller), as well as the ability to suppress all exceptions. This allows for a "convergent" instruction set architecture (ISA) that can run multiple processor core architectures that can support all or a subset of vector widths. In order to maintain area, power, and cost efficiency, it may be important to only require these architectures to support the maximum required mask vector width applicable to the host ISA.

[0049] In some examples, the mask register bit width and associated instructions will be determined by the maximum enumerated supported vector width advertised by a particular core product (e.g., via CPUID). This allows the programmer to statically apply a particular arithmetic rounding mode without regard to the value of the rounding bits in the control register. In some examples, prefix-encoded rounding modes are only available on register-to-register instructions.

[0050] Allowing write masking, embedded rounding, etc. enables efficient but smaller cores to support feature-rich modern vector instruction set architectures (ISAs) and provide capabilities and performance approaching that of larger high-performance cores. It also enables applications to run on all heterogeneous cores, both discrete and integrated in hybrid system-on-chip (SOC).

[0051] Figure 1 An example of a processor with multiple cores is illustrated; the processor illustrated may be a central processing unit (CPU), a graphics processing unit (GPU), etc. Note that the sizes are illustrative in some examples. For example, while 512 bits are shown as the largest vector size, in some examples, one or more larger sizes (e.g., 1024, 2048, etc.) are supported.

[0052] Processor 101 includes one or more cores 103 that support vector processing of up to 512 bits. Typically, these cores also support vectors of other smaller sizes (e.g., 128 bits, 256 bits, etc.).

[0053] Processor 111 includes one or more cores 113 that support vector processing of up to 512 bits. Typically, these cores also support other smaller vector sizes (e.g., 256 bits, 128 bits, etc.). In addition, processor 111 also includes one or more cores 115 that support vector processing of less than 512 bits (but not 512 bits). These cores support smaller vector sizes (e.g., 256 bits, 128 bits, etc.).

[0054] Processor 121 includes one or more cores 123 that support processing of vectors smaller than 512 bits. Typically, these cores support vectors of smaller sizes (e.g., 256 bits, 128 bits, etc.).

[0055] In the examples detailed herein, each of the different core types illustrated supports a prefix that, when enabled, enables write masking (related to the vector width of the processor core (or the vector width enabled on the processor core)) and embedded rounding for 256-bit vector widths (or smaller), as well as the ability to suppress all exceptions.

[0056] As described above, in some examples, prefixes of instructions are utilized to support write masking, embedded rounding, etc. Instructions have a format that a decoder of a processor can understand. Figure 2 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 201, an opcode 203, addressing information 205 (e.g., register identifiers, memory addressing information, etc.), a displacement field 207, and / or an immediate value 209. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 203 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.

[0057] (One or more) prefix fields 201 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.

[0058] The opcode field 203 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 203 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.

[0059] The addressing information field 205 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Figure 3An example of an addressing information field 205 is illustrated. In this illustration, an optional MOD R / M byte 302 and an optional Scale, Index, Base (SIB) byte 304 are shown. The MOD R / M byte 302 and SIB byte 304 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 fields are optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 302 includes a MOD field 342, a register (reg) field 344, and an R / M field 346.

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

[0061] Register field 344 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 344 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 344 is supplemented with additional bits from a prefix (e.g., prefix 201) to allow for greater addressing.

[0062] R / M field 346 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 346 may be combined with MOD field 342 to specify an addressing mode.

[0063] SIB byte 304 includes a scale field 352, an index field 354, and a base address field 356 for address generation. Scaling field 352 indicates a scaling factor. Index field 354 specifies the index register to be used. In some examples, index field 354 is complemented with additional bits from a prefix (e.g., prefix 201) to allow for larger addressing. Base address field 356 specifies the base address register to be used. In some examples, base address field 356 is complemented with additional bits from a prefix (e.g., prefix 201) to allow for larger addressing. In practice, the contents of scale field 352 allow the contents of index field 354 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0064] Some addressing forms utilize a displacement value to generate a memory address. For example, a memory address may be generated based on 2 scale * index + base address + displacement, index * scale + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement may be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the displacement field 207 provides this value. In addition, in some examples, the use of a displacement factor is encoded in the MOD field of the addressing information field 205, which indicates a compressed displacement scheme, for which the displacement value is calculated and stored in the displacement field 207.

[0065] In some examples, the immediate value field 209 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.

[0066] Figure 4 An example of a first prefix 201(C) is illustrated that supports write masking (related to the vector width of the processor core (or the vector width enabled on the processor core)) and embedded rounding for 256-bit vector widths (or smaller), as well as the ability to suppress all exceptions. In some examples, the first prefix 201(C) is an example of an EVEX prefix. The first prefix 201(C) is typically a four-byte prefix.

[0067] The first prefix 201 (C) can 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 are used (see the discussion of registers in previous figures, e.g., Figure 6 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions whose source / destination operands are operation mask registers and treat the contents of the operation mask register as a single value are encoded using the second prefix 201 (B).

[0068] The first prefix 201(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0069] The first byte of the first prefix 201 (C) is the format field 411, which in some examples has a value of 62 H. The subsequent bytes are called payload bytes 415-419, and together form a 24-bit value of P[23:0], providing specific capabilities in the form of one or more fields (described in detail herein).

[0070] In some examples, P[1:0] of payload byte 419 is the same as the two mm bits in the lower order. 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 the reg field 344 of MOD R / M. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with the MOD R / M register field 344 and the MOD R / MR / M field 346, allows access to the next set of 8 registers beyond the lower 8 registers. P[9:8] provides opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

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

[0071] P

[15] is similar to W of the first prefix 201 (A) and the second prefix 211 (B), and can be used as an opcode extension bit or an operand size increase.

[0072] P[18:16] specifies the index of a register in an operation mask (write mask) register (e.g., write mask / predicate register 615). In some examples, a particular value aaa=000 has special behavior, implying that no operation mask is used for this particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in some other examples, the old value of each element of the destination where the corresponding mask bit has a value of 0 is retained. In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic and enhanced operations); 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 of elements modified, from first to last); however, the elements modified do not have to be contiguous. Thus, the operation mask field allows for a subset of vector operations, including loads, stores, arithmetic, logical, and so on. While in the described examples, the contents of the operation mask field selects which of several operation mask registers contains the operation mask to be used (thus the contents of the operation mask field indirectly identify the masking to be performed), alternative examples alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0073] P

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

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

[20] (when the source is memory, "b" or "b" indicates source broadcast) encodes various features that vary in 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).

[0074] An example of the encoding of registers in instructions using the first prefix 201 (C) is detailed in the table below.

[0075]

[0076] Table 1: 32-register support in 64-bit mode

[0077]

[0078]

[0079] Table 2: Encoding register specifiers in 32-bit mode

[0080]

[0081] Table 3: Operation Mask Register Specifier Encoding

[0082] In the first prefix, to support embedded rounding and SAE features at all vector widths, bits 20 (payload byte 2 415 bit 4) and 10 (payload byte 1 417 bit 2) are reused to indicate the vector width. For some cases, bits 21-22 (LL bits or payload byte 2 415 bits 5-6) are used for rounding control (e.g., 0b00 = round to the nearest even number, 0b01 = round down, 0b10 = round up, 0b11 = round towards zero). In some examples, the MOD 342 value needs to be set to 0b11.

[0083] Figure 5 An example of the settings of bits 20 and 10 of the prefix and how they define the vector length and / or embedded rounding control is illustrated. When bit 20 is 0, bit 10 is 1 (bit 10 is set to the default value in some examples), and MOD 342 is 0b11, the instruction is a register instruction (no memory operand is used), and the vector length is determined from the LL bits.

[0084] When bit 20 is 1, bit 10 is 1, and MOD 342 is 0b11, the instruction is a 512-bit vector register instruction (using no memory operands), and the LL bit is overloaded to indicate embedded rounding.

[0085] When bit 20 is 1, bit 10 is 0 (eg, not the default value), and MOD 342 is 0b11, the instruction is a 256-bit vector register instruction (using no memory operands), and the LL bit is overloaded to indicate embedded rounding.

[0086] When bit 20 is 0, bit 10 is 0 (eg, not the default value), and MOD 342 is 0b11, the instruction is a 128-bit vector register instruction (using no memory operands), and the LL bit is overloaded to indicate embedded rounding.

[0087] In some examples, other MOD 342 value combinations with bit 10=0 and bit 20=1 or 0 are reserved but may be overloaded to support different vector widths.

[0088] In addition, this feature of the present invention is to architecturally limit the width (in bits) of the mask register to the number of bytes of the maximum supported vector width. For example, if the maximum width advertised by the implementation is 256b=32B, then the mask register is specified to be 32 bits wide. If the width is 512b=64B, then the mask register is specified to be 64 bits wide.

[0089] Example register architecture.

[0090] Figure 6 6 is a block diagram of a register architecture 600 according to some examples. As shown, the register architecture 600 includes a vector / SIMD register 610, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 610 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 610 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.

[0091] In some examples, the register architecture 600 includes a write mask / predicate register 615. 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 615 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 615 corresponds to a data element position in the destination. In other examples, the write mask / predicate register 615 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).

[0092] The register architecture 600 includes a plurality of general purpose registers 625. 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.

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

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

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

[0096] Model specific registers or machine specific registers (MSRs) 635 control and report processor performance. Most MSRs 635 handle system-related functions and are inaccessible to applications. For example, MSRs may provide control of 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 660 consist of control, status, and error reporting MSRs for detecting and reporting hardware errors. (One or more) control registers 655 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 1270, 1280, 1238, 1215, and / or 1300) and the characteristics of the task currently being executed. In some examples, MSRs 635 are a subset of control registers 655.

[0097] One or more instruction pointer registers 630 store instruction pointer values. Debug registers 650 control and allow monitoring of debug operations of the processor or core.

[0098] Memory (mem) management registers 665 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.

[0099] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer, or different register files and registers. Register architecture 600 may be used, for example, in register file / memory 808, or in physical register file circuit 1958.

[0100] As described above, for vectors smaller than 512 bits, the write mask / predicate register does not require 64 bits to address byte-sized elements. In some examples, write mask / predicate registers of other sizes are used depending on the size of the vector being operated on. Figure 7 Examples of write mask / predicate registers of different sizes are illustrated (e.g., 64-bit write mask / predicate register 701, 32-bit write mask / predicate register 703, and / or 16-bit write mask / predicate register 705) that allow for byte-sized write masking / predicates. Note that only one register is shown, but multiple of these registers (e.g., 16, 32, 64, etc.) may be available.

[0101] In some examples, only one write mask / predicate register size is available. This helps maintain area, power, and cost efficiency since no resources will go unused.

[0102] In some examples, the write mask / predicate register is a proper subset of a larger size write mask / predicate register. For example, only 256 bits of a 512-bit register are used.

[0103] In some examples, the mask register bit width is an enumerated value that can be found using an instruction such as CPUID.

[0104] Figure 8An example of computing hardware for processing a first prefix support instruction is illustrated. As indicated by the opcode, the instruction may be a load, store, arithmetic and / or Boolean instruction. As shown, a storage device 803 stores at least one first prefix support instruction 801 to be executed and / or other instructions 802 to be executed.

[0105] Instruction 801 is received by decoder circuit 805. For example, decoder circuit 805 receives the instruction from a fetch circuit (not shown). Decoder circuit 805 decodes the instruction into one or more operations. In some examples, such decoding includes generating a plurality of micro-operations to be executed by an execution circuit (e.g., execution circuit 809). Decoder circuit 805 also decodes the instruction prefix.

[0106] In some examples, the register renaming, register allocation and / or scheduling circuitry 807 provides functionality for one or more of the following: 1) renaming logical operand values ​​to physical operand values ​​(e.g., a register alias table in some examples); 2) assigning status bits and flags to decoded instructions; and 3) scheduling decoded instructions from an instruction pool for execution by execution circuitry (e.g., using a reservation station in some examples).

[0107] Registers (register files) and / or memory 808 store data as operands of instructions, which are then operated on by execution circuitry 809. Example register types include packed data registers, general purpose registers (GPRs), and floating point registers.

[0108] The execution circuit 809 executes the decoded instruction. The example detailed execution circuit includes the execution circuit, and (one or more) execution clusters 1960 shown in Figure 19 (B), etc. The execution of the decoded instruction causes the execution circuit to perform (one or more) operations indicated by the opcode, rounding (if specified by the prefix) and / or write masking / predicate assertion (if specified by the prefix).

[0109] In some examples, retirement / writeback circuitry 811 architecturally commits the destination register to register or memory 808 and retires the instruction.

[0110] Fig. 9 An example execution circuit supporting up to 512-bit vector execution is illustrated. As shown, in response to a decoded instruction using a first prefix (or other prefixes supporting the contents detailed above), the execution circuit 901 performs one or more operations indicated by the opcode of the instruction. In some examples, the execution circuit 901 is, for example, Figure 8etc., and a portion of the execution circuitry of other figures. Depending on the instruction, there may be 0-3 register sources (e.g., first source 911, second source 913, and / or third source 915) and 0-1 register destinations (e.g., destination 921). In some examples, the source is a source and a destination.

[0111] In some examples, one or more of the source and / or destination stores packed data (e.g., vector or SIMD registers). Packed data register sizes include, but are not limited to, 512 bits, 256 bits, 128 bits, 64 bits, and the like. The data can be scalar (e.g., INT4, INT8, INT16, INT23, INT64, and the like) or floating point (e.g., FP8, FP16, FP32, FP64, Bfloat16, and the like).

[0112] Execution circuitry 901 includes first prefix support circuitry 902. In some examples, the operation(s) include using arithmetic circuitry 904, such as dot product, addition, subtraction, multiplication, division, and the like. In some examples, the operation(s) include using Boolean circuitry 906, such as AND, NOR, NAND, OR, XOR, NOT, and the like. In some examples, rounding circuitry 905 is applied to the result of the operation using rounding mode 933 (e.g., provided by the first prefix). In some examples, the operation(s) include using load or store circuitry 907. In some examples, the operation(s) include using write mask / predicate register 917 to use write mask / predicate circuitry 909. In some examples, the size of write mask / predicate register 917 is determined by the first prefix. In some examples, write mask / predicate circuitry 909 is part of a write back circuitry (e.g., write back circuitry 811).

[0113] Which circuits are to be used (and which other circuits 910 are not to be used) is provided by a specific circuit selector 931, which is typically generated by a decoder.

[0114] Fig.10 The diagram shows an example method for a processor to process a vector of up to 512 bits. For example, as shown in FIG. 19(B), Figure 8 , Fig. 9 The processor core shown, the pipeline as described in detail below, etc., execute this method.

[0115] At 1001, an instance of a single instruction is obtained. The instance of the single instruction has at least fields for a prefix, an opcode, and operand addressing information, wherein the prefix and addressing information are used to determine support for a specific vector length of one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands. In some examples, the prefix is ​​the first prefix described in detail above. In some examples, the instruction is obtained from an instruction cache. The opcode indicates one or more operations to be performed.

[0116] At 1003, the fetched instruction is decoded. For example, the fetched instruction is decoded by a decoder circuit, such as decoder circuit 805 or decode circuit 1940 described in detail herein. In some examples, when the processor does not support the size of the vector operand(s) indicated by the prefix and MOD 342, the decoding may fail (e.g., return an undefined error).

[0117] At 1005 , when a decoded instruction is dispatched, data values ​​associated with the source operand(s) of the decoded instruction are retrieved.

[0118] At 1007, the decoded instructions are executed by execution circuitry (hardware), e.g. Fig. 9 The execution circuit shown in Figure 8 19(B) , or the execution cluster(s) 1960 shown in FIG. 19(B) , etc. In some examples, the execution may use write masking and / or embedded rounding defined by a prefix.

[0119] In some examples, at 1009 , the instruction is committed or retired.

[0120] Fig.11 An example method for processing up to 512-bit vector execution instructions using emulation or binary translation is illustrated. For example, a processor core, pipeline, and / or emulation / translation layer as shown in FIG. 19(B) performs various aspects of this method.

[0121] At 1101, an instance of a single instruction of a first instruction set architecture is obtained. The instance of the single instruction of the first instruction set architecture includes an instance of a single instruction of a first ISA, having at least fields for a prefix, an opcode, and operand addressing information, wherein the prefix and the addressing information are used to determine support for a specific vector length of one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands. In some examples, the prefix is ​​the first prefix described in detail above. In some examples, the instruction is obtained from an instruction cache. The opcode indicates the operation(s) to be performed.

[0122] At 1102, the obtained single instruction of the first instruction set architecture is translated into one or more instructions of the second instruction set architecture. In some examples, this translation is performed by a translation and / or emulation layer of software. In some examples, this translation is performed by a software such as Figure 3 The instruction converter 312 is shown to perform this translation. In some examples, this translation is performed by hardware translation circuitry.

[0123] At 1103, one or more translated instructions of the second instruction set architecture are decoded. For example, the translated instructions are decoded by a decoder circuit, such as decoder circuit 805 or decode circuit 1940 described in detail herein. In some examples, the translation and decoding operations of 1102 and 1103 are combined.

[0124] At 1105, data values ​​associated with source operand(s) of the decoded one or more instructions of the second instruction set architecture are retrieved, and the one or more instructions are dispatched.

[0125] At 1107, the decoded instruction(s) of the second instruction set architecture are executed by execution circuitry (hardware), e.g. Fig. 9 The execution circuit shown in Figure 8 19(B) , and so on, to perform the (one or more) operations indicated by the opcode of the single instruction of the first instruction set architecture. In some examples, the execution can use write masking and / or embedded rounding defined by the prefix.

[0126] In some examples, at 1109 , the instruction is committed or retired.

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

[0128] Example Architecture

[0129] The example computer architecture is described in detail below. Other system designs and configurations for laptops, desktop computers, handheld personal computers (personal computers, PCs), personal digital assistants, engineering workstations, servers, decomposed servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (digitalsignal 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 appropriate. In short, various systems or electronic devices that can include processors and / or other execution logic disclosed herein are generally appropriate.

[0130] Example System

[0131] Fig.12 An example computing system is illustrated. Multiprocessor system 1200 is an interfaced system and includes multiple processors or cores, including a first processor 1270 and a second processor 1280 coupled via an interface 1250 (e.g., a point-to-point (PP) interconnect, a fabric, and / or a bus). In some examples, first processor 1270 and second processor 1280 are isomorphic. In some examples, first processor 1270 and second processor 1280 are heterogeneous. Although example system 1200 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).

[0132] Processors 1270 and 1280 are shown as including integrated memory controller (IMC) circuits 1272 and 1282, respectively. Processor 1270 also includes interface circuits 1276 and 1278; similarly, second processor 1280 includes interface circuits 1286 and 1288. Processors 1270, 1280 may exchange information via interface 1250 using interface circuits 1278, 1288. IMCs 1272 and 1282 couple processors 1270, 1280 to respective memories, namely memory 1232 and memory 1234, which may be part of the main memory locally attached to the respective processors.

[0133] Processors 1270, 1280 can each utilize interface circuits 1276, 1294, 1286, 1298 to exchange information with a network interface (NW I / F) 1290 via respective interfaces 1252, 1254. Network interface 1290 (e.g., one or more of an interconnect, bus, and / or structure, a chipset in some examples) can optionally exchange information with a coprocessor 1238 via interface circuit 1292. In some examples, coprocessor 1238 is a special-purpose processor, such as 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.

[0134] A shared cache (not shown) may be included in either processor 1270, 1280, or may be external to the two processors but connected to the processors via an interface (e.g., a PP interconnect) such that if a processor is placed in a low power mode, local cache information of either or both processors may also be stored in the shared cache.

[0135] The network interface 1290 can be coupled to the first interface 1216 via the interface circuit 1296. In some examples, the first interface 1216 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 1216 is coupled to a power control unit (PCU) 1217, which can include circuits, software, and / or firmware to perform power management operations with respect to the processors 1270, 1280, and / or the coprocessor 1238. The PCU 1217 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 1217 also provides control information to control the generated operating voltage. In various examples, the PCU 1217 can include various power management logic units (circuits) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0136] PCU 1217 is illustrated as existing as logic separate from processor 1270 and / or processor 1280. In other cases, PCU 1217 may execute on a given one or more of the cores (not shown) of processor 1270 or 1280. In some cases, PCU 1217 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is 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 1217 may be implemented external to the processor, such as by 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 1217 may be implemented within BIOS or other system software.

[0137] Various I / O devices 1214 and a bus bridge 1218 can be coupled to the first interface 1216, which couples the first interface 1216 to the second interface 1220. In some examples, (one or more) additional processors 1215 are coupled to the first interface 1216, such as a coprocessor, a high-throughput integrated many-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. In some examples, the second interface 1220 can be a low pin count (LPC) interface. Various devices can be coupled to the second interface 1220, including, for example, a keyboard and / or mouse 1222, a communication device 1227, and a storage circuit 1228. The storage circuit 1228 can be one or more non-transitory machine-readable storage media described below, such as a disk drive or other mass storage device, which in some examples may include instructions / codes and data 1230 and can implement the storage device 803. In addition, audio I / O 1224 can be coupled to second interface 1220. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 1200 can implement a multi-drop interface or other such architecture instead of a point-to-point architecture.

[0138] Example core architectures, processors, and computer architectures.

[0139] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores for general-purpose computing purposes; 2) high-performance general-purpose out-of-order cores for general-purpose computing purposes; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU including one or more general-purpose in-order cores for general-purpose computing purposes and / or one or more general-purpose out-of-order cores for general-purpose computing purposes; and 2) a coprocessor including one or more special-purpose cores mainly for graphics and / or scientific (throughput) computing purposes. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies in the same package as the CPU; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip (SoC), which may be included on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s), the coprocessors described above, and additional functionality. An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0140] Fig.13 A block diagram of an example processor and / or SoC 1300 is illustrated, which may have one or more cores and an integrated memory controller. The processor 1300 illustrated in solid line boxes has a single core 1302(A), a system agent unit circuit 1310, and a set of one or more interface controller unit circuits 1316, while the optionally added dashed line boxes illustrate an alternative processor 1300 as having multiple cores 1302(A)-(N), a set of one or more integrated memory control unit circuits 1314 in the system agent unit circuit 1310, dedicated logic 1308, and a set of one or more interface controller unit circuits 1316. Note that the processor 1300 may be Fig.12 processor 1270 or 1280, or one of the coprocessors 1238 or 1215.

[0141] Thus, different implementations of processor 1300 may include: 1) a CPU, where dedicated logic 1308 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1302(A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 1302(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 1302(A)-(N) are a large number of general purpose in-order cores. Thus, processor 1300 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication 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, and the like. The processor may be implemented on one or more chips. Processor 1300 may be part of one or more substrates and / or may be implemented on one or more substrates using any of a variety of process technologies, such as complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0142] The memory hierarchy includes one or more levels of cache unit circuits 1304(A)-(N) within the cores 1302(A)-(N), a set of one or more shared cache unit circuits 1306, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 1314. The set of one or more shared cache unit circuits 1306 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other levels of cache, such as last level cache (LLC), and / or combinations thereof. While in some examples an interface network circuit 1312 (e.g., a ring interconnect) provides an interface to dedicated logic 1308 (e.g., integrated graphics logic), the set of shared cache unit circuits 1306, and the system agent unit circuit 1310, alternative examples use any number of well-known techniques to provide interfaces to these units. In some examples, coherency is maintained between one or more circuits in the shared cache unit circuits 1306 and the cores 1302(A)-(N). In some examples, interface controller unit circuit 1316 couples the cores 1302 to one or more other devices 1318, such as one or more I / O devices, storage devices, one or more communication devices (e.g., wireless network, wired network, etc.), and the like.

[0143] In some examples, one or more of the cores 1302(A)-(N) have multi-threading capabilities. System agent unit circuitry 1310 includes those components that coordinate and operate the cores 1302(A)-(N). System agent unit circuitry 1310 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 the cores 1302(A)-(N) and / or the dedicated logic 1308 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0144] The cores 1302(A)-(N) may be homogeneous with respect to instruction set architecture (ISA). Alternatively, the cores 1302(A)-(N) may be heterogeneous with respect to ISA; that is, a subset of the cores 1302(A)-(N) may be capable of executing one ISA, while other cores may be capable of executing only a subset of the ISA or may be capable of executing another ISA.

[0145] Fig.14The block diagram of 1400 illustrates a computing system 1400 configured to implement one or more aspects of the examples described herein. The computing system 1400 includes a processing subsystem 1401 having one or more processors 1402, and a system memory 1404, which communicate via an interconnect path, which may include a memory hub 1405. The memory hub 1405 may be a separate component within a chipset component, or may be integrated within the one or more processors 1402. The memory hub 1405 is coupled to an I / O subsystem 1411 via a communication link 1406. The I / O subsystem 1411 includes an I / O hub 1407, which may enable the computing system 1400 to receive input from one or more input devices 1408. In addition, the I / O hub 1407 may enable a display controller included in the one or more processors 1402 to provide output to one or more display devices 1410A. In some examples, one or more display devices 1410A coupled to I / O hub 1407 may include local, internal, or embedded display devices.

[0146] For example, the processing subsystem 1401 includes one or more parallel processors 1412, which are coupled to the memory hub 1405 via a bus or other communication link 1413. The communication link 1413 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 structure. One or more parallel processors 1412 can form a computationally concentrated parallel or vector processing system that can include a large number of processing cores and / or processing clusters, such as an integrated many-core (MIC) processor. For example, one or more parallel processors 1412 form a graphics processing subsystem that can output pixels to one of one or more display devices 1410A coupled via an I / O hub 1407. One or more parallel processors 1412 may also include a display controller and a display interface (not shown) to enable direct connection to one or more display devices 1410B.

[0147] Within the I / O subsystem 1411, a system storage unit 1414 may be connected to the I / O hub 1407 to provide a storage mechanism for the computing system 1400. An I / O switch 1416 may be used to provide an interface mechanism to enable connections between the I / O hub 1407 and other components (e.g., a network adapter 1418 and / or a wireless network adapter 1419 that may be integrated into the platform) and various other devices that may be added via one or more additional devices 1420. (One or more) additional devices 1420 may also include, for example, one or more external graphics processor devices, graphics cards, and / or computing accelerators. The network adapter 1418 may be an Ethernet adapter or another wired network adapter. The wireless network adapter 1419 may include one or more of Wi-Fi, Bluetooth, near field communication (NFC), or other network devices including one or more wireless radios.

[0148] Computing system 1400 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 I / O hub 1407 . Fig.14 The communication paths 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 (one or more) other bus or point-to-point communication interface and / or protocol, such as NVLink high-speed interconnect, Compute Express Link TM (CXL TM) (e.g., CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802.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 QuickPath 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 (Cache Coherent Interconnect) For Accelerators, CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variants thereof, or wired or wireless interconnect protocols known in the art. In some examples, data can be copied or stored to a virtualized storage node using a protocol such as non-volatile memory express (NVMe) over Fabrics (NVMe-oF) or NVMe.

[0149] One or more parallel processors 1412 may include circuits optimized for graphics and video processing, such as video output circuits, and constitute a graphics processing unit (GPU). Alternatively or additionally, one or more parallel processors 1412 may include circuits optimized for general processing while retaining the underlying computing architecture described in more detail herein. The components of the computing system 1400 may be integrated with one or more other system elements on a single integrated circuit. For example, one or more parallel processors 1412, a memory hub 1405, (one or more) processors 1402, and an I / O hub 1407 may be integrated into a system on chip (SoC) integrated circuit. Alternatively, the components of the computing system 1400 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 1400 may be integrated into a multi-chip module (MCM), which may be interconnected with other multi-chip modules to form a modular computing system.

[0150] It will be understood that the computing system 1400 shown herein is illustrative only and may be varied and modified. The connection topology, including the number and arrangement of bridges, the number of (one or more) processors 1402, and the number of (one or more) parallel processors 1412, may be modified as needed. For example, the system memory 1404 may be directly connected to the (one or more) processors 1402, rather than through a bridge, while other devices communicate with the system memory 1404 via the memory hub 1405 and the (one or more) processors 1402. In other alternative topologies, the (one or more) parallel processors 1412 are connected to the I / O hub 1407 or directly to one of the one or more processors 1402, rather than to the memory hub 1405. In other examples, the I / O hub 1407 and the memory hub 1405 may be integrated into a single chip. Two or more groups of processors 1402 may also be attached via multiple sockets, which may be coupled to two or more instances of the (one or more) parallel processors 1412.

[0151] Some specific components shown herein are optional and may not be included in all implementations of computing system 1400. For example, any number of add-in cards or peripherals may be supported, or some components may be eliminated. In addition, some architectures may have different Fig.14 Similar components shown in FIG. 1404 may use different terminology. For example, in some architectures, memory hub 1405 may be referred to as a north bridge, while I / O hub 1407 may be referred to as a south bridge.

[0152] Fig.15A An example of a parallel processor 1500 is shown. The parallel processor 1500 may be a GPU, a GPGPU, or the like as described herein. The various components of the parallel processor 1500 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 1500 may be Fig.14 One or more of the parallel processor(s) 1412 shown in .

[0153] Parallel processor 1500 includes parallel processing unit 1502. Parallel processing unit includes I / O unit 1504, which enables communication with other devices (including other instances of parallel processing unit 1502). I / O unit 1504 can be directly connected to other devices. For example, I / O unit 1504 is connected to other devices by using a hub or switch interface (such as memory hub 1405). The connection between memory hub 1405 and I / O unit 1504 forms communication link 1413. Within parallel processing unit 1502, I / O unit 1504 is connected to host interface 1506 and memory crossbar 1516, wherein host interface 1506 receives commands for performing processing operations, and memory crossbar 1516 receives commands for performing memory operations.

[0154] When the host interface 1506 receives the command buffer via the I / O unit 1504, the host interface 1506 can direct the work operations of executing these commands to the front end 1508. In some examples, the front end 1508 is coupled with a scheduler 1510, which is configured to distribute commands or other work items to the processing cluster array 1512. Before the task is distributed to the processing clusters of the processing cluster array 1512, the scheduler 1510 ensures that the processing cluster array 1512 is correctly configured and in a valid state. The scheduler 1510 can be implemented via firmware logic executed on a microcontroller. The microcontroller-implemented scheduler 1510 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 1512. Preferably, the host software can prove the workload via one of a plurality of graphics processing doorbells for scheduling on the processing cluster array 1512. In other examples, polling for new workloads or interrupts can be used to identify or indicate the availability of work to be executed. The scheduler 1510 logic within the scheduler microcontroller may then automatically distribute the workload across the array of processing clusters 1512 .

[0155] The processing cluster array 1512 may include up to "N" processing clusters (e.g., cluster 1514A, cluster 1514B to cluster 1514N). Each cluster 1514A-1514N of the processing cluster array 1512 may execute a large number of concurrent threads. The scheduler 1510 may use various scheduling and / or work distribution algorithms to assign work to the clusters 1514A-1514N of the processing cluster array 1512, which may vary depending on the workload that occurs for each type of program or calculation. Scheduling may be handled dynamically by the scheduler 1510, or may be partially assisted by compiler logic during the compilation of program logic configured for execution by the processing cluster array 1512. Optionally, different clusters 1514A-1514N of the processing cluster array 1512 may be assigned to process different types of programs or perform different types of calculations.

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

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

[0158] In examples where parallel processing unit 1502 is used to perform graphics processing, scheduler 1510 may be configured to divide the processing workload into tasks of approximately the same size so that graphics processing operations can be better distributed to multiple clusters 1514A-1514N of processing cluster array 1512. In some of these examples, portions of processing cluster array 1512 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 1514A-1514N may be stored in a buffer to allow the intermediate data to be transferred between clusters 1514A-1514N for further processing.

[0159] During operation, processing cluster array 1512 may receive processing tasks to be performed via scheduler 1510, which receives commands defining the processing tasks from front end 1508. For graphics processing operations, a processing task may include an index of 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 to execute). Scheduler 1510 may be configured to retrieve an index corresponding to a task, or may receive an index from front end 1508. Front end 1508 may be configured to ensure that processing cluster array 1512 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.

[0160] Each of the one or more instances of parallel processing unit 1502 may be coupled to parallel processor memory 1522. Parallel processor memory 1522 may be accessed via memory crossbar 1516, which may receive memory requests from processing cluster array 1512 and I / O unit 1504. Memory crossbar 1516 may access parallel processor memory 1522 via memory interface 1518. Memory interface 1518 may include a plurality of partition units (e.g., partition unit 1520A, partition unit 1520B, up to partition unit 1520N), each of which may be coupled to a portion (e.g., memory cell) of parallel processor memory 1522. The number of partition units 1520A-1520N may be configured to be equal to the number of memory cells, such that a first partition unit 1520A has a corresponding first memory cell 1524A, a second partition unit 1520B has a corresponding second memory cell 1524B, and an Nth partition unit 1520N has a corresponding Nth memory cell 1524N. In other examples, the number of partition units 1520A-1520N may not be equal to the number of memory devices.

[0161] The memory units 1524A-1524N 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 1524A-1524N 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 1524A-1524N may be varied and may be selected from one of various conventional designs. Rendering targets (such as frame buffers or texture maps) may be stored across the memory units 1524A-1524N, thereby allowing the partition units 1520A-1520N to write portions of each rendering target in parallel to efficiently use the available bandwidth of the parallel processor memory 1522. In some examples, a local instance of the parallel processor memory 1522 may not be included, and a unified memory design utilizing system memory in combination with local cache memory may be employed.

[0162] Optionally, any of the clusters 1514A-1514N of the processing cluster array 1512 has the ability to process data to be written to any memory unit 1524A-1524N within the parallel processor memory 1522. The memory crossbar 1516 can be configured to transmit the output of each cluster 1514A-1514N to any partition unit 1520A-1520N or another cluster 1514A-1514N, which can perform additional processing operations on the output. Each cluster 1514A-1514N can communicate with a memory interface 1518 via the memory crossbar 1516 to read from or write to various external memory devices. In one example having a memory crossbar 1516, the memory crossbar 1516 has connections to a memory interface 1518 for communicating with the I / O unit 1504, and connections to a local instance of parallel processor memory 1522, thereby enabling processing units within different processing clusters 1514A-1514N to communicate with system memory or other memory that is not local to the parallel processing unit 1502. In general, the memory crossbar 1516 may be able to separate traffic flows between the clusters 1514A-1514N and the partition units 1520A-1520N using virtual channels, for example.

[0163] Although a single instance of parallel processing unit 1502 is illustrated within parallel processor 1500, any number of instances of parallel processing unit 1502 may be included. For example, multiple instances of parallel processing unit 1502 may be provided on a single add-in card, or multiple add-in cards may be interconnected. For example, parallel processor 1500 may be an add-in device, such as Fig.14 Additional device 1420, which can be a graphics card, for example, a discrete graphics card including one or more GPUs, one or more memory devices, and a device-to-device or network or structure interface. Different instances of parallel processing unit 1502 can be configured to interoperate, even if different instances have different numbers of processing cores, different numbers of local parallel processor memories, and / or other configuration differences. Optionally, some instances of parallel processing unit 1502 may include floating point units with higher precision relative to other instances. Systems including one or more instances of parallel processing unit 1502 or parallel processor 1500 can be implemented in various configurations and form factors, including but not limited to desktop, laptop or handheld personal computers, servers, workstations, game consoles, and / or embedded systems. The coordinator can utilize 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.

[0164] In some examples, the parallel processing unit 1502 can be partitioned into multiple instances. These multiple instances can be configured to execute workloads associated with different clients in an isolated manner, so that a predetermined quality of service can be provided for each client. For example, each cluster 1514A-1514N can be separated and isolated from other clusters, thereby allowing the processing cluster array 1512 to be divided into multiple computing partitions or instances. In this configuration, the workload executed on the isolated partition can be protected from the impact of failures or errors associated with different workloads executed on different partitions. Partition units 1520A-1520N can be configured to implement dedicated and / or isolated paths to memory for clusters 1514A-1514N associated with each computing partition. This data path isolation enables the computing resources within the partition to communicate with one or more assigned memory units 1524A-1524N without being disturbed by the activities of other partitions.

[0165] Fig. 15B is a block diagram of the partition unit 1520. The partition unit 1520 may be Fig.15A 1520N. As shown, partition unit 1520 includes L2 cache 1521, frame buffer interface 1525, and ROP 1526 (raster operation unit). L2 cache 1521 is a read / write cache that is configured to perform load and store operations received from memory crossbar 1516 and ROP 1526. Read misses and emergency writeback requests are output by L2 cache 1521 to frame buffer interface 1525 for processing. Updates can also be sent to the frame buffer via frame buffer interface 1525 for processing. In some examples, frame buffer interface 1525 interfaces with one of the storage units in the parallel processor memory, such as Fig.15A Partition unit 1520 may additionally or alternatively interface with one of the memory units in the parallel processor memory via a memory controller (not shown).

[0166] In graphics applications, ROP 1526 is a processing unit that performs raster operations (e.g., stencil, z-test, blending, etc.). ROP 1526 then outputs processed graphics data, which is stored in graphics memory. In some examples, ROP 1526 includes or is coupled to a codec 1527, which includes compression logic to compress depth or color data written to memory or L2 cache 1521 and decompress depth or color data read from memory or L2 cache 1521. The compression logic can be lossless compression logic that uses one or more of a variety of compression algorithms. The type of compression performed by codec 1527 can vary based on the statistical characteristics of the data to be compressed. For example, in some examples, incremental color compression is performed on depth and color data on a per-tile basis. In some examples, codec 1527 includes compression and decompression logic that can compress and decompress computational data associated with machine learning operations. For example, codec 1527 can compress sparse matrix data for sparse machine learning operations. The codec 1527 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 the processing element, or the processing element can be configured to consume compressed, encoded, or compressed and encoded data for processing.

[0167] ROP 1526 may be included in each processing cluster (e.g., Fig.15A 1514A-1514N) rather than within partition unit 1520. In this example, read and write requests for pixel data rather than pixel fragment data are transmitted through memory crossbar 1516. The processed graphics data can be displayed on a display device, such as Fig.14 One of the one or more display devices 1410A-1410B is routed to be further processed by (one or more) processors 1402, or is routed to be further processed by (one or more) processors 1402. Fig.15A One of the processing entities within parallel processor 1500 is further processed.

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

[0169] The operation of the processing cluster 1514 may be controlled via a pipeline manager 1532, which distributes processing tasks to SIMT parallel processors. Fig.15A The scheduler 1510 receives instructions and manages the execution of these instructions via the graphics multiprocessor 1534 and / or the texture unit 1536. The illustrated graphics multiprocessor 1534 is an exemplary instance of a SIMT parallel processor. However, various types of SIMT parallel processors of different architectures may be included within the processing cluster 1514. One or more instances of the graphics multiprocessor 1534 may be included within the processing cluster 1514. The graphics multiprocessor 1534 may process data, and the data cross bar 1540 may be used to distribute the processed data to one of a plurality of possible destinations, including other shader units. The pipeline manager 1532 may facilitate the distribution of processed data by specifying a destination for the processed data to be distributed via the data cross bar 1540.

[0170] Each graphics multiprocessor 1534 within a processing cluster 1514 may include a set of identical function execution logic (e.g., arithmetic logic units, load-store units, etc.). The function execution logic may be configured in a pipelined manner, where 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, 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 be present.

[0171] The instructions transmitted to the processing cluster 1514 constitute threads. A group of threads executed on a group of parallel processing engines is a thread group. A thread group executes the same program on different input data. Each thread in a thread group can be assigned to a different processing engine in the graphics multiprocessor 1534. The number of threads included in the thread group may be less than the number of processing engines in the graphics multiprocessor 1534. When the number of threads included in the thread group is less than the number of processing engines, one or more of the processing engines may be idle during the cycle in which the thread group is processed. The number of threads included in the thread group may also be more than the number of processing engines in the graphics multiprocessor 1534. When the number of threads included in the thread group is more than the number of processing engines in the graphics multiprocessor 1534, processing can be performed in consecutive clock cycles. Optionally, multiple thread groups can be executed simultaneously on the graphics multiprocessor 1534.

[0172] The graphics multiprocessors 1534 may include internal cache memory to perform load and store operations. Alternatively, the graphics multiprocessors 1534 may forgo internal cache and use cache memory (e.g., level 1 (L1) cache 1548) within the processing cluster 1514. Each graphics multiprocessor 1534 may also have access to a partition unit (e.g., Fig.15A 1520A-1520N) that are shared between all processing clusters 1514 and can be used to transfer data between threads. Graphics multiprocessor 1534 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 1502 can be used as global memory. Embodiments in which processing cluster 1514 includes multiple instances of graphics multiprocessor 1534 can share common instructions and data, which can be stored in L1 cache 1548.

[0173] Each processing cluster 1514 may include an MMU 1545 (memory management unit) that is configured to map virtual addresses to physical addresses. In other examples, one or more instances of MMU 1545 may exist in Fig.15A1518. The MMU 1545 includes a set of page table entries (PTEs) for mapping virtual addresses to physical addresses of tiles, and optionally also includes a cache line index. The MMU 1545 may include an address translation lookaside buffer (TLB) or cache, which may be present in the L1 cache 1548 of the graphics multiprocessor 1534 or processing cluster 1514. The physical address is processed to distribute the surface data access location to allow 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.

[0174] In graphics and compute applications, the processing clusters 1514 may be configured such that each graphics multiprocessor 1534 is coupled to a texture unit 1536 that is used to perform 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 1534, and is retrieved from an L2 cache, local parallel processor memory, or system memory as needed. Each graphics multiprocessor 1534 outputs processed tasks to a data crossbar 1540 to provide the processed tasks to another processing cluster 1514 for further processing, or stores the processed tasks in an L2 cache, local parallel processor memory, or system memory via a memory crossbar 1516. A preROP 1542 (pre-raster operation unit) is configured to receive data from the graphics multiprocessor 1534, direct the data to a ROP unit, which may communicate with a partition unit (e.g., Fig.15A The preROP 1542 unit may perform color blending optimization, organize pixel color data, and perform address translation.

[0175] It will be understood that the core architecture described herein is illustrative only and is subject to variation and modification. Any number of processing units may be included within a processing cluster 1514, e.g., a graphics multiprocessor 1534, a texture unit 1536, a preROP 1542, and the like. Additionally, while only one processing cluster 1514 is shown, a parallel processing unit as described herein may include any number of instances of a processing cluster 1514. Optionally, each processing cluster 1514 may be configured to operate independently of other processing clusters 1514 using separate and distinct processing units, L1 caches, L2 caches, and the like.

[0176] Fig.15DAn example of a graphics multiprocessor 1534 is shown, where the graphics multiprocessor 1534 is coupled to a pipeline manager 1532 of a processing cluster 1514. The graphics multiprocessor 1534 has an execution pipeline that includes, but is not limited to, an instruction cache 1552, an instruction unit 1554, an address mapping unit 1556, a register file 1558, one or more general purpose graphics processing unit (GPGPU) cores 1562, and one or more load / store units 1566. The GPGPU cores 1562 and the load / store units 1566 are coupled to a cache memory 1572 and a shared memory 1570 via a memory and cache interconnect 1568. The graphics multiprocessor 1534 may also include a tensor and / or ray tracing core 1563, which includes hardware logic for accelerating matrix and / or ray tracing operations.

[0177] The instruction cache 1552 may receive a stream of instructions to be executed from the pipeline manager 1532. These instructions are cached in the instruction cache 1552 and dispatched by the instruction unit 1554 for execution. The instruction unit 1554 may dispatch instructions as a thread group (e.g., a warp), each thread of the thread group being assigned to a different execution unit within the GPGPU core 1562. Instructions may access any of the local, shared, or global address spaces by specifying an address within the unified address space. The address mapping unit 1556 may be used to translate addresses in the unified address space into different memory addresses accessible by the load / store unit 1566.

[0178] The register file 1558 provides a set of registers for the functional units of the graphics multiprocessor 1534. The register file 1558 provides temporary storage for operands of data paths connected to the functional units of the graphics multiprocessor 1534 (e.g., GPGPU core 1562, load / store unit 1566). The register file 1558 may be divided between each functional unit so that each functional unit may be allocated a dedicated portion of the register file 1558. For example, the register file 1558 may be divided between different warps executed by the graphics multiprocessor 1534.

[0179] The GPGPU cores 1562 may each include a floating point unit (FPU) and / or an integer arithmetic logic unit (ALU) that is used to execute instructions of the graphics multiprocessor 1534. In some implementations, the GPGPU cores 1562 may include hardware logic that may otherwise exist within the tensor and / or ray tracing cores 1563. The GPGPU cores 1562 may be similar in architecture or may be different in architecture. For example, in some examples, a first portion of the GPGPU core 1562 includes a single-precision FPU and an integer ALU, while a 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 1534 may also include one or more fixed-function or special-function units to perform specific functions, such as copying rectangles or pixel blending operations. One or more GPGPU cores may also include fixed or special-function logic.

[0180] GPGPU core 1562 may include SIMD logic capable of executing a single instruction to multiple sets of data. Optionally, GPGPU core 1562 may physically execute SIMD4, SIMD8, and SIMD16 instructions, and logically execute SIMD1, SIMD2, and SIMD32 instructions. The SIMD instructions of the GPGPU core 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, in some examples, eight SIMT threads performing the same or similar operation may be executed in parallel via a single SIMD8 logic unit.

[0181] The memory and cache interconnect 1568 is an interconnect network that connects each functional unit of the graphics multiprocessor 1534 to the register file 1558 and the shared memory 1570. For example, the memory and cache interconnect 1568 is a crossbar interconnect that allows the load / store unit 1566 to implement load and store operations between the shared memory 1570 and the register file 1558. The register file 1558 can operate at the same frequency as the GPGPU core 1562, so that the data transfer latency between the GPGPU core 1562 and the register file 1558 is very low. The shared memory 1570 can be used to implement communication between threads executed on the functional units within the graphics multiprocessor 1534. The cache memory 1572 can be used, for example, as a data cache to cache texture data communicated between the functional unit and the texture unit 1536. The shared memory 1570 can also be used as a program management cache. The shared memory 1570 and the cache memory 1572 can be coupled to the data crossbar 1540 to enable communication with other components of the processing cluster. In addition to automatically cached data stored in cache memory 1572, threads executing on GPGPU core 1562 can also programmatically store data in shared memory.

[0182] Figures 16A-16C Additional graphics multiprocessors are illustrated according to examples. Figures 16A-16B Graphics multiprocessors 1625, 1650 are shown, which are connected to Fig. 15C The graphics multiprocessor 1534 of FIG. 1625 and can be used to replace one of them. Therefore, any feature disclosed herein in conjunction with the graphics multiprocessor 1534 also discloses a corresponding combination with (one or more) graphics multiprocessors 1625, 1650, but is not limited to this. Fig. 16C A graphics processing unit (GPU) 1680 is illustrated that includes a collection of specialized graphics processing resources arranged into multi-core groups 1665A-1665N, which correspond to graphics multiprocessors 1625, 1650. The illustrated graphics multiprocessors 1625, 1650 and multi-core groups 1665A-1665N may be streaming multiprocessors (SMs) that are capable of executing a large number of execution threads simultaneously.

[0183] Relative to Fig.15D Graphics multiprocessor 1534, Fig.16AThe graphics multiprocessor 1625 includes multiple additional instances of execution resource units. For example, the graphics multiprocessor 1625 may include multiple instances of instruction units 1632A-1632B, register files 1634A-1634B, and (one or more) texture units 1644A-1644B. ​​The graphics multiprocessor 1625 also includes multiple groups of graphics or computational execution units (e.g., GPGPU cores 1636A-1636B, tensor cores 1637A-1637B, ray tracing cores 1638A-1638B) and multiple groups of load / store units 1640A-1640B. The execution resource units have a shared instruction cache 1630, texture and / or data cache memory 1642, and a shared memory 1646.

[0184] The various components may communicate via the interconnect structure 1627. The interconnect structure 1627 may include one or more crossbar switches to enable communication between the various components of the graphics multiprocessor 1625. The interconnect structure 1627 may be a separate high-speed network fabric layer on which each component of the graphics multiprocessor 1625 is stacked. The components of the graphics multiprocessor 1625 communicate with remote components via the interconnect structure 1627. For example, the cores 1636A-1636B, 1637A-1637B, and 1638A-1638B may each communicate with the shared memory 1646 via the interconnect structure 1627. The interconnect structure 1627 may arbitrate communications within the graphics multiprocessor 1625 to ensure fair bandwidth allocation between components.

[0185] Fig. 16B The graphics multiprocessor 1650 includes multiple groups of execution resources 1656A-1656D, wherein each group of execution resources includes multiple instruction units, register files, GPGPU cores, and load storage units, such as Fig.15D and Fig.16A 1656A-1656D can work in conjunction with (one or more) texture units 1660A-1660D to perform texture operations while sharing instruction cache 1654 and shared memory 1653. For example, execution resources 1656A-1656D can share instruction cache 1654 and shared memory 1653, as well as multiple instances of texture and / or data caches 1658A-1658B. Various components can be connected to the same Fig.16A The interconnect structure 1627 communicates with a similar interconnect structure 1652 .

[0186] Those skilled in the art will understand that Figure 1 , Figures 15A-15D and Figures 16A-16BThe architecture described in the present invention is merely illustrative and does not limit the scope of the present examples. Therefore, the techniques described herein may be implemented on any appropriately configured processing unit, 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 processing units (e.g., Fig.15A parallel processing unit 1502), and one or more graphics processors or special purpose processing units without departing from the scope of the examples described herein.

[0187] A parallel processor or GPGPU as described herein may 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 may be communicatively coupled to a host processor / core via a bus or other 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 may be integrated with the core on the same package or chip and communicatively coupled to the core via an internal processor bus / interconnect (i.e., inside a package or chip). Regardless of how the GPU is connected, the processor core may assign work to the GPU in the form of a sequence of commands / instructions contained in a work descriptor. The GPU then uses dedicated circuits / logic to efficiently process these commands / instructions.

[0188] Fig. 16C A graphics processing unit (GPU) 1680 is illustrated that includes a collection of specialized graphics processing resources arranged into multi-core groups 1665A-1665N. Although details are provided for only a single multi-core group 1665A, it will be appreciated that other multi-core groups 1665B-1665N may be equipped with the same or similar sets of graphics processing resources. The detailed descriptions related to multi-core groups 1665A-1665N may also apply to any of the graphics multiprocessors 1534, 1625, and 1650 described herein.

[0189] As shown, multi-core group 1665A may include a set of graphics cores 1670, a set of tensor cores 1671, and a set of ray tracing cores 1672. Scheduler / dispatcher 1668 schedules and dispatches graphics threads for execution on various cores 1670, 1671, 1672. A set of register files 1669 may store operand values ​​used by cores 1670, 1671, and 1672 when executing graphics threads. These registers may include, for example, integer registers for storing integer values, floating point registers for storing floating point values, vector registers for storing packed data elements (integer and / or floating point data elements), and tile registers for storing tensor / matrix values. Tile registers may be implemented as a combined set of vector registers.

[0190] One or more combined level 1 (L1) caches and shared memory units 1673 store graphics data such as texture data, vertex data, pixel data, ray data, bounded volume data, etc. locally within each multi-core group 1665A. One or more texture units 1674 can also be used to perform texture rendering operations, such as texture mapping and sampling. A level 2 (L2) cache 1675 shared by all or a subset of the multi-core groups 240A-240N can store graphics data and / or instructions for multiple concurrent graphics threads. As shown, the L2 cache 1675 can be shared between multiple multi-core groups 1665A-1665N. One or more memory controllers 1667 couple the GPU 1680 to a memory 1666, which can be system memory (e.g., DRAM) and / or dedicated graphics memory (e.g., GDDR6 memory).

[0191] Input / output (I / O) circuitry 1663 couples GPU 1680 to one or more I / O devices 1662, 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 1662 to GPU 1680 and memory 1666. One or more I / O memory management units (IOMMUs) 1664 of I / O circuitry 1663 couple I / O devices 1662 directly to memory 1666. Optionally, IOMMUs 1664 manage multiple sets of page tables to map virtual addresses to physical addresses in system memory 1666. I / O devices 1662, CPU(s) 1661, and GPU 1680 may then share the same virtual address space.

[0192] In one implementation of IOMMU 1664, IOMMU 1664 supports virtualization. In this case, it can manage a first set of page tables to map guest / graphics virtual addresses to guest / graphics physical addresses, and a second set of page tables to map guest / graphics physical addresses to system / host physical addresses (e.g., within system memory 1666). The base address of each of the first and second sets of page tables can be stored in a control register and swapped out at context switch time (e.g., to enable a new context to access the associated set of page tables). Although in Fig. 16CNot shown, each core 1670, 1671, 1672 and / or multi-core group 1665A-16650N may include a translation lookaside buffer (TLB) to cache guest virtual to guest physical translations, guest physical to host physical translations, and guest virtual to host physical translations.

[0193] (One or more) CPU 1661, GPU 1680 and I / O device 1662 can be integrated on a single semiconductor chip and / or chip package. The illustrated memory 1666 can be integrated on the same chip, or can be coupled to a memory controller 1667 via an off-chip interface. In one implementation, the memory 1666 includes GDDR6 memory that shares the same virtual address space with other physical system-level memories, but the underlying principles described herein are not limited to this particular implementation.

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

[0195] In a deep learning implementation, parallel matrix multiplication work can be scheduled to execute on the tensor core 1671. The training of neural networks in particular requires a large number of matrix dot product operations. To process the inner product formula of Nx Nx N matrix multiplication, the tensor core 1671 may include at least N dot product processing elements. Before the matrix multiplication begins, a complete matrix is ​​loaded into the tile register, and at least one column of the second matrix is ​​loaded in each cycle within N cycles. In each cycle, N dot products are processed.

[0196] 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), depending on the specific implementation. Different precision modes can be specified for the tensor core 1671 to ensure that the most efficient precision is used for different workloads (e.g., reasoning workloads, which can tolerate quantization to bytes and nibbles). Supported formats also include 64-bit floating point (FP64) and non-IEEE floating point formats, such as the bfloat16 format (e.g., brain floating point), which is a 16-bit floating point format with a sign bit, eight exponent bits, and eight significand bits, of which seven bits are explicitly stored. An example includes support for reduced precision tensor-floating point (TF32) mode, which 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 higher precision relative to FP16. In some examples, one or more 8-bit floating point formats (FP8) are supported.

[0197] In some examples, the tensor core 1671 supports a sparse operation mode for matrices, in which the vast majority of values ​​are zero. The tensor core 1671 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.). In the case where the sparse matrix representation can be further compressed, the tensor core 1671 also includes support for compressed sparse matrix representations. Compressed, encoded, and / or compressed and encoded matrix data and associated compression and / or encoding metadata can be read by the tensor core 1671, and non-zero values ​​can be extracted. For example, for a given input matrix A, non-zero values ​​can be loaded from a compressed and / or encoded representation of at least a portion of matrix A. Based on the position of the non-zero value in matrix A (which can be determined based on 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), if the corresponding value is a zero value, the operation of loading the value from the input matrix B can be bypassed. In some examples, the pairing of values ​​for certain operations (e.g., multiplication operations) may be pre-scanned by the scheduler logic, and only operations between non-zero inputs are scheduled. Depending on the size of matrices A and B and the operations to be performed, the output matrix C may be dense or sparse. In the case where the output matrix C is sparse, depending on the configuration of the tensor core 1671, the output matrix C may be output in a compressed format, sparse coding, or compressed sparse coding.

[0198] The ray tracing core 1672 can accelerate ray tracing operations for both real-time ray tracing and non-real-time ray tracing implementations. Specifically, the ray tracing core 1672 may include a ray traversal / intersection circuit for performing ray traversal using a bounding volume hierarchy (BVH) and identifying intersections between rays and primitives enclosed within the BVH volume. The ray tracing unit 1672 may also include circuits for performing depth testing and culling (e.g., using a Z buffer or similar arrangement). In one implementation, the ray tracing core 1672 performs traversal and intersection operations in conjunction with the image denoising technique described herein, at least a portion of which may be performed on the tensor core 1671. For example, the tensor core 1671 may implement a deep learning neural network to perform denoising on frames generated by the ray tracing core 1672. However, (one or more) CPUs 1661, graphics core 1670, and / or ray tracing core 1672 may also implement all or part of the denoising and / or deep learning algorithms.

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

[0200] The ray tracing core 1672 can handle all BVH traversals and / or ray primitive intersections so that the graphics core 1670 is not overloaded with thousands of instructions per ray. For example, each ray tracing core 1672 includes a first set of dedicated circuits for performing bounding box tests (e.g., for traversal operations) and / or a second set of dedicated circuits for performing ray-triangle intersection tests (e.g., traversed intersecting rays). Thus, for example, multi-core group 1665A can simply start a ray probe, and the ray tracing core 1672 independently performs ray traversals and intersections and returns hit data (e.g., hits, misses, multiple hits, etc.) to the thread context. While the ray tracing core 1672 performs traversal and intersection operations, the other cores 1670, 1671 are freed up to perform other graphics or computational work.

[0201] Optionally, each ray tracing core 1672 may include a traversal unit that performs BVH test operations and / or an intersection unit that performs ray-primitive intersection tests. The intersection unit generates a "hit", "miss", or "multiple hits" response and provides it to the appropriate thread. During traversal and intersection operations, execution resources of other cores (e.g., graphics core 1670 and tensor core 1671) are freed up to perform other forms of graphics work.

[0202] In some examples described below, a hybrid rasterization / ray tracing scheme is used in which the work is distributed between graphics core 1670 and ray tracing core 1672.

[0203] The ray tracing core 1672 (and / or other cores 1670, 1671) may include hardware support for ray tracing instruction sets, such as Microsoft's DirectX Ray Tracing (DXR), which includes the DispatchRays command, as well as ray generation, nearest hit, any hit, and miss shaders, which enable unique shader and texture sets to be assigned to each object. Another ray tracing platform that the ray tracing core 1672, graphics core 1670, and tensor core 1671 can support is the Vulkan API (e.g., Vulkan 1.1.85 and later). However, it should be noted that the underlying principles described herein are not limited to any particular ray tracing ISA.

[0204] In general, the various cores 1672, 1671, 1670 may support a ray tracing instruction set that includes instructions / functions for one or more of ray generation, nearest hit, any hit, ray-primitive intersection, per-primitive and hierarchical bounding box construction, misses, visits, and exceptions. More specifically, some examples include ray tracing instructions for performing one or more of the following functions:

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

[0206] Closest Hit—A closet hit instruction can be executed to locate the closest intersection point of a ray with a primitive within the scene.

[0207] Any Hit—Any Hit instruction identifies multiple intersections of a ray with primitives within the scene, potentially identifying a new closest intersection point.

[0208] The intersection-intersection commands perform ray-primitive intersection tests and output the results.

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

[0210] Misses—Indicates that the ray missed all geometry within the scene or within a specified area of ​​the scene.

[0211] Visits—Indicates the subvolumes that the ray will traverse.

[0212] Exceptions—Includes various types of exception handlers (eg, called for various error conditions).

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

[0214] The ray tracing core 1672 can also be used to perform calculations that are not directly similar to ray tracing. For example, the ray tracing core 1672 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, by defining a bounding box in the coordinate space around a given point, a set of points near the point can be found. The BVH and ray detection logic within the ray tracing core 1672 can then be used to determine the set of intersections within the bounding box. These intersections constitute the origin and the nearest neighbors of the origin. Calculations performed using the ray tracing core 1672 can be performed in parallel with calculations performed on the graphics core 1672 and the tensor core 1671. 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 processed in parallel on the graphics core 1670, the tensor core 1671, and the ray tracing core 1672.

[0215] Building larger and larger silicon dies is challenging for a variety of reasons. As silicon dies get larger, manufacturing yields become smaller, and process technology requirements for different components may diverge. On the other hand, to achieve high-performance systems, key components should be connected to each other through high-speed, high-bandwidth, low-latency interfaces. These conflicting requirements pose challenges to high-performance chip development.

[0216] The embodiments described herein provide a technique for decomposing the architecture of an on-chip integrated circuit system into a plurality of different chiplets that can be packaged into a common housing. In some examples, a graphics processing unit or a parallel processor is composed of different silicon chiplets manufactured separately. A chiplet is an integrated circuit that is at least partially packaged and includes different logic units that can be assembled with other chiplets into a larger package. Different chiplet groups with different IP core logic can be assembled into a single device. In addition, active insert technology can be used to integrate chiplets into a base die or base chiplet. The concepts described herein make it possible to interconnect and communicate between different forms of IP within a GPU. The development of IPs on different processes can be mixed. This avoids the complexity of converging multiple IPs, especially on large SoCs with multiple styles of IPs, to the same process.

[0217] 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 products that better meet their requirements in a cost-effective and timely manner. In addition, disaggregated IP is more suitable for being independently power-gated, and components that are not used on a given workload can be powered off, reducing overall power consumption.

[0218] Fig.17 A parallel computing system 1700 according to some examples is shown. In some examples, the parallel computing system 1700 includes a parallel processor 1720, which can be a graphics processor or a computing accelerator as described herein. The parallel processor 1720 includes a global logic unit 1701, an interface 1702, a thread dispatcher 1703, a media unit 1704, a group of computing units 1705A-1705H, and a cache / memory unit 1706. The global logic unit 1701 includes global functions of the parallel processor 1720 in some examples, including device configuration registers, a global scheduler, power management logic, etc. The interface 1702 may include a front-end interface of the parallel processor 1720. The thread dispatcher 1703 can receive a workload from the interface 1702 and dispatch the threads of the workload to the computing units 1705A-1705H. If the workload includes any media operations, at least a portion of these operations can be performed by the media unit 1704. The media unit may also offload some operations to the compute units 1705A-1705H. The cache / memory unit 1706 may include cache memory (eg, L3 cache) and local memory (eg, HBM, GDDR) for the parallel processors 1720.

[0219] Figures 18A-18BIllustrated is a hybrid logical / physical view of a factorized parallel processor according to examples described herein. Fig.18A A decomposed parallel computing system 1800 is illustrated. Fig.18B A chiplet 1830 of the decomposed parallel computing system 1800 is illustrated.

[0220] like Fig.18A As shown, the decomposed computing system 1800 may include a parallel processor 1820, wherein various components of the parallel processor SOC are distributed across multiple chiplets. Each chiplet may be a different IP core of independent design, and the IP core is configured to communicate with other chiplets via one or more common interfaces. The chiplets include, but are not limited to, a computing chiplet 1805, a media chiplet 1804, and a memory chiplet 1806. Each chiplet can be manufactured separately using different process technologies. For example, the computing chiplet 1805 can be manufactured using the smallest or most advanced process technology available at the time of manufacture, while the memory chiplet 1806 or other chiplets (e.g., I / O, networking, etc.) can be manufactured using larger or less advanced process technologies.

[0221] Various chiplets may be bonded to a base die 1810 and configured to communicate with each other and logic within the base die 1810 via an interconnect layer 1812. In some examples, the base die 1810 may include global logic 1801, which may include a scheduler 1811 and power management 1821 logic unit, an interface 1802, a dispatch unit 1803, and an interconnect fabric module 1808 coupled or integrated with one or more L3 cache bank groups 1809A-1809N. The interconnect fabric 1808 may be an inter-chiplet fabric integrated into the base die 1810. The logic chiplets may use the fabric 1808 to pass messages between the various chiplets. In addition, the L3 cache bank groups 1809A-1809N in the base die and / or the L3 cache bank groups within the memory chiplets 1806 may cache data read from the DRAM chiplets within the memory chiplets 1806 and sent to these DRAM chiplets and to the system memory of the host.

[0222] In some examples, global logic 1801 is a microcontroller that can execute firmware to perform scheduler 1811 and power management 1821 functions for parallel processor 1820. The microcontroller that executes the global logic can be customized based on the target use case of parallel processor 1820. Scheduler 1811 can perform global scheduling operations for parallel processor 1820. Power management 1821 functions can be used to enable or disable individual chiplets within a parallel processor when they are not in use.

[0223] The various chiplets of the parallel processor 1820 may be designed to perform specific functions that would otherwise be integrated into a single die in existing designs. A set of compute chiplets 1805 may include a cluster of compute units (e.g., execution units, streaming multiprocessors, etc.) that include programmable logic to execute compute or graphics shader instructions. Media chiplets 1804 may include hardware logic to accelerate media encoding and decoding operations. Memory chiplets 1806 may include volatile memory (e.g., DRAM) and one or more SRAM cache memory bank groups (e.g., L3 bank groups).

[0224] like Fig.18B As shown, each chiplet 1830 may include common components and application-specific components. The chiplet logic 1836 within the chiplet 1830 may include specific components of the chiplet, such as an array of streaming multiprocessors, compute units, or execution units described herein. The chiplet logic 1836 may be coupled to an optional cache or shared local memory 1838, or may include a cache or shared local memory within the chiplet logic 1836. The chiplet 1830 may include a fabric interconnect node 1842 that receives commands via an inter-chiplet fabric. Commands and data received via the fabric interconnect node 1842 may be temporarily stored in an interconnect buffer 1839. Data sent to and received from the fabric interconnect node 1842 may be stored in the interconnect cache 1840. Power control 1832 and clock control 1834 logic may also be included within the chiplet. The power control 1832 and clock control 1834 logic may receive configuration commands via the fabric and may configure dynamic voltage and frequency scaling for the chiplet 1830. In some examples, each chiplet can have independent clock and power domains and can be clock-gated and power-gated independently of other chiplets.

[0225] At least a portion of the components within the illustrated chiplet 1830 may also be included in a Fig.18A 1810. For example, logic within a base die that communicates with the fabric may include a version of fabric interconnect node 1842. Independently clocked or power gated base die logic may include a version of power control 1832 and / or clock control 1834 logic.

[0226] Thus, while various examples described herein use the term SOC to describe a device or system 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 (“IC”) die or chip, the present disclosure is not limited in this regard. 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.) that are arranged in a disaggregated collection of discrete dies, tiles, and / or chiplets (e.g., one or more discrete processor core dies are arranged adjacent to one or more other dies (e.g., memory dies, I / O dies, etc.)). In such disaggregated devices and systems, the various dies, tiles, and / or chiplets may be physically and electrically coupled together by a packaging structure that may include, for example, various packaging substrates, interposers, active interposers, photonic interposers, interconnect bridges, and the like. A disaggregated collection of discrete dies, tiles, and / or chiplets may also be part of a system-in-package ("SoP").

[0227] Example core architectures—in-order and out-of-order core block diagrams.

[0228] The block diagram of FIG. 19(A) illustrates both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to some examples. The block diagram of FIG. 19(B) illustrates 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. The solid line boxes in FIG. 19(A)-(B) illustrate the in-order pipeline and the 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.

[0229] In FIG. 19(A), a processor pipeline 1900 includes a fetch stage 1902, an optional length decoding stage 1904, a decode stage 1906, an optional allocation (Alloc) stage 1908, an optional rename stage 1910, a dispatch (also called dispatch or issue) stage 1912, an optional register read / memory read stage 1914, an execute stage 1916, a write back / memory write stage 1918, an optional exception handling stage 1922, and an optional commit stage 1924. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1902, one or more instructions are fetched from an instruction memory, and during the decode stage 1906, 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 1906 and register read / memory read stage 1914 can be combined into one pipeline stage. In some examples, during execute stage 1916, 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.

[0230] As an example, the example register renaming, out-of-order issue / execution architecture core of FIG. 19(B) may implement pipeline 1900 by: 1) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 2) decoding circuit 1940 performs decoding stage 1906; 3) renaming / allocator unit circuit 1952 performs allocation stage 1908 and renaming stage 1910; 4) (one or more) scheduler circuit 1956 performs scheduling stage 1912; 5) (one or more) physical registers 1910; 6) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 7) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 8) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 9) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 10) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 11) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 12) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 13) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 14) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 15) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and 1904; 16) instruction fetch circuit 1938 performs fetch and length decoding stages 1902 and The register file circuit 1958 and the memory unit circuit 1970 perform the register read / memory read phase 1914; (one or more) execution clusters 1960 perform the execute phase 1916; 6) the memory unit circuit 1970 and (one or more) physical register file circuits 1958 perform the write back / memory write phase 1918; 7) various circuits may be involved in the exception handling phase 1922; and 8) the retirement unit circuit 1954 and (one or more) physical register file circuits 1958 perform the commit phase 1924.

[0231] 19(B) shows that the processor core 1990 includes a front end unit circuit 1930 coupled to an execution engine unit circuit 1950, and both are coupled to a memory unit circuit 1970. The core 1990 may be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 1990 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.

[0232] The front end unit circuit 1930 may include a branch prediction circuit 1932 coupled to an instruction cache circuit 1934 coupled to an instruction translation lookaside buffer (TLB) 1936 coupled to an instruction fetch circuit 1938 coupled to a decode circuit 1940. In some examples, the instruction cache circuit 1934 is included in the memory unit circuit 1970 instead of the front end circuit 1930. The decode circuit 1940 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode circuit 1940 may also include an address generation unit (AGU, not shown) circuit. 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 1940 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 1990 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit 1940 or otherwise within the front end circuit 1930). In some examples, the decode circuit 1940 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 1900. The decode circuit 1940 may be coupled to the rename / allocator unit circuit 1952 in the execution engine circuit 1950.

[0233] The execution engine circuit 1950 includes a rename / allocator unit circuit 1952 coupled to a retirement unit circuit 1954 and a set of one or more scheduler circuits 1956. The scheduler circuits 1956 represent any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuit(s) 1956 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuit(s) 1956 are coupled to the physical register file(s) circuit(s) 1958. Each of the physical register file circuits 1958 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., an instruction pointer that is the address of the next instruction to be executed), and the like. In some examples, the (one or more) physical register file circuits 1958 include vector register unit circuits, write mask register unit circuits, and scalar register unit circuits. These register units can provide architectural vector registers, vector mask registers, general registers, etc. The (one or more) physical register file circuits 1958 are coupled to the retirement unit circuit 1954 (also called the retirement queue) to demonstrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROB) 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.). The retirement unit circuit 1954 and the (one or more) physical register file circuits 1958 are coupled to (one or more) execution clusters 1960. The (one or more) execution clusters 1960 include a set of one or more execution unit circuits 1962 and a set of one or more memory access circuits 1964. The execution unit circuit(s) 1962 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 circuits dedicated to a particular function or set of functions, other examples may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 1956, physical register file circuit(s) 1958, and execution cluster(s) 1960 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with its own scheduler circuit(s), physical register file circuit(s), and / or execution cluster—and in the case of a separate memory access pipeline, only the execution cluster of that pipeline has memory access unit circuit(s) 1964 in some examples of the implementation). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0234] In some examples, the execution engine unit circuit 1950 can 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.

[0235] A set of memory access circuits 1964 are coupled to the memory cell circuit 1970, which includes a data TLB circuit 1972, which is coupled to a data cache circuit 1974, which is coupled to a level 2 (L2) cache circuit 1976. In some examples, the memory access circuit 1964 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 1972 in the memory cell circuit 1970. The instruction cache circuit 1934 is further coupled to the level 2 (L2) cache circuit 1976 in the memory cell circuit 1970. In some examples, the instruction cache 1934 and the data cache 1974 are combined into an L2 cache circuit 1976, a level 3 (L3) cache circuit (not shown), and / or a single instruction and data cache in the main memory (not shown). The L2 cache circuit 1976 is coupled to one or more other levels of cache and ultimately coupled to the main memory.

[0236] Core 1990 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 1990 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.

[0237] Example execution unit circuit(s).

[0238] Fig. 20 An example of (one or more) execution unit circuits is illustrated, such as (one or more) execution unit circuits 1962 of FIG. 19 (B). As shown, (one or more) execution unit circuits 1962 may include one or more ALU circuits 2001, optional vector / single instruction multiple data (single instruction multiple data, SIMD) circuits 2003, load / store circuits 2005, branch / jump circuits 2007, and / or floating-point unit (FPU) circuits 2009. ALU circuits 2001 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 2003 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 2005 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store circuits 2005 may also generate addresses. Branch / jump circuits 2007 cause branches or jumps to a certain memory address depending on the instruction. FPU circuit 2009 performs floating point arithmetic. The width of execution unit circuit(s) 1962 varies depending on the example and may range, for example, from 16 bits to 1024 bits. 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).

[0239] Instruction set architecture.

[0240] 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. Therefore, each instruction of an 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 that selects 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 to other ISAs.

[0241] Example instruction format.

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

[0243] Fig.21 An example of a second prefix 201(A) is illustrated. In some examples, the second prefix 201(A) is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction, multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0244] Instructions using the second prefix 201(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the reg field 344 and the R / M field 346 of the MOD R / M byte 302; 2) using the MOD R / M byte 302 with the SIB byte 304, including using the reg field 344 as well as the base field 356 and the index field 354; or 3) using the register field of the opcode.

[0245] In the second prefix 201 (A), bit positions 7:4 of the payload bytes are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0246] Note that adding another bit allows addressing 16 (2 4 ) registers, while the separate MOD R / M reg field 344 and MOD R / MR / M field 346 can only address 8 registers each.

[0247] In the second prefix 201 (A), bit position 2 (R) may be an extension of the MOD R / M reg field 344 and may be used to modify the MOD R / M reg field 344 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 302 specifies other registers or defines an extended opcode, R is ignored.

[0248] Bit position 1 (X) may modify the SIB byte index field 354 .

[0249] Bit position 0 (B) may modify the base address in R / M field 346 or SIB byte base address field 356 of MOD R / M; or it may modify the opcode register field used to access a general register (eg, general register 625).

[0250] 22(A)-(D) illustrate examples of how the R, X, and B fields of the second prefix 201(A) are used. FIG. 22(A) illustrates that when the SIB byte 304 is not used for memory addressing, the R and B from the second prefix 201(A) are used to extend the reg field 344 and the R / M field 346 of the MOD R / M byte 302. FIG. 22(B) illustrates that when the SIB byte 304 is not used, the R and B from the second prefix 201(A) are used to extend the reg field 344 and the R / M field 346 of the MOD R / M byte 302 (register-register addressing). FIG. 22(C) illustrates that when the SIB byte 304 is used for memory addressing, the R, X, and B from the second prefix 201(A) are used to extend the reg field 344 and the index field 354 and the base address field 356 of the MOD R / M byte 302. FIG. 22(D) illustrates that when a register is encoded in the opcode 203 , the B from the second prefix 201 (A) is used to extend the reg field 344 of the MOD R / M byte 302 .

[0251] Figure 23 (A)-(B) illustrates an example of a third prefix 201 (B). In some examples, the third prefix 201 (B) is an example of a VEX prefix. The third prefix 201 (B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector / SIMD register 610) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the third prefix 201 (B) provides a syntax for three operands (or more). For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the third prefix 201 (B) enables the operands to perform non-destructive operations, such as A=B+C.

[0252] In some examples, the third prefix 201(B) has two forms, a two-byte form and a three-byte form. The two-byte third prefix 201(B) is mainly used for 128-bit, scalar and some 256-bit instructions; while the three-byte third prefix 201(B) provides a compact replacement for 3-byte opcode instructions and the second prefix 201(A).

[0253] Figure 23 (A) illustrates an example of a two-byte form of the third prefix 201 (B). In some examples, the format field 2301 (byte 0 2303) contains the value C5H. In some examples, byte 1 2305 includes an "R" value in bit [7]. This value is the complement of the "R" value of the second prefix 201 (A). Bit [2] is used to specify the length (L) of the vector (wherein the value of 0 is a scalar or 128-bit vector, and the value of 1 is a 256-bit vector). Bit [1:0] provides an operation code extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0254] Instructions using this prefix may use the MOD R / MR / M field 346 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0255] Instructions using this prefix may use the MOD R / M reg field 344 to encode either a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0256] For instruction syntax supporting four operands, three of the four operands are encoded by vvvv, MOD R / MR / M field 346, and MOD R / M reg field 344. Bits [7:4] of immediate value field 209 are then used to encode the third source register operand.

[0257] Figure 23 (B) illustrates an example of a three-byte form of the third prefix 201 (B). In some examples, the format field 2311 (byte 0 2313) contains the value C4H. Byte 1 2315 includes "R", "X" and "B" in bits [7:5], which are the complements of these values ​​of the second prefix 201 (A). Bits [4:0] (shown as mmmmm) of byte 1 2315 include content that encodes one or more implicit leading opcode bytes as needed. For example, 00001 means 0FH leading opcode, 00010 means 0F38H leading opcode, 00011 means 0F3AH leading opcode, and so on.

[0258] The use of bit [7] of byte 2 2317 is similar to that of W of the second prefix 201 (A), including helping to determine the size of operands that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form, valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value, such as 1111b.

[0259] Instructions using this prefix may use the MOD R / MR / M field 346 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0260] Instructions using this prefix may use the MOD R / M reg field 344 to encode either a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0261] For instruction syntax supporting four operands, three of the four operands are encoded by vvvv, MOD R / MR / M field 346, and MOD R / M reg field 344. Bits [7:4] of immediate value field 209 are then used to encode the third source register operand.

[0262] Graphics Execution Unit

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

[0264] like Fig.24AAs shown in , in some examples, thread execution logic 2400 includes a shader processor 2402, a thread dispatcher 2404, an instruction cache 2406, a scalable execution unit array including a plurality of execution units 2408A-2408N, a sampler 2410, a shared local memory 2411, a data cache 2412, and a data port 2414. 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 2408A, 2408B, 2408C, 2408D to 2408N-1 and 2408N) based on the computational requirements of the workload. In some examples, the included components are interconnected via an interconnect structure linked to each component. In some examples, thread execution logic 2400 includes one or more connections to a memory (e.g., system memory or cache memory) through instruction cache 2406, data port 2414, sampler 2410, and one or more of execution units 2408A-2408N. In some examples, each execution unit (e.g., 2408A) is an independent programmable general-purpose computing unit that is 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 2408A-2408N is scalable to include any number of individual execution units.

[0265] In some examples, execution units 2408A-2408N are primarily used to execute shader programs. Shader processor 2402 can process various shader programs and dispatch execution threads associated with the shader programs via thread dispatcher 2404. In some examples, the thread dispatcher includes logic that arbitrates thread initiation requests from graphics and media pipelines and instantiates the requested threads on one or more execution units in execution units 2408A-2408N. For example, a geometry pipeline can dispatch vertex, subdivision, or geometry shaders to thread execution logic for processing. In some examples, thread dispatcher 2404 can also handle runtime thread derivation requests from executing shader programs.

[0266] In some examples, the instruction set supported by execution units 2408A-2408N includes native support for many standard 3D graphics shader instructions, so that when executing shader programs from graphics libraries (e.g., Direct 3D and OpenGL), only minimal translation is required. The execution unit supports 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 of execution units 2408A-2408N is capable of multi-issue single instruction multiple data (SIMD) execution and multi-threaded operations enable efficient execution environments in the face of higher latency memory accesses. Each hardware thread within each execution unit has a dedicated high-bandwidth register stack and associated independent thread state. Execution is multi-issued to the pipeline at each clock, capable of integer, single-precision and double-precision floating-point operations, SIMD branching capabilities, logical operations, transcendental operations, and other miscellaneous operations. While waiting for data from one of the memory or shared functions, the dependency logic within the execution unit 2408A-2408N causes the waiting thread to sleep until the requested data has been returned. While the waiting thread is sleeping, hardware resources can be used to process other threads. For example, during the delay period associated with the vertex shader operation, the execution unit can perform operations for pixel shaders, fragment shaders, or other types of shader programs, including different vertex shaders. Various examples can be applied to use execution by using single instruction multiple threads (SIMT) as an alternative to using SIMD or in addition to using SIMD. References to SIMD cores or operations can also be applied to SIMT or to SIMD combined with SIMT.

[0267] Each of the execution units 2408A-2408N operates on an array of data elements. The number of data elements is the "execution size," or number of lanes of an instruction. An execution lane is a logical execution unit used for 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) of a particular graphics processor. In some examples, the execution units 2408A-2408N support integer and floating point data types.

[0268] 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 (data elements of four words (QW) size), eight independent 32-bit compact data elements (data elements of double words (DW) size), sixteen independent 16-bit compact data elements (data elements of word (W) size), or thirty-two independent 8-bit data elements (data elements of byte (B) size). However, different vector widths and register sizes are possible.

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

[0270] One or more internal instruction caches (e.g., 2406) are included in the thread execution logic 2400 to cache thread instructions for the execution unit. In some examples, one or more data caches (e.g., 2412) are included to cache thread data during thread execution. Threads executed on the execution logic 2400 can also store explicitly managed data in the shared local memory 2411. In some examples, a sampler 2410 is included to provide texture sampling for 3D operations and media sampling for media operations. In some examples, the sampler 2410 includes a specialized texture or media sampling function to process texture or media data during the sampling process and then provide the sampled data to the execution unit.

[0271] During execution, the graphics and media pipeline sends thread initiation requests to the thread execution logic 2400 via thread derivation and dispatch logic. Once a set of geometric objects is processed and rasterized into pixel data, the pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within the shader processor 2402 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 values ​​of various vertex attributes to be interpolated on the rasterized object. In some examples, the pixel processor logic within the shader processor 2402 then executes the pixel or fragment shader program provided by the application programming interface (API). To execute the shader program, the shader processor 2402 dispatches the thread to an execution unit (e.g., 2408A) via the thread dispatcher 2404. In some examples, the shader processor 2402 uses the texture sampling logic in the sampler 2410 to access the texture data in the texture atlas 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 from further processing.

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

[0273] In some examples, execution logic 2400 may also include a ray tracer 2405, which may provide ray tracing acceleration functionality. Ray tracer 2405 may support a ray tracing instruction set that includes instructions / functions for ray generation.

[0274] Fig. 24B2426, and a set of dedicated integer SIMD ALUs 2435. The GRF 2424 and ARF 2426 include a set of general register files and architectural register files associated with each simultaneous hardware thread that may be active in the graphics execution unit 2408. In some examples, the per-thread architectural state is maintained in the ARF 2426, while data used during thread execution is stored in the GRF 2424. The execution state of each thread, including the instruction pointer of each thread, can be saved in thread-specific registers in the ARF 2426.

[0275] In some examples, the graphics execution unit 2408 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 resources are divided between the logic for executing multiple simultaneous threads. The number of logical threads that the graphics execution unit 2408 can execute is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread.

[0276] In some examples, the graphics execution unit 2408 may issue multiple instructions together, each of which may be a different instruction. The thread arbiter 2408 of the graphics execution unit 2408 may dispatch instructions to the send unit 2430, the branch unit 2432, or one of (one or more) SIMD FPUs 2434 for execution. Each execution thread may access 128 general registers within the GRF 2424, each of which may store 32 bytes, which may be accessed as a SIMD8 element vector of 32-bit data elements. In some examples, each execution unit thread is able to access 4K bytes within the GRF 2424, but the example is not limited thereto, and more or less register resources may be provided in other examples. In some examples, the graphics execution unit 2408 is partitioned into seven hardware threads, which may independently perform computing operations, but the number of threads per 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 may access 4K bytes, the GRF 2424 may store a total of 28K bytes. With 16 threads accessing 4K bytes, a total of 64K bytes can be stored in the GRF 2424. Flexible addressing modes allow registers to be addressed together, effectively building wider registers or representing strided rectangular block data structures.

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

[0278] In some examples, the graphics execution unit 2408 includes one or more SIMD floating point units (FPUs) 2434 to perform floating point operations. In some examples, (one or more) FPUs 2434 also support integer calculations. In some examples, (one or more) FPUs 2434 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 (one or more) FPUs provides extended math capabilities to support high throughput transcendental math functions and double-precision 64-bit floating point. In some examples, there is also a set of 8-bit integer SIMD ALUs 2435, and these ALUs can be specifically optimized to perform operations associated with machine learning calculations.

[0279] In some examples, an array of multiple instances of graphics execution unit 2408 can be instantiated in graphics sub-core groupings (e.g., sub-slices). To achieve scalability, product architects can select the exact number of execution units for each sub-core grouping. In some examples, execution unit 2408 can execute instructions across multiple execution lanes. In another example, each thread executed on graphics execution unit 2408 is executed on a different lane.

[0280] Fig.25 An additional execution unit 2500 according to one example is illustrated. In some examples, the execution unit 2500 includes a thread control unit 2501, a thread state unit 2502, an instruction fetch / prefetch unit 2503, and an instruction decode unit 2504. The execution unit 2500 also includes a register file 2506 that stores registers that can be assigned to hardware threads within the execution unit. The execution unit 2500 also includes a dispatch unit 2507 and a branch unit 2508. In some examples, the operations of the dispatch unit 2507 and the branch unit 2508 can be similar to Fig. 24B The sending unit 2430 and the branching unit 2432 of the graphics execution unit 2408.

[0281] The execution unit 2500 also includes a computing unit 2510, which includes a plurality of functional units of different types. In some examples, the computing unit 2510 includes an ALU unit 2511, which includes an array of arithmetic logic units. The ALU unit 2511 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 2510 may also include a systolic array 2512, and a mathematical unit 2513. The systolic array 2512 includes a network of data processing units with a width of W and a depth of D, which can be used to perform vector or other data parallel operations in a systolic manner. In some examples, the systolic array 2512 can be configured to perform matrix operations, such as matrix dot product operations. In some examples, the systolic array 2512 supports 16-bit floating-point operations, as well as 8-bit and 4-bit integer operations. In some examples, the systolic array 2512 can be configured to accelerate machine learning operations. In such an example, systolic array 2512 may be configured to support bfloat 16-bit floating point format. In some examples, math unit 2513 may be included to perform a specific subset of math operations in a more efficient, lower power manner than ALU unit 2511. Math unit 2513 may include a variation of math logic that may be found in the shared functional logic of the graphics processing engine provided in other examples. In some examples, math unit 2513 may be configured to perform 32-bit and 64-bit floating point operations.

[0282] Thread control unit 2501 includes logic to control the execution of threads within execution units. Thread control unit 2501 may include thread arbitration logic to start, stop, and preempt the execution of threads within execution unit 2500. Thread state unit 2502 may be used to store thread states of threads assigned to execute on execution unit 2500. Storing thread states within execution unit 2500 enables threads to be quickly preempted when they become blocked or idle. Instruction fetch / prefetch unit 2503 may fetch instructions from instruction caches of higher level execution logic (e.g., Fig.24A The instruction fetch / prefetch unit 2503 may also issue a prefetch request to load instructions into the instruction cache based on an analysis of the currently executing thread. The instruction decode unit 2504 may be used to decode instructions to be executed by the computing unit. In some examples, the instruction decode unit 2504 may be used as a secondary decoder to decode complex instructions into component micro-operations.

[0283] Execution unit 2500 also includes a register file 2506 that can be used by hardware threads executing on execution unit 2500. Registers in register file 2506 can be divided among logic used to execute multiple simultaneous threads within compute unit 2510 of execution unit 2500. The number of logical threads that can be executed by graphics execution unit 2500 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread. The size of register file 2506 can vary between examples based on the number of hardware threads supported. In some examples, register renaming can be used to dynamically allocate registers to hardware threads.

[0284] Fig.26 2600 according to some examples. In one or more examples, the graphics processor execution unit supports an instruction set having instructions in multiple formats. Solid line boxes illustrate components that are generally included in execution unit instructions, while dashed lines include components that are optional or included only in a subset of instructions. In some examples, the instruction format 2600 described and illustrated are macroinstructions because they are instructions provided to the execution unit, rather than micro-operations generated from instruction decoding once the instructions are processed.

[0285] In some examples, the graphics processor execution unit natively supports instructions in 128-bit instruction format 2610. Based on the selected instruction, instruction options, and the number of operands, a 64-bit compressed instruction format 2630 may be used for some instructions. The native 128-bit instruction format 2610 provides access to all instruction options, while some options and operations are restricted in the 64-bit format 2630. The native instructions available in the 64-bit format 2630 vary from example to example. In some examples, a portion of the instruction is compressed using a set of index values ​​in the index field 2613. 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 2610. Instructions of other sizes and formats may also be used.

[0286] For each format, the instruction opcode 2612 defines the operation to be performed by the execution unit. The execution unit executes each instruction in parallel on multiple data elements of each operand. For example, in response to an addition instruction, the execution unit performs simultaneous addition operations on each color channel representing a texture element or a picture element. By default, the execution unit executes each instruction on all data channels of the operand. In some examples, the instruction control field 2614 enables control of certain execution options, such as channel selection (e.g., predicate) and data channel order (e.g., swizzle). For instructions 2610 in a 128-bit instruction format, an execution size field 2616 limits the number of data channels that will be executed in parallel. In some examples, the execution size field 2616 is not available for a 64-bit compressed instruction format 2630.

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

[0288] In some examples, the 128-bit instruction format 2610 includes an access / address mode field 2626 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 address of one or more operands is provided directly by bits in the instruction.

[0289] In some examples, the 128-bit instruction format 2610 includes an access / address mode field 2626 that specifies the address mode and / or access mode of the instruction. In some examples, the access mode is used to define the data access alignment of the instruction. The access modes supported by some examples include a 16-byte aligned access mode and a 1-byte aligned access mode, wherein the byte alignment of the access mode determines the access alignment of the instruction operand. For example, in a first mode, the instruction can use byte-aligned addressing for the source operand and the destination operand, and in a second mode, the instruction can use 16-byte aligned addressing for all source operands and the destination operand.

[0290] In some examples, the address mode portion of the access / address mode field 2626 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.

[0291] In some examples, instructions are grouped based on opcode 2612 bit fields to simplify opcode decoding 2640. For 8-bit opcodes, bits 4, 5, and 6 allow execution units to determine the type of opcode. The precise opcode grouping shown is just an example. In some examples, move and logic opcode groups 2642 include data movement and logic instructions (e.g., move (mov), compare (cmp)). In some examples, move and logic groups 2642 share five most significant bits (most significant bit, MSB), wherein the form of move (mov) instruction is 0000xxxxb, and the form of logic instruction is 0001xxxxb. Flow control instruction group 2644 (e.g., call, jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). Miscellaneous instruction group 2646 includes a mixture of instructions, including synchronization instructions (e.g., wait, send) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group 2648 includes component-wise arithmetic instructions (e.g., addition, multiplication (mul)) of the form 0100xxxxb (e.g., 0x40). The parallel math group 2648 performs arithmetic operations in parallel across data lanes. The vector math group 2650 includes arithmetic instructions (e.g., dp4) of the form 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic operations, such as dot product calculations on vector operands. In some examples, the illustrated opcode decode 2640 may be used to determine which portion of the execution unit will be used to execute the decoded instruction. 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.

[0292] Graphics Pipeline

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

[0294] In some examples, graphics processor 2700 includes geometry pipeline 2720, media pipeline 2730, display engine 2740, thread execution logic 2750, and rendering output pipeline 2770. In some examples, graphics processor 2700 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 by commands issued to graphics processor 2700 via ring interconnect 2702. In some examples, ring interconnect 2702 couples graphics processor 2700 to other processing components, such as other graphics processors or general-purpose processors. Commands from ring interconnect 2702 are interpreted by command stream processor 2703, which provides instructions to individual components of geometry pipeline 2720 or media pipeline 2730.

[0295] In some examples, command stream processor 2703 directs the operation of vertex fetcher 2705, which reads vertex data from memory and executes vertex processing commands provided by command stream processor 2703. In some examples, vertex fetcher 2705 provides vertex data to vertex shader 2707, which performs coordinate space transformation and lighting operations on each vertex. In some examples, vertex fetcher 2705 and vertex shader 2707 execute vertex processing instructions by dispatching execution threads to execution units 2752A-2752B via thread dispatcher 2731.

[0296] In some examples, execution units 2752A-2752B are arrays of vector processors with instruction sets for performing graphics and media operations. In some examples, execution units 2752A-2752B have an attached L1 cache 2751, which is either per array or shared between arrays. The cache can be configured as a data cache, an instruction cache, or a single cache that is partitioned to contain data and instructions in different partitions.

[0297] In some examples, the geometry pipeline 2720 includes a tessellation component to perform hardware accelerated tessellation of 3D objects. In some examples, the programmable hull shader 2711 can configure the tessellation operation. The programmable domain shader 2717 provides back-end evaluation of the tessellation output. The tessellation 2713 operates under the guidance of the hull shader 2711 and contains special purpose logic to generate a set of detailed geometric objects based on the coarse geometric model provided as input to the geometry pipeline 2720. In some examples, if tessellation is not used, the tessellation components (e.g., the hull shader 2711, the tessellation 2713, and the domain shader 2717) can be bypassed.

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

[0299] Before rasterization, the clipper 2729 processes the vertex data. The clipper 2729 can be a fixed function clipper, or can be a programmable clipper with clipping and geometry shader functions. In some examples, the rasterizer and depth test component 2773 in the render output pipeline 2770 dispatches a pixel shader to convert the geometric object into a representation of each pixel. In some examples, the pixel shader logic is included in the thread execution logic 2750. In some examples, the application can bypass the rasterizer and depth test component 2773 and access the unrasterized vertex data via the stream output unit 2723.

[0300] The graphics processor 2700 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, execution units 2752A-2752B and associated logic units (e.g., L1 cache 2751, sampler 2754, texture cache 2758, etc.) are interconnected via data port 2756 to perform memory access and communicate with the rendering output pipeline components of the processor. In some examples, sampler 2754, cache 2751, 2758, and execution units 2752A-2752B each have a separate memory access path. In some examples, texture cache 2758 may also be configured as a sampler cache.

[0301] In some examples, the rendering output pipeline 2770 includes a rasterizer and a depth test component 2773, which converts vertex-based objects into associated pixel-based representations. In some examples, the rasterizer logic includes a windower / masker unit to perform fixed-function triangle and linear rasterization. In some examples, associated rendering buffers 2778 and depth buffers 2779 are also available. Pixel operation components 2777 perform pixel-based operations on data, but in some cases, pixel operations associated with 2D operations (e.g., bit block image transfer with blending) are performed by the 2D engine 2741, or replaced by a display controller 2743 using an overlay display plane when displayed. In some examples, a shared L3 cache 2775 is available for all graphics components, thereby allowing data to be shared without using main system memory.

[0302] In some examples, the graphics processor media pipeline 2730 includes a media engine 2737 and a video front end 2734. In some examples, the video front end 2734 receives pipeline commands from the command stream processor 2703. In some examples, the media pipeline 2730 includes a separate command stream processor. In some examples, the video front end 2734 processes the media commands before sending the commands to the media engine 2737. In some examples, the media engine 2737 includes a thread spawning function to spawn a thread for dispatching to the thread execution logic 2750 via the thread dispatcher 2731.

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

[0304] In some examples, the geometry pipeline 2720 and the media pipeline 2730 may be configured to perform operations based on multiple graphics and media programming interfaces, rather than specifically for any one application programming interface (API). In some examples, driver software for a graphics processor translates API calls specific to a particular graphics or media library into commands that can be processed by the graphics processor. In some examples, support is provided for the Open Graphics Library (OpenGL), the Open Computing Language (OpenCL), and / or the Vulkan graphics and computing APIs, all of which are 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 it is possible to map from the pipeline of a future API to the pipeline of a graphics processor, future APIs with compatible 3D pipelines will also be supported.

[0305] Graphics pipeline programming

[0306] Fig.28A ' is a block diagram illustrating a graphics processor command format 2800 according to some examples. Fig.28B The block diagram of 2810 illustrates a graphics processor command sequence 2810 according to one example. Fig.28A The solid-line boxes in the figure 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.28A An exemplary graphics processor command format 2800 includes a data field for identifying a client 2802, a command operation code (opcode) 2804, and command data 2806. In some commands, a sub-opcode 2805 and a command size 2808 are also included.

[0307] In some examples, client 2802 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 determine the conditions for 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 2804 and, if present, a subopcode 2805 to determine the operation to be performed. The client unit executes the command using the information in data field 2806. For some commands, it is expected that there is a clear command size 2808 to specify the size of the command. In some examples, the command parser automatically determines the size of at least some commands based on the command opcode. In some examples, commands are aligned via multiples of double words. Other command formats can be used.

[0308] Fig.28B The flowchart in 28 illustrates an exemplary graphics processor command sequence 2810. In some examples, software or firmware of a data processing system featuring an example of a graphics processor uses a version of the command sequence shown to set up, 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 this command sequence. In addition, commands can be issued as batch commands in a command sequence so that the graphics processor will process the sequence of commands at least partially concurrently.

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

[0310] In some examples, when a command sequence requires the graphics processor to explicitly switch between pipelines, pipeline select command 2813 is used. In some examples, unless the context is to issue commands for both pipelines, pipeline select command 2813 is only required once within the execution context before issuing pipeline commands. In some examples, pipeline flush command 2812 is required immediately before a pipeline switch is made via pipeline select command 2813.

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

[0312] In some examples, return buffer state commands 2816 are used to configure a set of return buffers for each pipeline to write data. Some pipeline operations require allocating, selecting, or configuring one or more return buffers into which these operations write intermediate data during processing. In some examples, the graphics processor also uses one or more return buffers to store output data and perform cross-thread communication. In some examples, return buffer state 2816 includes selecting the size and number of return buffers for a set of pipeline operations.

[0313] The remaining commands in the command sequence differ based on the active pipeline of the operation.Based on the pipeline determination 2820 , the command sequence is tailored for either the 3D pipeline 2822 starting from the 3D pipeline state 2830 or the media pipeline 2824 starting from the media pipeline state 2840 .

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

[0315] In some examples, the 3D primitive 2832 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 2832 command are forwarded to the vertex acquisition function in the graphics pipeline. The vertex acquisition function uses the 3D primitive 2832 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 2832 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 2822 dispatches the shader execution thread to the graphics processor execution unit.

[0316] In some examples, the 3D pipeline 2822 is triggered via an execute 2834 command or event. In some examples, a register write triggers the command execution. In some examples, the execution is triggered via a "go" or "kick" command in a command sequence. In some examples, the 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 on the 3D primitives. Once the operation is completed, the resulting geometric objects are rasterized and the pixel engine colors the resulting pixels. For these operations, additional commands that control pixel shading and pixel backend operations may also be included.

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

[0318] In some examples, the media pipeline 2824 is configured in a manner similar to the 3D pipeline 2822. A set of commands to configure the media pipeline state 2840 are dispatched or placed into a command queue before the media object commands 2842. In some examples, the commands for the media pipeline state 2840 include data used to configure the media pipeline elements that will be used to process the media objects. This includes data used to configure the video decoding and video encoding logic within the media pipeline, such as the encoding or decoding format. In some examples, the commands for the media pipeline state 2840 also support the use of one or more pointers to "indirect" state elements, which contain a batch of state settings.

[0319] In some examples, media object command 2842 provides a pointer to a media object for processing by the media pipeline. The media object includes a memory buffer containing video data to be processed. In some examples, all media pipeline states must be valid before issuing media object command 2842. Once the pipeline state is configured and media object command 2842 is queued, media pipeline 2824 is triggered via execute command 2844 or an equivalent execution event (e.g., a register write). The output from media pipeline 2824 can then be post-processed by operations provided by 3D pipeline 2822 or media pipeline 2824. In some examples, GPGPU operations are configured and executed similarly to media operations.

[0320] Program code can be applied to input information to perform the functions described herein and generate output information. Output information can be applied to one or more output devices in a known manner. For the present application, a 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.

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

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

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

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

[0325] Emulation (including binary translation, code deformation, etc.).

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

[0327] Fig.29The block diagram of illustrates the use of a software instruction converter according to an example, which is used to convert binary instructions in a source ISA into binary instructions in a target ISA. 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.29 It is shown that a program in a high-level language 2902 can be compiled using a first ISA compiler 2904 to generate first ISA binary code 2906 that can be natively executed by a processor having at least one first ISA core 2916. The processor having at least one first ISA core 2916 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 2904 represents a compiler operable to generate first ISA binary code 2906 (e.g., object code) that can be executed on a processor 2916 having at least one first ISA core with or without additional linking processing. Similarly, Fig.29 It is shown that a program in a high-level language 2902 can be compiled using an alternative ISA compiler 2908 to generate an alternative ISA binary code 2910, which can be executed natively by a processor 2914 without a first ISA core. An instruction converter 2912 is used to convert the first ISA binary code 2906 into code that can be executed natively by a processor 2914 without a first ISA core. This converted code will not necessarily be the same as the alternative ISA binary code 2910; however, the converted code will implement the overall operation and be composed of instructions from the alternative ISA. Thus, the instruction converter 2912 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 2906 through simulation, emulation, or any other process.

[0328] IP Core Implementation

[0329] One or more aspects of at least some examples may be implemented by representative code stored on a machine-readable medium, which represents and / or defines logic within an integrated circuit such as a processor. For example, a machine-readable medium may include instructions representing various logics within a processor. When read by a machine, the instructions may cause the machine to make logic to perform the techniques described herein. This form of expression, known as an "IP core," is a reusable unit of logic for an integrated circuit that may be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model may be provided to various customers or manufacturing facilities, which load the hardware model on a manufacturing machine that manufactures the integrated circuit. An integrated circuit may be made so that the circuit performs the operations described in association with any of the examples described herein.

[0330] Fig.30 The block diagram of illustrates an IP core development system 3000 according to some examples, which can be used to manufacture integrated circuits to perform operations. The IP core development system 3000 can be used to generate modular, reusable designs that can be included in larger designs or used to construct entire integrated circuits (e.g., SOC integrated circuits). The design facility 3030 can generate a software simulation 3010 of the IP core design in a high-level programming language (e.g., C / C++). The software simulation 3010 can be used to design, test, and verify the behavior of the IP core using a simulation model 3012. The simulation model 3012 can include functional, behavioral, and / or timing simulations. A register transfer level (RTL) design 3015 can then be created or synthesized from the simulation model 3012. The RTL design 3015 is an abstraction of the behavior of an integrated circuit that models the flow of digital signals between hardware registers, including associated logic that is executed using the modeled digital signals. In addition to the RTL design 3015, 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 may vary.

[0331] The RTL design 3015 or equivalent may also be synthesized by the design facility into a hardware model 3020, which may take the form of 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 for delivery to a third-party fabrication facility 3065 using a non-volatile memory 3040 (e.g., a hard disk, flash memory, or any other non-volatile storage medium). Alternatively, the IP core design may be transmitted via a wired connection 3050 or a wireless connection 3060 (e.g., via the Internet). The fabrication facility 3065 may then fabricate an integrated circuit based at least in part on the IP core design. The fabricated integrated circuit may be configured to perform operations according to at least some of the examples described herein.

[0332] Examples include, but are not limited to:

[0333] 1. A device comprising:

[0334] decoder circuitry to decode an instance of a single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and addressing information are used by the decoder circuitry to determine support for a particular vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands; and

[0335] Execution circuitry is configured to execute the decoded instance of the single instruction according to the opcode to perform one or more operations on one or more operands having the determined vector length.

[0336] 2. An apparatus as described in Example 1, wherein when bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the vector length of the instance of the single instruction is determined by bits 21-22 of the prefix.

[0337] 3. The apparatus of Example 1, wherein, when bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 512-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0338] 4. The apparatus of Example 1, wherein, when bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 256-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0339] 5. The apparatus of Example 1, wherein, when bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 128-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0340] 6. The apparatus of any one of Examples 1-5, wherein two bits of the prefix specify an embedded rounding mode.

[0341] 7. The apparatus of Example 6, wherein the specified embedded rounding mode is one of: round to zero, round to nearest even, round down, or round up.

[0342] 8. A system comprising:

[0343] a memory for storing at least a single instance of an instruction; and

[0344] A processor core, the processor core comprising:

[0345] decoder circuitry for decoding an instance of the single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and addressing information are used by the decoder circuitry to determine support for a particular vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands, and

[0346] Execution circuitry is configured to execute the decoded instance of the single instruction according to the opcode to perform one or more operations on one or more operands having the determined vector length.

[0347] 9. A system as described in Example 8, wherein when bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the vector length of the instance of the single instruction is determined by bits 21-22 of the prefix.

[0348] 10. The system of Example 8, wherein when bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 512-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0349] 11. The system of Example 8, wherein, when bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 256-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0350] 12. The system of Example 8, wherein when bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 128-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0351] 13. The system of any of Examples 8-12, wherein two bits of the prefix specify an embedded rounding mode.

[0352] 14. The system of example 13, wherein the specified embedded rounding mode is one of: round to zero, round to nearest even, round down, or round up.

[0353] 15. A method comprising:

[0354] decoding an instance of a single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and addressing information are used by decoder circuitry to determine support for a particular vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands; and

[0355] The decoded instance of the single instruction is executed according to the opcode to perform one or more operations on one or more operands having the determined vector length.

[0356] 16. A method as described in Example 15, wherein when bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the vector length of the instance of the single instruction is determined by bits 21-22 of the prefix.

[0357] 17. A method as described in Example 15, wherein when bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 512-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0358] 18. A method as described in Example 15, wherein when bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 256-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0359] 19. A method as described in Example 15, wherein, when bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 128-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

[0360] 20. The method of any of Examples 15-19, wherein two bits of the prefix specify an embedded rounding mode.

[0361] References to "some examples," "an example," and the like indicate that the examples being described may include a particular feature, structure, or characteristic, but that not every example may include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same example. In addition, when a particular feature, structure, or characteristic is described in conjunction with one example, it should be considered that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other examples (whether or not explicitly described).

[0362] In addition, in the various examples described above, unless otherwise specifically noted, selection language such as phrases "at least one of A, B, or C" or "A, B and / or C" should be understood to refer to A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B and C).

[0363] 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 present disclosure as set forth in the claims.

Claims

1. A device comprising: decoder circuitry to decode an instance of a single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and addressing information are used by the decoder circuitry to determine support for a particular vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands; and Execution circuitry is configured to execute the decoded instance of the single instruction according to the opcode to perform one or more operations on one or more operands having the determined vector length.

2. The device according to claim 1, wherein: When bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the vector length of the instance of the single instruction is determined by bits 21-22 of the prefix.

3. The device according to claim 1, wherein: When bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 512-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

4. The device according to claim 1, wherein: When bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 256-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

5. The device according to claim 1, wherein: When bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 128-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

6. The device according to any one of claims 1 to 5, wherein: The two bits of the prefix specify the embedded rounding mode.

7. The device according to claim 6, wherein: The specified embedded rounding mode is one of: round to zero, round to nearest even, round down, or round up.

8. A system comprising: a memory for storing at least a single instance of an instruction; as well as A processor core, the processor core comprising: decoder circuitry for decoding an instance of the single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and addressing information are used by the decoder circuitry to determine support for a particular vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands, and Execution circuitry is configured to execute the decoded instance of the single instruction according to the opcode to perform one or more operations on one or more operands having the determined vector length.

9. The system of claim 8, wherein: When bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the vector length of the instance of the single instruction is determined by bits 21-22 of the prefix.

10. The system of claim 8, wherein: When bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 512-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

11. The system of claim 8, wherein: When bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 256-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

12. The system of claim 8, wherein: When bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 128-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

13. The system of any one of claims 8 to 12, wherein: The two bits of the prefix specify the embedded rounding mode.

14. The system of claim 13, wherein: The specified embedded rounding mode is one of: round to zero, round to nearest even, round down, or round up.

15. A method comprising: decoding an instance of a single instruction, the instance of the single instruction comprising at least fields for a prefix, an opcode, and addressing information, wherein the prefix and addressing information are used by decoder circuitry to determine support for a particular vector length for one or more operands of the instance of the single instruction, and the opcode indicates one or more operations to be performed on the one or more operands; and The decoded instance of the single instruction is executed according to the opcode to perform one or more operations on one or more operands having the determined vector length.

16. The method of claim 15, wherein: When bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the vector length of the instance of the single instruction is determined by bits 21-22 of the prefix.

17. The method of claim 15, wherein: When bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 1, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 512-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

18. The method of claim 15, wherein: When bit position 20 of the prefix is ​​set to 1, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 256-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

19. The method of claim 15, wherein: When bit position 20 of the prefix is ​​set to 0, bit position 10 of the prefix is ​​set to 0, and bit positions 7:6 of the addressing information are set to 11, the instance of the single instruction has a 128-bit vector length, and bits 21-22 of the prefix specify rounding for the instance of the single instruction.

20. The method according to any one of claims 15 to 19, wherein: The two bits of the prefix specify the embedded rounding mode.

Images