Direct unconditional jump

Abstract

The invention discloses a direct unconditional jump. Techniques for performing unconditional jumps are described. In some examples, instructions are processed to perform unconditional jumps. In some examples, an instruction includes at least one or more fields for an opcode and a 64-bit immediate, where the 64-bit immediate is used to encode an absolute address, and the opcode is used to indicate execution circuitry to jump to the absolute address.

Description

Background Art

[0001] Branch instructions can cause the processor to start executing a different sequence of instructions by changing the processor's instruction pointer. In some processors, displacement limits are imposed on all direct branches. This allows software to fall back to indirect branches that jump "anywhere". This is common in code generated / used by dynamic linkers for program linkage tables and just-in-time (JIT) compilation. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0003] Figure 1 Illustrate an example of hardware for processing direct absolute jump instructions.

[0004] Figure 2 An example of the instruction format is shown.

[0005] Figure 3 Figure 1 shows an example of an addressing information field.

[0006] Figure 4 Examples of prefixes are shown in the figure.

[0007] Figure 5(A)-Figure 5(D) An example illustrating how to use the R, X, and B fields of REX2.

[0008] Figure 6 Figure 1 shows an example of the JMPABS instruction.

[0009] Figure 7 An example method executed by a processor to process a JMPABS instruction is illustrated.

[0010] Figure 8 An example of pseudo code for executing a JMPABS instruction is shown.

[0011] Fig. 9 An example of pseudo code for executing a CALLABS instruction is shown.

[0012] Fig.10 An example computing system is illustrated.

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

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

[0015] Fig.13A Figure 1 shows an example of a parallel processor.

[0016] Fig. 13B An example of a block diagram of a partition unit is illustrated.

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

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

[0019] Figure 14A-Figure 14C Additional graphics multiprocessors are illustrated according to examples.

[0020] Fig.15 A parallel computing system 1500 is shown according to some examples.

[0021] Figure 16A-16B Illustrate a hybrid logical / physical view of a split parallel processor according to examples described herein.

[0022] 17(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.

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

[0024] Fig.18 Examples of execution unit circuit(s) are illustrated, such as execution unit circuit(s).

[0025] Fig.19 is a block diagram of a register architecture according to some examples.

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

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

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

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

[0030] Fig.24Ais a block diagram illustrating a graphics processor command format according to some examples.

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

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

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

[0035] The present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for supporting direct absolute jump instructions.

[0036] However, indirect branches have some disadvantages, such as suboptimal prediction performance, no support for meaningful branch address calculation (BAC) at the decode stage, etc. Without BAC support, mispredicted indirect branches have jump execution clears (JEClears), which are much more expensive and amplify the cost of misspeculation. This can be further amplified when encountering cold code or large footprint workloads.

[0037] Indirect branches may also have suboptimal security behavior. Indirect branches can be hijacked by an attacker who has control over the target. Additionally, the predicted behavior of indirect branches may reveal details about the microarchitectural / architectural state.

[0038] The problems described above are old, exist across many different architectures, and are typically addressed by investing in larger (and more power hungry) predictor structures to enhance the power and capabilities of indirect branch predictors.

[0039] Detailed herein is an example of a direct absolute jump instruction (JMPABS / CALLABS instruction), which is an absolute ("ABS") branch (jump) instruction with a full 64-bit target. This allows a "far" target to be encoded directly and provides software with a more powerful branch instruction. In some examples, the instruction has BAC clear (BAClear) correctability (which is correctable in the front end of the CPU on cold misses without having to wait for a full branch misprediction in the execution window of the CPU (which is much more costly)).

[0040] For the end user, this equates to higher performing code with fewer branch mispredictions. The instruction also reduces the number of indirect branches, which reduces the attack surface of the program. Users do not have to recompile to benefit from this new instruction, as one of the main uses of the instruction is to replace indirect instructions for the Program Linkage Table (PLT) of a dynamic link library. Therefore, running on a system with hardware that supports the instruction and an updated dynamic linker / loader automatically benefits.

[0041] The JMPABS / CALLABS instructions allow software to overwrite the entire virtual address space without relying on indirect branches. The use of 64-bit absolute targets (as opposed to RIP-relative) simplifies the hardware logic because it makes unnecessary the use of 64-bit adders that could introduce timing problems in high-frequency CPUs.

[0042] In some examples, the JMPABS / CALLABS instruction is only 64 bits. The 64-bit immediate operand is treated as an absolute effective address, which may be subject to a standardization check. In some examples, if address bits 63 to the most effective implementation bit are set to all 0 or all 1 by the microarchitecture, the 64-bit address is considered to be in standard form. In some examples, the JMPABS / CALLABS instruction is a direct unconditional jump, and will be treated as such from the perspective of performance monitoring and the Last Branch Record (LBR) facility. In some examples, the JMPABS / CALLABS instruction defaults to issuing a processor trace TIP packet (this is different from other direct unconditional jumps).

[0043] In some examples, in the case of BAC, JMPABS / CALLABS instructions are correctable. As described above, traditional indirect branches are not BAC correctable because the target of the indirect branch is contained in a register / memory location and must be calculated / read. Therefore, the indirect branch has to wait for execution time in the jump execution unit (JEU) to be corrected, which is much more costly (in terms of performance, power, and the amount of wrong path execution in its shadow).

[0044] Thus, JMPABS / CALLABS provide an alternative to using indirect branches that have a known target but could not previously be encoded in direct form; such an alternative is a very common pattern in programming languages, including PLTs, V-tables, JITs, etc.

[0045] An example of code that does not use JMPABS in the PLT is as follows: <.text>; call lib_foo call lib_bar <.plt>; … lib_foo@plt; jmpq *got.plt+0x24 (%rip) … lib_bar@plt; jmpq *got.plt+0x32(%rip)

[0046] 0x24 and 0x32 can be turned into direct addresses, and JMPABS can be used: <.text>; call lib_foo call lib_bar <.plt>; … lib_foo@plt; jmpabs 0x12345678ABCDE0 … lib_bar@plt; jmpabs 0xDE345678CAFEF0

[0047] Figure 1 An example of hardware for processing a direct absolute jump instruction is shown. Execution of a direct absolute jump instruction causes the instruction pointer (stored in an instruction pointer register 138, such as a 64-bit register, such as the RIP register) to be written with the address value of the immediate value of the direct absolute jump instruction.

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

[0049] The branch prediction unit 114 may be used to predict branches.

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

[0051] Instruction decoding circuitry 105 includes or is coupled to branch address calculation circuitry 112. In some examples, when BAC 112 ensures that both relative and direct branches have correct branch predictions after calculating and comparing an absolute address from the instruction itself, a BACLEAR is issued if this is not the case.

[0052] The instruction cache (icache) 102 is a backing store for instruction bytes. An instruction fetch is a lookup into the instruction cache 102 to the instruction translation lookaside buffer (iTLB).

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

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

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

[0056] In some examples, decoder circuit 101 includes a microsequencer (microcode ROM 108 or other medium that stores microcode for certain macroinstructions). In some examples, microsequencer read-only memory (ROM) 108 decodes some instructions into a multi-micro-operation (uop) stream.

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

[0058] The instruction or micro-operation may be selected by the selector 110 .

[0059] Decode circuitry 101 is coupled to one or more register renaming / allocator / retirement / scheduler circuitry 111. The register renaming circuitry moves micro-ops from a micro-op queue to be bound to a dispatch port in a scheduler with execution resources. In some examples, zero-idiom, one-idiom, and zero-latency register move operations are performed by the renamer.

[0060] The distributor reads a queue (e.g., a micro-op queue) and generates ordered stream splices across cluster boundaries in the same cycle when necessary.

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

[0062] The retirement circuitry tracks when instructions are ready to retire from both logical processors. The retirement circuitry retires instructions in program order for each logical processor.

[0063] Execution circuit 113 includes branch circuit 115 for executing a branch (jump) to set the instruction pointer in instruction pointer register 138, such as a direct unconditional jump of a JMPABS instruction. In some examples, branch circuit 115 includes conditional logic 129, which is used to determine whether the branch is allowed based on one or more conditions in condition code (flag) register 133. Note that conditional logic 129 is not used for JMPABS instruction. In some examples, if the branch is incorrectly predicted and subsequently taken, the jump execution unit asserts control signal JEClear when the oldest mispredicted branch is detected to flush the ordered instruction pipeline. Other circuits 117 can be used to execute other instructions.

[0064] The register file and / or memory 140 is coupled to one or more execution circuits and / or register renaming / allocator / retirement / scheduler circuits 111. The register file includes a plurality of registers.

[0065] Instructions (including direct absolute jump instructions) utilize an instruction format. Figure 2 An example of an instruction format is shown. 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., a register identifier, memory addressing information, etc.), a displacement value 207, and / or an immediate value 209. Note that some instructions utilize some or all of the fields in the format, while other instructions may only use the field for the opcode 203. In some examples, the order shown 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 a different order, combined, etc.

[0066] (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 the operation object (e.g., 0x66) and address size (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes may 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.

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

[0068] The addressing information field 205 is used to address one or more operands of the instruction, such as locations in memory or one or more registers. Figure 3246.

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

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

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

[0072] SIB byte 304 includes a scale field 252, an index field 254, and a base address field 256 for address generation. Scale field 252 indicates a scale factor. Index field 254 specifies the index register to be used. In some examples, index field 254 is complemented with additional bits from a prefix (e.g., prefix 201) to allow for larger addressing. Base address field 256 specifies the base address register to be used. In some examples, base address field 256 is complemented with additional bits from a prefix (e.g., prefix 201) to allow for larger addressing. In practice, the contents of scale field 252 allow the contents of index field 254 to be scaled for memory address generation (e.g., for use with (2 缩放 *index+base address) is generated).

[0073] Some addressing forms use displacement values ​​to generate memory addresses. For example, (2缩放 The memory address may be generated by (*index+base+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. Additionally, 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.

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

[0075] Figure 4 An example of a prefix used by a direct absolute jump instruction is shown. In some examples, prefix 401 supports addressing 32 general registers. In some examples, the prefix is ​​called REX2.

[0076] In some examples, one or more of the instructions for increment, decrement, negation, addition, subtraction, AND, OR, XOR, arithmetic left shift, logical left shift, arithmetic right shift, logical right shift, left rotation, right rotation, multiplication, division, population count, leading zero count, total zero count, etc. support flag suppression.

[0077] In some examples, one or more of instructions for increment, decrement, NOT, negation, addition, addition with carry, subtraction with borrow, subtraction, AND, OR, XOR, arithmetic left shift, logical left shift, arithmetic right shift, logical right shift, left rotation, right rotation, multiplication, division, population count, leading zero count, total zero count, unsigned integer addition of two operands with carry flag, unsigned integer addition of two operands with overflow flag, conditional move, pop, push, etc. support REX2.

[0078] As shown, REX2 has a format field 403 in the first byte and 8 bits in the second byte (e.g., payload byte). In some examples, the value of the format field 403 is 0xD5. In some examples, 0xD5 encodes an ASCIII Adjust AX Before Division (AAD) instruction in 32-bit mode. In those examples, 0xD5 is used as Figure 4 The first byte of the prefix.

[0079] The payload byte consists of a number of bits.

[0080] Bit position 0 (B3) may modify the base address in the R / M field 546 of the MOD R / M or the base address field 556 of the SIB byte; or it may modify the opcode register field used to access a general register (eg, general register 1925).

[0081] Bit position 1 (X3) may modify the SIB byte index field 554 .

[0082] Bit position 2 (R3) may be an extension of the MOD R / M reg field 544 and may be used to modify the MOD R / M reg field 544 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 502 specifies another register or defines an extended opcode, R is ignored.

[0083] Bit position 3 (W) can be used to determine the operand size, but not the operand width alone. Thus, 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.

[0084] Bit position 4 (B4) may further (along with B3) modify the base address in the R / M field 546 of MOD R / M or the base address field 556 of the SIB byte; or it may modify the opcode register field used to access a general register (e.g., general register 1925).

[0085] Bit position 5 (X4) may further (along with X3) modify the SIB byte index field 554.

[0086] Bit position 6 (R4) may further be used (along with R3) as an extension of the MOD R / M's reg field 544 and may be used to modify the MOD R / M's reg field 544 when that field encodes a general purpose register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register.

[0087] In some examples, bit position 7 (M0) indicates an opcode mapping (eg, 0 or 1).

[0088] R3, R4, X3, X4, B3, and B4 allow addressing of 32 GPRs. That is, if and only if an R, X, or B register identifier encodes a GPR register, the R, X, or B register identifier is extended by the R3, X3, and B3 bits in the REX2 prefix, as well as the R4, X4, and B4 bits. In some examples, vector registers (or any other type of register) are not encoded using those bits.

[0089] In some examples, REX2 must be the last prefix, and the byte following REX2 is interpreted as the main opcode byte indicated by M0 in the opcode map. The 0x0F escape byte is neither required nor allowed. In some examples, the prefix that can be before the REX2 prefix is ​​LOCK (0xF0), REPE / REP / REPZ (0xF3), REPNE / REPNZ (0xF2), operation object size supercontrol (0x66), address size supercontrol (0x67), and segment supercontrol.

[0090] In general, when any byte in REX2 R4, X4, B4, R3, X3, and B3 is not used, they are ignored. For example, when there is no index register, both X4 and X3 are ignored. Similarly, when the R, X, or B register identifier encodes a vector register, the R4, X4, or B4 bits are ignored. However, in some examples, there are one or two exceptions to this general rule: 1) attempting to access a non-existent control register or debug register will trigger #UD; and 2) instructions with opcodes 0x50-0x5F (including pop and push) use R4 to encode the push-pop acceleration hint.

[0091] Figure 5(A)-Figure 5(D) An example of how the R, X, and B fields of REX2 are used is shown. In some examples, the MOD R / M byte 502 and SIB byte 504 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that both fields are optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 502 includes a MOD field 542, a register (reg) field 544, and an R / M field 546. An opcode 503 is also shown.

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

[0093] In some examples, register field 544 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 544 specify the location (in a register or in a memory) of the source or destination operand directly or through address generation. In some examples, register field 544 is supplemented with additional bits from a prefix to allow for greater addressing.

[0094] In some examples, R / M field 546 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 546 may be combined with MOD field 542 to specify an addressing mode.

[0095] In some examples, SIB byte 504 includes a scaling field 552, an index field 554, and a base address field 556 for address generation. Scaling field 552 indicates a scaling factor. Index field 554 specifies the index register to be used. In some examples, index field 554 is complemented with additional bits from the prefix to allow for greater addressing. Base address field 556 specifies the base address register to be used. In some examples, base address field 556 is complemented with additional bits from the prefix to allow for greater addressing. In practice, the contents of scaling field 552 allow the contents of index field 554 to be scaled for memory address generation (e.g., for use with (2 缩放 *index+base address) is generated).

[0096] Some addressing forms use displacement values ​​to generate memory addresses. For example, (2 缩放 The memory address may be generated by (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 provides the value.

[0097] 5(A) illustrates that when the SIB byte 504 is not used for memory addressing, R3 and R4, and B3 and B4 from the REX2 prefix 401 are used to extend the reg field 544 and the R / M field 546 of the MOD R / M byte 502, respectively.

[0098] 5(B) illustrates that when SIB byte 504 is not used, R3 and R4, and B3 and B4 from REX2 prefix 401 are used to extend reg field 544 and R / M field 546, respectively, of MOD R / M byte 502 (for register-register addressing).

[0099] 5(C) illustrates that R3 and R4, X3 and X4, and B3 and B4 from the REX2 prefix 401 are used to extend the reg field 544, index field 554, and base field 556 of the MOD R / M byte 502 when the SIB byte 504 is not used for memory addressing.

[0100] FIG. 5(D) illustrates that B3 and B4 from the REX2 prefix 401 are used to extend the reg field 544 of the MOD R / M byte 502 when the register is encoded in the opcode.

[0101] An example of a format for a move-to-zero instruction is JMPABSIMM64. In some examples, JMPABS is the opcode mnemonic for the opcode of the instruction encoded at least in field 203. IMM64 is the immediate value encoded in the immediate field, such as immediate 209. In some examples, the instruction utilizes prefix 201. Figure 6 Figure 1 shows an example of the JMPABS instruction.

[0102] Figure 7 An example method executed by a processor to process a JMPABS or CALLABS instruction is shown. For example, a processor core as shown in FIG. 17(B), a pipeline as described in detail below, Figure 1 The method is performed by hardware etc.

[0103] At 701, an instance of a single instruction is obtained. For example, a JMPABS or CALLABS instruction is obtained. The instruction includes fields for an opcode and a 64-bit immediate value. In some examples, the instruction is obtained from an instruction cache. The opcode indicates that the branch or jump execution circuit is to jump to an address encoded by a 64-bit immediate value. In some examples, jumping means storing the address in an instruction pointer register. In some examples, the address must be standardized, otherwise execution will result in errors such as general protection errors. In some examples, the instruction includes one or more prefix fields. In some examples, the prefix is ​​a REX2 prefix. In some examples, for the CALLABS instruction, the opcode also indicates that the execution circuit is to place the instruction pointer on a stack or a shadow stack.

[0104] The fetched instruction is decoded at 703. For example, the fetched JMPABS or CALLABS instruction is decoded by a decoder circuit, such as decoder circuit 101 or decode circuit 1740 described in detail herein.

[0105] At 705, the decoded instructions are scheduled.

[0106] At 707, the decoded instruction is executed according to the opcode by execution circuitry (hardware), such as Figure 1 , the execution circuit 113 shown in FIG. 17(B) , the (one or more) execution clusters 1760 shown in FIG. 17(B) , and the like.

[0107] In some examples, at 709 , the instructions are committed or retired.

[0108] Figure 8 An example of pseudo code for executing a JMPABS instruction is shown.

[0109] Fig. 9 An example of pseudo code for executing a CALLABS instruction is shown.

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

[0111] The example computer architecture is described in detail below. Other system designs and configurations for laptop computers, 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 a word, various systems or electronic devices that can include processors and / or other execution logic disclosed herein are generally appropriate. Example System

[0112] Fig.10 An example computing system is illustrated. Multiprocessor system 1000 is an interfaced system and includes a plurality of processors or cores, including a first processor 1070 and a second processor 1080 coupled via an interface 1050 (e.g., a point-to-point (PP) interconnect, a fabric, and / or a bus). In some examples, first processor 1070 and second processor 1080 are isomorphic. In some examples, first processor 1070 and second processor 1080 are heterogeneous. Although example system 1000 is shown as having two processors, the system may have three or more processors, or may be a single processor system. In some embodiments, the computing system is a system on a chip (SoC).

[0113] Processors 1070 and 1080 are shown as including integrated memory controller (IMC) circuits 1072 and 1082, respectively. Processor 1070 also includes interface circuits 1076 and 1078; similarly, second processor 1080 includes interface circuits 1086 and 1088. Processors 1070, 1080 may exchange information via interface 1050 using interface circuits 1078, 1088. IMCs 1072 and 1082 couple processors 1070, 1080 to respective memories, namely memory 1032 and memory 1034, which may be part of the main memory locally attached to the respective processors.

[0114] Processors 1070, 1080 can each utilize interface circuits 1076, 1094, 1086, 1098 to exchange information with a network interface (NW I / F) 1090 via respective interfaces 1052, 1054. Network interface 1090 (e.g., one or more of an interconnect, bus, and / or structure, a chipset in some examples) can optionally exchange information with a coprocessor 1038 via interface circuit 1092. In some examples, coprocessor 1038 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.

[0115] A shared cache (not shown) may be included in either processor 1070, 1080, or may be external to both 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.

[0116] The network interface 1090 can be coupled to the first interface 1016 via the interface circuit 1096. In some examples, the first interface 1016 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 1016 is coupled to a power control unit (PCU) 1017, which can include circuits, software, and / or firmware to perform power management operations with respect to the processors 1070, 1080, and / or the coprocessor 1038. The PCU 1017 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 1017 also provides control information to control the generated operating voltage. In various examples, the PCU 1017 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).

[0117] PCU 1017 is illustrated as existing as logic separate from processor 1070 and / or processor 1080. In other cases, PCU 1017 may execute on a given one or more cores of a core (not shown) of processor 1070 or 1080. In some cases, PCU 1017 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 1017 may be implemented outside 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 1017 may be implemented within BIOS or other system software.

[0118] Various I / O devices 1014 and a bus bridge 1018 can be coupled to the first interface 1016, and the bus bridge 1018 couples the first interface 1016 to the second interface 1020. In some examples, (one or more) additional processors 1015 are coupled to the first interface 1016, such as a coprocessor, a high-throughput many integrated core (MIC) processor, a GPGPU, an accelerator (such as a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some examples, the second interface 1020 can be a low pin count (LPC) interface. Various devices can be coupled to the second interface 1020, including, for example, a keyboard and / or mouse 1022, a communication device 1027, and a storage circuit 1028. Storage circuit 1028 may 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 / code and data 1030 and may implement storage device `ISAB03. Additionally, audio I / O 1024 may be coupled to second interface 1020. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 1000 may implement a multi-drop interface or other such architecture instead of a point-to-point architecture.

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

[0120] 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 (SoCs), which may include the described CPU (sometimes referred to as application core(s) or application processor(s), the coprocessors described above, and additional functionality on the same die. An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0121] Fig.11 A block diagram of an example processor and / or SoC 1100 is illustrated, which may have one or more cores and have an integrated memory controller. The processor 1100 illustrated in solid line blocks has a single core 1102(A), a system agent unit circuit 1110, and a set of one or more interface controller unit circuits 1116, while the optionally added dashed line blocks illustrate an alternative processor 1100 as having multiple cores 1102(A)-(N), a set of one or more integrated memory control unit circuits 1114 in the system agent unit circuit 1110, dedicated logic 1108, and a set of one or more interface controller unit circuits 1116. Note that the processor 1100 may be Fig.10 One of the processors 1070 or 1080 or the coprocessors 1038 or 1015.

[0122] Thus, different implementations of processor 1100 may include: 1) a CPU, where dedicated logic 1108 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1102(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 1102(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 1102(A)-(N) are a large number of general purpose in-order cores. Thus, processor 1100 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, etc. The processor may be implemented on one or more chips. Processor 1100 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).

[0123] The memory hierarchy includes one or more levels of cache unit circuits 1104(A)-(N) within the cores 1102(A)-(N), a set of one or more shared cache unit circuits 1106, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 1114. The set of one or more shared cache unit circuits 1106 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other level caches, such as last level cache (LLC), and / or combinations thereof. While in some examples an interface network circuit 1112 (e.g., a ring interconnect) provides an interface to dedicated logic 1108 (e.g., integrated graphics logic), the set of shared cache unit circuits 1106, and the system agent unit circuit 1110, 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 1106 and the cores 1102(A)-(N). In some examples, interface controller unit circuitry 1116 couples the cores 1102 to one or more other devices 1118 , such as one or more I / O devices, storage, one or more communication devices (e.g., wireless network, wired network, etc.), and the like.

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

[0125] The cores 1102(A)-(N) may be homogeneous with respect to instruction set architecture (ISA). Alternatively, the cores 1102(A)-(N) may be heterogeneous with respect to ISA; that is, a subset of the cores 1102(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.

[0126] Fig.121 is a block diagram illustrating a computing system 1200 configured to implement one or more aspects of the examples described herein. The computing system 1200 includes a processing subsystem 1201 having one or more processors 1202 and a system memory 1204 communicating via an interconnect path, which may include a memory hub 1205. The memory hub 1205 may be a separate component within a chipset component, or may be integrated within one or more processors 1202. The memory hub 1205 is coupled to an I / O subsystem 1211 via a communication link 1206. The I / O subsystem 1211 includes an I / O hub 1207, which may enable the computing system 1200 to receive input from one or more input devices 1208. In addition, the I / O hub 1207 may enable a display controller (which may be included in one or more processors 1202) to provide output to one or more display devices 1210A. In some examples, one or more display devices 1210A coupled to I / O hub 1207 may include local, internal, or embedded display devices.

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

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

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

[0130] One or more parallel processors 112 may include circuits optimized for graphics and video processing (including, for example, video output circuits) and constitute a graphics processing unit (GPU). Alternatively or additionally, as described in more detail herein, one or more parallel processors 112 may include circuits optimized for general-purpose processing while retaining the underlying computing architecture. Components of computing system 100 may be integrated on a single integrated circuit with one or more other system elements. For example, one or more parallel processors 112, memory hub 105, (one or more) processors 102, and I / O hub 107 may be integrated into a system-on-chip (SoC) integrated circuit. Alternatively, components of computing system 100 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 computing system 100 may be integrated into a multi-chip module (MCM), which may be interconnected with other multi-chip modules into a modular computing system.

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

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

[0133] Fig.13AAn example of a parallel processor 1300 is shown. The parallel processor 1300 may be a GPU, a GPGPU, etc. as described herein. The various components of the parallel processor 1300 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 1300 may be Fig.12 One or more of the parallel processor(s) 1212 shown in FIG.

[0134] Parallel processor 1300 includes parallel processing unit 1302. Parallel processing unit includes I / O unit 1304 that enables communication with other devices, including other instances of parallel processing unit 1302. I / O unit 1304 can be directly connected to other devices. For example, I / O unit 1304 is connected to other devices via the use of a hub or switch interface (such as memory hub 1205). The connection between memory hub 1205 and I / O unit 1304 forms communication link 1213. Within parallel processing unit 1302, I / O unit 1304 is connected to host interface 1306 and memory cross switch 1316, wherein host interface 1306 receives commands related to performing processing operations and memory cross switch 1316 receives commands related to performing memory operations.

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

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

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

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

[0139] In examples where parallel processing units 1302 are used to perform graphics processing, scheduler 1310 may be configured to divide the processing workload into tasks of approximately equal size to better enable distribution of graphics processing operations to multiple clusters 1314A-1314N in processing cluster array 1312. In some of these examples, portions of processing cluster array 1312 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 1314A-1314N may be stored in a buffer to allow the intermediate data to be transferred between clusters 1314A-1314N for further processing.

[0140] During operation, the processing cluster array 1312 may receive processing tasks to be executed via the scheduler 1310, which receives commands defining the processing tasks from the front end 1308. For graphics processing operations, the processing tasks may include data to be processed, such as surface (patch) data, primitive data, vertex data, and / or pixel data, and state parameters and commands that define how the data is to be processed (e.g., what program is to be executed). The scheduler 1310 may be configured to retrieve an index corresponding to the task, or may receive the index from the front end 1308. The front end 1308 may be configured to ensure that the processing cluster array 1312 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.

[0141] Each of the one or more instances of parallel processing unit 1302 may be coupled to parallel processor memory 1322. Parallel processor memory 1322 may be accessed via memory crossbar switch 1316, which may receive memory requests from processing cluster array 1312 and I / O unit 1304. Memory crossbar switch 1316 may access parallel processor memory 1322 via memory interface 1318. Memory interface 1318 may include a plurality of partition units (e.g., partition unit 1320A, partition unit 1320B, up to partition unit 1320N), each of which may be coupled to a portion (e.g., memory unit) of parallel processor memory 1322. The number of partition units 1320A-1320N may be configured to be equal to the number of memory units, such that a first partition unit 1320A has a corresponding first memory unit 1324A, a second partition unit 1320B has a corresponding second memory unit 1324B, and an Nth partition unit 1320N has a corresponding Nth memory unit 1324N. In other examples, the number of partition units 1320A-1320N may not be equal to the number of memory devices.

[0142] The memory units 1324A-1324N 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 1324A-1324N 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 1324A-1324N may vary and may be selected from one of a variety of conventional designs. Render targets such as frame buffers or texture maps may be stored across the memory units 1324A-1324N, allowing the partition units 1320A-1320N to write portions of each render target in parallel to efficiently use the available bandwidth of the parallel processor memory 1322. In some examples, local instances of parallel processor memory 1322 may be eliminated in favor of a unified memory design utilizing system memory in conjunction with local cache memory.

[0143] Optionally, any of the clusters 1314A-1314N in the processing cluster array 1312 has the capability to process data to be written to any of the memory units 1324A-1324N within the parallel processor memory 1322. The memory crossbar 1316 may be configured to transfer the output of each cluster 1314A-1314N to any partition unit 1320A-1320N or to another cluster 1314A-1314N, which may perform additional processing operations on the output. Each cluster 1314A-1314N may communicate with a memory interface 1318 through the memory crossbar 1316 to read from or write to various external memory devices. In one example with a memory crossbar 1316, the memory crossbar 1316 has connections to a memory interface 1318 to communicate with the I / O unit 1304 and has connections to a local instance of parallel processor memory 1322, thereby enabling processing units within different processing clusters 1314A-1314N to communicate with system memory or other memory that is not local to the parallel processing unit 1302. In general, the memory crossbar 1316 may be able to separate traffic flows between the clusters 1314A-1314N and the partition units 1320A-1320N using virtual channels, for example.

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

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

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

[0147] In graphics applications, ROP 1326 is a processing unit that performs raster operations such as stenciling, z-testing, blending, etc. ROP 1326 then outputs processed graphics data, which is stored in graphics memory. In some examples, ROP 1326 includes or is coupled to a codec (CODEC) 1327 that includes compression logic for compressing depth or color data written to memory or L2 cache 1321 and decompressing depth or color data read from memory or L2 cache 1321. The compression logic may be lossless compression logic that utilizes one or more of a variety of compression algorithms. The type of compression performed by CODEC 1327 may vary based on the statistical characteristics of the data to be compressed. For example, in some examples, delta color compression is performed on depth and color data on a slice-by-slice basis. In some examples, CODEC 1327 includes compression and decompression logic that can compress and decompress computational data associated with machine learning operations. CODEC 1327 can, for example, compress sparse matrix data for sparse machine learning operations. CODEC 1327 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.

[0148] ROP 1326 may be included in each processing cluster (e.g., Fig.13A 1314A-1314N) rather than being included in partition unit 1320. In such examples, read and write requests for pixel data rather than pixel fragment data are transmitted through memory crossbar switch 1316. The processed graphics data may be displayed on a display device such as a Fig.12 1210B), is routed for further processing by the processor(s) 1202, or is routed for processing by the processor(s) 1202. Fig.13A One of the processing entities within the parallel processor 1300 further processes.

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

[0150] The operation of the processing cluster 1314 may be controlled via a pipeline manager 1332 that distributes processing tasks to SIMT parallel processors. The pipeline manager 1332 receives Fig.13A The graphics multiprocessor 1334 may be used to process the graphics multiprocessor 1334 and / or the texture unit 1336. The graphics multiprocessor 1334 is an exemplary embodiment of a SIMT parallel processor. However, various types of SIMT parallel processors of different architectures may be included in the processing cluster 1314. One or more instances of the graphics multiprocessor 1334 may be included in the processing cluster 1314. The graphics multiprocessor 1334 may process data, and the data crossbar 1340 may be used to distribute the processed data to one of a plurality of possible destinations, including other shader units. The pipeline manager 1332 may facilitate the distribution of processed data by specifying a destination for the processed data to be distributed via the data crossbar 1340.

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

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

[0153] The graphics multiprocessor 1334 may include internal cache memory to perform load and store operations. Optionally, the graphics multiprocessor 1334 may abandon the internal cache and use cache memory (e.g., first level (level 1, L1) cache 1348) within the processing cluster 1314. Each graphics multiprocessor 1334 also has a partition unit (e.g., Fig.13A 1320A-1320N), which are shared between all processing clusters 1314 and can be used to transfer data between threads. Graphics multiprocessor 1334 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 1302 can be used as global memory. In embodiments where processing cluster 1314 includes multiple instances of graphics multiprocessor 1334, common instructions and data can be shared, which can be stored in L1 cache 1348.

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

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

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

[0157] Fig.13D An example of a graphics multiprocessor 1334 is shown, where the graphics multiprocessor 1334 is coupled to a pipeline manager 1332 of a processing cluster 1314. The graphics multiprocessor 1334 has an execution pipeline that includes, but is not limited to, an instruction cache 1352, an instruction unit 1354, an address mapping unit 1356, a register file 1358, one or more general purpose graphics processing unit (GPGPU) cores 1362, and one or more load / store units 1366. The GPGPU cores 1362 and the load / store units 1366 are coupled to a cache memory 1372 and a shared memory 1370 via a memory and cache interconnect 1368. The graphics multiprocessor 1334 may additionally include a tensor and / or ray tracing core 1363 that includes hardware logic for accelerating matrix and / or ray tracing operations.

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

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

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

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

[0162] The memory and cache interconnect 1368 is an interconnect network that connects each of the functional units of the graphics multiprocessor 1334 to the register file 1358 and to the shared memory 1370. For example, the memory and cache interconnect 1368 is a crossbar interconnect that allows the load / store unit 1366 to implement load and store operations between the shared memory 1370 and the register file 1358. The register file 1358 can operate at the same frequency as the GPGPU core 1362, so data transfers between the GPGPU core 1362 and the register file 1358 are very low latency. The shared memory 1370 can be used to enable communication between threads executing on the functional units within the graphics multiprocessor 1334. The cache memory 1372 can be used as a data cache, for example, to cache texture data passed between the functional unit and the texture unit 1336. The shared memory 1370 can also be used as a managed cached program. The shared memory 1370 and the cache memory 1372 can be coupled with the data crossbar 1340 to enable communication with other components of the processing cluster. Threads executing on GPGPU core 1362 can programmatically store data in shared memory in addition to automatically cached data stored in cache memory 1372.

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

[0164] Fig.14A The graphics multiprocessor 1425 includes relative Fig.13DThe graphics multiprocessor 1425 may include multiple additional instances of execution resource units of the graphics multiprocessor 1334. For example, the graphics multiprocessor 1425 may include multiple instances of instruction units 1432A-1432B, register files 1434A-1434B, and (one or more) texture units 1444A-1444B. The graphics multiprocessor 1425 also includes multiple sets of graphics or compute execution units (e.g., GPGPU cores 1436A-1436B, tensor cores 1437A-1437B, ray tracing cores 1438A-1438B) and multiple sets of load / store units 1440A-1440B. The execution resource units have a common instruction cache 1430, texture and / or data cache memory 1442, and shared memory 1446.

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

[0166] Fig. 14B The graphics multiprocessor 1450 includes a plurality of execution resource sets 1456A-1456D, wherein Fig.13D and Fig.14A As shown in FIG. 1 , each set of execution resources includes multiple instruction units, register files, GPGPU cores, and load storage units. Execution resources 1456A-1456D can work in conjunction with (one or more) texture units 1460A-1460D for texture operations while sharing instruction cache 1454 and shared memory 1453. For example, execution resources 1456A-1456D can share multiple instances of instruction cache 1454 and shared memory 1453 and texture and / or data cache memory 1458A-1458B. Each component can be connected to the CPU via the CPU. Fig.14A The interconnect structure 1427 communicates with a similar interconnect structure 1452 .

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

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

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

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

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

[0172] Input / output (I / O) circuitry 1463 couples GPU 1480 to one or more I / O devices 1462, 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 1462 to GPU 1480 and memory 1466. One or more I / O memory management units (IOMMUs) 1464 of I / O circuitry 1463 directly couple I / O devices 1462 to system memory 1466. Optionally, IOMMU 1464 manages a plurality of page table sets for mapping virtual addresses to physical addresses in system memory 1466. I / O devices 1462, CPU(s) 1461, and GPU(s) 1480 may then share the same virtual address space.

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

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

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

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

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

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

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

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

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

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

[0183] In the example described below, a hybrid rasterization / ray tracing approach is used in which the work is distributed between graphics core 1470 and ray tracing core 1472 .

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

[0185] In general, each core 1472, 1471, 1470 may support a ray tracing instruction set including instructions / functions for one or more of the following: ray generation, nearest hit, any hit, ray-primitive intersection, per-primitive and hierarchy bounding box construction, misses, visits, and exceptions. More specifically, some examples include ray tracing instructions for performing one or more of the following functions: Light Generation - Ray generation instructions can be executed for each pixel, sample, or other user-defined work assignment. Recent Hits - A nearest hit command may be executed to locate the closest intersection of a ray with a primitive within the scene. Any hit - Any hit command identifies multiple intersections between rays and primitives within the scene, potentially identifying a new closest intersection point. intersect ——The intersection instruction performs a ray-primitive intersection test and outputs the result. Per-primitive bounding box construction - This instruction builds a bounding box around a given primitive or group of primitives (e.g., when building a new BVH or other acceleration data structure). miss - Indicates that the ray missed the scene or all geometry within a specified region of the scene. visit ——Indicates the subvolume that the ray will traverse. abnormal - Includes various types of exception handlers (e.g., called for various error conditions).

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

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

[0188] 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 vary. On the other hand, in order to have a high-performance system, key components should be interconnected through high-speed, high-bandwidth, low-latency interfaces. These conflicting requirements pose challenges to high-performance chip development.

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

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

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

[0192] Figure 16A-16BIllustrate a hybrid logical / physical view of a split parallel processor according to examples described herein. Fig.16A A split parallel computing system 1600 is shown. Fig. 16B A chiplet 1630 of the split parallel computing system 1600 is shown.

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

[0194] The individual chiplets may be bonded to a base die 1610 and configured to communicate with each other and logic within the base die 1610 via an interconnect layer 1612. In some examples, the base die 1610 may include a global logic 1601, which may include a scheduler 1611 and power management 1621 logic unit, an interface 1602, a dispatch unit 1603, and an interconnect fabric module 1608 coupled or integrated with one or more L3 cache blocks 1609A-1609N. The interconnect fabric 1608 may be an inter-chiplet fabric integrated into the base die 1610. The fabric 1608 may be used by the logic chiplets to relay messages between the individual chiplets. Additionally, the L3 cache blocks 1609A-1609N in the base die and / or the L3 cache blocks within the memory chiplet 1606 may cache data read from and transferred to the DRAM chiplets within the memory chiplet 1606 and to the system memory of the host.

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

[0196] The individual chiplets of the parallel processor 1620 may be designed to perform a specific function that is integrated into a single die in existing designs. The collection of compute chiplets 1605 may include a cluster of compute units (e.g., execution units, streaming multiprocessors, etc.) that include programmable logic for executing compute or graphics shader instructions. The media chiplet 1604 may include hardware logic for accelerating media encoding and decoding operations. The memory chiplet 1606 may include volatile memory (e.g., DRAM) and one or more SRAM cache memory blocks (e.g., L3 blocks).

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

[0198] At least a portion of the components within the illustrated chiplet 1630 may also be included in a Fig.16A The base die 1610 may be within logic within the base die 1610. For example, logic within the base die that communicates with the fabric may include some version of the fabric interconnect node 1642. The base die logic that may be independently clock gated or power gated may include some version of the power control 1632 and / or clock control 1634 logic.

[0199] 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 (“Input / Output”, “I / O”) circuitry, power delivery circuitry, memory circuitry, etc.) monolithically integrated into a single integrated circuit (“Integrated Circuit”, “IC”) die or chip, the present disclosure is not limited in this respect. For example, in various examples of the present disclosure, a device or system may have one or more processors (e.g., one or more processor cores) and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, memory circuitry, etc.) arranged in a discrete collection of discrete dies, slices, and / or chiplets (e.g., one or more discrete processor core dies arranged adjacent to one or more other dies (such as memory dies, I / O dies, etc.)). In such discrete devices and systems, the individual dies, slices, and / or chiplets may be physically and / or electrically coupled together by a packaging structure including, for example, individual packaging substrates, interposers, active interposers, photonic interposers, interconnect bridges, and the like. A separate collection of discrete dies, slices, and / or chiplets may also be part of a System-on-Package (“SoP”).

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

[0201] The block diagram of FIG. 17(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. 17(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. 17(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.

[0202] In FIG. 17 (A), the processor pipeline 1700 includes a fetch stage 1702, an optional length decoding stage 1704, a decoding stage 1706, an optional allocation (Alloc) stage 1708, an optional renaming stage 1710, a scheduling (also called dispatch or issue) stage 1712, an optional register read / memory read stage 1714, an execution stage 1716, a write back / memory write stage 1718, an optional exception handling stage 1722, and an optional commit stage 1724. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1702, one or more instructions are fetched from the instruction memory, and during the decoding stage 1706, 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 1706 and register read / memory read stage 1714 can be combined into one pipeline stage. In some examples, during execute stage 1716, 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.

[0203] As an example, the example register renaming, out-of-order issue / execution architecture core of FIG. 17(B) may implement pipeline 1700 in the following manner: 1) instruction fetch circuit 1738 performs fetch and length decoding stages 1702 and 1704; 2) decoding circuit 1740 performs decoding stage 1706; 3) renaming / allocator unit circuit 1752 performs allocation stage 1708 and renaming stage 1710; 4) (one or more) scheduler circuit 1756 performs scheduling stage 1712; 5) (one or more) physical registers The register file circuit 1758 and the memory unit circuit 1770 perform the register read / memory read phase 1714; (one or more) execution clusters 1760 perform the execute phase 1716; 6) the memory unit circuit 1770 and (one or more) physical register file circuits 1758 perform the write back / memory write phase 1718; 7) various circuits may be involved in the exception handling phase 1722; and 8) the retirement unit circuit 1754 and (one or more) physical register file circuits 1758 perform the commit phase 1724.

[0204] 17(B) shows that the processor core 1790 includes a front end unit circuit 1730 coupled to an execution engine unit circuit 1750, and both are coupled to a memory unit circuit 1770. The core 1790 can 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 1790 can 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.

[0205] The front end unit circuit 1730 may include a branch prediction circuit 1732 coupled to an instruction cache circuit 1734 coupled to an instruction translation lookaside buffer (TLB) 1736 coupled to an instruction fetch circuit 1738 coupled to a decode circuit 1740. In some examples, the instruction cache circuit 1734 is included in the memory unit circuit 1770 instead of the front end circuit 1730. The decode circuit 1740 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, micro-instructions, 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 1740 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 1740 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 1790 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit 1740 or otherwise within the front end circuit 1730). In some examples, the decode circuit 1740 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 1700. The decode circuit 1740 may be coupled to the rename / allocator unit circuit 1752 in the execution engine circuit 1750.

[0206] The execution engine circuit 1750 includes a rename / allocator unit circuit 1752, which is coupled to a retirement unit circuit 1754 and a set of one or more scheduler circuits 1756. The scheduler circuit 1756 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuit(s) 1756 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) 1756 is coupled to the physical register file(s) circuit(s) 1758. Each of the physical register file(s) circuit(s) 1758 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., instruction pointers, i.e., the address of the next instruction to be executed), and the like. In some examples, the (one or more) physical register file circuits 1758 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 1758 are coupled to the retirement unit circuit 1754 (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 1754 and the (one or more) physical register file circuits 1758 are coupled to (one or more) execution clusters 1760. The (one or more) execution clusters 1760 include a set of one or more execution unit circuits 1762 and a set of one or more memory access circuits 1764. The execution unit circuit(s) 1762 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) 1756, physical register file circuit(s) 1758, and execution cluster(s) 1760 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, 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) 1764 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.

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

[0208] A set of memory access circuits 1764 are coupled to the memory cell circuit 1770, which includes a data TLB circuit 1772, which is coupled to a data cache circuit 1774, which is coupled to a level 2 (L2) cache circuit 1776. In some examples, the memory access circuit 1764 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 1772 in the memory cell circuit 1770. The instruction cache circuit 1734 is further coupled to the level 2 (L2) cache circuit 1776 in the memory cell circuit 1770. In some examples, the instruction cache 1734 and the data cache 1774 are combined into a single instruction and data cache in the L2 cache circuit 1776, a level 3 (L3) cache circuit (not shown), and / or a main memory (not shown). The L2 cache circuit 1776 is coupled to one or more other levels of cache and ultimately to the main memory.

[0209] Core 1790 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 1790 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data. Example execution unit circuit(s).

[0210] Fig.18 An example of (one or more) execution unit circuits is illustrated, such as (one or more) execution unit circuits 1762 of FIG. 17 (B). As shown, (one or more) execution unit circuits 1762 may include one or more ALU circuits 1801, optional vector / single instruction multiple data (single instruction multiple data, SIMD) circuits 1803, load / store circuits 1805, branch / jump circuits 1807, and / or floating-point unit (FPU) circuits 1809. ALU circuits 1801 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1803 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 1805 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store circuits 1805 may also generate addresses. Branch / jump circuits 1807 cause branches or jumps to a certain memory address depending on the instruction. FPU circuit 1809 performs floating point arithmetic. The width of execution unit circuit(s) 1762 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).

[0211] Example register architecture.

[0212] Fig.19 1 is a block diagram of a register architecture 1900 according to some examples. As shown, the register architecture 1900 includes a vector / SIMD register 1910, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 1910 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 1910 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.

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

[0214] The register architecture 1900 includes a plurality of general registers 1925. 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.

[0215] In some examples, register architecture 1900 includes a scalar floating-point (FP) register file 1945, which is used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set architecture extensions, or as 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.

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

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

[0218] Model specific registers or machine-specific registers (MSRs) 1935 control and report processor performance. Most MSRs 1935 handle system-related functions and are not accessible to applications. For example, MSR1 provides control for one or more of the following: performance monitoring counters, debug extensions, memory type range registers, thermal and power management, instruction specific support, and / or processor feature / mode support. Machine check registers 1960 consist of control, status, and error reporting MSRs for detecting and reporting hardware errors. (One or more) control registers 1955 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 1070, 1080, 1038, 1015, and / or 1100) and the characteristics of the task currently being executed. In some examples, the MSRs are a subset of control registers 1955.

[0219] One or more instruction pointer registers 1930 store instruction pointer values. Debug registers 1950 control and allow monitoring of debug operations of the processor or core.

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

[0221] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, less or different register files and registers. Register architecture 1900 may be used, for example, in register file / memory `ISAB08, or in physical register file circuit 1758.

[0222] Instruction set architecture.

[0223] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because there are fewer included fields) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, the example ADD instruction has a specific opcode and instruction format, the instruction format includes an opcode field to specify the opcode, and includes an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field 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.

[0224] 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. Graphics Execution Unit

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

[0226] As in Fig. 20A2008N-1 and 2008N) can be dynamically scaled by enabling or disabling one or more execution units (e.g., execution units 2008A, 2008B, 2808C, 2808D, up to any execution unit in 2008N-1 and 2008N) based on the computational requirements of the workload. In some examples, the included components are interconnected via an interconnect structure that links each of the components. In some examples, thread execution logic 2000 includes one or more connections to a memory (such as system memory or cache memory) through instruction cache 2006, data port 2014, sampler 2010, and one or more of execution units 2008A-2008N. In some examples, each execution unit (e.g., 2008A) is a self-contained programmable general-purpose computing unit capable of executing multiple simultaneous hardware threads while processing multiple data elements in parallel for each thread. In various examples, the array of execution units 2008A-2008N is scalable to include any number of separate execution units.

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

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

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

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

[0231] In some examples, one or more execution units may be combined into a fused execution unit 2009A-2009N, which has a common thread control logic (2007A-2007N) for the fused EU. Multiple EUs may be fused into an EU group. 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. Additionally, various SIMD widths may be executed EU by EU, including but not limited to SIMD8, SIMD16, and SIMD32. Each fused graphics execution unit 2009A-2009N includes at least two execution units. For example, the fused execution unit 2009A includes a first EU 2008A, a second EU 2008B, and a common thread control logic 2007A for the first EU 2008A and the second EU 2008B. Thread control logic 2007A controls threads executing on fused graphics execution unit 2009A, allowing each EU within fused execution units 2009A-2009N to execute using a common instruction pointer register.

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

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

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

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

[0236] Fig. 20B2026, and may include a set of dedicated integer SIMD ALUs 2035. The GRF 2024 and ARF 2026 include a set of general register files and architectural register files associated with each synchronous hardware thread that can be active in the graphics execution unit 2008. In some examples, the per-thread architectural state is maintained in the ARF 2026, while data used during thread execution is stored in the GRF 2024. The execution state of each thread (including the instruction pointer for each thread) can be saved in thread-specific registers in the ARF 2026.

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

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

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

[0240] In some examples, the graphics execution unit 2008 includes one or more SIMD floating point units (FPUs) 2034 for performing floating point operations. In some examples, (one or more) FPUs 2034 also support integer calculations. In some examples, (one or more) FPUs 2034 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 that support high throughput transcendental math functions and double-precision 64-bit floating points. In some examples, a set 2035 of 8-bit integer SIMD ALUs also exists and can be specifically optimized to perform operations associated with machine learning calculations.

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

[0242] Fig.21 An additional execution unit 2100 according to an example is illustrated. In some examples, the execution unit 2100 includes a thread control unit 2101, a thread state unit 2102, an instruction fetch / prefetch unit 2103, and an instruction decode unit 2104. The execution unit 2100 additionally includes a register file 2106, which stores registers that can be assigned to hardware threads within the execution unit. The execution unit 2100 additionally includes a dispatch unit 2107 and a branch unit 2108. In some examples, the dispatch unit 2107 and the branch unit 2108 can be configured to be executed in the same manner as the thread control unit 2101. Fig. 20B The sending unit 2030 and the branching unit 2032 of the graphics execution unit 2008 operate in a similar manner.

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

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

[0245] The execution unit 2100 additionally includes a register file 2106 that can be used by hardware threads executing on the execution unit 2100. The registers in the register file 2106 can be divided across logic used to execute multiple simultaneous threads within the compute unit 2110 of the execution unit 2100. The number of logical threads that can be executed by the graphics execution unit 2100 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread. The size of the register file 2106 can vary across examples based on the number of hardware threads supported. In some examples, register renaming can be used to dynamically assign registers to hardware threads.

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

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

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

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

[0250] In some examples, the 128-bit instruction format 2210 includes an access / addressing mode field 2226 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.

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

[0252] In some examples, the addressing mode portion of the access / addressing mode field 2226 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.

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

[0254] Graphics Pipeline

[0255] Fig.23 is a block diagram of another example of a graphics processor 2300 . Fig.23 Those elements having the same reference numerals (or names) as elements of any other figure herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0256] In some examples, graphics processor 2300 includes geometry pipeline 2320, media pipeline 2330, display engine 2340, thread execution logic 2350, and rendering output pipeline 2370. In some examples, graphics processor 2300 is a graphics processor within a multi-core processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writes to one or more control registers (not shown) or via commands issued to graphics processor 2300 through ring interconnect 2302. In some examples, ring interconnect 2302 couples graphics processor 2300 to other processing components, such as other graphics processors or general-purpose processors. Commands from ring interconnect 2303 are interpreted by command stream converter 2302, which supplies instructions to various components of geometry pipeline 2330 or media pipeline 2830.

[0257] In some examples, command stream converter 2303 directs the operation of vertex fetcher 2305, which reads vertex data from memory and executes vertex processing commands provided by command stream converter 2303. In some examples, vertex fetcher 2305 provides vertex data to vertex shader 2307, which performs coordinate space transformation and lighting operations on each vertex. In some examples, vertex fetcher 2305 and vertex shader 2307 execute vertex processing instructions by dispatching execution threads to execution units 2352A-2352B via thread dispatcher 2331.

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

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

[0260] In some examples, the complete geometric object may be processed by the geometry shader 2319 via one or more threads dispatched to the execution units 2352A-2352B, or may proceed directly to the clipper 2329. 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 2319 receives input from the vertex shader 2307. In some examples, the geometry shader 2319 is programmable by a geometry shader program to perform geometry tessellation when the tessellation unit is disabled.

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

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

[0263] In some examples, the render output pipeline 2370 includes a rasterizer and depth test component 2373, which converts vertex-based objects into associated pixel-based representations. In some examples, the rasterizer logic includes a window / masker unit for performing fixed-function triangle and line rasterization. In some examples, associated rendering buffers 2378 and depth buffers 2379 are also available. Pixel operation components 2377 perform pixel-based operations on data, but in some instances, pixel operations associated with 2D operations (e.g., using mixed bit block image transfers) are performed by the 2D engine 2341, or replaced by the display controller 2343 using an overlay display plane when displayed. In some examples, a shared L3 cache 2375 can be used for all graphics components, allowing data to be shared without using main system memory.

[0264] In some examples, the graphics processor media pipeline 2330 includes a media engine 2337 and a video front end 2334. In some examples, the video front end 2334 receives pipeline commands from the command stream converter 2303. In some examples, the media pipeline 2330 includes a separate command stream converter. In some examples, the video front end 2334 processes the media commands before sending them to the media engine 2337. In some examples, the media engine 2337 includes a thread generation function for generating threads for dispatching to the thread execution logic 2350 via the thread dispatcher 2331.

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

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

[0267] Graphics pipeline programming

[0268] Fig.24A is a block diagram illustrating a graphics processor command format 2400 according to some examples. Fig. 24B is a block diagram illustrating a graphics processor command sequence 2410 according to an example. Fig.24A The solid-line boxes in illustrate components that are typically 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.24A An exemplary graphics processor command format 2400 includes a data field for identifying a client 2402, a command operation code (opcode) 2404, and data for the command 2406. A subopcode 2405 and a command size 2408 are also included in some commands.

[0269] In some examples, client 2402 specifies a client unit of a graphics device that processes command data. In some examples, a graphics processor command parser checks the client field of each command to adjust further processing of the command and route 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 2404 and a sub-opcode 2405 (if present) to determine the operation to be performed. The client unit uses the information in data field 2406 to execute the command. For some commands, an expected explicit command size 2408 specifies the size of the command. In some examples, the command parser automatically determines the size of at least some of the commands in the command based on the command opcode. In some examples, the command is aligned via multiples of double words. Other command formats can be used.

[0270] Fig. 24B 2410. 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 establish, execute, and terminate a set of graphics operations. The sample command sequence is shown and described for example purposes only, as the examples are not limited to these particular commands or command sequences. Moreover, commands can be issued as batches of commands in a command sequence so that the graphics processor will process the command sequence in an at least partially concurrent manner.

[0271] In some examples, graphics processor command sequence 2410 may begin with pipeline flush command 2412 to cause any active graphics pipeline to complete the pipeline's currently pending commands. In some examples, 3D pipeline 2422 and media pipeline 2424 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 for the graphics processor will suspend command processing until the active drawing engine completes pending operations and the associated read cache is invalidated. Optionally, any data marked as "dirty" in the rendering cache may be flushed to memory. In some examples, pipeline flush command 2412 may be used for pipeline synchronization, or used before placing the graphics processor in a low power state.

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

[0273] In some examples, pipeline control commands 2414 configure the graphics pipeline for operation and are used to program 3D pipeline 2422 and media pipeline 2424. In some examples, pipeline control commands 2414 configure the pipeline state of the active pipeline. In some examples, pipeline control commands 2414 are used for pipeline synchronization and are used to clear data from one or more cache memories within the active pipeline before processing a batch of commands.

[0274] In some examples, return buffer state commands 2416 are used to configure a set of return buffers for the corresponding pipeline to write data. Some pipeline operations require the allocation, selection, or configuration of one or more return buffers into which the operation writes intermediate data during processing. In some examples, 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 2416 includes selecting the size and number of return buffers to be used for the set of pipeline operations.

[0275] The remaining commands in the command sequence differ based on the active pipeline for operation. Based on pipeline decision 2420 , the command sequence is tailored for either the 3D pipeline 2422 starting at 3D pipeline state 2430 , or the media pipeline 2424 starting at media pipeline state 2440 .

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

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

[0278] In some examples, the 3D pipeline 2424 is triggered via an execute 2432 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 the command sequence. In some examples, the command execution is triggered using a pipeline synchronization command so that the command sequence is flushed through the graphics pipeline. The 3D pipeline will perform geometry processing for 3D primitives. Once the operation is completed, the resulting geometric objects are rasterized and the pixel engine shades the resulting pixels. For those operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0279] In some examples, when performing media operations, the graphics processor command sequence 2410 follows the media pipeline 2424 path. In general, the specific purpose and manner of programming for the media pipeline 2424 depends on the media or computing operations to be performed. During media decoding operations, specific media decoding operations can be migrated to the media pipeline. 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, wherein the graphics processor is used to perform SIMD vector operations using compute shader programs that are not explicitly related to the rendering of graphics primitives.

[0280] In some examples, the media pipeline 2424 is configured in a similar manner to the 3D pipeline 2422. A set of commands for configuring the media pipeline state 2440 is dispatched or placed into a command queue, before the media object commands 2442. In some examples, the commands for the media pipeline state 2440 include data for configuring the media pipeline elements that will be used to process the media objects. This includes data for configuring the video decoding and video encoding logic within the media pipeline, such as encoding or decoding formats. In some examples, the commands for the media pipeline state 2440 also support the use of one or more pointers to "indirect" state elements that contain batches of state settings.

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

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

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

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

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

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

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

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

[0289] Fig.25 The 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.25 It is shown that a program in a high-level language 2502 can be compiled using a first ISA compiler 2504 to generate first ISA binary code 2506 that can be natively executed by a processor having at least one first ISA core 2516. The processor having at least one first ISA core 2516 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 2504 represents a compiler operable to generate first ISA binary code 2506 (e.g., object code) that can be executed on a processor 2516 having at least one first ISA core with or without additional linking processing. Similarly, Fig.25It is shown that a program in a high-level language 2502 can be compiled using an alternative ISA compiler 2508 to generate an alternative ISA binary code 2510, which can be executed natively by a processor 2514 without a first ISA core. An instruction converter 2512 is used to convert the first ISA binary code 2506 into code that can be executed natively by a processor 2514 without a first ISA core. This converted code will not necessarily be the same as the alternative ISA binary code 2510; however, the converted code will implement the overall operation and be composed of instructions from the alternative ISA. Thus, the instruction converter 2512 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 2506 through simulation, emulation, or any other process.

[0290] IP core implementation

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

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

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

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

[0295] Examples include, but are not limited to: 1. A device comprising: decoder circuitry for decoding an instance of a single instruction, the single instruction comprising at least one or more fields for an opcode and a 64-bit immediate value, wherein the 64-bit immediate value is used to encode an absolute address; and Execution circuitry for executing a decoded instance of the single instruction in accordance with the opcode to jump to an absolute address. 2. The apparatus of example 1, wherein, to jump to the absolute address, the execution circuit is operable to write the absolute address into an instruction pointer register. 3. The apparatus of example 2, wherein the instruction pointer register is RIP. 4. An apparatus as described in any of Examples 1-3, wherein the instruction further includes a REX2 prefix. 5. The apparatus of any of Examples 1-4, wherein the execution circuit is used to confirm that the absolute address is canonical. 6. The apparatus of example 5, wherein the execution circuit is to generate an error when the absolute address is not standardized. 7. An apparatus as described in any of Examples 1-6, wherein the decoder circuit and the execution circuit are used to support other instructions. 8. A method comprising: decoding an instance of a single instruction, the single instruction comprising at least one or more fields for an opcode and a 64-bit immediate value, wherein the 64-bit immediate value is used to encode an absolute address; and Executes a decoded instance of a single instruction according to the opcode to jump to an absolute address. 9. The method of Example 8, wherein jumping to the absolute address comprises performing a write of the absolute address into an instruction pointer register. 10. The method of Example 9, wherein the instruction pointer register is RIP. 11. The method of any of Examples 8-10, wherein the instruction further comprises a REX2 prefix. 12. The method as described in any of Examples 8-11 further includes: confirming that the absolute address is canonical. 13. The method of example 12, wherein an error is to be generated when the absolute address is not normalized. 14. A system comprising: a memory for storing at least a single instance of an instruction; decoder circuitry for decoding an instance of a single instruction, the single instruction comprising at least one or more fields for an opcode and a 64-bit immediate value, wherein the 64-bit immediate value is used to encode an absolute address; and Execution circuitry for executing a decoded instance of the single instruction in accordance with the opcode to jump to an absolute address. 15. The system of example 14, wherein, for jumping to the absolute address, the execution circuit is operable to write the absolute address into an instruction pointer register. 16. The system of example 15, wherein the instruction pointer register is RIP. 17. The system of any of Examples 14-16, wherein the instruction further comprises a REX2 prefix. 18. The system of any of Examples 14-16, wherein the execution circuit is to confirm that the absolute address is canonical. 19. The system of example 19, wherein an error is to be generated when the absolute address is not canonical. 20. The system of any of Examples 14-19, wherein the decoder circuitry and execution circuitry are used to support other instructions.

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

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

Claims

1. A device comprising: decoder circuitry for decoding an instance of a single instruction, the single instruction comprising at least one or more fields for an opcode and a 64-bit immediate value, wherein the 64-bit immediate value is used to encode an absolute address; and Execution circuitry is configured to execute a decoded instance of a single instruction in accordance with the opcode to jump to the absolute address.

2. The device according to claim 1, wherein: In order to jump to the absolute address, the execution circuit is configured to write the absolute address into an instruction pointer register.

3. The device as claimed in claim 2, wherein: The instruction pointer register is RIP.

4. The device according to any one of claims 1 to 3, wherein: The instruction further includes a REX2 prefix.

5. The device according to any one of claims 1 to 4, wherein: The execution circuit is used to confirm that the absolute address is standard.

6. The device according to claim 5, wherein: The execution circuit is configured to generate an error when the absolute address is not standardized.

7. The device according to any one of claims 1 to 6, wherein: The decoder circuit and the execution circuit are used to support other instructions.

8. A method comprising: decoding an instance of a single instruction, the single instruction comprising at least one or more fields for an opcode and a 64-bit immediate value, wherein the 64-bit immediate value is used to encode an absolute address; and A decoded instance of the single instruction is executed according to the opcode to jump to the absolute address.

9. The method of claim 8, wherein: Jumping to the absolute address includes performing a write of the absolute address into an instruction pointer register.

10. The method of claim 9, wherein: The instruction pointer register is RIP.

11. The method according to any one of claims 8 to 10, wherein: The instruction further includes a REX2 prefix.

12. The method of any one of claims 8 to 11, further comprising: Verify that the absolute address is canonical.

13. The method of claim 12, wherein: When the absolute address is not normalized, an error is generated.

14. A system comprising: a memory for storing at least a single instance of an instruction; a decoder circuit for decoding the instance of the single instruction, the single instruction comprising at least one or more fields for an opcode and a 64-bit immediate value, wherein the 64-bit immediate value is used to encode an absolute address; as well as Execution circuitry is configured to execute a decoded instance of the single instruction in accordance with the opcode to jump to the absolute address.

15. The system of claim 14, wherein: In order to jump to the absolute address, the execution circuit is configured to write the absolute address into an instruction pointer register.

16. The system of claim 15, wherein: The instruction pointer register is RIP.

17. The system of any one of claims 14 to 16, wherein: The instruction further includes a REX2 prefix.

18. The system of any one of claims 14 to 16, wherein: The execution circuit is used to confirm that the absolute address is standard.

19. The system of claim 19, wherein: When the absolute address is not normalized, an error is generated.

20. The system of any one of claims 14-19, wherein: The decoder circuit and the execution circuit are used to support other instructions.

Images