Circuits and methods for conditional fence instructions

Abstract

Circuits and methods for conditional fence instructions are described. In some examples, a hardware processor (e.g., a core) includes a branch predictor to predict one of an taken path and an untaken path of a conditional branch instruction; decoder circuitry to decode an instruction to a decoded instruction, the instruction including a field indicating a condition set by executing another instruction and an opcode indicating that the execution circuitry will implement an execution fence in response to the condition being satisfied to delay execution of the instruction prior to execution of a previous instruction in a program order, the opcode indicating that the execution circuitry will implement the execution fence in response to the condition being satisfied. And before the instruction is executed, delaying execution of an instruction following the instruction according to the program order; and the execution circuit is used for executing the decoded instruction according to the operation code.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computers, and more specifically, to circuitry and methods for conditional fence instructions. BACKGROUND

[0002] Processors or groups of processors execute instructions from an instruction set (e.g., an instruction set architecture (ISA)). An instruction set is the programming-related part of a computer architecture, typically including native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I / O). It should be noted that the term “instruction” herein can refer to either macroinstructions (e.g., instructions provided to a processor for execution) or microinstructions (e.g., instructions generated by a processor’s decoder from a macroinstruction). SUMMARY

[0003] An aspect of the present disclosure provides an apparatus comprising: a branch predictor to predict one of a taken path and an untaken path of a conditional branch instruction, the conditional branch instruction to precede in program order an instruction following the conditional branch instruction; a decoder circuit to decode the instruction into a decoded instruction, the instruction including a field to indicate a condition to be set by execution of another instruction and an opcode to indicate that an execution circuit is to implement an execution fence in response to the condition being satisfied to delay execution of the instruction before execution of a previous instruction in program order and to delay execution of an instruction following the instruction in program order before execution of the instruction; and the execution circuit to execute the decoded instruction according to the opcode.

[0004] An aspect of the present disclosure provides a method comprising: predicting, by a branch predictor, one of a taken path and an untaken path of a conditional branch instruction, the conditional branch instruction to precede in program order an instruction following the conditional branch instruction; decoding, by a decoder circuit, the instruction into a decoded instruction, the instruction including a field to indicate a condition to be set by execution of another instruction and an opcode to indicate that an execution circuit is to implement an execution fence in response to the condition being satisfied to delay execution of the instruction before execution of a previous instruction in program order and to delay execution of an instruction following the instruction in program order before execution of the instruction; and executing, by the execution circuit, the decoded instruction according to the opcode.

[0005] One aspect of this disclosure provides a non-transitory machine-readable medium storing code that, when executed by a machine, causes the machine to perform a method comprising: predicting, by a branch predictor, one of a taken path and an untaken path for a conditional branch instruction, the conditional branch instruction preceding an instruction immediately following the conditional branch instruction in program order; decoding the instruction into a decoded instruction by a decoder circuit, the instruction including a field and an opcode, the field indicating a condition to be set by executing another instruction, the opcode indicating that: an execution circuit will implement an execution fence in response to the condition being met, to delay the execution of the instruction before the execution of a previously executed instruction in program order, and to delay the execution of instructions following the instruction in program order before the execution of the previous instruction; and executing the decoded instruction by the execution circuit according to the opcode. Attached Figure Description

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

[0007] Figure 1 A block diagram of a computer system according to an example of this disclosure is shown, the computer system including a hardware processor with multiple cores, each core including a branch predictor.

[0008] Figure 2 A processor core pipeline according to an example of this disclosure is shown.

[0009] Figure 3 This is a summary of example conditional code based on the examples in this disclosure.

[0010] Figure 4 Examples of this disclosure are shown: (400A) unenforced insecure code, (400B) code enhanced with speculative load enhancement, and (400C) code enhanced with conditional fence instructions.

[0011] Figure 5 This is a simulation of the conditional fence instruction based on the example of this disclosure.

[0012] Figure 6 An example of computing hardware for processing (one or more) FENCEcc instructions is shown according to the present disclosure.

[0013] Figure 7 An example method for processing FENCEcc instructions, executed by a processor according to an example of this disclosure, is shown.

[0014] Figure 8 An example method for processing FENCEcc instructions using emulation or binary translation, according to examples of this disclosure, is shown.

[0015] Figure 9 An example computing system is shown.

[0016] Figure 10 A block diagram of an example processor and / or System-on-a-Chip (SoC) that may have one or more cores and an integrated memory controller is shown.

[0017] Figure 11 This is a block diagram illustrating a computing system 1100 configured to implement one or more aspects of the examples described herein.

[0018] Figure 12A An example of a parallel processor is shown.

[0019] Figure 12B An example block diagram of a partition unit is shown.

[0020] Figure 12C An example block diagram of a processing cluster within a parallel processing unit is shown.

[0021] Figure 12D An example of a graphics multiprocessor is shown, in which the graphics multiprocessor is coupled to a pipeline manager of a processing cluster.

[0022] Figures 13A-13C An additional graphics multiprocessor is shown based on the example.

[0023] Figure 14 Parallel computing system 1400 is shown according to some examples.

[0024] Figures 15A-15B A hybrid logical / physical view of a decomposed parallel processor, based on the example described herein, is shown.

[0025] Figure 16A This is a block diagram illustrating the example ordered pipeline and example register renaming, out-of-order release / execution pipeline based on the example.

[0026] Figure 16B This is a block diagram illustrating the example ordered architecture core and example register renaming, out-of-order release / execution architecture core that will be included in the example processor.

[0027] Figure 17 Examples of one or more execution unit circuits are shown, for example, one or more execution unit circuits.

[0028] Figure 18 It is a block diagram of a register architecture based on some examples.

[0029] Figure 19 An example of the instruction format is shown.

[0030] Figure 20 An example of an addressing information field is shown.

[0031] Figure 21 An example of the first prefix is ​​shown.

[0032] Figures 22A-22D Examples of how to use the R, X, and B fields with the first prefix are shown.

[0033] Figures 23A-23B An example of the second prefix is ​​shown.

[0034] Figure 24 An example of a third prefix is ​​shown.

[0035] Figures 25A-25B The following illustrates thread execution logic, including an array of processing elements employed in a graphics processor core, according to an example described herein.

[0036] Figure 26 An additional execution unit is shown based on the example.

[0037] Figure 27 This is a block diagram illustrating the graphics processor instruction format 2700 according to some examples.

[0038] Figure 28 This is a block diagram of another example of a graphics processor.

[0039] Figure 29A This is a block diagram illustrating the format of graphics processor commands according to some examples.

[0040] Figure 29B This is a block diagram illustrating a sequence of graphics processor commands based on an example.

[0041] Figure 30 This is a block diagram illustrating the use of a software instruction converter to convert binary instructions in a source ISA into binary instructions in a target ISA, according to an example.

[0042] Figure 31 This is a block diagram illustrating an IP core development system 3100 based on some examples, which can be used to manufacture integrated circuits to perform operations. Detailed Implementation

[0043] This disclosure relates to methods, apparatus, systems, and nontransitory computer-readable storage media for executing condition fence (FENCEcc) (e.g., one or more FENCEcc (e.g., macro) instructions (e.g., primitives)) via a hardware processor.

[0044] Side-channel methods are techniques that allow attackers to gain information by observing the processor (e.g., the processor of a computing system) (e.g., measuring microarchitectural properties about the processor). Some side-channel methods perform transient execution attacks. On some processors, speculative execution resulting from branch error speculation can leave observable side effects, leaking private data to attackers. For example, if the memory access patterns performed by such speculative execution depend on private data, the final state of the data cache constitutes a side channel that an attacker can use to extract information about the private data through attacks (e.g., timing attacks).

[0045] In some examples, side-channeling methods are a type of boundary-check bypass (e.g., called Spectre v1), which, for example, exploits speculative execution that may occur after a conditional branch instruction. Specifically, in some examples, such side-channeling methods are used when the processor is checking whether the input is within the boundary (e.g., when checking whether the index of an array element being read is within acceptable values). The processor may speculatively issue operations (e.g., fetch, decode, and / or execute operations) before the boundary check is resolved. If an attacker manages to access off-boundary memory for these operations, information may be leaked to the attacker in some cases. However, these side-channeling methods (e.g., Spectre v1) lack hardware mitigation. In some examples, these side-channeling methods (e.g., Spectre v1) utilize a trained conditional branch predictor that mispredicts leading to the execution of unintended code (e.g., "gadgets") that may speculatively read arbitrary memory locations, for example, by bypassing the conditional branch that performs the boundary check. In addition to pure software methods specific to particular code patterns (e.g., mask array indexing), some software typically uses two primitives to mitigate these side-channel (e.g., Spectre v1) methods: (1) load fencing (LFENCE) and (2) conditional movement based on conditional codes (CMOVcc). In some examples, LFENCE instructions (e.g., primitives) are inserted into potentially vulnerable code patterns to limit speculation, and as a mitigation of these side-channel (e.g., Spectre v1) methods, CMOVcc instructions are used by the software to convert control dependencies into data dependencies in comprehensive mitigation techniques (e.g., software load hardening).

[0046] In some examples, the mitigation of these side-channel (e.g., Spectre v1) methods is done in software, for example, by hardening the code to bypass boundary checks.

[0047] In some examples, a common software mitigation for side-channel (e.g., Spectre v1) methods is (e.g., Linux) a kernel implementation of a technique to mask array indices to zero out array indices outside array boundaries. However, boundary check bypass is merely a variation of these side-channel (e.g., Spectre v1) methods. Other types of side-channel (e.g., Spectre v1) methods exist, such as speculative type obfuscation, speculative race conditions, etc.

[0048] In some examples, mitigation techniques for avoiding certain side-channel exploits (e.g., Spectre v1) involve inserting LFENCE instructions at the failed targets of a branch. However, some examples of LFENCE as a Spectre v1 mitigation are computationally and time-intensive because they prevent all instructions sequentially following LFENCE from executing before all instructions sequentially preceding LFENCE have completed execution and retired, thus making it safe to execute instructions once the conditional branch is resolved / executed. Therefore, LFENCE can incur significant performance overhead, and may therefore be used for point mitigation rather than full mitigation (e.g., LFENCE can still incur significant performance overhead).

[0049] In some other examples, mitigation techniques used to avoid certain side-channel vulnerabilities (e.g., Spectre v1) are called speculative load hardening (SLH). In some examples, the ISA primitive that SLH leverages is called CMOVcc. In some examples, SLH traces the predicate state along each path of a conditional branch, using the CMOVcc ISA primitive to determine if a given code path is mispredicted, and if so, poisons the predicate state. In some examples, SLH then uses the predicate state to harden a load value or load address such that the load value (or load address) is poisoned when executed under the shadow of a mispredicted branch. In some examples, CMOVcc thus provides a way to create a data dependency between the load to be hardened and the branch condition of the conditional branch, such that the load cannot be executed (or its value cannot be consumed) until the branch condition is resolved. In some examples, because the CMOVccISA primitive can only create dependencies between two single instructions (e.g., as a fence, only fence a single instruction, affecting only a single instruction), SLH uses a complex way to accumulate predicate state (especially between function calls).

[0050] In some examples, a mitigation measure for the side-channel (e.g., Spectre v1) approach is to use a branch FENCE instruction (BFENCE) to instruct the processor (e.g., the central processing unit (CPU)) to resolve all previous branches before executing subsequent instructions.

[0051] In some examples, a mitigation for the side-channel (e.g., Spectre v1) approach is to use register FENCE instructions (RFENCE) to instruct the processor (e.g., CPU) to resolve all control and data speculation (essentially all previous instructions) before speculatively executing the next instruction following the RFENCE, which uses register operands with the RFENCE. However, none of these FENCE instructions are specifically designed for Spectre v1 or conditional branch predictors, and all of these FENECE instructions are computationally and time-intensive (e.g., Spectre v1) mitigations, resulting in significant performance overhead.

[0052] In some examples, the LFENCE instruction isolates all preceding instructions and affects all instructions following FENCE. In other examples, the RFENCE instruction isolates all preceding instructions but affects only a single instruction.

[0053] To overcome these issues, the examples in this paper involve the conditional FENCE instruction (FENCEcc), which adds expressive power to (e.g., x86) instruction set architectures (ISAs) for Spectre v1 mitigation, thus providing a new type of lightweight fence primitive specifically for conditional branch predictors. In some examples, the FENCEcc instruction behaves like LFENCE when the condition is met, and otherwise behaves like a no-op (NOP). In some examples, the FENCEcc instruction outperforms the LFENCE instruction, replaces LFENCE for Spectre v1 mitigation purposes, and may serve other use cases, such as more comprehensive software mitigation than CMOVcc-based mitigation. In some examples, the FENCEcc instruction isolates only a single conditional branch but affects all instructions following FENCE in procedural order, thus increasing the expressive power of speculative barriers, particularly for Spectre v1 mitigation measures. In some examples, the FENCEcc instruction is backward compatible with LFENCE on other hardware. In some examples, the FENCEcc instruction (e.g., a primitive) provides software with more control over conditional control flow speculation.

[0054] The FENCEcc instructions disclosed herein are improvements to the functionality of the processor (e.g., a computer's processor) itself because they achieve the aforementioned functions by electrically altering a general-purpose computer (e.g., its decoder circuitry and / or execution circuitry) by creating electrical paths within the computer (e.g., within its decoder circuitry and / or execution circuitry). These electrical paths create dedicated machines for performing specific FENCEcc functions.

[0055] The instructions disclosed herein are improvements to the functionality of the processor (e.g., a computer's processor) itself. Instruction decoder circuitry without such instructions as part of its instruction set would not decode as described herein. Execution circuitry without such instructions as part of its instruction set would not execute as described herein. For example, the FENCEcc instructions according to this disclosure are improvements to the functionality of the processor (e.g., a computer's processor) itself because they provide conditional execution fences for side-channel (e.g., Spectre v1) mitigation.

[0056] Now turn to the attached image. Figure 1 A block diagram of a computer system 101 according to an example of the present disclosure is shown. The computer system 101 includes a hardware processor 100 having multiple cores 111(1) to 111(N), each core including branch predictors 104(1) to 104(N). In one example, N is any integer greater than or equal to 1. In some examples, the processor core includes decoder circuitry for decoding instructions and execution circuitry for executing the decoded instructions, for example, decoder circuitry 111(1)-DEC and execution circuitry 111(1)-EXEC in core 111(1) to decoder circuitry 111(N)-DEC and execution circuitry 111(N)-EXEC in core 111(N).

[0057] Hardware processor 100 is depicted as coupled to system memory 102, for example, to form computing system 101. In the depicted example, the cores (e.g., each core) of hardware processor 100 include multiple logical cores (e.g., logical processing elements or logical processors). In some examples, each of the physical cores 111(1) to 111(N) supports multithreaded processing (e.g., executing two or more parallel operations or sets of threads on first and second logical cores), and can do so in a variety of ways, including time-sliced ​​multithreaded processing, simultaneous multithreaded processing (e.g., a single physical core providing a corresponding logical core for each thread (e.g., a hardware thread) that the physical core is simultaneously multithreaded processing), or combinations thereof (e.g., time-sliced ​​fencing and decoding followed by simultaneous multithreaded processing). In some examples, each logical core appears as a different processing unit to software (e.g., an operating system (OS)), for example, such that the software (e.g., the OS) can schedule two processes (e.g., two threads) for concurrent execution.

[0058] The depicted hardware processor 100 includes registers 106. Registers 106 may include one or more general-purpose (e.g., data) registers 108 to perform (e.g., logical or arithmetic) operations, such as additionally or alternatively accessing (e.g., loading or storing) data in memory 102. Registers 106 may include one or more model-specific registers, such as configuration and / or control registers. In some examples, each physical core has its own set of corresponding registers 106. In some examples, for example, each logical core (e.g., each of a plurality of logical cores of a single physical core) has its own set of corresponding registers 106. In some examples, each logical core has its own corresponding configuration and / or control registers. In one example, one or more (e.g., model-specific) registers (e.g., only) are written at the request of an OS running on the processor, for example, where the OS operates in privileged (e.g., system) mode and not in non-privileged (e.g., user) mode. In one example, model-specific registers can only be written by software running in supervised mode and not by software running in user mode.

[0059] Register 106 (e.g., model-specific register 110) may include a flag register 110. In one example, flag register 110 includes a field (e.g., single-bit wide) for each flag. Flags may include one, all, or any combination of the following: carry flag (CF) 110CF, zero flag (ZF) 110ZF, adjustment flag (AF) 110AF, parity flag (PF) 110PF, overflow flag (OF) 110OF, or sign flag (SF) 110SF. In one example, flag register 110 (e.g., only) includes six flags (e.g., CF, ZF, AF, PF, OF, and SF). In one example, each flag is a single bit; for example, some bits of the register are not used. In one example, CF is located at bit index 0 of flag register 110, ZF is located at bit index 6 of flag register 110, AF is located at bit index 4 of flag register 110, PF is located at bit index 2 of flag register 110, OF is located at bit index 11 of flag register 110, and / or SF is located at bit index 7 of flag register 110.

[0060] In some examples, the flag register 110 is a single logic register, such as EFLAGS (e.g., 32-bit wide) or RFLAGS (e.g., 64-bit wide). In some examples, if the result of an operation (e.g., an arithmetic operation, such as a micro-operation) has an arithmetic carry, the carry flag (CF) (e.g., a bit) is set (e.g., set to binary 1) (e.g., set by flag logic in the execution circuitry that updates the flag register), and if there is no arithmetic carry, the carry flag (CF) is cleared (e.g., set to binary 0). In some examples, if the result of an operation (e.g., an arithmetic operation, such as a micro-operation) is zero, the zero flag (ZF) is set (e.g., set to binary 1) (e.g., set by flag logic in the execution circuitry that updates the flag register), and if the result of the operation is not zero, the zero flag (ZF) is cleared (e.g., set to binary 0). In some examples, if an operation (e.g., an arithmetic operation, such as a micro-operation) results in an arithmetic carry or borrow (e.g., a carry or borrow in the four least significant bits), the adjustment flag (AF) (or auxiliary flag or auxiliary carry flag) is set (e.g., set to binary 1) (e.g., set by flag logic in the execution circuitry that updates the flag register), otherwise it is cleared (e.g., set to binary 0). In some examples, if the result of an operation (e.g., an arithmetic operation, such as a micro-operation) is even, the parity flag (PG) is set (e.g., set to binary 1) (e.g., set by flag logic in the execution circuitry that updates the flag register), and if the result of the operation is odd, the parity flag (PG) is cleared (e.g., set to binary 0). In some examples, if the result of an operation (e.g., an arithmetic operation, or a micro-operation) overflows, the overflow flag (OF) is set (e.g., set to binary 1) (e.g., by flag logic in the execution circuitry that updates the flag register). If the result of the operation does not overflow, the overflow flag (OF) is cleared (e.g., set to binary 0). For example, overflow can indicate that the result of an operation (e.g., signed two's complement) is not compatible with the number of bits used in the operation, such as the result of the operation being wider than the width of the execution circuitry (e.g., its arithmetic logic unit (ALU)). In some examples, if the result of an operation (e.g., an arithmetic operation, or a micro-operation) is negative, the sign flag (SF) is set (e.g., set to binary 1) (e.g., by flag logic in the execution circuitry that updates the flag register). If the result of the operation is positive, the sign flag (SF) is cleared (e.g., set to binary 0), for example, for results with signed (+ or -) values.

[0061] In one example, register 106 stores data indicating the current privilege level of the software operating on a logical core, for example, stored separately for each logical core. In another example, the current privilege level is stored in the Current Privilege Level (CPL) field 124 of the code segment selector register 122 of segment register(s) 120. In some examples, processor 100 requires a certain level of privilege to perform certain actions, such as actions requested by a specific logical core (e.g., actions requested by software running on that specific logical core).

[0062] System memory 102 may include (for example, store) one or more (for example, any combination thereof) of the following software: operating system (OS) code 130, first application code 132, second (or more) application code 134, virtual machine monitor code 136, or any combination thereof. First application code 132 or second application code 134 may be a corresponding user program.

[0063] Note that the accompanying drawings may not depict all data communication connections. Those skilled in the art will understand that this is to avoid obscuring certain details in the drawings. Note that bidirectional arrows in the figures may not require bidirectional communication; for example, they may indicate unidirectional communication (e.g., to or from the component or device). In some examples herein, any or all combinations of communication paths may be used. In one example, processor 100 has a single core. In some examples, computing system 101 and / or processor 100 include one or more features and / or components discussed below (e.g., referring to any of the accompanying drawings).

[0064] In some examples, for instance, each physical core includes its own branch predictor (e.g., branch predictor circuitry) such that each logical core of that single physical core shares the same branch predictor. In another example, each physical core in a plurality of physical cores shares a single branch predictor (e.g., branch predictor circuitry). In one example, a single physical core contains multiple logical cores, and the multiple logical cores share some (or all) (one or more) branch predictors and / or (one or more) branch predictions. In one example, a single physical core contains only a single logical core, and that single logical core itself has a dedicated branch predictor and / or branch prediction. In one example, a single physical core contains multiple logical cores, and some (or all) (one or more) branch predictors (and / or (one or more) predictions) are per logical core, rather than shared.

[0065] In some examples, a branch predictor (e.g., circuitry) is used to predict the next instruction to be fetched after a branch-type instruction (e.g., for an out-of-order execution processor) (e.g., predicting a pointer to that next instruction). The predicted next instruction may be referred to as the target instruction, and the prediction process may be referred to as branch-target prediction. Some branch instructions are referred to as indirect branch instructions. In one example, the branch target (e.g., IP) of an indirect branch instruction is stored in a branch predictor storage device (e.g., one or more branch registers). In one example, the branch predictor storage device (e.g., one or more registers) is located within a branch predictor (e.g., branch predictor circuitry). In one example, the branch predictor register is one of registers 106. Alternatively or concurrently, conditional branch prediction can be used to predict whether a conditional instruction (e.g., a conditional jump) will be taken, for example, taking the conditional instruction if the condition is true and not taking it if the condition is false.

[0066] In some examples, a branch instruction is called an indirect branch instruction when it can address more than two targets (e.g., any target specified in a register or in an indicated memory location). In one example, a branch instruction is a conditional branch instruction when the target can be the next sequential instruction (e.g., condition-dependent) or a specified target. Some processors (e.g., architectures) allow both direct and indirect conditional branches. Some processors (e.g., architectures) allow only direct conditional branches. In one example, a direct unconditional branch has only one target (e.g., as part of the code byte of an instruction). In one example, a direct conditional branch and / or a direct unconditional branch (e.g., IP) are stored in a branch predictor to know the next address before the branch address calculator (BAC) stage of the pipeline. In some examples, an indirect branch has a target address (e.g., IP) in one or more branch predictors, for example, while a direct branch also has a target address (e.g., IP) in one or more branch predictors.

[0067] As an example, branch predictors improve the functionality of pipelined processors. Processors (e.g., microprocessors) can use pipelined architecture to improve performance. In some examples of pipelined processors, functional units for different stages of instruction execution (e.g., fetch, decode, execute, deprecate, etc.) operate on multiple instructions simultaneously to achieve a degree of parallelism, thereby improving the performance of non-pipelined processors. In one example, an instruction fetch unit (e.g., circuitry), an instruction decoder (e.g., a decoder unit or decoder circuitry), and an instruction execution unit (e.g., execution circuitry) operate concurrently. In some examples, within a clock cycle, the instruction execution unit executes the first instruction, while the instruction decoder decodes the second instruction, and the fetch unit fetches the third instruction. In some examples, in the next clock cycle, the execution unit executes the newly decoded instruction, while the instruction decoder decodes the newly fetched instruction, and the fetch unit fetches another instruction. In this way, neither the fetch unit nor the decoder needs to wait for the instruction execution unit to execute the last instruction before processing a new instruction.

[0068] In some cases, instructions are executed in the order they appear in program order. However, some processors allow instructions to be executed in a different order than program order. For example, a computer program may include multiple branch instructions (e.g., CALL, JUMP, or RETURN) that, when executed, cause (e.g., target) instructions to be executed. More specifically, when a branch instruction is encountered in the program flow, execution either continues to the next instruction in sequence or jumps to the instruction designated as the branch target (e.g., the target instruction). Typically, if execution jumps to an instruction other than the next instruction in sequence, the branch instruction is considered "adopted," and if execution continues to the next instruction in sequence, the branch instruction is considered "unadopted." In one example, instructions may be executed in an order different from that specified in program order (e.g., "out of order").

[0069] In some examples, branch instructions are either unconditional (e.g., a branch is taken every time an instruction is executed) or conditional (e.g., a branch depends on a condition). For example, the instructions executed after a conditional branch are indeterminate until the condition on which the branch depends is resolved. Here, the processor can perform branch prediction to predict whether a branch will be taken, and if so, predict the target instruction (e.g., the target address) of the branch, rather than waiting for the condition to be resolved. In one example, if the branch is predicted to be taken, the processor fetches and speculatively executes one or more instructions(s) found at the predicted branch target address. In some examples where the processor has not yet determined whether the prediction is correct, the instructions executed after the branch prediction are speculative. In some examples, the processor resolves the branch instruction at the back end of the pipeline (e.g., in a retirement unit). In one example, if it is determined that the processor (e.g., the back end) will not take the branch instruction, all instructions (e.g., and their data) currently following the untaken branch instruction in the pipeline are flushed (e.g., discarded). In one example, if the prediction does not match the determined direction, flushing is performed.

[0070] FENCEcc support

[0071] In some examples, processor 100 (e.g., core 111) supports conditional FENCE instructions (FENCEcc), for example, with the following architectural properties: (i) if the condition of FENCEcc is met, FENCEcc will not complete execution until all previous instructions have completed locally (e.g., all previous instructions have retired, but these instructions (e.g., store instructions) are not necessarily observable in the computing system (e.g., globally)) (e.g., execution completion is delayed), and the execution of subsequent instructions is delayed such that no subsequent instructions in program order begin execution before FENCEcc completes; and (ii) if the condition of FENCEcc is not met, FENCEcc and younger instructions may be executed before the previous instructions in program order have completed locally (e.g., FENCEcc is executed as a non-operation (NOP)). In both cases, in some examples, no instructions in program order following FENCEcc cannot be executed until the condition on which FENCEcc depends is resolved. In some examples, the condition (e.g., statically encoded in the instruction) is determined by... Figure 3One of the condition codes in the code indicates this. In some examples, (e.g., dynamically determined based on one or more flags) the condition depends on the immediately preceding instruction (in program order), such that the condition is resolved (e.g., before FENCEcc is executed) once the immediately preceding instruction (in program order) is executed (e.g., and terminated). In some examples, FENCEcc conditionally performs a serialization operation on all instructions loaded from memory that precede the FENCEcc instruction. In some examples, FENCEcc (e.g., when the condition is met) does not execute until all preceding instructions have completed locally, and no subsequent instructions begin execution before FENCEcc completes. In some examples, instructions loaded from memory and preceding FENCEcc (e.g., when the condition is met) receive data from memory before FENCEcc completes. In some examples, FENCEcc (e.g., when the condition is met) following instructions stored in memory may complete before the stored data becomes globally visible. In some examples, instructions following FENCEcc (e.g., when a condition is met) may be fetched from memory before FENCEcc, but they will not be executed (e.g., not even speculatively) until FENCEcc completes (e.g., retires).

[0072] In some examples, FENCEcc can be defined with a reversed polarity, for example, (i) if the condition of FENCEcc is not met, FENCEcc will not complete execution until all previous instructions have completed locally, and no subsequent instructions begin execution before FENCEcc completes, and (ii) if the condition of FENECcc is met, FENCEcc and younger instructions can be executed before the previous instructions in program order have completed locally (e.g., FENCEcc is executed as NOP).

[0073] Figure 2A processor core pipeline 200 according to an example of this disclosure is shown. In some examples, pipeline 200 includes a fetch (202) stage for fetching instructions, a decode (204) stage for decoding the fetched instructions into a set of one or more micro-operations for execution of the instructions(s) requesting operations, a rename / allocation (206) stage for renaming / allocating resources, a reservation station (RS) scheduling (208) stage (e.g., for monitoring one or more operands and dispatching appropriate micro-operations for execution when operands are ready), an execution (210) stage for executing micro-operations, and a ROB / retire (212) stage for reordering / retire micro-operations. In some examples, for instructions whose execution is speculatively determined based on predictions from a branch predictor (e.g., whether to take), flushing is performed via redirection / sweep (214) if the prediction does not match the determined direction.

[0074] In one example, pipeline 200 receives an instruction that, in addition to updating data locations (e.g., data register 108 and / or data cache), also updates the flag register (e.g., ...). Figure 1 The flag update is performed in the flag register 110. In some examples, the FENCEcc instruction depends on... Figure 1 The flag register 110 is set to a condition, for example, to control the fence (or not control the fence) by executing the (210) phase.

[0075] Side-channel (e.g., Spectre v1) mitigation using FENCEcc

[0076] In some examples, to protect conditional branch jump condition codes (Jcc) (e.g., causing a jump to a target when the condition is met (e.g., true), and not jumping when the condition is not met (e.g., simply passing through)) and to prevent Jcc from being exploited in Spectre v1 attacks, FENCEcc is inserted at both targets of Jcc, with the negation of the condition serving as the expected condition for reaching a specific target of Jcc. For example, if "CC" is the condition code for Jcc to jump to the taken path, then the negation of CC is the condition code of FENCEcc at the taken target; similarly, the negation of CC is the condition code for jumping to the Jcc's pass-through path, so CC is the condition code of FENCEcc at the pass-through path. In some examples, when Jcc is correctly predicted, the condition of FENCEcc will not be met, so once the condition is resolved, it will allow speculative execution of younger instructions (e.g., behaving like NOP). In some examples, when Jcc is mispredicted, the condition of FENCEcc will be satisfied, so FENCEcc will not complete execution until all previous instructions have completed locally, and no subsequent instructions in program order will begin execution until FENCEcc completes (e.g., behaving as LFENCE) (e.g., pausing execution of the mispredicted instruction before Jcc is executed and the pipeline is redirected). Compared to simply disabling Jcc prediction, some FENCEcc examples allow Jcc to be predicted, so the instructions at the prediction target of Jcc can still be extracted and decoded, but execution at the prediction target can only be paused until the condition is resolved (e.g., for both cases where the condition of FENCEcc is satisfied or not).

[0077] The reason why the FENCEcc directive can be used for Spectre v1 mitigation can be clearly illustrated by the pseudocode of the "non-zero" (NZ) condition code version of FENCEcc (e.g., FENCEnz) below.

[0078] pseudocode:

[0079] ENDBR

[0080] SUB R10d, $12345678

[0081] JZ L1 / / This is equivalent to allowing JZ predictions, but conservatively suspending the execution of the JZ objective until JZ is resolved.

[0082] UD2 / / Hash check failed, explicitly raising an exception (invalid opcode exception).

[0083] L1:FENCEnz / / If NZ is incorrectly predicted as Z, then a trap speculation occurs.

[0084] This code snippet is an example of code at the call target of a fine-grained control flow integrity (CFI) hardening function (e.g., fineIBT). In some examples, at the call location, the function stores a hash (e.g., a compile-time constant) into a special register (e.g., R10) before the indirect call. At the call target, it uses a conditional branch to check if the hash value in R10 matches as expected. If the hash matches, execution is allowed to continue at the call target. In some examples, the conditional branch performing the hash check is vulnerable to Spectre v1 attacks: if the hash does not match, JZ may still be incorrectly predicted as adopted, thus violating speculative CFI. Some examples of FENCEcc can be used to harden JZ by placing FENCEnz at the target where JZ is adopted. In some examples, no instructions after FENCEnz can be executed until the condition of FENCEnz is resolved. In some examples, FENCEnz is satisfied when NZ is incorrectly predicted as Z (e.g., JZ is incorrectly predicted as adopted), preventing speculative execution of instructions at the incorrect target. In some examples, FENCEnz does not affect performance when JZ is correctly predicted to be adopted because the condition can be resolved quickly.

[0085] Note that in the pseudocode above, in some examples, if JZ is incorrectly predicted from "adopted" to "not adopted" (affecting only performance), FENCEcc is only inserted into the adopted target in examples where there are no security issues.

[0086] FENCEcc encoding

[0087] In some examples, FENCEcc instructions are encoded as extensions to new or existing instruction set architectures. One example is encoding FENCEcc to allow fallback to LFENCE on legacy architectures (e.g., but not limited to x86-64). In some examples, FENCEcc stimulus use cases replace LFENCE for Spectre v1 mitigation. Some examples in this paper ensure that software mitigation using FENCEcc is as secure on legacy machines as it is on newer machines that support FENCEcc. To encode FENCEcc within the LFENCE encoding space, some examples in this paper find encoding spaces for condition codes. In some examples, condition codes are encoded using opcode bytes, e.g., each condition code uses a new opcode.

[0088] In some examples, FENCEcc is encoded within the LFENCE encoding space. In some examples, FENCEcc encodes condition codes using register direct addressing mode fields (e.g., Mod R / M in other diagrams). In some examples, FENCEcc uses register / memory (“r / m”) operations on numeric fields (e.g., ...). Figure 20 The condition code is encoded using r / m 2046. For example, when the field is three bits wide, up to eight encodings are provided (e.g., one encoding to support unconditional fences (e.g., LFENCE) and seven encodings to support different FENCEcc condition codes).

[0089] Figure 3 This is a summary of example condition code 300 according to the examples of this disclosure. In some examples, the FENCEcc directive supports any or an appropriate subset of condition code 300. Condition code 300 includes sixteen condition codes, for example, where the 10 in bold (e.g., the first 10 entries in a table) are the appropriate subset of condition codes to be supported in some examples.

[0090] In some examples, the BE (or NA) and LE (or NG) condition codes are disjunctive conditions that can be simulated by combining two FENCEccs, for example, by stacking FENCEz (zero) and FENCEc (carry) to simulate FENCEbe. This can further reduce the number of supported condition codes to eight, thus adapting to three-bit wide encodings (e.g., as described above). Some examples not only use the r / m field of ModR / M but also utilize prefix bytes to increase the encoding space. One extension of the r / m field of the ModR / M byte is REX.B, which is sufficient to support ten condition codes. Alternatively, the purpose of the segmented overlay prefix can be repurposed to indicate the condition code upon which the FENCEcc instruction depends, for example, ignoring this prefix for LFENCE (but not for FENCEcc).

[0091] Some examples in this paper encode FENCEcc in the LFENCE encoding space, allowing condition codes to be encoded using ModR / M bytes and prefix bytes. In some examples, only a subset (e.g., commonly used) of the condition codes can be encoded by the FENCEcc instruction. Furthermore, the number of supported condition codes can be reduced by combining two FENCEcc instructions to decompose the condition.

[0092] Some examples in this paper do not use encoding for FENCEcc in the LFENCE coding space and / or do not restrict FENCEcc backward compatibility. For example, the encoding choice may be an Advanced Performance Extensions (APX) prefix to encode condition codes, but FENCEcc would be undefined on a legacy machine (e.g., #UD).

[0093] Code hardened with FENCEcc instructions

[0094] FENCEcc can also be used to achieve comprehensive side-channel (e.g., Spectre v1) mitigation by placing FENCEcc with a negative condition code (e.g., negating from the condition code of the condition branch) along each target of the conditional branch, for example, as Figure 4 As shown. In some examples, FENCEcc pauses the execution of instructions at the prediction target of a conditional branch until the condition is resolved. For example, in some examples, this is better than disabling the prediction of conditional branches because it still allows speculative extraction and decoding of instructions at the prediction target of the conditional branch. In some examples, FENCEcc enhances properties equivalent to sequential branch execution; for example, branches are either executed sequentially or out of order only if the branch is correctly predicted. Therefore, in some examples, FENCEcc does not require the complex predicate accumulation used by SLH, and thus the code enhanced by FENCEcc in these examples does not lead to code bloat.

[0095] Figure 4 Examples of unhardened unsafe code (400A), hardened code (400B) with speculative load hardening, and hardened code (400C) with conditional fence instruction 402 are shown according to this disclosure. The code in 400C includes a Jump greater than equal (Jge) instruction that causes a jump to target .LBB0_2 when a condition is met (e.g., for a previous Compare (CMP) instruction, the GE condition is met (e.g., SF flag value = OF flag value). Therefore, if the GE condition is met (and thus there is a jump to target .LBB0_2), the FENCEge instruction should be skipped; however, if code 400C fails even if the GE condition is met (e.g., due to speculative execution), FENCEge will result in a fence because the GE condition is met. Therefore, FENCEge 402 will not complete execution until all previous instructions have completed, and subsequent instructions in procedural order will not begin execution until FENCEge 402 completes.

[0096] Comparison of LFENCE and FENCEcc

[0097] Some examples of FENCEcc (unlike some examples of LFENCE) allow execution of younger instructions immediately if a condition resolves and is not satisfied. In some examples, the condition will resolve faster than all older instructions (like LFENCE) reach retirement (thus satisfying the condition FENCEcc is waiting for). For example, consider again the example shown in the pseudocode below (e.g., FineIBT). The pseudocode (using FENCEnz) shows that code after tag L1 can be safely executed as soon as the subtraction (SUB) instruction updates the flag register (e.g., EFLAGS), while the pseudocode (using LFENCE) waits until a jump occurs if the zero (JZ) instruction and all older instructions retire.

[0098] Pseudocode (using FENCEnz):

[0099] ENDBR

[0100] SUB R10d, $12345678

[0101] JZ L1

[0102] UD2

[0103] L1:FENCEnz / / If NZ is incorrectly predicted as Z, then a trap prediction occurs.

[0104] Pseudocode (using LFENCE):

[0105] ENDBR

[0106] SUB R10d, $12345678

[0107] JZ L1

[0108] UD2

[0109] L1:LFENCE

[0110] Alternative example using statically predicted branches

[0111] In some examples (e.g., x86) the ISA has two branch hint prefixes (e.g., 0x2E and 0x3E). If the microarchitecture can force conditional branches with branch hint prefixes (e.g., always) to statically predict the direction specified in the prefix, then conditional branches with branch hint prefixes can be used to simulate FENCEcc. In some examples, the alternative instruction for FENCEcc functionality is a statically predicted conditional branch. Figure 5 As shown, some examples use statically predicted Jcc and LFENCE to simulate FENCEcc.

[0112] Figure 5 This is a simulation of the condition fence instruction according to the example of this disclosure. In some examples, if the condition code (Jcc) instruction is statically predicted to be adopted, such a jump (e.g., always) first hits the LFENCE, so that: (1) if the condition is met, the Jcc is correctly predicted and the LFENCE takes effect; (2) if the condition is not met, the Jcc is incorrectly predicted and the LFENCE is released (e.g., by jump execute clear, jeclear, e.g., jumping the incorrect prediction to redirect / clear).

[0113] In some examples, using statically predicted conditional branches to simulate FENCEcc may be less efficient than native FENCEcc instructions, for example, due to code bloat and reliance on jeclear when correctly predicted. However, it may have the advantage of leveraging existing ISAs, and statically predicted conditional branches may also have other use cases, such as improving performance when the software knows the direction of the conditional branch, or facilitating software debug-side channels (e.g., Spectre v1) gadgets by forcing conditional branches to execute specific paths.

[0114] In some examples, today's branch hint prefixes are merely hints to the processor, and there is no guarantee that the processor will implement these branch hints. In fact, some microarchitectures may choose to ignore these prefixes. Therefore, some examples in this paper repurpose these branch hint prefixes to enforce statically predicted branches, but it may fall back to dynamically predicted branches, as on legacy machines. In some examples, this is not an ideal property if statically predicted branches are used to simulate FENCEcc; for example, in this case, the preferred behavior on a legacy machine is to fall back to NOPs for statically predicted branches. In this case, the preferred encoding is not to use the existing branch hint prefixes, but to use new conditional branching instructions in the NOP encoding space (e.g., encoding 16 condition codes or a subset of common condition codes).

[0115] ISA for FENCEcc instruction

[0116] Figure 6 An example of computing hardware for processing one or more FENCEcc instructions according to the present disclosure is shown. As shown, storage device 603 stores FENCEcc instructions 601 to be executed.

[0117] Instruction 601 is received by decoder circuit 605. For example, decoder circuit 605 receives this instruction from extraction circuit (not shown). The instruction can be in any suitable format, as shown in the following reference. Figure 19The format is as described. In some examples, the instruction includes a field and an opcode indicating that the condition set by another instruction (e.g., a condition code to be compared with one or more flags) is to be executed, and the opcode instructs the execution circuit to: (i) suspend execution of instructions following this instruction in procedural order until the condition is resolved, in response to the condition not being resolved; (ii) implement an execution fence in response to the condition being satisfied, such that this instruction does not complete execution until all previous instructions in procedural order have been (e.g., locally) executed, and that instructions following this instruction in procedural order (e.g., subsequent / younger) do not execute until this instruction (e.g., locally) completes (e.g., is executed); and (iii) allow one or more instructions following this instruction in procedural order to execute (e.g., not in procedural order) after the condition is resolved, in response to the condition code not being satisfied.

[0118] In some examples, the source(s) are registers(s), while in other examples, the source(s) are storage locations. In some examples, the source(s) can be immediate operands.

[0119] The following describes a more detailed example of at least one instruction format. Decoder circuit 605 decodes the instruction into one or more operations. In some examples, this decoding includes generating multiple micro-operations that will be executed by execution circuitry. In some examples, decoder circuit 605 also decodes instruction prefixes.

[0120] In some examples, register renaming, register allocation, and / or scheduling circuit 607 provides one or more of the following functions: 1) renaming logical operand values ​​to physical operand values ​​(e.g., in some examples, renaming to a register alias table), 2) assigning status bits and flags to decoded instructions, and 3) scheduling decoded instructions outside the instruction pool for execution by the execution circuit (e.g., using a reserved station in some examples).

[0121] Registers (register files) (e.g., flag register 110) and / or memory 608 store data that serves as operands for instructions to be executed by execution circuitry 609. Example register types include compact data registers, general-purpose registers (GPRs), and floating-point registers.

[0122] Execution circuit 609 executes the decoded instructions. A detailed exemplary execution circuit includes... Figure 1 The execution circuit shown is 111(1)-EXEC or 111(N)-EXEC and Figure 16B The example shows one or more execution clusters such as 1660. In some examples, the execution of the decoded instructions causes the execution circuitry to perform conditional fence operations (e.g., one or more steps) based on the opcode.

[0123] In some examples, the write-back / retrieval circuit 611 architecturally submits one or more destination registers to register or memory 608 and writes back instructions.

[0124] FENCEcc (for example, the FENCEcc mnemonic, where cc is a two-letter abbreviation for condition codes, see also FENCEcc). Figure 3 An example of the instruction format is OPCODE, which, for example, also includes a field indicating the condition code (cc). In some examples, the opcode is provided by fields 1903, 2712, or 2904. In some examples, the source and / or destination location is provided by one or more bits from prefix 1901 (e.g., R bit, VVVV, etc.), addressing information 1905 (e.g., reg 2044, R / M 2046, SIB byte 2004, etc.), 2718, 2720, 2722, 2724, 2726, etc.

[0125] Figure 7 An example method for processing FENCEcc instructions, executed by a processor according to an example of this disclosure, is shown. For example, such as... Figure 16B , Figure 1 , Figure 6 The processor core shown, the pipelines detailed below, etc., execute this method.

[0126] In 701, an instance of fetching a single instruction is described. For example, fetching an instruction to switch a subprocess (e.g., switch a memory tag table). In some examples, the instruction includes a field and an opcode indicating a condition to be set by executing another instruction (e.g., a condition code compared to one or more flags), the opcode instructing the execution circuit to: (i) suspend execution of instructions following this instruction in program order until the condition is resolved, in response to the condition not being currently resolved; (ii) implement an execution fence in response to the condition being satisfied, such that the instruction does not complete execution until all preceding instructions in program order have been (e.g., locally) executed, and that instructions following this instruction in program order (e.g., subsequent / younger) do not execute until this instruction (e.g., locally) completes (e.g., is executed); and (iii) allow one or more instructions following this instruction in program order to execute after the condition is resolved, in response to the condition not being satisfied. In some examples, the instruction also includes a field for a write mask. In some examples, the instruction is fetched from an instruction cache. The opcode indicates the operation to be performed.

[0127] In step 703, the extracted instructions are decoded. For example, the extracted FENCEcc instructions are decoded by the decoder circuitry, for example... Figure 1 decoder circuit in Figure 6The decoding circuit in the document, or the decoding circuit 1640 described in detail in this document.

[0128] In 705, when a decode instruction is scheduled, the data value associated with the source operand of the decoded instruction is retrieved. For example, when one or more source operands are memory operands, data from the indicated memory location is retrieved.

[0129] In the 707, decoding instructions are executed by the execution circuitry (hardware), such as... Figure 1 The execution circuit shown Figure 6 The execution circuit shown, or Figure 16B The execution cluster (one or more) 1660 is shown. In some examples, for the FENCEcc instruction, execution will cause the execution circuitry to perform the operations described above.

[0130] In some examples, a 709 error indicates a commit or quit command.

[0131] Figure 8 An example method for processing FENCEcc instructions using emulation or binary translation, according to examples of this disclosure, is shown.

[0132] For example, such as Figure 16B , Figure 1 , Figure 6 The processor core, pipeline, and / or emulation / translation layer shown execute various aspects of this method.

[0133] In 801, an instance of a single instruction of a first instruction set architecture is fetched. An instance of a single instruction of the first instruction set architecture includes a field and an opcode indicating a condition to be set by executing another instruction (e.g., a condition code to be compared with one or more flags), the opcode instructing the execution circuit to: (i) suspend execution of instructions following this instruction in program order until the condition is resolved, in response to the condition not being currently resolved; (ii) implement an execution fence in response to the condition being satisfied, such that the instruction does not complete execution until all preceding instructions in program order have been (e.g., locally) executed, and that instructions following this instruction in program order (e.g., subsequent / younger) do not execute until this instruction (e.g., locally) completes (e.g., is executed); and (iii) allow one or more instructions following this instruction in program order to execute after the condition is resolved, in response to the condition not being satisfied. In some examples, the instruction also includes a field for a write mask. In some examples, the instruction is fetched from an instruction cache. The opcode indicates the operation to be performed.

[0134] In 802, a single instruction extracted from a first instruction set architecture is translated into one or more instructions from a second instruction set architecture. In some examples, this translation is performed by a software translation and / or emulation layer. In some examples, such as... Figure 30 As shown, this translation is performed by the instruction converter 3012. In some examples, the translation is performed by hardware translation circuitry.

[0135] In the 803, one or more translated instructions from the second instruction set architecture are decoded. For example, the translated instructions are decoded by decoder circuitry, such as... Figure 1 decoder circuit in Figure 6 The decoder circuit in the document, or the decoder circuit 1640 described in detail herein. In some examples, the translation and decoding operations at 802 and 803 are combined.

[0136] At 805, data values ​​associated with one or more source operands of one or more decoded instructions of a second instruction set architecture are retrieved, and the one or more instructions are scheduled. For example, when one or more source operands are memory operands, data from the indicated memory location is retrieved.

[0137] In the 807, one or more decoded instructions of the second instruction set architecture are executed by the execution circuitry (hardware), such as... Figure 1 The execution circuit shown Figure 6 The execution circuit shown, or Figure 16B The execution cluster(s) 1660 shown executes one or more operations indicated by the opcode of a single instruction of a first instruction set architecture. In some examples, for the FENCEcc instruction, this execution will cause the execution circuitry to perform the aforementioned operation.

[0138] In some examples, 809 is a commit or retirement instruction.

[0139] Some examples utilize the instruction format 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 emulation and / or translation.

[0140] Given the following sets of examples, at least some examples of the disclosed technology can be described.

[0141] Example 1. An apparatus comprising:

[0142] A branch predictor is used to predict one of the taken and untaken paths of a conditional branch instruction.

[0143] A decoder circuit for decoding an instruction into a decoded instruction, the instruction including a field and an opcode, the field indicating a condition to be set by executing another instruction, the opcode indicating that an execution circuit, in response to the condition being met, implements an execution fence to delay the execution of the instruction before the execution of a previously ordered instruction, and to delay the execution of instructions following the instruction in program order before the execution of the first instruction; and

[0144] The execution circuit is used to execute the decoded instruction according to the opcode.

[0145] Example 2. The apparatus of Example 1, wherein the opcode further instructs the execution circuit to delay the execution of instructions following the instruction in program order until the condition is resolved, in response to the condition not being currently resolved.

[0146] Example 3. The apparatus of any one of Examples 1-2, wherein the opcode further instructs the execution circuit to allow one or more instructions following the instruction to be executed sequentially before the execution of one or more of the previous instructions in response to the condition not being met.

[0147] Example 4. The apparatus of Example 3, wherein the opcode further instructs the execution circuit to perform the instruction as no operation in response to the condition not being met.

[0148] Example 5. The apparatus of any one of Examples 1-4 further includes a flag register, wherein the condition refers to a flag in the flag register.

[0149] Example 6. The apparatus of any one of Examples 1-5, wherein the field indicating the condition is the register direct addressing mode field of the instruction.

[0150] Example 7. The apparatus of Example 6, wherein the field is a register operand field of the register direct addressing mode field.

[0151] Example 8. A method comprising:

[0152] The branch predictor predicts one of the taken and untaken paths for a conditional branch instruction, which precedes the instruction immediately following the conditional branch instruction in program order.

[0153] The decoder circuit decodes the instruction into a decoded instruction, the instruction including a field and an opcode. The field indicates a condition to be set by executing another instruction, and the opcode indicates that the execution circuit will implement an execution fence in response to the condition being met, to delay the execution of the instruction before the execution of the preceding instruction in program order, and to delay the execution of the instruction following the instruction in program order before the execution of the following instruction; and

[0154] The execution circuit executes the decoded instruction according to the opcode.

[0155] Example 9. The method of Example 8, wherein the opcode further instructs the execution circuit to delay the execution of instructions following the instruction in program order until the condition is resolved, in response to the condition not being resolved at present.

[0156] Example 10. The method of any one of Examples 8-9, wherein the opcode further instructs the execution circuit to allow one or more instructions following the instruction to be executed in program order before one or more of the previous instructions in response to the condition not being met.

[0157] Example 11. The method of Example 10, wherein the opcode further instructs the execution circuit to perform the instruction as no operation in response to the condition not being met.

[0158] Example 12. The method of any one of Examples 8-11 further includes a flag register, wherein the condition refers to a flag in the flag register.

[0159] Example 13. The method of any one of Examples 8-12, wherein the field indicating the condition is the register direct addressing mode field of the instruction.

[0160] Example 14. The method described in Example 13, wherein the field is the register operand field of the register direct addressing mode field.

[0161] Example 15. A non-transitory machine-readable medium storing code, which, when executed by a machine, causes the machine to perform a method comprising the following processes:

[0162] The branch predictor predicts one of the taken and untaken paths for a conditional branch instruction, which precedes the instruction immediately following the conditional branch instruction in program order.

[0163] The decoder circuit decodes the instruction into a decoded instruction, the instruction including a field and an opcode. The field indicates a condition to be set by executing another instruction, and the opcode indicates that the execution circuit will implement an execution fence in response to the condition being met, to delay the execution of the instruction before the execution of the preceding instruction in program order, and to delay the execution of the instruction following the instruction in program order before the execution of the following instruction; and

[0164] The execution circuit executes the decoded instruction according to the opcode.

[0165] Example 16. The non-transitory machine-readable medium of Example 15, wherein the opcode further instructs the execution circuit to delay the execution of instructions following the instruction in program order until the condition is resolved, in response to the condition not being currently resolved.

[0166] Example 17. A non-transitory machine-readable medium as described in any one of Examples 15-16, wherein the opcode further instructs the execution circuitry to allow one or more instructions following the instruction in program order to be executed before one or more of the preceding instructions in response to the condition not being met.

[0167] Example 18. The non-transient machine-readable medium of Example 17, wherein the opcode further instructs the execution circuit to perform the instruction as no operation in response to the condition not being met.

[0168] Example 19. The non-transitory machine-readable medium of any one of Examples 15-18 further includes a flag register, wherein the condition refers to a flag in the flag register.

[0169] Example 20. A non-transitory machine-readable medium as described in any one of Examples 15-19, wherein the field indicating the condition is a register direct addressing mode field of the instruction.

[0170] Example 21. The non-transitory machine-readable medium of Example 20, wherein the field is the register operand field of the register direct addressing mode field.

[0171] Exemplary architectures and systems to which the above content is applicable will be described in detail below. The exemplary instruction format of the FENCEcc instruction will also be described in detail below.

[0172] Example Architecture

[0173] Example computer architectures are described in detail below. Other system designs and configurations known in the art for laptops, desktop computers, personal computers (PCs), personal digital assistants, engineering workstations, servers, discrete servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. In summary, various systems or electronic devices capable of incorporating the processors and / or other execution logic disclosed herein are generally suitable.

[0174] Example System

[0175] Figure 9 An example computing system is illustrated. The multiprocessor system 900 is an interface system and includes multiple processors or cores, including a first processor 970 and a second processor 980 coupled via an interface 950 (e.g., a point-to-point (PP) interconnect, fabric, and / or bus). In some examples, the first processor 970 and the second processor 980 are homogeneous. In some examples, the first processor 970 and the second processor 980 are heterogeneous. While the example system 900 is shown as having two processors, the system may have three or more processors, or it may be a single-processor system. In some embodiments, the computing system is a system-on-a-chip (SoC).

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

[0177] Processors 970 and 980 can each exchange information with network interface (NWI / F) 990 via interface circuits 976, 994, 986, and 998, respectively, through interfaces 952 and 954. Network interface 990 (e.g., one or more of an interconnect, bus, and / or structure, in some examples a chipset) can optionally exchange information with coprocessor 938 via interface circuit 992. In some examples, coprocessor 938 is a dedicated processor, such as a high-throughput processor, network or communication processor, compression engine, graphics processor, general-purpose graphics processing unit (GPGPU), neural-network processing unit (NPU), embedded processor, etc.

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

[0179] Network interface 990 may be coupled to first interface 916 via interface circuitry 996. In some examples, first interface 916 may be an interface such as a Peripheral Component Interconnect (PCI) interconnect, a PCI Express interconnect, or another I / O interconnect. In some examples, first interface 916 is coupled to power control unit (PCU) 917, which may include circuitry, software, and / or firmware to perform power management operations with respect to processors 970, 980, and / or coprocessor 938. PCU 917 provides control information to a voltage regulator (not shown) to cause the voltage regulator to generate an appropriate regulated voltage. PCU 917 also provides control information to control the generated operating voltage. In various examples, PCU 917 may include various power management logic units (circuitry) to perform hardware-based power management. Such power management can be entirely processor-controlled (e.g., controlled by various processor hardware and can be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management can be performed in response to an external source (e.g., a platform or power management source or system software).

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

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

[0182] Example core architecture, processor, and computer architecture.

[0183] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, these core implementations can include: 1) general-purpose ordered cores for general computing purposes; 2) high-performance general-purpose out-of-order cores for general computing purposes; and 3) dedicated cores primarily for graphics and / or scientific (throughput) computing purposes. Different processor implementations can include: 1) CPUs, including one or more general-purpose ordered cores and / or one or more general-purpose out-of-order cores for general computing purposes; and 2) coprocessors, including one or more dedicated cores primarily for graphics and / or scientific (throughput) computing purposes. These different processors lead to different computer system architectures, which can include: 1) coprocessors on a different chip than the CPU; 2) coprocessors on different dies in the same package as the CPU; 3) coprocessors on the same die as the CPU (in this case, such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or dedicated cores); and 4) system-on-a-chip (SoC), which can be included on the same die as the described CPU (sometimes referred to as application cores or application processors), the aforementioned coprocessors, and additional functionality. An example core architecture is described next, followed by a description of the example processor and computer architecture.

[0184] Figure 10 A block diagram of an example processor and / or SoC 1000 is shown, which may have one or more cores and an integrated memory controller. Solid-line boxes indicate that the processor 1000 has a single core 1002(A), system proxy unit circuitry 1010, and a set of one or more interface controller unit circuitry 1016, while optionally added dashed-line boxes indicate an alternative processor 1000 having multiple cores 1002(A)-(N), a set of one or more integrated memory controller unit circuitry 1014 from the system proxy unit circuitry 1010, dedicated logic 1008, and a set of one or more interface controller unit circuitry 1016. Note that the processor 1000 may be... Figure 9 It is one of the processors 970 or 980 or the coprocessor 938 or 915.

[0185] Therefore, different implementations of processor 1000 may include: 1) a CPU, wherein dedicated logic 1008 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1002(A)-(N) are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose out-of-order cores, or a combination of both); 2) a coprocessor, wherein cores 1002(A)-(N) are a large number of dedicated cores primarily used for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, wherein cores 1002(A)-(N) are a large number of general-purpose ordered cores. Thus, processor 1000 can be a general-purpose processor, a coprocessor, or a dedicated 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 can be implemented on one or more chips. The processor 1000 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).

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

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

[0188] Cores 1002(A)-(N) can be homogeneous in terms of instruction set architecture (ISA). Alternatively, cores 1002(A)-(N) can also be heterogeneous in terms of ISA; that is, a subset of cores 1002(A)-(N) may be able to execute an ISA, while other cores may be able to execute only a subset of that ISA or be able to execute another ISA.

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

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

[0191] Within the I / O subsystem 1111, system storage unit 1114 can be connected to I / O hub 1107, providing a storage mechanism for computing system 1100. I / O switch 1116 can be used to provide an interface mechanism to enable connectivity between I / O hub 1107 and other components, such as network adapter 1118 and / or wireless network adapter 1119 that can be integrated into the platform, and various other devices that can be added via one or more plug-in devices 1120. The plug-in devices 1120 may also include, for example, one or more external graphics processing units, graphics cards, and / or computing accelerators. Network adapter 1118 can be an Ethernet adapter or another wired network adapter. Wireless network adapter 1119 can include one or more of Wi-Fi, Bluetooth, Near Field Communication (NFC), or other network devices including one or more wireless radios.

[0192] The computing system 1100 may include other components not explicitly shown, including USB or other port connections, optical storage device drives, video capture devices, etc., which may also be connected to the I / O hub 1107. Interconnection Figure 11 The communication paths between the various components can be implemented using any suitable protocol, such as protocols based on Peripheral Component Interconnect (PCI) (e.g., PCI Express), or any other bus or one or more point-to-point communication interfaces and / or protocols, such as NVLink high-speed interconnect, Compute ExpressLink, etc. TM CXL TM(For example, CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802.3), Remote Direct Memory Access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connection (QUIC), RDMA over Converged Ethernet (RoCE), Intel's QuickPath Interconnect (QPI), Intel's 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 Accelerator Caches Accelerator (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G and its variants, or wired or wireless interconnect protocols known in the art. In some examples, protocols such as non-volatile memory express over Fabric (NVMe-oF) or NVMe can be used to copy or store data to virtualized storage nodes.

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

[0194] It should be understood that the computing system 1100 shown herein is illustrative, and variations and modifications are possible. The connectivity topology, including the number and arrangement of bridges, the number of processors(one or more) 1102, and the number of parallel processors(one or more) 1112, can be modified as needed. For example, system memory 1104 may be directly connected to one or more processors 1102 instead of via bridges, while other devices communicate with system memory 1104 via memory hub 1105 and one or more processors 1102. In other alternative topologies, one or more parallel processors 1112 may be connected to I / O hub 1107 or directly to one of the one or more processors 1102 instead of to memory hub 1105. In other examples, I / O hub 1107 and memory hub 1105 may be integrated into a single chip. Two or more groups of one or more processors 1102 may also be connected via multiple sockets that can couple to two or more instances of parallel processors 1112.

[0195] Some specific components shown in this article are optional and may not be included in all implementations of the computing system 1100. For example, any number of plug-in cards or peripherals may be supported, or certain components may be eliminated. Furthermore, some architectures may be adapted to... Figure 11 The components shown are similar to those described using different terminology. For example, in some architectures, the memory hub 1105 may be referred to as the Northbridge, while the I / O hub 1107 may be referred to as the Southbridge.

[0196] Figure 12A An example of a parallel processor 1200 is shown. The parallel processor 1200 can be a GPU, GPGPU, etc., as described herein. Various components of the parallel processor 1200 can 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 parallel processor 1200 shown can be... Figure 11 One or more parallel processors 1112 are shown.

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

[0198] When host interface 1206 receives a command buffer via I / O unit 1204, host interface 1206 can route work operations to execute these commands to front end 1208. In some examples, front end 1208 is coupled to scheduler 1210, which is configured to distribute commands or other work items to processing cluster array 1212. Scheduler 1210 ensures that processing cluster array 1212 is correctly configured and in an active state before tasks are distributed to the processing clusters of processing cluster array 1212. Scheduler 1210 can be implemented through firmware logic executed on a microcontroller. The microcontroller-implemented scheduler 1210 can be configured to perform complex scheduling and work distribution operations at both coarse and fine granular levels, enabling rapid preemption and context switching of threads that can execute on processing cluster array 1212. Preferably, the host software can demonstrate the workload for scheduling on processing cluster array 1212 through one of a plurality of graphics processing doorbells. In other examples, polling for new workloads or interrupts can be used to identify or indicate the availability of work to be performed. The workload can then be automatically distributed among the processing cluster array 1212 by the scheduler 1210 logic within the scheduler microcontroller.

[0199] Processing cluster array 1212 may include up to "N" processing clusters (e.g., clusters 1214A, 1214B to 1214N). Each cluster 1214A-1214N of processing cluster array 1212 can execute a large number of concurrent threads. Scheduler 1210 may use various scheduling and / or work distribution algorithms to distribute work to clusters 1214A-1214N of processing cluster array 1212, which may vary depending on the workload generated by each type of program or computation. Scheduling may be dynamically handled by scheduler 1210 or may be partially assisted by compiler logic during the compilation of program logic configured to be executed by processing cluster array 1212. Optionally, different clusters 1214A-1214N of processing cluster array 1212 may be assigned to process different types of programs or perform different types of computations.

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

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

[0202] In an example where the parallel processing unit 1202 is used to perform graphics processing, the scheduler 1210 can be configured to divide the processing workload into tasks of approximately equal size to better distribute graphics processing operations across multiple clusters 1214A-1214N of the processing cluster array 1212. In some of these examples, portions of the processing cluster array 1212 can be configured to perform different types of processing. For example, a first portion can be configured to perform vertex shading and topology generation, a second portion can be configured to perform tessellation and geometry shading, and a third portion can 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 the clusters 1214A-1214N can be stored in a buffer to allow intermediate data to be transferred between the clusters 1214A-1214N for further processing.

[0203] During operation, the processing cluster array 1212 can receive processing tasks to be executed via scheduler 1210, which receives commands defining the processing tasks from front-end 1208. For graphics processing operations, processing tasks may include indexes of data to be processed, such as surface (patch) data, graph data, vertex data, and / or pixel data, as well as state parameters and commands defining how to process the data (e.g., what program to execute). Scheduler 1210 can be configured to retrieve the index corresponding to the task, or can receive the index from front-end 1208. Front-end 1208 can be configured to ensure that the processing cluster array 1212 is configured to be active before starting the workload specified by the incoming command buffer (e.g., batch buffer, push buffer, etc.).

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

[0205] Memory cells 1224A-1224N may include various types of memory devices, including dynamic random-access memory (DRAM) or graphics random-access memory, such as synchronous graphics random-access memory (SGRAM), including graphics double data rate (GDDR) memory. Optionally, memory cells 1224A-1224N may also include 3D stacked memory, including but not limited to high bandwidth memory (HBM). Those skilled in the art will understand that the specific implementation of memory cells 1224A-1224N can vary and can be selected from a variety of conventional designs. Rendering targets, such as framebuffers or texture maps, can be stored across memory cells 1224A-1224N, allowing partitioning cells 1220A-1220N to write portions of each rendering target in parallel to efficiently utilize the available bandwidth of the parallel processor memory 1222. In some examples, local instances of the parallel processor memory 1222 may be excluded to support a unified memory design that utilizes a combination of system memory and local cache memory.

[0206] Optionally, any one of the clusters 1214A-1214N of the processing cluster array 1212 is capable of processing data to be written to any memory cell 1224A-1224N within the parallel processor memory 1222. The memory crossbar switch 1216 can be configured to transfer the output of each cluster 1214A-1214N to any partition cell 1220A-1220N or another cluster 1214A-1214N, which can perform additional processing operations on the output. Each cluster 1214A-1214N can communicate with the memory interface 1218 via the memory crossbar switch 1216 to read from or write to various external memory devices. In one example with a memory crossbar switch 1216, the memory crossbar switch 1216 has a connection to a memory interface 1218 for communication with I / O unit 1204, and a connection to a local instance of parallel processor memory 1222, enabling processing units within different processing clusters 1214A-1214N to communicate with system memory or other memory local to non-parallel processing unit 1202. Typically, the memory crossbar switch 1216 can, for example, use virtual channels to separate traffic flows between clusters 1214A-1214N and partition units 1220A-1220N.

[0207] Although a single instance of the parallel processing unit 1202 is shown within the parallel processor 1200, any number of instances of the parallel processing unit 1202 may be included. For example, multiple instances of the parallel processing unit 1202 may be provided on a single plug-in card, or multiple plug-in cards may be interconnected. For example, the parallel processor 1200 may be a plug-in device, such as... Figure 11 The plug-in device 1120 may be a graphics card, such as a discrete graphics card, including one or more GPUs, one or more memory devices, and a device-to-device or network or architecture interface. Different instances of the parallel processing unit 1202 may be configured to interoperate, even if the different instances have different numbers of processing cores, different numbers of local parallel processor memories, and / or other configuration differences. Optionally, some instances of the parallel processing unit 1202 may include higher precision floating-point units relative to other instances. Systems containing one or more instances of the parallel processing unit 1202 or the parallel processor 1200 may be implemented in various configurations and forms, including but not limited to desktop computers, laptops, or handheld personal computers, servers, workstations, game consoles, and / or embedded systems. The orchestrator may use one or more of the following resources to form composite nodes for workload performance: decomposed processor resources, cache resources, memory resources, storage device resources, and network resources.

[0208] In some examples, the parallel processing unit 1202 can be divided into multiple instances. These instances can be configured to execute workloads associated with different clients in an isolated manner, thereby providing a predetermined quality of service for each client. For example, each cluster 1214A-1214N can be isolated from other clusters, allowing the processing cluster array 1212 to be divided into multiple compute partitions or instances. In this configuration, workloads executed on isolated partitions are protected from failures or errors associated with different workloads running on different partitions. Partition units 1220A-1220N can be configured to enable dedicated and / or isolated paths to the memory used by the clusters 1214A-1214N associated with each compute partition. This data path isolation allows compute resources within a partition to communicate with one or more assigned memory units 1224A-1224N without interference from activity in other partitions.

[0209] Figure 12B This is a block diagram of partition unit 1220. Partition unit 1220 can be... Figure 12A An example of one of the partitioning units 1220A-1220N. As shown, partitioning unit 1220 includes an L2 cache 1221, a frame buffer interface 1225, and a ROP 1226 (raster operation unit). The L2 cache 1221 is a read / write cache configured to perform load and store operations received from memory crossbar switches 1216 and ROP 1226. Read misses and urgent write-back requests are output from the L2 cache 1221 to the frame buffer interface 1225 for processing. Updates can also be sent to the frame buffer for processing via the frame buffer interface 1225. In some examples, the frame buffer interface 1225 is connected to memory cells in the parallel processor memory (e.g., ...). Figure 12A The partition unit 1220 interfaces with one of the memory cells 1224A-1224N (e.g., within the parallel processor memory 1222). The partition unit 1220 may also additionally or alternatively interface with one of the memory cells in the parallel processor memory via a memory controller (not shown).

[0210] In graphics applications, ROP 1226 is a processing unit that performs raster operations such as stenciling, z-testing, blending, etc. ROP 1226 then outputs the processed graphics data stored in graphics memory. In some examples, ROP 1226 includes or is coupled to CODEC 1227, which includes compression logic to compress depth or color data written to memory or L2 cache 1221 and decompress depth or color data read from memory or L2 cache 1221. The compression logic can be lossless compression logic utilizing one or more of a variety of compression algorithms. The type of compression performed by CODEC 1227 can vary based on the statistical characteristics of the data to be compressed. For example, in some examples, incremental color compression is performed on depth and color data on a per-tile basis. In some examples, CODEC 1227 includes compression and decompression logic that can compress and decompress computational data associated with machine learning operations. For example, CODEC 1227 can compress sparse matrix data for use in sparse machine learning operations. CODEC 1227 can also compress sparse matrix data encoded in sparse matrix formats (e.g., coordinate list encoding (COO), compressed sparse row (CSR), compressed sparse column (CSC), etc.) to generate compressed and encoded sparse array 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.

[0211] ROP 1226 can be included in each processing cluster (e.g., Figure 12A The data is stored within clusters 1214A-1214N, not within partition units 1220. In these examples, read / write requests for pixel data are sent via memory crossbar switch 1216 instead of pixel fragment data. The processed graphics data can then be displayed on a display device, for example, Figure 11 One or more display devices 1110A-1110B are routed for further processing by one or more processors 1102, or are routed for... Figure 12A One of the processing entities within the parallel processor 1200 is further processed.

[0212] Figure 12C This is a block diagram of a processing cluster 1214 within a parallel processing unit. For example, the processing cluster is... Figure 12AAn instance of one of the processing clusters 1214A-1214N. Processing cluster 1214 can be configured to execute many threads in parallel, where the term "thread" refers to an instance of a specific program executing on a specific input dataset. Optionally, single-instruction, multiple-data (SIMD) instruction issuing techniques can be used to support the parallel execution of a large number of threads without providing multiple independent instruction units. Alternatively, single-instruction, multiple-thread (SIMT) techniques can be used to support the parallel execution of a large number of typically synchronous threads, using a common instruction unit configured to issue instructions to a set of processing engines within each processing cluster. Unlike SIMD execution mechanisms, where all processing engines typically execute the same instructions, SIMT execution allows different threads to more easily follow different execution paths through a given thread program. Those skilled in the art will understand that the SIMD processing mechanism represents a subset of the functionality of the SIMT processing mechanism.

[0213] The operation of cluster 1214 can be controlled by the pipeline manager 1232, which distributes processing tasks to the SIMT parallel processors. The pipeline manager 1232... Figure 12A The scheduler 1210 receives instructions and manages the execution of these instructions via the graphics multiprocessor 1234 and / or texture unit 1236. The graphics multiprocessor 1234 shown is an exemplary instance of a SIMT parallel processor. However, various types of SIMT parallel processors with different architectures may be included within the processing cluster 1214. One or more instances of the graphics multiprocessor 1234 may be included within the processing cluster 1214. The graphics multiprocessor 1234 can process data, and the data crossover switch 1240 can be used to distribute the processed data to one of several possible destinations, including other shader units. The pipeline manager 1232 can facilitate the distribution of processed data by specifying the destination of the processed data to be distributed via the data crossover switch 1240.

[0214] Each graphics multiprocessor 1234 within the processing cluster 1214 may include a set of identical functional execution logic (e.g., arithmetic logic units, load-memory units, etc.). The functional execution logic can be configured in a pipelined manner, where new instructions can be issued before previous instructions complete. The functional execution logic supports a variety of operations, including integer and floating-point arithmetic, comparison operations, Boolean operations, shift operations, and computation of various algebraic functions. Different operations can be performed using the same functional unit hardware, and any combination of functional units can exist.

[0215] Instructions sent to the processing cluster 1214 constitute threads. A group of threads executing across a set of parallel processing engines is a thread group. Thread groups execute the same program on different input data. Each thread within a thread group can be assigned to a different processing engine within the graphics multiprocessor 1234. A thread group may include fewer threads than the number of processing engines within the graphics multiprocessor 1234. When a thread group includes fewer threads than the number of processing engines, one or more processing engines may be idle during the processing cycle of that thread group. A thread group may also include more threads than the number of processing engines within the graphics multiprocessor 1234. When a thread group includes more threads than the number of processing engines within the graphics multiprocessor 1234, processing can be performed in consecutive clock cycles. Optionally, multiple thread groups can be executed concurrently on the graphics multiprocessor 1234.

[0216] The graphics multiprocessor 1234 may include an internal cache memory to perform load and store operations. Optionally, the graphics multiprocessor 1234 may forgo the internal cache and use a cache memory within the processing cluster 1214 (e.g., a Level 1 (L1) cache 1248). Each graphics multiprocessor 1234 may also access partition units (e.g., ...). Figure 12A The graphics multiprocessor 1234 has a Level 2 (L2) cache within partition units 1220A-1220N, which are shared across all processing clusters 1214 and can be used to transfer data between threads. The graphics multiprocessor 1234 can also access off-chip global memory, which may include one or more of local parallel processor memory and / or system memory. Any memory outside of the parallel processing unit 1202 can be used as global memory. Examples of processing clusters 1214 including multiple instances of the graphics multiprocessor 1234 can share common instructions and data, which can be stored in the L1 cache 1248.

[0217] Each processing cluster 1214 may include an MMU 1245 (Memory Management Unit) configured to map virtual addresses to physical addresses. In other examples, one or more instances of the MMU 1245 may reside on Figure 12AThe MMU 1245 is located within the memory interface 1218. It includes a set of page table entries (PTEs) used to map virtual addresses to physical addresses of tiles, and optional cache line indexes. The MMU 1245 may include address translation lookup buffers (TLBs) or caches that may reside within the L1 cache 1248 of the graphics multiprocessor 1234 or processing cluster 1214. Physical addresses are processed to distribute surface data access locality, allowing efficient request interleaving between partition units. Cache line indexes can be used to determine whether a request for a cache line is a hit or a miss.

[0218] In graphics and computing applications, processing cluster 1214 can be configured such that each graphics multiprocessor 1234 is coupled to a texture unit 1236, which performs texture mapping operations, such as determining texture sample locations, reading texture data, and filtering texture data. Texture data is read from an internal texture L1 cache (not shown), or in some examples from an L1 cache within the graphics multiprocessor 1234, and may be retrieved from an L2 cache, local parallel processor memory, or system memory as needed. Each graphics multiprocessor 1234 outputs a processed task to a data crossbar switch 1240 to provide the processed task to another processing cluster 1214 for further processing, or stores the processed task in an L2 cache, local parallel processor memory, or system memory via a memory crossbar switch 1216. A pre-ROP 1242 (pre-raster operation unit) is configured to receive data from the graphics multiprocessor 1234 and direct the data to a ROP unit, which may be associated with a partitioning unit (e.g., [missing information]). Figure 12A The partition units 1220A-1220N are located together. The pre-ROP 1242 unit can perform color blending optimization, organize pixel color data, and perform address translation.

[0219] It should be understood that the core architecture described herein is illustrative and can be varied and modified. Any number of processing units, such as graphics multiprocessors 1234, texture units 1236, pre-ROPs 1242, etc., can be included within processing cluster 1214. Furthermore, although only one processing cluster 1214 is shown, the parallel processing units as described herein can include any number of instances of processing cluster 1214. Optionally, each processing cluster 1214 can be configured to operate independently of other processing clusters 1214 using separate and distinct processing units, L1 caches, L2 caches, etc.

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

[0221] Instruction cache 1252 receives a stream of instructions to be executed from pipeline manager 1232. Instructions are cached in instruction cache 1252 and dispatched to instruction unit 1254 for execution. Instruction unit 1254 can dispatch instructions as thread groups (e.g., thread bundles), with each thread in the thread group assigned to a different execution unit within GPGPU core 1262. Instructions can access any of the local, shared, or global address spaces by specifying an address within a unified address space. Address mapping unit 1256 can be used to translate addresses in the unified address space into different memory addresses accessible by load / store unit 1266.

[0222] Register file 1258 provides a set of registers for the functional units of graphics multiprocessor 1234. Register file 1258 provides temporary storage for operands on data paths connected to functional units of graphics multiprocessor 1234 (e.g., GPGPU core 1262, load / store unit 1266). Register file 1258 can be partitioned between each functional unit, such that each functional unit is allocated a dedicated portion of register file 1258. For example, register file 1258 can be partitioned between different bundles executed by graphics multiprocessor 1234.

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

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

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

[0226] Figures 13A-13C An additional graphics multiprocessor is shown based on the example. Figures 13A-13B The graphics multiprocessors 1325 and 1350 are shown, and these graphics multiprocessors are related to... Figure 12C The graphics multiprocessor 1234 is related to and can be used in place of one of the graphics multiprocessors 1234. Therefore, any features disclosed herein in conjunction with the graphics multiprocessor 1234 are also disclosed in corresponding combinations with one or more graphics multiprocessors 1325, 1350, but are not limited thereto. Figure 13C A graphics processing unit (GPU) 1380 is shown, which includes a dedicated set of graphics processing resources arranged as multi-core groups 1365A-1365N, corresponding to graphics multiprocessors 1325 and 1350. The illustrated graphics multiprocessors 1325 and 1350 and the multi-core groups 1365A-1365N can be streaming multiprocessors (SMs) capable of executing a large number of execution threads simultaneously.

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

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

[0229] Figure 13B The graphics multiprocessor 1350 includes multiple execution resources 1356A-1356D, each of which includes multiple instruction units, register files, GPGPU cores, and load memory units, such as... Figure 12D and Figure 13A As shown. Execution resources 1356A-1356D can work in conjunction with one or more texture units 1360A-1360D for texture operations, while sharing instruction cache 1354 and shared memory 1353. For example, execution resources 1356A-1356D can share instruction cache 1354 and shared memory 1353, as well as multiple instances of texture and / or data cache memories 1358A-1358B. Various components can be configured similarly to... Figure 13A The interconnection structure 1327 communicates with the interconnection structure 1352.

[0230] Those skilled in the art will understand that Figure 1 , 12AThe architectures described in -12D and 13A-13B are descriptive and do not limit the scope of this example. Therefore, the techniques described herein can 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, and one or more parallel processing units (such as...). Figure 12A Parallel processing unit 1202), and one or more graphics processors or dedicated processing units.

[0231] The parallel processors or GPGPUs described herein can be communicatively coupled to the 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 other interconnect (e.g., high-speed interconnects such as PCIe, NVLink, or other known, standardized, or proprietary protocols). In other examples, the GPU can be integrated with the core on the same package or chip and communicatively coupled to the core via an internal processor bus / interconnect (i.e., within the package or chip). Regardless of how 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 job descriptor. The GPU then uses dedicated circuitry / logic to efficiently process these commands / instructions.

[0232] Figure 13C A graphics processing unit (GPU) 1380 is shown, which includes a dedicated set of graphics processing resources arranged as multi-core groups 1365A-1365N. While only details of a single multi-core group 1365A are provided, it should be understood that other multi-core groups 1365B-1365N may be equipped with the same or similar sets of graphics processing resources. The details described regarding multi-core groups 1365A-1365N also apply to any graphics multiprocessors 1234, 1325, 1350 described herein.

[0233] As shown in the figure, the multi-core group 1365A may include a set of graphics cores 1370, a set of tensor cores 1371, and a set of ray tracing cores 1372. A scheduler / dispatcher 1368 schedules and dispatches graphics threads for execution on the various cores 1370, 1371, and 1372. A set of register files 1369 stores the operation values ​​used by the cores 1370, 1371, and 1372 when executing graphics threads. For example, these register files may include integer registers for storing integer values, floating-point registers for storing floating-point values, vector registers for storing compressed data elements (integer and / or floating-point data elements), and tile registers for storing tensor / matrix values. The tile registers may be implemented as a combined set of vector registers.

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

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

[0236] In one implementation of the IOMMU 1364, the IOMMU 1364 supports virtualization. In this case, it can manage a first set of page tables to map guest / graphics virtual addresses to guest / graphics physical addresses, and a second set of page tables to map guest / graphics physical addresses to system / host physical addresses (e.g., within system memory 1366). The base address of each page table in the first and second sets of page tables can be stored in a control register and swapped out during context switching (e.g., to provide access to the relevant set of page tables for the new context). Although Figure 13C Not shown, but each of cores 1370, 1371, 1372 and / or multi-core groups 1365A-1365N may include a translation back buffer (TLB) for caching guest virtual to guest physical translation, guest physical to host physical translation, and guest virtual to host physical translation.

[0237] One or more CPUs 1361, GPUs 1380, and I / O devices 1362 may be integrated on a single semiconductor chip and / or chip package. The memory 1366 shown may be integrated on the same chip or coupled to the memory controller 1367 via an off-chip interface. In one implementation, the memory 1366 includes GDDR6 memory that shares the same virtual address space with other physical system-level memories, although the basic principles described herein are not limited to this particular implementation.

[0238] The Tensor Core 1371 may include multiple execution units specifically designed to perform matrix operations, which are fundamental computational operations used for performing deep learning operations. For example, matrix multiplication can be used for both neural network training and inference. The Tensor Core 1371 can perform matrix processing using various operand precisions, including single-precision floating-point (e.g., 32 bits), half-precision floating-point (e.g., 16 bits), integers (16 bits), bytes (8 bits), and half-bytes (4 bits). For example, a neural network implementation may extract features from each rendered scene, possibly combining details from multiple frames, to construct a high-quality final image.

[0239] In deep learning implementations, parallel matrix multiplication can be scheduled to be performed on the Tensor Core 1371. This is particularly important for training neural networks, which requires a large number of matrix dot product operations. To handle the inner product formulas of N x N x N matrix multiplications, the Tensor Core 1371 can include at least N dot product processing elements. Before matrix multiplication begins, a complete matrix is ​​loaded into a block register, and at least one column of a second matrix is ​​loaded in each of the N cycles. N dot products are processed in each cycle.

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

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

[0242] Ray tracing core 1372 can accelerate ray tracing operations implemented in both real-time and non-real-time ray tracing. Specifically, ray tracing core 1372 may include ray traversal / intersection circuitry for performing ray traversal using a boundary volume hierarchy (BVH) and identifying intersections between rays and primitives enclosed within a BVH volume. Ray tracing core 1372 may also include circuitry for performing depth testing and culling (e.g., using a Z-buffer or similar arrangement). In one implementation, ray tracing core 1372 performs traversal and intersection operations in conjunction with the image denoising techniques described herein, at least a portion of which may be performed on tensor core 1371. For example, tensor core 1371 may implement a deep learning neural network to denoise frames generated by ray tracing core 1372. However, CPU 1361, graphics core 1370, and / or ray tracing core 1372 may also implement all or part of the denoising and / or deep learning algorithms.

[0243] Furthermore, as mentioned above, a distributed denoising approach can be employed, where the GPU 1380 resides within a computing device coupled to other computing devices via a network or high-speed interconnect. In this distributed approach, the interconnected computing devices can share neural network learning / training data to improve the speed at which the entire system learns to perform denoising on different types of image frames and / or different graphics applications.

[0244] Ray tracing core 1372 can handle all BVH traversals and / or ray primitive intersections, thus avoiding overloading graphics core 1370 with thousands of instructions per ray. For example, each ray tracing core 1372 includes a first set of dedicated circuitry for performing bounding box tests (e.g., for traversal operations) and / or a second set of dedicated circuitry for performing ray triangle intersection tests (e.g., for traversed intersecting rays). Thus, for example, a multi-core group 1365A can simply enable ray detection, with ray tracing core 1372 independently performing ray traversal and intersection and returning hit data (e.g., hit, miss, multiple hits, etc.) to the thread context. Other cores 1370, 1371 are freed to perform other graphics or computational work, while ray tracing core 1372 performs traversal and intersection operations.

[0245] Optionally, each ray tracing core 1372 may include a traversal unit that performs BVH test operations and / or an intersection unit that performs ray primitive intersection tests. The intersection unit generates a "hit," "miss," or "multiple hits" response and provides it to the corresponding thread. During traversal and intersection operations, execution resources of other cores (e.g., graphics core 1370 and tensor core 1371) are released to perform other forms of graphics work.

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

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

[0248] Generally, various cores such as 1372, 1371, and 1370 can support a ray tracing instruction set, which includes instructions / functions for one or more of the following: ray generation, nearest hit, any hit, ray primitive intersection, construction of bounding boxes for each primitive and hierarchy, miss, access, and exception. More specifically, some examples include ray tracing instructions that perform one or more of the following functions:

[0249] -Ray generation – Ray generation instructions can be assigned to each pixel, sample, or other user-defined task.

[0250] -Nearest Hit-- The nearest hit command can be executed to locate the nearest intersection point between a ray and a primitive in the scene.

[0251] -AnyHit-- The AnyHit instruction identifies multiple intersections between rays and primitives in a scene, and may be used to identify new nearest intersections.

[0252] -Intersection-- The intersection command performs an intersection test on ray primitives and outputs the results.

[0253] -Per-Primitive Boundary Box Construction – This instruction constructs a bounding box around a given primitive or group of primitives (e.g., when constructing a new BVH or other acceleration data structure).

[0254] -Missed – indicates that the ray missed the scene or all geometry within a specified area of ​​the scene.

[0255] -Access– indicates the sub-volume through which light will pass.

[0256] - Exceptions – include various types of exception handlers (e.g., calls for various error conditions).

[0257] In some examples, the ray tracing core 1372 can be adapted to accelerate general computational operations that can be accelerated using computational techniques similar to ray intersection testing. A computational framework can be provided that enables shader programs to be compiled into low-level instructions and / or primitives that perform general computational operations via the ray tracing core. Exemplary computational problems that can benefit from computational operations performed on the ray tracing core 1372 include computations involving the propagation of beams, waves, rays, or particles within coordinate space. Interactions associated with this propagation can be computed relative to geometry or a mesh within coordinate space. For example, computations associated with the propagation of electromagnetic signals through the environment can be accelerated using instructions or primitives executed via the ray tracing core. Diffraction and reflection of signals by objects in the environment can be computed using direct ray tracing analogies.

[0258] Ray Tracing Core 1372 can also be used to perform calculations not directly similar to ray tracing. For example, Ray Tracing Core 1372 can be used to accelerate mesh projection, mesh refinement, and volume sampling calculations. It can also perform general coordinate space calculations, such as nearest neighbor calculations. For instance, a set of points near a given point can be discovered by defining a bounding box in the coordinate space around the point. The BVH and ray probing logic within Ray Tracing Core 1372 can then be used to determine a set of intersections within the bounding box. These intersections constitute the origin and its nearest neighbors. Computations performed using Ray Tracing Core 1372 can be executed in parallel with calculations performed on Graphics Core 1372 and Tensor Core 1371. The shader compiler can be configured to compile computation shaders or other general graphics processing programs into low-level primitives that can be parallelized across Graphics Core 1370, Tensor Core 1371, and Ray Tracing Core 1372.

[0259] Building increasingly larger silicon chips is becoming increasingly challenging for various reasons. As silicon chip size increases, manufacturing yield decreases, and the process technology requirements for different components may differ. On the other hand, to achieve high-performance systems, key components should be interconnected through high-speed, high-bandwidth, and low-latency interfaces. These conflicting requirements pose challenges to the development of high-performance chips.

[0260] The examples described in this article provide techniques for decomposing the architecture of a system-on-a-chip (SoC) integrated circuit into multiple different chiplets that can be packaged into a common chassis. In some examples, a graphics processing unit or parallel processor consists of various silicon chiplets manufactured separately. A chiplet is an integrated circuit that is at least partially packaged and includes different logic units that can be assembled with other chiplets into a larger package. A different set of chiplets with different IP core logic can be assembled into a single device. Furthermore, chiplets can be integrated into a base die or base chiplet using active interposer techniques. The concepts described in this article enable interconnection and communication between different forms of IP within a GPU. IP development using different processes can be hybrid. This avoids the complexity of aggregating multiple IPs into the same process, especially on large SoCs with multiple IPs.

[0261] Employing multiple process technologies can shorten time-to-market and provide a cost-effective way to create multiple product SKUs. For customers, this means obtaining products that better meet their requirements in a cost-effective and timely manner. Furthermore, decomposed IP is better suited for independent power gating; components not used at a given workload can be powered off, thereby reducing overall power consumption.

[0262] Figure 14 A parallel computing system 1400 is illustrated according to some examples. In some examples, the parallel computing system 1400 includes a parallel processor 1420, which may be a graphics processor or computing accelerator as described herein. The parallel processor 1420 includes a global logic unit 1401, an interface 1402, a thread dispatcher 1403, a media unit 1404, a set of computing units 1405A-1405H, and a cache / memory unit 1406. In some examples, the global logic unit 1401 includes global functions of the parallel processor 1420, including device configuration registers, a global scheduler, power management logic, etc. The interface 1402 may include a front-end interface for the parallel processor 1420. The thread dispatcher 1403 may receive workloads from the interface 1402 and dispatch threads of the workloads to the computing units 1405A-1405H. If the workload includes any media operations, at least a portion of these operations may be performed by the media unit 1404. The media unit can also offload some operations to computing units 1405A-1405H. Cache / memory unit 1406 may include cache (e.g., L3 cache) and local memory (e.g., HBM, GDDR) for parallel processor 1420.

[0263] Figures 15A-15B A hybrid logical / physical view of a decomposed parallel processor, based on the example described herein, is shown. Figure 15A The decomposed parallel computing system 1500 is shown. Figure 15BThe chip 1530 of the decomposed parallel computing system 1500 is shown.

[0264] like Figure 15A As shown, the decomposed computing system 1500 may include a parallel processor 1520, wherein various components of the parallel processor SOC are distributed across multiple chiplets. Each chiplet can be an independently designed and configured individual IP core that communicates with other chiplets through one or more common interfaces. Chipslets include, but are not limited to, a computing chiplet 1505, a media chiplet 1504, and a memory chiplet 1506. Each chiplet can be manufactured individually using different process technologies. For example, the computing chiplet 1505 may be manufactured using the smallest or most advanced process technology available at the time of manufacture, while the memory chiplet 1506 or other chiplets (e.g., I / O, networking, etc.) may be manufactured using a larger or less advanced process technology.

[0265] Various chiplets can be bonded to the base die 1510 and configured to communicate with each other and with logic within the base die 1510 via interconnect layer 1512. In some examples, the base die 1510 may include global logic 1501, which may include a scheduler 1511 and power management logic unit 1521, interface 1502, dispatch unit 1503, and interconnect structure module 1508 coupled to or integrated with one or more L3 cache libraries 1509A-1509N. The interconnect structure 1508 may be an inter-chiplet structure integrated into the base die 1510. Logic chiplets can use structure 1508 to relay messages between various chiplets. Furthermore, the L3 cache libraries 1509A-1509N in the base die and / or the L3 cache library within the memory chiplet 1506 can cache data read from and sent to the DRAM chiplets and the host's system memory within the memory chiplet 1506.

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

[0267] The various chiplets of the parallel processor 1520 can be designed to perform specific functions, which in existing designs would be integrated into a single die. A group of computing chiplets 1505 may include a cluster of computing units (e.g., execution units, streaming multiprocessors, etc.) that include programmable logic for performing computations or graphics shader instructions. The media chiplet 1504 may include hardware logic to accelerate media encoding and decoding operations. The memory chiplet 1506 may include volatile memory (e.g., DRAM) and one or more SRAM cache banks (e.g., L3 memory).

[0268] like Figure 15B As shown, each chiplet 1530 may include general-purpose and special-purpose components. Chiplet logic 1536 within chiplet 1530 may include chiplet-specific components, such as an array of streaming multiprocessors, compute units, or execution units as described herein. Chiplet logic 1536 may be coupled to, or may include within, an optional cache or shared local memory 1538. Chiplet 1530 may include a structure interconnect node 1542 that receives commands via an inter-chiplet structure. Commands and data received via the structure interconnect node 1542 may be temporarily stored in an interconnect buffer 1539. Data sent to and received from the structure interconnect node 1542 may be stored in the interconnect cache 1540. Power control 1532 and clock control 1534 logic may also be included within the chiplet. Power control 1532 and clock control 1534 logic may receive configuration commands via the structure, configuring dynamic voltage and frequency scaling for chiplet 1530. In some examples, each chiplet can have its own independent clock and power domains and can be clock-gated and power-gated independently of other chipslets.

[0269] At least some components within the small chip 1530 shown may also be included in the embedded... Figure 15A The logic within the base die 1510. For example, the logic within the base die that communicates with the structure may include a version of the structure interconnect node 1542. The base die logic, which can be independently clocked or power-gated, may include versions of the power control 1532 and / or clock control 1534 logic.

[0270] Therefore, while the various examples described herein use the term SOC to describe a device or system having a processor and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, memory circuitry, etc.) monolithically integrated into a single integrated circuit (“IC”) die or chip, this disclosure is not limited in this respect. For example, in various examples of this disclosure, a device or system may have one or more processors (e.g., one or more processor cores) and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, etc.) arranged in discrete dies, tiles, and / or chiplets (e.g., a set of discrete processor core dies arranged adjacent to one or more other dies (such as memory dies, I / O dies, etc.). In such decomposed devices and systems, the various dies, tiles, and / or chiplets may be physically and electrically coupled together by a package structure including, for example, various package substrates, interposers, active interposers, photonic interposers, interconnect bridges, etc. The categorized set of discrete chips, tiles, and / or chiplets may also be part of a system-in-package (“SoP”).

[0271] Example core architecture—ordered and out-of-order core block diagram.

[0272] Figure 16A This is a block diagram illustrating both example ordered pipelines and example register renaming, out-of-order issue / execution pipelines based on some examples. Figure 16B It is a block diagram illustrating both the example ordered architecture core and the example register renaming, out-of-order issuance / execution architecture core that will be included in the processor according to the example. Figures 16A-16B The solid boxes in the diagram illustrate ordered pipelines and ordered cores, while the optional dashed boxes illustrate register renaming, out-of-order issue / execution pipelines, and cores. Since ordered aspects are a subset of out-of-order aspects, out-of-order aspects will be described.

[0273] exist Figure 16AIn this processor pipeline, 1600 includes a fetch phase 1602, an optional length-decoding phase 1604, a decoding phase 1606, an optional alloc phase 1608, an optional rename phase 1610, a scheduling (also known as dispatch or issue) phase 1612, an optional register read / memory read phase 1614, an execution phase 1616, a write-back / memory write phase 1618, an optional exception handling phase 1622, and an optional commit phase 1624. One or more operations can be performed in each of these processor pipeline phases. For example, during the fetch phase 1602, one or more instructions are fetched from instruction memory, and during the decoding phase 1606, the fetched instructions can be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) can be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) can be performed. In some examples, the decoding phase 1606 and the register read / memory read phase 1614 can be combined into a single pipeline phase. In some examples, during execution phase 1616, decoded instructions can be executed, LSU address / data pipelined to the Advanced Microcontroller Bus (AMB) interface can be executed, multiplication and addition operations can be performed, arithmetic operations with branch results can be performed, and so on.

[0274] As an example, Figure 16B The example register renaming, out-of-order issue / execution architecture core can implement pipeline 1600 in the following ways: 1) Instruction fetch circuit 1638 performs fetch and length decoding stages 1602 and 1604; 2) Decoding circuit 1640 performs decoding stage 1606; 3) Rename / allocator unit circuit 1652 performs allocation stage 1608 and rename stage 1610; 4) (one or more) scheduler circuit 1656 performs scheduling stage 1612; 5) (one or more) physical register file circuit 1658 and memory unit circuit 1670 perform register read / memory read stage 1614; (one or more) execution cluster 1660 performs execution stage 1616; 6) memory unit circuit 1670 and (one or more) physical register file circuit 1658 perform write-back / memory write stage 1618; 7) Various circuits may be involved in exception handling stage 1622; and 8) retirement unit circuit 1654 and (one or more) physical register file circuit 1658 perform commit stage 1624.

[0275] Figure 16BThe processor core 1690 is shown to include a front-end unit circuitry 1630 coupled to the execution engine unit circuitry 1650, and both are coupled to the memory unit circuitry 1670. The core 1690 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. Alternatively, the core 1690 can be a dedicated 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 so on.

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

[0277] The execution engine circuitry 1650 includes a renaming / allocator unit circuitry 1652, which is coupled to a retirement unit circuitry 1654 and a set of one or more scheduler circuits 1656. The scheduler circuits 1656 represent any number of different schedulers, including reservation stations, central instruction windows, etc. In some examples, the scheduler circuits 1656 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, etc. The scheduler circuits 1656 are coupled to one or more physical register file circuits 1658. Each of the physical register file circuits 1658 represents one or more physical register files, which store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer, i.e., the address of the next instruction to be executed), etc. In some examples, one or more physical register file circuits 1658 include vector register cell circuits, write mask register cell circuits, and scalar register cell circuits. These register cells can provide architectural vector registers, vector mask registers, general-purpose registers, etc. One or more physical register file circuits 1658 are coupled to retirement cell circuits 1654 (also called retirement queues) to demonstrate various ways that can be used to implement register renaming and out-of-order execution (e.g., using one or more reorder buffers (ROBs) and one or more retirement register files; using one or more future heaps, one or more history buffers, and one or more retirement register files; using register maps and register pools; etc.). Retirement cell circuits 1654 and one or more physical register file circuits 1658 are coupled to one or more execution clusters 1660. One or more execution clusters 1660 include a set of one or more execution cell circuits 1662 and a set of one or more memory access circuits 1664. One or more execution unit circuits 1662 can perform various arithmetic, logical, floating-point, or other types of operations (e.g., shift, addition, subtraction, multiplication) on various types of data (e.g., scalar integers, scalar floating-points, compressed integers, compressed floating-points, vector integers, vector floating-points). 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 perform all functions.One or more scheduler circuits 1656, one or more physical register file circuits 1658, and one or more execution clusters 1660 are shown as potentially multiple, because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines, each with its own scheduler circuitry, one or more physical register file circuits, and / or execution clusters—and in the case of separate memory access pipelines, in some examples of implementations only the execution cluster of that pipeline has one or more memory access unit circuits 1664). It should also be understood that, in the case of using separate pipelines, one or more of these pipelines may be issued / executed out of order, while the rest are ordered.

[0278] In some examples, the execution engine unit circuit 1650 can perform load memory unit (LSU) address / data pipelined operations to the Advanced Microcontroller Bus (AMB) interface (not shown), as well as address phases and write-back, data phase load, store, and branch.

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

[0280] Core 1690 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions added with later versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions, such as NEON)) that include the instructions(s) described herein. In some examples, Core 1690 includes logic supporting compressed data instruction set architecture extensions (e.g., AVX1, AVX2), thereby allowing the use of compressed data to perform operations used by many multimedia applications.

[0281] Example (one or more) execution unit circuits.

[0282] Figure 17 Examples of one or more execution unit circuits are shown, such as Figure 16B The execution unit circuit(s) 1662(s) may include one or more ALU circuits 1701, optional vector / single-instruction multiple-data (SIMD) circuits 1703, load / store circuits 1705, branch / jump circuits 1707, and / or floating-point unit (FPU) circuits 1709. ALU circuits 1701 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1703 perform vector / SIMD operations on compressed data (such as SIMD / vector registers). Load / store circuits 1705 execute load and store instructions to load data from memory into registers or store data from registers into memory. Load / store circuits 1705 may also generate addresses. Branch / jump circuits 1707 cause a branch or jump to a memory address depending on the instruction. FPU circuits 1709 perform floating-point arithmetic. The width of the (one or more) execution unit circuits 1662 varies depending on the example and can range from, for example, 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).

[0283] Example register architecture.

[0284] Figure 18This is a block diagram of register architecture 1800 based on some examples. As shown, register architecture 1800 includes vector / SIMD registers 1810, whose widths range from 128 bits to 1024 bits. In some examples, vector / SIMD registers 1810 are physically 512 bits, and depending on the mapping, only some low-order bits are used. For example, in some examples, vector / SIMD registers 1810 are 512-bit ZMM registers: the lower 256 bits are used for the YMM register, and the lower 128 bits are used for the XMM register. Therefore, register overriding exists. In some examples, the vector length field is chosen between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the previous one. Scalar operations are performed on the lowest-order data element positions in the ZMM / YMM / XMM registers; higher-order data element positions are either preserved as they were before the instruction or zeroed out, depending on the example.

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

[0286] The register architecture 1800 includes several general-purpose registers 1825. These registers can be 16-bit, 32-bit, 64-bit, etc., and can 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 through R15.

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

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

[0289] Segment register 1820 contains segment points used to access memory. In some examples, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0290] Model-specific registers (MSRs) 1835 control and report processor performance. Most MSRs 1835 handle system-related functions and are inaccessible to applications. For example, an MSR may provide control over 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 function / mode support. The machine check register 1860 consists of control, status, and error reporting MSRs for detecting and reporting hardware errors. One or more control registers 1855 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 970, 980, 938, 915, and / or 1000) and the characteristics of the currently executing task. In some examples, the MSR 1835 is a subset of the control registers 1855.

[0291] One or more instruction pointer registers 1830 store instruction pointer values. Debug register 1850 controls and allows monitoring of debug operations on the processor or core.

[0292] The memory management register 1865 specifies the location of data structures used in protected-mode memory management. These registers may include the global descriptor table register (GDTR), the interrupt descriptor table register (IDTR), the task register, and the local descriptor table register (LDTR).

[0293] Alternative examples may use wider or narrower registers. Furthermore, alternative examples may use more, fewer, or different register files and registers. Register architecture 1800 may be used, for example, in register file / memory 608, or in one or more physical register file circuits 1658.

[0294] Instruction set architecture.

[0295] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) to specify the operation to be performed (e.g., opcode) and the operand(s) to be performed on that operation, and / or other data fields(e.g., mask), and so on. Some instruction formats are further decomposed through the definition of instruction templates (or subformats). For example, an instruction template for a given instruction format may be defined as having different subsets of the fields of that instruction format (the included fields are usually in the same order, but at least some have different bit positions, since fewer fields are included) and / or may be defined as having given fields interpreted in different ways. Thus, each instruction in an ISA is expressed using a given instruction format (and, if defined, as a given instruction template within the instruction templates of that instruction format) and includes fields for specifying the operation and operands. For example, the sample ADD instruction has a specific opcode and instruction format, which includes an opcode field to specify the opcode and an operand field to select operands (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 operands. Furthermore, although the following description is made in the context of an x86 ISA, it is within the knowledge of those skilled in the art to apply the teachings of this disclosure to other ISAs.

[0296] Example instruction format.

[0297] Examples of the instructions(s) described herein can be implemented in different formats. Furthermore, example systems, architectures, and pipelines are detailed below. The examples of the instructions(s) can be executed on these systems, architectures, and pipelines, but are not limited to those detailed herein.

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

[0299] One or more prefix fields of 1901 modify the instruction when used. In some examples, one or more prefixes are used for repeating string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), providing section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), performing bus locking operations, and / or changing operands (e.g., 0x66) and address size (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered "traditional" prefixes. Other prefixes (one or more examples of which are detailed herein) indicate and / or provide further capabilities, such as specifying particular registers, etc. These other prefixes typically follow "traditional" prefixes.

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

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

[0302] The contents of MOD field 2042 distinguish between memory access mode and non-memory access mode. In some examples, when MOD field 2042 has a binary value of 11 (11b), register direct addressing mode is used; otherwise, register indirect addressing mode is used.

[0303] Register field 2044 can encode either the destination register operand or the source register operand, or it can encode an opcode extension without being used to encode any instruction operand. The contents of register field 2044 directly specify or are generated from an address to specify the location of the source or destination operand (in a register or in memory). In some examples, register field 2044 is supplemented with extra bits from a prefix (e.g., prefix 1901) to allow for larger addressing.

[0304] R / M field 2046 can be used to encode instruction operands that reference memory addresses, or it can be used to encode destination register operands or source register operands. Note that in some examples, R / M field 2046 can be combined with MOD field 2042 to specify the addressing mode.

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

[0306] Some addressing schemes use bitwise shift values ​​to generate memory addresses. For example, they can be based on 2 缩放 Memory addresses are generated using methods such as *index + base address + offset, index *scaling + offset, r / m + offset, instruction pointer (RIP / EIP) + offset, register + offset, etc. The offset can be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the offset field 1907 provides this value. Furthermore, in some examples, the use of an offset factor is encoded in the MOD field of the addressing information field 1905, which indicates a compact offset scheme for which the offset value is calculated and stored in the offset field 1907.

[0307] In some examples, the immediate value field 1909 specifies an immediate value for the instruction. Immediate values ​​can be encoded as 1-byte values, 2-byte values, 4-byte values, and so on.

[0308] Figure 21 An example of the first prefix 1901(A) is shown. In some examples, the first prefix 1901(A) is an example of the REX prefix. Instructions using this prefix can specify general-purpose registers, 64-bit compact data registers (e.g., single-instruction multiple-data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0309] Instructions using the first prefix 1901(A) can specify up to three registers using 3-bit fields, depending on the format: 1) using reg field 2044 and R / M field 2046 of MOD R / M byte 2002; 2) using MOD R / M byte 2002 with SIB byte 2004, including using reg field 2044 as well as base field 2056 and index field 2054; or 3) using the register field of the opcode.

[0310] In the first prefix 1901(A), bits 7:4 of the payload byte are set to 0100. Bit 3(W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), while when W=1, the operand size is 64 bits.

[0311] Note that adding another bit allows for 16(2) 4 It can address 8 registers, while the individual MOD R / M reg field 2044 and MOD R / M R / M field 2046 can each address 8 registers.

[0312] In the first prefix 1901(A), bit position 2(R) can be an extension of the MOD R / M reg field 2044, and can be used to modify the MOD R / M reg field 2044 when this field encodes a general-purpose register, a 64-bit compressed data register (e.g., the SSE register), or a control or debug register. R is ignored when MOD R / M byte 2002 specifies other registers or defines extended opcodes.

[0313] Bit position 1 (X) can modify SIB byte index field 2054.

[0314] Setting bit position 0 (B) can modify the base address in the R / M field 2046 or the SIB byte base address field 2056 of MOD R / M; or it can modify the opcode register field used to access general-purpose registers (e.g., general-purpose register 1825).

[0315] Figures 22A-22D An example of how to use the R, X, and B fields of the first prefix 1901(A) is shown. Figure 22A It is shown that when SIB byte 2004 is not used for memory addressing, R and B from the first prefix 1901(A) are used to extend the reg field 2044 and R / M field 2046 of MOD R / M byte 2002. Figure 22B It is shown that when SIB byte 2004 is not used, R and B from the first prefix 1901(A) are used to extend the reg field 2044 and R / M field 2046 (register-to-register addressing) of MOD R / M byte 2002. Figure 22C It is shown that when SIB byte 2004 is used for memory addressing, R, X, and B from the first prefix 1901(A) are used for the reg field 2044, index field 2054, and base address field 2056 of the extended MOD R / M byte 2002. Figure 22D It is shown that when the register is encoded in opcode 1903, the B from the first prefix 1901(A) is used to extend the reg field 2044 of MODR / M byte 2002.

[0316] Figures 23A-23BAn example of the second prefix 1901(B) is shown. In some examples, the second prefix 1901(B) is an example of the VEX prefix. The second prefix 1901(B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD register 1810) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1901(B) provides a syntax for three (or more) operands. For example, the previous two-operand instructions performed operations such as A = A + B, which overwrote the source operands. The use of the second prefix 1901(B) allows operands to perform non-destructive operations, such as A = B + C.

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

[0318] Figure 23A An example of the two-byte form of the second prefix 1901(B) is shown. In some examples, format field 2301 (byte 0 2303) contains the value C5H. In some examples, byte 1 2305 includes the value “R” in bit [7]. This value is the complement of the value of “R” in the first prefix 1901(A). Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or a 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensions equivalent to some conventional prefixes (e.g., 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H). The bits [6:3] shown as vvvv can be used to: 1) encode the first source register operand, which is specified in reverse (one's complement) form and is valid for instructions with two or more source operands; 2) encode the destination register operand, which is specified in 1s complement form for certain vector shifts; or 3) not encode any operand, in which case the field is reserved and should contain a value such as 1111b.

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

[0320] Instructions using this prefix can use the MOD R / M reg field 2044 to encode either the destination register operand or the source register operand, or be treated as an opcode extension without being used to encode any instruction operand.

[0321] For instruction syntax that supports four operands, vvvv, MOD R / MR / M field 2046, and MOD R / M reg field 2044 encode three of the four operands. Then bits [7:4] of the immediate value field 1909 are used to encode the third source register operand.

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

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

[0324] Instructions using this prefix can use the R / M field 2046 of MOD R / M to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0325] Instructions using this prefix can use the reg field 2044 of MOD R / M to encode either the destination register operand or the source register operand, or be treated as an opcode extension without being used to encode any instruction operand.

[0326] For instruction syntax that supports four operands, vvvv, the R / M field 2046 of MOD R / M, and the reg field 2044 of MOD R / M encode three of the four operands. Then bits [7:4] of the immediate value field 1909 are used to encode the third source register operand.

[0327] Figure 24 An example of the third prefix 1901(C) is shown. In some examples, the third prefix 1901(C) is an example of the EVEX prefix. The third prefix 1901(C) is a four-byte prefix.

[0328] The third prefix 1901(C) enables the encoding of 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks are used (see the discussion of registers in the previous diagrams, e.g.) Figure 18 Instructions that use predicates or operands utilize this prefix. Operation mask registers allow conditional processing or selection control. Operation mask instructions—whose source / destination operands are operation mask registers and whose contents are treated as a single value—are encoded using the second prefix 1901(B).

[0329] The third prefix 1901(C) can encode instruction class-specific features (e.g., a compact instruction with "load + operation" semantics can support embedded broadcast functionality, a floating-point instruction with rounding semantics can support static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics can support "suppress all exceptions" functionality, and so on).

[0330] The first byte of the third prefix 1901(C) is the format field 2411, which has a value of 62H in some examples. The subsequent bytes are referred to as payload bytes 2415-2419, and together they form the 24-bit value of P[23:0], which provides specific capabilities in the form of one or more fields (detailed herein).

[0331] In some examples, P[1:0] of payload byte 2419 is the same as the two lower mm bits. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the high 16 vector register set when combined with P[7] and MOD R / M's reg field 2044. P[6] can also provide access to the high 16 vector registers when SIB type addressing is not required. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general purpose registers, and memory addressing, and when combined with MOD R / M's register field 2044 and MOD R / M's R / M field 2046, allows access to the next set of 8 registers beyond the lower 8 registers. P[9:8] provides opcode extensions equivalent to some conventional prefixes (e.g., 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H). P

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

[0332] P

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

[0333] P[18:16] specifies the index of the register in the operation mask (write mask) register (e.g., write mask / predicate register 1815). In some examples, the specific value aaa = 000 has special behavior, implying that no operation mask is used for this particular instruction (this can be achieved in various ways, including using a hard-wired operation mask to all one or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in other examples, the old value of each element in the destination is preserved (if the corresponding mask bit has a value of 0). Conversely, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic and enhanced operations); in some examples, the elements in the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span of the modified elements, from the first to the last); however, the modified elements do not necessarily have to be contiguous. Thus, the operation mask field allows for some vector operations, including load, store, arithmetic, logical, and so on. While in the described example, the content of the operation mask field selects the one among several operation mask registers containing the operation mask to be used (thus the content of the operation mask field indirectly identifies the mask to be performed), alternatively or additionally, alternative examples allow the content of the mask write field to directly specify the mask to be performed.

[0334] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that allows access to the high 16 vector registers using P

[19] . P

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

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

[0335] The table below details examples of register encoding in instructions using the third prefix 1901(C).

[0336]

[0337] Table 1: 32 Registers Supported in 64-bit Mode

[0338]

[0339] Table 2: Encoding Register Specify in 32-bit Mode

[0340] Table 3: Operation Mask Register Specifier Encoding

[0341] Graphics Execution Unit

[0342] Figures 25A-25B The example described herein illustrates thread execution logic 2500, which includes an array of processing elements employed in a graphics processor core. Figures 25A-25B Elements that have the same reference numerals (or names) as elements in any other figure herein may operate or function in any manner similar to, but not limited to, those described elsewhere herein. Figure 25A Represents the execution unit within a general-purpose graphics processing unit, while Figure 25B This represents an execution unit that can be used within a computing accelerator.

[0343] like Figure 25A As shown, in some examples, the thread execution logic 2500 includes a shader processor 2502, a thread dispatcher 2504, an instruction cache 2506, a scalable execution unit array including multiple execution units 2508A-2508N, a sampler 2510, shared local memory 2511, a data cache 2512, and a data port 2514. In some examples, the scalable execution unit array can be dynamically expanded by enabling or disabling one or more execution units (e.g., any one of execution units 2508A, 2508B, 2508C, 2508D through 2508N-1, and 2508N) based on workload computational requirements. In some examples, the included components are interconnected via an interconnect structure linking each component. In some examples, the thread execution logic 2500 includes one or more connections to memory (such as system memory or cache) via one or more of the instruction cache 2506, data port 2514, sampler 2510, and execution units 2508A-2508N. In some examples, each execution unit (e.g., 2508A) is an independent programmable general-purpose computing unit capable of executing multiple concurrent hardware threads, processing multiple data elements in parallel for each thread. In various examples, the array of execution units 2508A-2508N can be expanded to include any number of individual execution units.

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

[0345] In some examples, the execution units 2508A-2508N support an instruction set that includes native support for many standard 3D graphics shader instructions, enabling shader programs from graphics libraries (e.g., Direct3D and OpenGL) to execute with minimal translation. The execution units support vertex and geometry processing (e.g., vertex programs, geometry programs, vertex shaders), pixel processing (e.g., pixel shaders, fragment shaders), and general processing (e.g., computation and media shaders). Each execution unit in the 2508A-2508N is capable of multi-issue single-instruction multiple-data (SIMD) execution, and multithreaded operations provide an efficient execution environment when faced with higher latency memory accesses. Each hardware thread within each execution unit has a dedicated high-bandwidth register file and associated independent thread state. Execution is a series of multiple issues issued per clock cycle to a pipeline capable of integer, single-precision and double-precision floating-point operations, SIMD branching capabilities, logical operations, transcendental operations, and other miscellaneous operations. While waiting for data from memory or a shared function, the dependency logic within the execution units 2508A-2508N causes the waiting thread to sleep until the requested data is returned. While the waiting thread is sleeping, hardware resources may be dedicated to processing other threads. For example, during the latency associated with vertex shader operations, the execution unit may execute operations of the pixel shader, fragment shader, or another type of shader program (including different vertex shaders). Various examples can be applied to using execution with Single Instruction Multiple Thread (SIMT) as an alternative to or supplement to using SIMD. References to SIMD cores or operations can also be applied to SIMD or in combination with SIMD.

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

[0347] 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 these elements according to their data size. For example, when operating on a 256-bit wide vector, with the 256 bits of the vector stored in a register, the execution unit will operate on the vector as four separate 64-bit compact data elements (four-word (QW) size data elements), eight separate 32-bit compact data elements (double-word (DW) size data elements), sixteen separate 16-bit compact packet data elements (word (W) size data elements), or thirty-two separate 8-bit data elements (byte (B) size elements). However, different vector widths and register sizes are possible.

[0348] In some examples, one or more execution units can be combined into fused execution units 2509A-2509N, which have thread control logic (2507A-2507N) shared by the fused EUs. Multiple EUs can be fused into EU groups. Each EU in a fused EU group can be configured to execute a separate SIMD hardware thread. The number of EUs in a fused EU group may vary depending on the example. Furthermore, each EU can execute various SIMD widths, including but not limited to SIMD8, SIMD16, and SIMD32. Each fused graphics execution unit 2509A-2509N includes at least two execution units. For example, fused execution unit 2509A includes a first EU 2508A, a second EU 2508B, and thread control logic 2507A, which is shared by the first EU 2508A and the second EU 2508B. The thread control logic 2507A controls the threads executing on the fused graphics execution unit 2509A, allowing each EU within the fused execution units 2509A-2509N to execute using a common instruction pointer register.

[0349] The thread execution logic 2500 includes one or more internal instruction caches (e.g., 2506) to cache thread instructions for the execution unit. In some examples, one or more data caches (e.g., 2512) are included to cache thread data during thread execution. Threads executing on the execution logic 2500 may also store explicitly managed data in shared local memory 2511. In some examples, a sampler 2510 is included to provide texture sampling for 3D operations and media sampling for media operations. In some examples, the sampler 2510 includes dedicated texture or media sampling functions to process texture or media data during the sampling process before providing sampled data to the execution unit.

[0350] During execution, the graphics and media pipeline sends thread start requests to thread execution logic 2500 via thread generation and dispatch logic. Once a set of geometric objects has been processed and rasterized into pixel data, pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within shader processor 2502 is invoked to further compute output information and write the results to output surfaces (e.g., color buffer, depth buffer, stencil buffer, etc.). In some examples, the pixel shader or fragment shader computes values ​​of various vertex attributes to be interpolated onto the rasterized objects. In some examples, the pixel processor logic within shader processor 2502 then executes the pixel or fragment shader program provided by the application programming interface (API). To execute the shader program, shader processor 2502 dispatches threads to execution units (e.g., 2508A) via thread scheduler 2504. In some examples, shader processor 2502 uses texture sampling logic in sampler 2510 to access texture data in a texture map stored in memory. Arithmetic operations on texture data and input geometry data can be used to calculate pixel color data for each geometric fragment, or to discard one or more pixels from further processing.

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

[0352] In some examples, execution logic 2500 may also include a ray tracer 2505 that can provide ray tracing acceleration capabilities. Ray tracer 2505 may support a ray tracing instruction set that includes instructions / functions for ray generation.

[0353] Figure 25B Exemplary internal details of an execution unit 2508 according to an example are shown. The graphics execution unit 2508 may include an instruction fetch unit 2537, a general register file array (GRF) 2524, an architectural register file array (ARF) 2526, a thread arbiter 2522, a send unit 2530, a branch unit 2532, a set of SIMD floating-point units (FPUs) 2534, and in some examples, a set of dedicated integer SIMD ALUs 2535. The GRF 2524 and ARF 2526 comprise collections of general register files and architectural register files associated with each concurrent hardware thread that may be active in the graphics execution unit 2508. In some examples, the architectural state of each thread is maintained in the ARF 2526, while data used during thread execution is stored in the GRF 2524. The execution state of each thread, including the instruction pointer for each thread, may be stored in thread-specific registers in the ARF 2526.

[0354] In some examples, the graphics execution unit 2508 features a combined architecture of simultaneous multi-threading (SMT) and fine-grained interleaved multi-threading (IMT). This architecture has a modular configuration that can be fine-tuned at design time based on the target number of concurrent threads and registers for each execution unit, where execution unit resources are partitioned logically for executing multiple concurrent threads. The number of logical threads that the graphics execution unit 2508 can execute is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread.

[0355] In some examples, the graphics execution unit 2508 can issue multiple instructions collectively, each of which can be a different instruction. The thread arbiter 2522 of the graphics execution unit thread 2508 can dispatch instructions to one of the sending unit 2530, the branching unit 2532, or one or more SIMD FPUs 2534 for execution. Each execution thread can access 128 general-purpose registers within the GRF 2524, each of which can store 32 bytes, accessible as a SIMD 8-element vector of 32-bit data elements. In some examples, each execution unit thread can access 4KB of data within the GRF 2524, but the examples are not limited to this; more or fewer register resources may be provided in other examples. In some examples, the graphics execution unit 2508 is divided into seven hardware threads capable of independently performing computational operations, although the number of threads per execution unit can vary depending on the example. For example, in some examples, up to 16 hardware threads are supported. In the example where seven threads can access 4KB of data, the GRF 2524 can store a total of 28KB of data. With 16 threads able to access 4KB, the GRF 2524 can store a total of 64KB. Its flexible addressing modes allow registers to be addressed together, enabling the efficient construction of wider registers or representations of straddle-shaped block data structures.

[0356] In some examples, memory operations, sampler operations, and other longer-latency system communications are dispatched via "send" instructions executed by message passing unit 2530. In some examples, branch instructions are dispatched to dedicated branch unit 2532 to facilitate SIMD divergence and eventual convergence.

[0357] In some examples, the graphics execution unit 2508 includes one or more SIMD floating-point units (FPUs) 2534 to perform floating-point operations. In some examples, the FPU(s) 2534 also support integer computation. In some examples, the FPU(s) 2534 can perform up to M 32-bit floating-point (or integer) operations in SIMD, or up to 2M 16-bit integer or 16-bit floating-point operations in SIMD. In some examples, at least one FPU provides extended mathematical capabilities to support high-throughput transcendental mathematical functions and double-precision 64-bit floating-point operations. In some examples, there is also a set of 8-bit integer SIMD ALUs 2535 that can be specifically optimized to perform operations associated with machine learning computations.

[0358] In some examples, an array of multiple instances of the graphics execution unit 2508 can be instantiated within a graphics sub-core group (e.g., a sub-slice). For scalability, the product architect can choose the exact number of execution units in each sub-core group. In some examples, the execution unit 2508 can execute instructions across multiple execution channels. In another example, each thread executing on the graphics execution unit 2508 executes on a different channel.

[0359] Figure 26 An additional execution unit 2600 according to an example is shown. In some examples, execution unit 2600 includes a thread control unit 2601, a thread state unit 2602, an instruction fetch / prefetch unit 2603, and an instruction decoding unit 2604. Execution unit 2600 also includes a register file 2606 that stores registers that can be assigned to hardware threads within the execution unit. Execution unit 2600 also includes a sending unit 2607 and a branching unit 2608. In some examples, sending unit 2607 and branching unit 2608 can be integrated with... Figure 25B The sending unit 2530 and branching unit 2532 of the graphics execution unit 2508 operate similarly.

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

[0361] The thread control unit 2601 includes logic for controlling the execution of threads within the execution unit. The thread control unit 2601 may include thread arbitration logic to start, stop, and preempt the execution of threads within the execution unit 2600. The thread state unit 2602 can be used to store the thread states of threads assigned to execution on the execution unit 2600. Storing the thread states within the execution unit 2600 allows for rapid preemption of threads when they are blocked or idle. The instruction fetch / prefetch unit 2603 can retrieve instructions from a higher-level execution logic cache (e.g., ...). Figure 25A Instructions are retrieved from the instruction cache 2506 shown. The instruction fetch / prefetch unit 2603 can also issue prefetch requests for instructions to be loaded into the instruction cache based on analysis of the currently executing thread. The instruction decoding unit 2604 can be used to decode instructions to be executed by the computation unit. In some examples, the instruction decoding unit 2604 can be used as a secondary decoder to decode complex instructions into constituent micro-operations.

[0362] The execution unit 2600 also includes a register file 2606, which can be used by hardware threads executing on the execution unit 2600. The registers in the register file 2606 can be partitioned across logic used to execute multiple concurrent threads within the computation unit 2610 of the execution unit 2600. The number of logical threads that the graphics execution unit 2600 can execute 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 2606 can vary in different examples depending on the number of supported hardware threads. In some examples, register renaming can be used to dynamically allocate registers to hardware threads.

[0363] Figure 27 This is a block diagram illustrating a graphics processor instruction format 2700 according to some examples. In one or more examples, the graphics processor execution unit supports an instruction set with multiple instruction formats. Solid-line boxes show components that are typically included in the execution unit instructions, while dashed lines include optional components or components that are only included in a subset of the instructions. In some examples, the instruction format 2700 described and shown are macro instructions because they are instructions supplied to the execution unit, rather than micro-operations generated by instruction decoding after instruction processing.

[0364] In some examples, the graphics processor execution unit natively supports instructions in 128-bit instruction format 2710. A 64-bit compact instruction format 2730 is available for some instructions, depending on the selected instruction, instruction options, and the number of operands. The native 128-bit instruction format 2710 provides access to all instruction options, while some options and operations are restricted to the 64-bit format 2730. The native instructions available in the 64-bit format 2730 vary by example. In some examples, instructions are partially compacted using a set of index values ​​in the index field 2713. The execution unit hardware references a set of compact tables based on the index values ​​and reconstructs the native instruction in 128-bit instruction format 2710 using the compact table output. Instructions of other sizes and formats can be used.

[0365] For each format, instruction opcode 2712 defines the operation to be performed by the execution unit. The execution unit executes each instruction in parallel on multiple data elements of each operand. For example, in response to an add instruction, the execution unit performs a simultaneous add operation on each color channel representing a texture element or picture element. By default, the execution unit executes each instruction on all data channels of the operand. In some examples, instruction control field 2714 enables control over certain execution options, such as channel selection (e.g., assertion) and data channel order (e.g., reordering). For instructions in 128-bit instruction format 2710, exec size field 2716 limits the number of data channels that will be executed in parallel. In some examples, exec size field 2716 is not available for 64-bit compact instruction format 2730.

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

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

[0368] In some examples, the 128-bit instruction format 2710 includes an access / addressing mode field 2726, 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 of the instruction. Some examples support access modes, including 16-byte aligned access modes and 1-byte aligned access modes, where the byte alignment of the access mode determines the access alignment of the instruction operands. For example, in the first mode, the instruction can use byte-aligned addressing for both source and destination operands, while in the second mode, the instruction can use 16-byte aligned addressing for all source and destination operands.

[0369] In some examples, the addressing mode portion of the access / addressing mode field 2726 determines whether the instruction uses direct or indirect addressing. When using direct register addressing mode, the bits in the instruction directly provide the register addresses of one or more operands. When using indirect register addressing mode, the register addresses of one or more operands can be calculated from the address register value and the address immediate field in the instruction.

[0370] In some examples, instructions are grouped based on the opcode 2712-bit field to simplify opcode decoding 2740. For 8-bit opcodes, bits 4, 5, and 6 allow the execution unit to determine the type of opcode. The precise opcode groupings shown are merely examples. In some examples, move and logic opcode group 2742 includes data move and logic instructions (e.g., move (mov), compare (cmp)). In some examples, move and logic group 2742 shares five most significant bits (MSB), where move (mov) instructions are in the form of 0000xxxxb and logic instructions are in the form of 0001xxxxb. Flow control instruction group 2744 (e.g., call, jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). Miscellaneous instruction group 2746 includes a mixture of instructions, including synchronization instructions in the form of 0011xxxxb (e.g., wait, send). Parallel math instruction group 2748 includes component-wise arithmetic instructions (e.g., addition, multiplication (mul)) in the form of 0100xxxxb (e.g., 0x40). Parallel math group 2748 performs arithmetic operations in parallel across data channels. Vector math group 2750 includes arithmetic instructions (e.g., dp4) in the form of 0101xxxxb (e.g., 0x50). Vector math group performs arithmetic operations on vector operands, such as dot product calculations. In some examples, the opcode decoder 2740 shown can be used to determine which part of the execution unit will be used to execute the decoded instructions. For example, some instructions can be specified as systolic instructions executed by a systolic array. Other instructions, such as ray tracing instructions (not shown), can be routed to ray tracing cores or ray tracing logic within slices or partitions of the execution logic.

[0371] Graphical Pipes

[0372] Figure 28 This is a block diagram of another example of a graphics processor 2800. Elements having the same reference numerals (or names) as any other element in this document... Figure 28 The components may operate or function in any manner similar to that described elsewhere in this document, but are not limited thereto.

[0373] In some examples, the graphics processor 2800 includes a geometry pipeline 2820, a media pipeline 2830, a display engine 2840, thread execution logic 2850, and a rendering output pipeline 2870. In some examples, the graphics processor 2800 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 commands written to registers of one or more control registers (not shown) or issued to the graphics processor 2800 via a ring interconnect 2802. In some examples, the ring interconnect 2802 couples the graphics processor 2800 to other processing components, such as other graphics processors or general-purpose processors. Commands from the ring interconnect 2802 are interpreted by a command streamer 2803, which provides instructions to the various components of the geometry pipeline 2820 or the media pipeline 2830.

[0374] In some examples, command streamer 2803 instructs vertex extractor 2805 to read vertex data from memory and execute vertex processing commands provided by command streamer 2803. In some examples, vertex extractor 2805 provides vertex data to vertex shader 2807, which performs coordinate space transformations and lighting operations on each vertex. In some examples, vertex extractor 2805 and vertex shader 2807 execute vertex processing instructions by dispatching execution threads to execution units 2852A-2852B via thread dispatcher 2831.

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

[0376] In some examples, the geometry pipeline 2820 includes tessellation components to perform hardware-accelerated tessellation of 3D objects. In some examples, a programmable shell shader 2811 configures the tessellation operation. A programmable domain shader 2817 provides back-end evaluation of the tessellation output. A tessell 2813 operates in the direction of the shell shader 2811 and contains dedicated logic to generate a set of detailed geometric objects based on a coarse geometric model provided as input to the geometry pipeline 2820. In some examples, the tessellation components (e.g., shell shader 2811, tessell 2813, and domain shader 2817) can be bypassed if tessellation is not used.

[0377] In some examples, the complete geometry object can be processed by the geometry shader 2819 via one or more threads dispatched to execution units 2852A-2852B, or it can directly enter the trimmer 2829. In some examples, the geometry shader operates on the entire geometry object, rather than operating on vertices or vertex patches as in the earlier stages of the graphics pipeline. If tessellation is disabled, the geometry shader 2819 receives input from the vertex shader 2807. In some examples, if tessellation units are disabled, the geometry shader 2819 can be programmed by the geometry shader program to perform geometry tessellation.

[0378] Prior to rasterization, clipper 2829 processes vertex data. Clipper 2829 can be a fixed-function clipper or a programmable clipper with clipping and geometry shader capabilities. In some examples, rasterization and depth testing component 2873 in the render output pipeline 2870 dispatches pixel shaders to convert geometry objects into per-pixel representations. In some examples, pixel shader logic is included in thread execution logic 2850. In some examples, the application can bypass rasterization and depth testing component 2873 and access unrasterized vertex data via streaming output unit 2823.

[0379] The graphics processor 2800 has an interconnect bus, interconnect structure, or other interconnect mechanisms that allow data and messages to be transferred between the processor's main components. In some examples, execution units 2852A-2852B and associated logic units (e.g., L1 cache 2851, sampler 2854, texture cache 2858, etc.) are interconnected via data port 2856 to perform memory accesses and communicate with the processor's rendering output pipeline components. In some examples, sampler 2854, caches 2851, 2858, and execution units 2852A-2852B each have separate memory access paths. In some examples, texture cache 2858 may also be configured as a sampler cache.

[0380] In some examples, the rendering output pipeline 2870 includes a rasterization and depth testing component 2873 that converts vertex-based objects into associated pixel-based representations. In some examples, the rasterization logic includes a windowing / masking unit for performing fixed-function triangle and line rasterization. In some examples, associated rendering caches 2878 and depth caches 2879 are also available. Pixel manipulation component 2877 performs pixel-based operations on the data, although in some cases, pixel operations associated with 2D operations (e.g., image transfers with mixed bit blocks) are performed by the 2D engine 2841, or replaced by the display controller 2843 using an overlay display plane during display. In some examples, a shared L3 cache 2875 is available to all graphics components, allowing data to be shared without using main system memory.

[0381] In some examples, the graphics processor media pipeline 2830 includes a media engine 2837 and a video front-end 2834. In some examples, the video front-end 2834 receives pipeline commands from a command streamer 2803. In some examples, the media pipeline 2830 includes a separate command streamer. In some examples, the video front-end 2834 processes the media command before sending it to the media engine 2837. In some examples, the media engine 2837 includes thread generation functionality to generate threads for dispatch to thread execution logic 2850 via a thread dispatcher 2831.

[0382] In some examples, the graphics processor 2800 includes a display engine 2840. In some examples, the display engine 2840 is external to the processor 2800 and coupled to the graphics processor via a ring interconnect 2802 or some other interconnect bus or structure. In some examples, the display engine 2840 includes a 2D engine 2841 and a display controller 2843. In some examples, the display engine 2840 contains dedicated logic capable of operating independently of the 3D pipeline. In some examples, the display controller 2843 is coupled to a display device (not shown), which may be a system-integrated display device, such as a display device in a laptop computer, or an external display device attached via a display device connector.

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

[0384] Graphics pipeline programming

[0385] Figure 29A This is a block diagram illustrating the graphics processor command format 2900 according to some examples. Figure 29B This is a block diagram illustrating the graphics processor command sequence 2910 according to the example. Figure 29A Solid lines in the diagram indicate components that are typically included in the graphics commands, while dashed lines indicate optional components or components that are only included in a subset of the graphics commands. Figure 29A An exemplary graphics processor command format 2900 includes a data field for identifying a client 2902, a command opcode 2904, and data 2906 for the command. Some commands also include a sub-opcode 2905 and a command size 2908.

[0386] In some examples, client 2902 specifies a client unit of the graphics device that processes command data. In some examples, the graphics processor command parser examines 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, the graphics processor client units include 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 to process the command. Once a client unit receives a command, it reads the opcode 2904 and sub-opcode 2905 (if a sub-opcode exists) to determine the operation to be performed. The client unit executes the command using the information in the data field 2906. For some commands, an explicit command size 2908 is required to specify the command size. In some examples, the command parser automatically determines the size of at least some commands based on the command opcode. In some examples, commands are aligned by multiples of double words. Other command formats may be used.

[0387] Figure 29B The flowchart illustrates an exemplary graphics processor command sequence 2910. In some examples, software or firmware of a data processing system, exemplified by a graphics processor, uses a version of the illustrated command sequence to set up, execute, and terminate a set of graphics operations. Sample command sequences are shown and described for illustrative purposes only, as the examples are not limited to these specific commands or this command sequence. Furthermore, commands may be issued as a batch of commands in a command sequence, such that the graphics processor will process the command sequence at least partially simultaneously.

[0388] In some examples, the graphics processor command sequence 2910 may begin with a pipeline flush command 2912 to cause any active graphics pipeline to complete its currently pending commands. In some examples, the 3D pipeline 2922 and the media pipeline 2924 do not operate simultaneously. A pipeline flush is performed to cause any pending commands in the active graphics pipeline to complete. In response to the pipeline flush, the graphics processor's command resolver suspends command processing until the active graphics engine completes its pending operations and the associated read cache is invalidated. Optionally, any data marked as "dirty" in the renderer cache may be flushed into memory. In some examples, the pipeline flush command 2912 may be used for pipeline synchronization or before placing the graphics processor into a low-power state.

[0389] In some examples, the pipeline selection command 2913 is used when the command sequence requires the graphics processor to explicitly switch between pipelines. In some examples, only one pipeline selection command 2913 is needed in the execution context before issuing pipeline commands, unless the context needs to issue commands for two pipelines. In some examples, the pipeline flushing command 2912 is required before switching pipelines via the pipeline selection command 2913.

[0390] In some examples, pipeline control command 2914 configures the graphics pipeline to operate and is used to program the 3D pipeline 2922 and the media pipeline 2924. In some examples, pipeline control command 2914 configures the pipeline state of the active pipeline. In some examples, pipeline control command 2914 is used for pipeline synchronization and to clear data from one or more caches within the active pipeline before processing a batch of commands.

[0391] In some examples, the Return Buffer Status command 2916 is used to configure a set of return buffers for each pipeline to write data. Some pipeline operations require allocating, selecting, or configuring one or more return buffers, which the operation writes intermediate data to 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 Status 2916 includes selecting the size and number of return buffers for a set of pipeline operations.

[0392] The remaining commands in the command sequence vary depending on the active pipeline used for the operation. Based on pipeline determination 2920, the command sequence is customized for either 3D pipeline 2922 starting from 3D pipeline state 2930 or media pipeline 2924 starting from media pipeline state 2940.

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

[0394] In some examples, the 3D Primitive 2932 command is used to submit 3D primitives to be processed by the 3D pipeline. The commands and associated parameters passed to the graphics processor via the 3D Primitive 2932 command are forwarded to the vertex extraction function in the graphics pipeline. The vertex extraction function uses the 3D Primitive 2932 command data to generate vertex data structures. The vertex data structures are stored in one or more return buffers. In some examples, the 3D Primitive 2932 command is used to perform vertex operations on the 3D primitives via vertex shaders. To process the vertex shaders, the 3D pipeline 2922 dispatches shader execution threads to the graphics processor execution unit.

[0395] In some examples, 3D pipeline 2922 is triggered by executing command 2934 or an event. In some examples, register writes trigger command execution. In some examples, execution is triggered by the "go" or "kick" command in a command sequence. In some examples, command execution is triggered using pipeline synchronization commands to flush the command sequence through the graphics pipeline. The 3D pipeline performs geometric processing on 3D primitives. Once the operations are complete, the resulting geometry is rasterized, and the pixel engine shades the resulting pixels. Additional commands controlling pixel shading and pixel backend operations may also be included for these operations.

[0396] In some examples, the graphics processor command sequence 2910 follows the media pipeline 2924 path when performing media operations. Generally, the specific use and programming of the media pipeline 2924 depends on the media or computational operation to be performed. During media decoding, specific media decoding operations can be offloaded to the media pipeline. In some examples, the media pipeline can also be bypassed, and media decoding can be performed wholly or partially using resources provided by one or more general-purpose processing cores. In some examples, the media pipeline also includes elements for general-purpose graphics processor unit (GPGPU) operations, where the graphics processor performs SIMD vector operations using computational shader programs that are not explicitly related to the rendering of graphics primitives.

[0397] In some examples, media pipeline 2924 is configured in a similar manner to 3D pipeline 2922. Prior to media object command 2942, a set of commands for configuring media pipeline state 2940 is dispatched or placed in a command queue. In some examples, the commands for media pipeline state 2940 include data for configuring media pipeline elements that will be used to process media objects. This includes data for configuring video decoding and video encoding logic within the media pipeline, such as encoding or decoding formats. In some examples, the commands for media pipeline state 2940 also support the use of one or more pointers to "indirect" state elements containing a batch of state settings.

[0398] In some examples, media object command 2942 provides a pointer to a media object for processing by the media pipeline. The media object includes a memory buffer containing the video data to be processed. In some examples, all media pipeline states must be valid before media object command 2942 is issued. Once the pipeline states are configured and media object command 2942 is queued, media pipeline 2924 is triggered by executing command 2944 or an equivalent execution event (e.g., register write). The output from media pipeline 2924 can then be post-processed using 3D pipeline 2922 or operations provided by media pipeline 2922. In some examples, GPGPU operations are configured and executed in a similar manner to media operations.

[0399] 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 purposes of this application, the processing system includes any system having a processor, such as a digital signal processor (DSP), microcontroller, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), microprocessor, or any combination thereof.

[0400] The program code can be implemented in a high-level procedural or object-oriented programming language to communicate with the processing system. If necessary, the program code can also be implemented in assembly language or machine language. In fact, the mechanisms described herein are not limited to any particular programming language. In any case, the language can be a compiled or interpreted language.

[0401] Examples of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of these implementation methods. Examples can be implemented as computer programs or program code that execute on a programmable system, which includes 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.

[0402] Such machine-readable storage media can include, but is not limited to, non-transient tangible arrangements of articles made 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 such as 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.

[0403] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or design data that defines the features of the structures, circuits, devices, processors, and / or systems described herein, such as Hardware Description Language (HDL). Such examples may also be referred to as program products.

[0404] Simulation (including binary translation, code transformation, etc.).

[0405] In some cases, instruction translators can be used to translate instructions from a source instruction set architecture to a target instruction set architecture. For example, an instruction translator can translate (e.g., using static binary translation, including dynamic binary translation with dynamic compilation), transform, emulate, or otherwise translate instructions into one or more other instructions to be processed by the kernel. Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. Instruction translators can be on the processor, off-processor, or partially on-processor and partially off-processor.

[0406] Figure 30This is a block diagram illustrating 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 using software, firmware, hardware, or various combinations thereof. Figure 30 A program of high-level language 3002 can be compiled using a first ISA compiler 3004 to generate first ISA binary code 3006, which can be natively executed by a processor 3016 having at least one first ISA core. The processor 3016 having at least one first ISA core represents any processor capable of compatibly executing or otherwise processing (1) a substantial portion of the first ISA or (2) in a processor having at least one first ISA core. A version of target code for an application or other software runs on the processor to perform substantially the same function as an Intel processor with at least one first ISA core, to achieve substantially the same results as a processor with at least one first ISA core. The first ISA compiler 3004 represents a compiler operable to generate first ISA binary code 3006 (e.g., target code), which can be executed on a processor 3016 with or without additional linking processing. Similarly, Figure 30 A program of high-level language 3002 can be compiled using an alternative ISA compiler 3008 to generate alternative ISA binary code 3010, which can be natively executed by a processor 3014 without a first ISA core. An instruction converter 3012 is used to convert the first ISA binary code 3006 into code that can be natively executed by the processor 3014 without a first ISA core. This converted code may not necessarily be identical to the alternative ISA binary code 3010; however, the converted code will implement the overall operation and consist of instructions from the alternative ISA. Thus, the instruction converter 3012 represents software, firmware, hardware, or a combination thereof, which, through emulation, simulation, or any other process, allows a processor or other electronic device without a first ISA processor or core to execute the first ISA binary code 3006.

[0407] IP Core Implementation

[0408] At least some examples, one or more aspects, can be implemented by representative code stored on a machine-readable medium that represents and / or defines the logic within an integrated circuit (such as a processor). For example, the machine-readable medium may include instructions representing various logics within a processor. When read by a machine, the instructions can cause the machine to manufacture the logic to perform the techniques described herein. This representation, referred to as an "IP core," is a reusable logic unit of the integrated circuit and can be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model can be provided to various customers or manufacturing facilities that load the hardware model onto manufacturing machines that manufacture the integrated circuit. Integrated circuits can be manufactured such that the circuit performs the operations described in association with any of the examples described herein.

[0409] Figure 31 This is a block diagram illustrating an IP core development system 3100, which can be used to manufacture integrated circuits to perform operations according to some examples. The IP core development system 3100 can be used to generate modular, reusable designs that can be incorporated into larger designs or used to build entire integrated circuits (e.g., SOC integrated circuits). Design tool 3130 can generate software simulations 3110 of the IP core design using a high-level programming language (e.g., C / C++). Software simulation 3110 can be used to design, test, and verify the behavior of the IP core using simulation model 3112. Simulation model 3112 can include functional, behavioral, and / or timing simulations. Register transfer level (RTL) designs 3115 can then be created or synthesized based on simulation model 3112. RTL design 3115 is an abstraction of the behavior of an integrated circuit that models the flow of digital signals between hardware registers, including the associated logic performed using the modeled digital signals. In addition to RTL design 3115, lower-level designs at the logic level or transistor level can also be created, designed, or synthesized. Therefore, the specific details of the initial design and simulation may differ.

[0410] The RTL design 3115 or its equivalent can be further synthesized by the design facility into a hardware model 3120, which can be a hardware description language (HDL) or some other representation of physical design data. The HDL can be further simulated or tested to validate the IP core design. The IP core design can be stored using non-volatile memory 3140 (e.g., hard disk, flash memory, or any non-volatile storage medium) for delivery to a third-party manufacturing facility 3165. Alternatively, the IP core design can be transmitted via a wired connection 3150 or a wireless connection 3160 (e.g., via the Internet). The manufacturing facility 3165 can then fabricate integrated circuits at least partially based on the IP core design. The fabricated integrated circuits can be configured to perform operations according to at least some of the examples described herein.

[0411] The use of phrases like "an example," "one example," etc., indicates that the described example may include a specific feature, structure, or characteristic, but not every example may necessarily include that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same example. Additionally, when an example is used to describe a specific feature, structure, or characteristic, it should be assumed that implementing that feature, structure, or characteristic in conjunction with other examples (whether explicitly described or not) is within the knowledge of someone skilled in the art.

[0412] Furthermore, in the various examples described above, unless otherwise specifically noted, disjunctive languages ​​such as “at least one of A, B, or C” or “A, B, and / or C” should be understood to refer to A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B, and C).

[0413] Therefore, the specification and drawings should be considered exemplary rather than restrictive. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the claims.

Claims

1. An apparatus comprising: A branch predictor is used to predict one of the taken and untaken paths of a conditional branch instruction. A decoder circuit for decoding an instruction into a decoded instruction, the instruction including a field and an opcode, the field indicating a condition to be set by executing another instruction, the opcode indicating that an execution circuit will implement an execution fence in response to the condition being met, to delay the execution of the instruction before executing a previously ordered instruction, and to delay the execution of instructions following the instruction in program order before executing the first instruction; and The execution circuit is used to execute the decoded instruction according to the opcode.

2. The apparatus according to claim 1, wherein, The opcode also indicates that the execution circuit will delay the execution of instructions following the instructions in program order until the condition is resolved, in response to the condition not being currently resolved.

3. The apparatus according to any one of claims 1-2, wherein, The opcode also indicates that the execution circuitry will, in response to the condition not being met, allow the execution of one or more instructions following the instructions in program order before executing one or more of the previous instructions.

4. The apparatus according to claim 3, wherein, The opcode also indicates that the execution circuit will execute the instruction as no operation in response to the condition not being met.

5. The apparatus of claim 1, further comprising a flag register, wherein the condition refers to a flag in the flag register.

6. The apparatus according to claim 1, wherein, The field indicating the condition is the register direct addressing mode field of the instruction.

7. The apparatus according to claim 6, wherein, The field is the register operand field in the register direct addressing mode field.

8. A method comprising: The branch predictor predicts one of the taken and untaken paths for a conditional branch instruction, which precedes the instruction immediately following the conditional branch instruction in program order. The decoder circuit decodes the instruction into a decoded instruction, which includes a field and an opcode. The field indicates a condition to be set by executing another instruction, and the opcode indicates that the execution circuit will implement an execution fence in response to the condition being met, to delay the execution of the instruction before executing the previous instruction in program order, and to delay the execution of the instruction after the instruction in program order before executing the instruction. as well as The execution circuit executes the decoded instruction according to the opcode.

9. The method according to claim 8, wherein, The opcode also indicates that the execution circuit will delay the execution of instructions following the instructions in program order until the condition is resolved, in response to the condition not being currently resolved.

10. The method according to any one of claims 8-9, wherein, The opcode also indicates that the execution circuitry will, in response to the condition not being met, allow the execution of one or more instructions following the instructions in program order before executing one or more of the previous instructions.

11. The method according to claim 10, wherein, The opcode also indicates that the execution circuit will execute the instruction as no operation in response to the condition not being met.

12. The method of claim 8, further comprising a flag register, wherein the condition refers to a flag in the flag register.

13. The method according to claim 8, wherein, The field indicating the condition is the register direct addressing mode field of the instruction.

14. The method according to claim 13, wherein, The field is the register operand field in the register direct addressing mode field.

15. A non-transitory machine-readable medium storing code, which, when executed by a machine, causes the machine to perform a method comprising the following processes: The branch predictor predicts one of the taken and untaken paths for a conditional branch instruction, which precedes the instruction immediately following the conditional branch instruction in program order. The decoder circuit decodes the instruction into a decoded instruction, the instruction including a field and an opcode, the field indicating a condition to be set by executing another instruction, and the opcode indicating that the execution circuit will implement an execution fence in response to the condition being met, to delay the execution of the instruction before executing the previous instruction in program order, and to delay the execution of instructions following the instruction in program order before executing the previous instruction; and The execution circuit executes the decoded instruction according to the opcode.

16. The non-transitory machine-readable medium according to claim 15, wherein, The opcode also indicates that the execution circuit will delay the execution of instructions following the instructions in program order until the condition is resolved, in response to the condition not being currently resolved.

17. The non-transitory machine-readable medium according to any one of claims 15-16, wherein, The opcode also indicates that the execution circuitry will, in response to the condition not being met, allow the execution of one or more instructions following the instructions in program order before executing one or more of the previous instructions.

18. The non-transitory machine-readable medium according to claim 17, wherein, The opcode also indicates that the execution circuit will execute the instruction as no operation in response to the condition not being met.

19. The non-transitory machine-readable medium of claim 15, further comprising a flag register, wherein the condition refers to a flag in the flag register.

20. The non-transitory machine-readable medium according to claim 15, wherein, The field indicating the condition is the register direct addressing mode field of the instruction.

21. The non-transitory machine-readable medium according to claim 20, wherein, The field is the register operand field in the register direct addressing mode field.

Images