A GPU internal instruction transmission control method and device and a GPU

Abstract

The application discloses a GPU internal instruction emission control method and device and a GPU, and relates to the technical field of GPU, and specifically discloses the following technical scheme: in response to a target type of instruction being determined as a first invalid instruction, the first invalid instruction is prohibited from being emitted to an execution pipeline of an instruction execution unit, the first invalid instruction and a first trigger reference value of the first invalid instruction are written into an invalid instruction queue to complete pseudo-emission, the first trigger reference value is a count value of emitted non-committed same type valid instructions counted by a counter at the time when the first invalid instruction is written into the invalid instruction queue; in response to the emitted valid instruction completing true submission, a current count value of the counter is updated in a decreasing manner, and when the number of the current count value decreasing reaches the first trigger reference value, the first invalid instruction is taken out from the invalid instruction queue and a pseudo-commitment operation is performed.

Description

Technical Field

[0001] This application relates to the field of computing processor technology, and in particular to a GPU internal instruction issuance control method, apparatus and GPU. Background Technology

[0002] In parallel computing processors such as GPUs, the instruction issue control mechanism directly affects the processor's execution efficiency and power consumption. As the scale of parallel computing continues to expand, the instruction execution unit needs to process a large number of concurrent instructions, which inevitably results in invalid instructions.

[0003] In typical GPU architectures, to ensure the sequential submission of instructions within a warp (the smallest execution scheduling unit or instruction execution unit in a GPU), invalid instructions still need to be issued into the instruction execution unit's pipeline. However, although these invalid instructions do not produce valid computation results in the instruction execution unit, they still trigger state transitions in flip-flops and logic circuits at various stages of the pipeline, resulting in unnecessary dynamic power consumption. This power waste caused by invalid instructions is particularly significant in high-density parallel computing scenarios, becoming one of the important factors restricting the improvement of processor energy efficiency.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] The purpose of this application is to provide a GPU internal instruction issuance control method, device, and GPU to solve the problem that existing GPUs cannot prevent invalid instructions from entering the pipeline while maintaining the instruction order, resulting in additional power consumption and resource waste.

[0006] The first aspect of this application provides a GPU internal instruction issuance control method, applied to the instruction execution unit of a parallel computing processor, wherein the instruction execution unit is configured with a counter and an invalid instruction queue, including: In response to an instruction of the target type being determined as a first invalid instruction, the first invalid instruction is prohibited from being issued to the execution pipeline of the instruction execution unit. The first invalid instruction and its first triggering reference value are written into the invalid instruction queue to complete a pseudo-issue. The first triggering reference value is the count of issued but not submitted valid instructions of the same type when the first invalid instruction is written into the invalid instruction queue. In response to a valid instruction that has been issued completing a true commit, the current count value of the counter is decremented and updated. When the decrease in the current count value reaches the first triggering reference value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo-commit operation is performed. The pseudo-commit operation only updates the internal state of the instruction execution unit.

[0007] In some embodiments of this application, the method further includes: In response to an instruction of the target type being determined to be a valid instruction, the valid instruction is issued to the execution pipeline, and the current count value of the counter is incremented. The incrementing update is performed by incrementing the current count value of the counter by 1 when the valid instruction is issued but not submitted, and the counter incrementing operation is triggered only once for each valid instruction issuance.

[0008] In some embodiments of this application, the decrement update includes performing a decrement operation on the current count value of the counter when the valid instruction is submitted, and a single valid instruction submission triggers only one decrement operation on the counter.

[0009] In some embodiments of this application, the decrease in the current count value is determined based on the number of valid instructions of the same type submitted, and the decrease in the current count value reaching the first triggering benchmark value indicates that all valid instructions of the same type issued before the first invalid instruction have been submitted.

[0010] In some embodiments of this application, the method further includes: In response to the target type instruction being determined as the second invalid instruction, the second invalid instruction and the second triggering reference value of the second invalid instruction are written into the invalid instruction queue to complete the pseudo-emission. The second triggering reference value is the count value of the same type of valid instructions that have been issued but not submitted, which is counted by the counter at the time when the second invalid instruction is written into the invalid instruction queue. The first invalid instruction is written to the head of the invalid instruction queue, and the second invalid instruction is written after the first invalid instruction. In response to the first invalid instruction completing the pseudo-commit operation and being removed from the invalid instruction queue, the second invalid instruction becomes the new head of the invalid instruction queue; When the number of decreases in the current count value reaches the second trigger baseline value, the second invalid instruction is retrieved from the new head of the invalid instruction queue and a pseudo-commit operation is performed.

[0011] In some embodiments of this application, the counter is a dedicated counter for target type instructions. The counter only counts valid memory access instructions that have been issued but not committed. The pseudo-issue and pseudo-commit processes of the first invalid instruction and the second invalid instruction do not change the count value of the counter.

[0012] In some embodiments of this application, the true commit includes: The execution pipeline completes the execution operation corresponding to the valid instructions of the target type, writes the execution result back to the instruction execution unit, and feeds back the instruction execution completion status; After confirming execution and write-back, the program counter status and instruction completion status of the instruction execution unit are updated, and the counter is decremented.

[0013] In some embodiments of this application, the pseudo-submission operation includes: Remove the first invalid instruction from the head of the invalid instruction queue; Update the program counter state of the instruction execution unit where the first invalid instruction is located; Update the instruction completion status of the instruction execution unit where the first invalid instruction is located; Keep the current count value of the counter unchanged.

[0014] In some embodiments of this application, the method further includes: When the instruction execution unit detects an abnormal event that affects the normal submission process of valid instructions, it triggers a counter abnormal calibration operation. The counter anomaly calibration operation includes: Pause the current counter increment / decrement updates and invalid instruction false commit checks; The number of valid instructions of the same type that have been launched into the execution pipeline but have not yet been truly committed is recounted to obtain the calibration count value; The current count value of the counter is calibrated to the calibration count value; After calibration, resume the increment and decrement updates of the counter, as well as the false commit detection.

[0015] In some embodiments of this application, the abnormal event includes at least one of the following: execution pipeline blockage, instruction commit interruption, hardware reset, clock gating exit, and power state switching.

[0016] A second aspect of this application provides an internal instruction dispatch control device for a GPU, applied to the instruction execution unit of a parallel computing processor. The instruction execution unit is configured with a counter and an invalid instruction queue, including: The invalid instruction queue module is used to respond to the first invalid instruction being determined as the first invalid instruction, prohibit the first invalid instruction from being issued to the execution pipeline of the memory access unit, and write the first invalid instruction and the first triggering reference value of the first invalid instruction into the invalid instruction queue to complete the pseudo-issue. The first triggering reference value is the count value of the issued but not submitted valid instructions of the same type when the first invalid instruction is written into the invalid instruction queue. The first invalid instruction pseudo-commit module is used to respond to the issued valid instruction completing the true commit by decrementing the current count value of the counter. When the decrease in the current count value reaches the first triggering benchmark value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo-commit operation is performed. The pseudo-commit operation only updates the internal state of the instruction execution unit.

[0017] A third aspect of this application provides a GPU including a streaming multiprocessor, wherein the streaming multiprocessor integrates the aforementioned instruction execution unit, and the GPU executes the aforementioned method through the instruction execution unit, wherein the instruction execution unit of each streaming multiprocessor independently performs instruction issuance control.

[0018] In some embodiments of this application, the instruction execution unit includes a decoding unit, an execution pipeline, a counter, an invalid instruction queue, and a submission unit. The decoding unit is used to determine the validity of instructions. The execution pipeline is used to issue, execute, and write back valid instructions. The counter is used to count the number of valid instructions of the same type that have been issued but not submitted. The invalid instruction queue is used to temporarily store invalid instructions and their triggering reference values. The submission unit is used to complete the true submission of valid instructions and the false submission of invalid instructions.

[0019] A fourth aspect of this application provides a chip including a processor and a memory storing processor-executable instructions, wherein the processor, when executing the instructions, implements the steps of any of the methods described above.

[0020] The fifth aspect of this application provides a computer storage medium storing computer program instructions that, when executed by a processor, implement the steps of any of the methods described above.

[0021] The sixth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0022] This application discloses a GPU internal instruction issuance control method, apparatus, and GPU. According to the above embodiments, in response to an instruction of a target type being determined as a first invalid instruction, the issuance of the first invalid instruction to the execution pipeline of the instruction execution unit is prohibited. This directly blocks the invalid instruction from entering the execution pipeline at its source, preventing the invalid instruction from triggering state flip-flops and logic circuits at various levels in the pipeline, thereby eliminating the resulting dynamic power consumption. By writing the first invalid instruction and its first trigger reference value into the invalid instruction queue to complete a pseudo-issuance, the invalid instruction completes the "issuance" operation without entering the execution pipeline, ensuring the continuity of instruction order while avoiding the power consumption overhead of actual execution. By limiting the first trigger reference value to the time the first invalid instruction is written into the invalid instruction queue, and by counting the number of issued but uncommitted valid instructions of the same type, a correlation between the execution progress of invalid and valid instructions can be established. This allows invalid instructions to perceive the completion status of previous valid instructions, providing a basis for subsequent correct submission. By responding to a valid instruction that has been issued and completing a true commit, the current count value of the counter is decremented and updated. When the decrease in the current count value reaches the first triggering base value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo commit operation is performed. This counter association mechanism can ensure that the invalid instruction is committed only after all the valid instructions before it have been completed, thus maintaining the sequential commit requirement of instructions within the thread bundle. At the same time, the pseudo commit only updates the internal state and does not generate additional power consumption. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is an architecture diagram of the different types of instructions issued to the corresponding execution units within the GPU, as provided in the embodiments of this specification. Figure 2 This is a schematic diagram of the sequential issuance, execution, and submission process of instructions within a single warp inside the GPU, provided in the embodiments of this specification. Figure 3 This is a timing diagram illustrating the transmission of invalid instructions within a GPU along the execution pipeline in the prior art provided in the embodiments of this specification; Figure 4 This is a flowchart illustrating a GPU internal instruction issuance control method provided in the embodiments of this specification; Figure 5This is a schematic diagram of the overall architecture of the GPU internal instruction issuance control provided in the embodiments of this specification; Figure 6 This is a schematic diagram of instruction distribution and queue splitting provided in the embodiments of this specification; Figure 7 This is a schematic diagram illustrating the sequential execution timing of the internal instructions of the warp provided in the embodiments of this specification; Figure 8 This is a schematic diagram illustrating the structural composition of an internal instruction dispatch control device for a GPU, as provided in an embodiment of this specification. Figure 9 This is a schematic diagram of the structure of a chip provided in an embodiment of this specification. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0027] This specification provides the operational steps of the methods described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the methods shown in the embodiments or drawings can be executed sequentially or in parallel.

[0028] It should be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of the present invention. However, they do not mean that the applicant has used or necessarily used such solutions.

[0029] In current GPU architecture, a warp is the smallest execution scheduling unit (i.e., instruction scheduling and execution unit) within the GPU. Multiple warps can run simultaneously within a streaming multiprocessor (SM), and instruction execution between different warps is independent. The GPU primarily relies on switching between different warps to hide instruction latency. When an executing warp is blocked due to memory access, synchronization, or other reasons, the scheduler checks if there is another warp that meets the issue execution requirements. If so, the scheduler switches that warp into the instruction issue execution pipeline. Therefore, instructions between different warps are issued and executed out of order.

[0030] Since instructions in different warps are out of order, to reduce the complexity of hardware design, instructions within the same warp are usually issued, executed, and committed sequentially to ensure that the execution timing of instructions within the warp is consistent with the program instruction flow.

[0031] GPUs support various instruction types, such as computation instructions, memory access instructions, and control instructions. Different types of instructions are decoded and dispatched to their corresponding instruction queues, awaiting scheduling and issuance by the scheduler. The scheduler then sends them to the corresponding execution units, where they are executed, written back, and finally committed. Instructions within the same warp sequentially undergo decoding, issuance, execution, write-back, and commit, strictly adhering to sequential execution rules. Figure 1 As shown, after the instruction is decoded by the decoding unit, it is distributed to the corresponding dedicated instruction issue queue according to the instruction type (computation instruction, memory access instruction, control instruction). The scheduler schedules the instructions in each issue queue and issues different types of instructions to the corresponding execution units (computation unit, memory access unit, control unit). After the instruction completes the corresponding execution operation in the corresponding execution unit, the execution result is written back to the on-chip storage resources of the instruction execution unit, and finally the instruction is committed. The whole process reflects the complete execution path of different types of instructions.

[0032] like Figure 2As shown, instructions within the same warp enter the decoding unit sequentially according to the program's writing order. After validity determination, valid instructions are issued to the execution pipeline in sequence. Instructions complete execution and write-back operations step by step in the execution pipeline. After each instruction completes its true commit, the issuance and execution of the next instruction are triggered. The rule of "sequential issuance, sequential execution, and sequential commit" is strictly followed to ensure the timing consistency of instruction execution within the warp and reduce hardware design complexity.

[0033] In existing technologies, GPU instructions may encounter exceptions during the decoding phase, causing them to be considered invalid. Theoretically, this invalid instruction should not be issued for execution. However, to ensure the order of instruction issuance and execution within the warp, and to adhere to the rule of order of instruction issuance and submission, this invalid instruction is issued to the execution unit, but marked as invalid. The execution unit, upon seeing this invalid instruction, does not actually execute it; instead, it allows it to proceed sequentially along the execution pipeline. The execution pipeline ensures that, from the execution unit's perspective, the order of instruction issuance to submission is consistent. Figure 3 As shown, after an instruction is determined to be invalid during the decoding stage, in order to ensure the order of instructions within the warp, the invalid instruction is still marked as invalid and issued to the execution pipeline. After the execution unit recognizes the mark of the invalid instruction, it does not execute the actual operations such as memory access and operation corresponding to the instruction, but still allows the invalid instruction to be passed step by step along each level of the execution pipeline (fetch level, decode level, execution level, write-back level) until a formal commit is completed. The timing of the pipeline ensures the consistency of the order of instructions from issuance to commit. This approach of ensuring the order of instruction issuance and commit within the warp through the instruction execution pipeline is undoubtedly simple and convenient.

[0034] While existing technologies offer the advantages of simplicity and convenience, they introduce unnecessary dynamic power consumption overhead. Although invalid instructions do not perform actual functions, their propagation through the execution pipeline still triggers flips and actions in registers, logic circuits, and data paths at each stage, increasing the GPU's dynamic power consumption. As GPU integration and parallelism continue to increase, chip power consumption becomes increasingly prominent, and energy efficiency has become one of the core metrics for GPU architecture design. The redundant power consumption caused by invalid instructions propagating through the pipeline, while having a small overhead per instruction, significantly reduces the overall energy efficiency of the GPU in large-scale concurrent, high-density instruction flow scenarios, exacerbating the chip's power consumption pressure.

[0035] Meanwhile, this method cannot fundamentally prevent invalid instructions from entering the pipeline without disrupting the internal instruction order of the warp or altering the execution pipeline. The above problems cannot be solved by traditional instruction masking, pipeline pausing, or warp scheduling optimization. They can only be fundamentally improved by the pseudo-launch and pseudo-commit mechanism proposed in this invention.

[0036] To reduce the additional power consumption caused by invalid instruction issuance during GPU operation, this specification provides an internal GPU instruction issuance control method. In response to an instruction of a target type being determined to be a first invalid instruction, the method prohibits the issuance of the first invalid instruction to the execution pipeline of the instruction execution unit. This directly blocks the invalid instruction from entering the execution pipeline at its source, preventing the invalid instruction from triggering state flip-flops and logic circuits at various stages of the pipeline, thereby eliminating the resulting dynamic power consumption. A pseudo-issuance is achieved by writing the first invalid instruction and its first trigger reference value into the invalid instruction queue. This allows the invalid instruction to complete the "issuance" operation without entering the execution pipeline, ensuring the continuity of instruction order while avoiding the power consumption overhead of actual execution. By limiting the first trigger reference value to the moment the first invalid instruction is written into the invalid instruction queue, and by counting the number of issued but uncommitted valid instructions of the same type, a correlation can be established between the execution progress of invalid and valid instructions. This allows invalid instructions to perceive the completion status of previous valid instructions, providing a basis for subsequent correct submission. By responding to a valid instruction that has already been issued and completing a true commit, the current count value of the counter is decremented and updated. When the decrease in the current count value reaches a first trigger threshold, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo-commit operation is performed. This counter association mechanism ensures that an invalid instruction is committed only after all valid instructions preceding it have been completed, maintaining the sequential commit requirement of instructions within the thread bundle. Furthermore, the pseudo-commit only updates the internal state and does not generate additional power consumption. This invention implements pseudo-issue and pseudo-commit of invalid instructions through a counter and an invalid instruction queue, enabling invalid instructions to complete sequential commit without entering the execution pipeline, thereby eliminating the dynamic power consumption caused by invalid instructions.

[0037] The GPU internal instruction issuance control method in the embodiments of this specification will be described in detail below with reference to the accompanying drawings.

[0038] Figure 4This is a flowchart illustrating a GPU internal instruction issuance control method provided in an embodiment of this specification. While this specification provides method operation steps or apparatus structures as shown in the following embodiments or figures, more or fewer operation steps or module units may be included in the method or apparatus based on conventional or non-inventive effort. In steps or structures where there is no logically necessary causal relationship, the execution order of these steps or the module structure of the apparatus is not limited to the execution order or module structure described in the embodiments and figures of this specification. When the method or module structure is applied in actual devices or terminal products, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or figures (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed processing environment). Figure 4 As shown, this method can be applied to the instruction execution unit of a parallel computing processor. The instruction execution unit is configured with a counter and an invalid instruction queue. The method may include: S401: In response to the instruction of the target type being determined as the first invalid instruction, the first invalid instruction is prohibited from being issued to the execution pipeline of the instruction execution unit. The first invalid instruction and the first triggering reference value of the first invalid instruction are written into the invalid instruction queue to complete the pseudo-issue. The first triggering reference value is the count value of the issued but not submitted valid instructions of the same type when the first invalid instruction is written into the invalid instruction queue. S402: In response to the completion of a true commit of a valid instruction that has been issued, the current count value of the counter is decremented and updated. When the decrease in the current count value reaches the first triggering reference value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo commit operation is performed. The pseudo commit operation only updates the internal state of the instruction execution unit.

[0039] Specifically, the decoding unit within the instruction execution unit (such as the warp inside the GPU) can decode and analyze the received target type instruction to determine its validity. The criteria for this determination may include: whether the instruction format is correct, whether the operands are valid, whether the memory access address is aligned, and whether the permission check is passed. If all checks pass, the instruction is considered valid; otherwise, it is considered invalid.

[0040] When an instruction is determined to be the first invalid instruction, the following operations are performed: the first invalid instruction is prevented from being issued to the execution pipeline of the instruction execution unit to avoid occupying pipeline resources; the count value N of the current counter for valid instructions of the same type is read, which represents the number of valid instructions of the same type that have been issued but not yet committed before the current invalid instruction; the first invalid instruction and its first trigger base value N are combined into a queue entry and written to the head of the invalid instruction queue; finally, the program counter of the instruction execution unit is updated to allow the instruction flow to continue, as if the instruction has been issued normally (pseudo-issue process).

[0041] After a valid instruction completes execution in the pipeline, a true commit is performed. Each true commit of a valid instruction causes the counter to decrement, triggering a false commit judgment for invalid instructions: First, the number of times the current count value of the counter has decreased is calculated. For example, if the original value of the counter is M and the current value is M-1, the number of times it has decreased is 1. Then, the triggering base value N of the instruction at the head of the invalid instruction queue is obtained. If the number of times the current count value has decreased is equal to or reaches N (that is, since the invalid instruction was written into the queue, N valid instructions have been committed), then a false commit of the invalid instruction is triggered. During the first false commit of an invalid instruction, only the internal state of the instruction execution unit (warp) is updated, and the actual instruction execution is not involved, so as to ensure the order of instructions.

[0042] The target type refers to a specific instruction category that requires processing by the mechanism of this invention. In GPU architecture, different types of instructions (such as memory access instructions, arithmetic instructions, control flow instructions, etc.) have different pipeline occupancy methods and power consumption characteristics. In this embodiment, the target type can be a memory access instruction because such instructions require a complete memory access operation in the execution pipeline; invalid instructions would result in significant power waste. An independent counter is also configured for each target type to ensure counting accuracy.

[0043] The first invalid instruction refers to a memory access instruction that has been determined to be invalid by the decoding unit. Criteria for determining an invalid instruction can include: incorrect instruction format, misaligned operand addresses, insufficient access permissions, and out-of-bounds address errors. When an instruction is determined to be invalid, it is called the "first invalid instruction" to distinguish it from other potentially invalid instructions. The characteristic of a first invalid instruction is that, although it does not produce a valid computation result, it still needs to be issued to the execution pipeline in traditional architectures to maintain instruction order.

[0044] An execution pipeline refers to the pipelined structure within an instruction execution unit used to process valid instructions. It typically contains multiple pipeline stages, such as the issue stage (allocating execution resources), the execution stage (performing actual computation or memory access), and the write-back stage (writing the result back to a register). Each stage in the execution pipeline contains flip-flops and combinational logic circuits; the passage of an instruction triggers state transitions in these circuits, resulting in dynamic power consumption. This invention avoids this power consumption by preventing invalid instructions from entering the execution pipeline.

[0045] A pseudo-launch refers to a special way of handling invalid instructions. Instead of actually sending the instruction to the execution pipeline, its relevant information (instruction identifier, trigger base value) is written to an invalid instruction queue, and the effect of the instruction being issued is simulated at the program counter level. Pseudo-launches consume only a small amount of resources for writing to the queue, avoiding the power overhead of the execution pipeline.

[0046] A pseudo-commit can be a special exit method for invalid instructions. When a trigger condition is met, the instruction is removed from the invalid instruction queue, and the program counter and instruction completion status are updated, but the actual computation result is not written back. A pseudo-commit only updates the internal state and does not involve pipelined operations, further avoiding wasted power.

[0047] The first trigger baseline value can refer to the count of issued but uncommitted valid instructions of the same type, as recorded by the counter at the moment the first invalid instruction is written into the queue. This value represents how many valid instructions of the same type have not yet been committed before the invalid instruction, and is used to determine when the invalid instruction can safely execute a pseudo-commit to ensure the correctness of the instruction order.

[0048] The counter, a dedicated hardware unit within the instruction execution unit of this invention, can be used to count the number of valid instructions of the same type that have been issued but not yet committed. The counter increments when each valid instruction is issued and decrements when each valid instruction is committed, accurately reflecting the number of valid instructions currently being executed. The counter value serves as a trigger reference value for invalid instructions, establishing a correlation between the execution progress of invalid and valid instructions.

[0049] The invalid instruction queue can be a dedicated FIFO (First-In-First-Out) queue in the instruction execution unit of this invention, used to temporarily store invalid instructions that have been pseudo-issued but have not yet met the pseudo-commit conditions. Each queue entry contains an instruction identifier and a trigger reference value. The queue adopts FIFO order to ensure that invalid instructions are processed in the order of the program.

[0050] A true commit refers to the normal completion of a valid instruction, which may include writing the execution result back to the register, updating the program counter, updating the instruction completion status, and triggering the decrementing of the counter. A true commit represents the actual completion of the instruction and produces the actual calculation result.

[0051] The reduction count can refer to the cumulative number of valid instructions that have been committed, starting from a certain reference point. For an invalid instruction that triggers a baseline value of N, when the reduction count reaches N, it means that all valid instructions of the same type preceding the invalid instruction have been committed, and at this point, it is safe to execute a pseudo-commit of the invalid instruction.

[0052] Based on the above embodiments, by using a counter and an invalid instruction queue to implement pseudo-issue and pseudo-commit of invalid instructions, invalid instructions can be prevented from entering the execution pipeline without disrupting the instruction submission order, thereby eliminating the resulting dynamic power consumption and significantly improving the processor's energy efficiency ratio.

[0053] In some embodiments, prior to completing a true commit in response to a valid command that has been issued, the method may further include: In response to an instruction of the target type being determined to be a valid instruction, the valid instruction is issued to the execution pipeline, and the current count value of the counter is incremented. The incrementing update is performed by incrementing the current count value of the counter by 1 when the valid instruction is issued but not submitted, and the counter incrementing operation is triggered only once for each valid instruction issuance.

[0054] Specifically, when an instruction is determined to be valid, the following operations are performed: the valid instruction is sent to the execution pipeline of the instruction execution unit to begin the instruction execution flow. At the moment when the instruction is successfully issued but not yet committed, the current count value of the counter is incremented by 1. For example, if the original count value is 5, it becomes 6 after issuing a valid instruction. It is necessary to ensure that each valid instruction triggers the counter increment operation only once to avoid double counting.

[0055] Incremental updates refer to incrementing the counter's current value by 1 when a valid instruction is successfully issued to the execution pipeline but not yet committed. An incremental update reflects that a new valid instruction is being executed and needs to be completed. Each valid instruction issuance triggers only one incremental update, ensuring accurate counter counting.

[0056] By accurately recording the number of valid commands that have been issued but not yet submitted using a counter, a basis can be provided for triggering invalid commands, ensuring that invalid commands can perceive the completion progress of their predecessor valid commands.

[0057] In some embodiments, the above-mentioned decrement update may include performing a decrement operation on the current count value of the counter when the valid instruction is submitted, and a single valid instruction submission triggers only one decrement operation on the counter.

[0058] Specifically, when a valid instruction completes a true commit, the following operations are performed: At the moment the instruction is committed, the current count value of the counter is decremented by 1. For example, if the original count value is 6, it becomes 5 after committing a valid instruction. It is necessary to ensure that each valid instruction triggers the counter decrement operation only once, corresponding one-to-one with the increment operation during transmission. The decrement and commit operations are atomic operations, which can avoid counting errors in a multi-threaded environment.

[0059] In this context, a decrement update refers to decrementing the current count value of a counter by 1 when a valid instruction completes a true commit. A decrement update reflects that one valid instruction has been executed, reducing the number of valid instructions currently executing in the system by one. Each valid instruction commit triggers only one decrement update, corresponding one-to-one with the increment update during transmission.

[0060] The decremental and incremental updates form a complete closed loop, which can ensure that the counter accurately reflects the number of valid commands that have been issued but not yet submitted, and provide a reliable basis for judging the false submission of invalid commands.

[0061] In some embodiments, the decrease in the current count value is determined based on the number of valid instructions of the same type submitted, and the decrease in the current count value reaching the first triggering benchmark value indicates that all valid instructions of the same type issued before the first invalid instruction have been submitted.

[0062] Specifically, a cumulative decrement counter R can be maintained, which increments by 1 each time a valid instruction is committed. R represents the total number of valid instruction commits starting from any reference point. For the first invalid instruction with a trigger base value of N, a pseudo-commit is triggered when R = N.

[0063] The reduction count can refer to the cumulative number of valid instructions that have been committed since the invalid instruction was written into the queue. When the reduction count reaches the trigger threshold for the invalid instruction, it means that all valid instructions of the same type issued before the invalid instruction have been committed, and a pseudo-commit of the invalid instruction can be executed at this time.

[0064] For example: Command sequence (in order of transmission): LS0 (valid) → LS1 (valid) → LS2 (first invalid command) → LS3 (valid); When the first invalid instruction (LS2) is enqueued, the current counter count value = 2 (LS0 and LS1 have been issued but not submitted) → the first trigger reference value = 2; After LS2 is enqueued, the count of "number of valid instructions of the same type" (i.e., the number of decrements) begins to be counted, which is initially 0; The first valid instruction LS0 completes a true commit → the counter is decremented by 1 (from 2 to 1), and the number of decrements is incremented by 1 (from 0 to 1); at this time, the number of decrements 1 < the first triggering base value 2, so a false commit is not triggered. The second valid instruction LS1 completes a true commit → the counter is decremented by 1 (from 1 to 0), and the number of decrements is incremented by 1 (from 1 to 2); at this time, the number of decrements of 2 = the first trigger base value 2, indicating that all valid instructions of the same type (LS0, LS1) issued before LS2 have been committed, and LS2 is taken out from the invalid instruction queue to perform a pseudo commit.

[0065] By comparing the number of times the current counter value is reduced with the trigger baseline value, it can be ensured that invalid instructions strictly adhere to the program order and are only committed after all valid instructions preceding them have been completed, thus maintaining the correctness of instruction execution.

[0066] In some embodiments, prior to completing a true commit in response to a valid command that has been issued, the method may further include: In response to the target type instruction being determined as the second invalid instruction, the second invalid instruction and the second triggering reference value of the second invalid instruction are written into the invalid instruction queue to complete the pseudo-emission. The second triggering reference value is the count value of the same type of valid instructions that have been issued but not submitted, which is counted by the counter at the time when the second invalid instruction is written into the invalid instruction queue. The first invalid instruction is written to the head of the invalid instruction queue, and the second invalid instruction is written after the first invalid instruction. In response to the first invalid instruction completing the pseudo-commit operation and being removed from the invalid instruction queue, the second invalid instruction becomes the new head of the invalid instruction queue; When the number of times the current count value decreases reaches the second trigger baseline value, the second invalid instruction is retrieved from the new head of the invalid instruction queue and a pseudo-commit operation is performed.

[0067] Specifically, the invalid instruction queue can adopt a FIFO (First-In, First-Out) structure to support the queuing and processing of multiple invalid instructions. When the second invalid instruction arrives, the current counter value is obtained as its second trigger base value N2, and the second invalid instruction and its N2 are written after the first invalid instruction. When the first invalid instruction completes its pseudo-commit, it is removed from the head of the queue. The second invalid instruction in the original queue automatically becomes the new head of the queue, and its trigger base value N2 remains unchanged. The new head instruction waits for its trigger condition to be met (the number of instructions decreases to N2) before performing a pseudo-commit. Managing multiple invalid instructions through a FIFO queue ensures that they are processed sequentially according to the program order, while each invalid instruction independently maintains its trigger base value, without interfering with each other.

[0068] The second invalid instruction can refer to another instruction that is determined to be invalid after the first invalid instruction. The second invalid instruction is handled in the same way as the first invalid instruction, but it is written after the first invalid instruction, with its trigger base value being the counter value at the time of writing. Multiple invalid instructions are arranged in a FIFO order in the queue, waiting for pseudo-commits in sequence.

[0069] Queue Head / Tail: The invalid instruction queue can use a FIFO structure, with the earliest invalid instruction entering the queue at the head and the most recently entered invalid instruction at the tail. Only the head instruction can perform a pseudo-commit; after committing, the original second instruction becomes the new head, ensuring the instruction order.

[0070] For example: There are 6 consecutive memory access instructions: LS0, LS1, LS2, LS3, LS4, LS5; among them, LS2 and LS4 are determined to be invalid instructions during the decoding stage, and the rest are valid instructions. The invalid instruction queue is initially empty, and the counter only counts valid memory access instructions that have been issued but not committed.

[0071] Step 1: LS0 decoding → transmit → counter incremented by 1.

[0072] LS0 is determined to be a valid instruction after the decoding stage and is issued to the memory access execution unit according to the normal procedure; Since LS0 is in the issued but not committed state, the memory access instruction counter is incremented by 1, and the current counter value is 1; LS0 has entered the execution pipeline and begun execution and write-back processes, but has not yet been committed.

[0073] Step 2: LS1 decoding → transmission → counter incremented by 1.

[0074] LS1 is determined to be a valid instruction after the decoding stage and is issued to the memory access execution unit; The memory access instruction counter is incremented by 1, and the current counter value is 2. LS1 enters the execution pipeline and is executed sequentially with LS0, but has not yet been committed.

[0075] Step 3: LS2 decoding → invalidation (first invalid instruction) → write to invalid instruction queue.

[0076] If an instruction is determined to be invalid during the decoding stage, it is not issued to the execution unit, but is directly written into the invalid instruction queue and placed at the head. The first trigger reference value to be written is: the number of valid memory access instructions that have been issued but not committed before LS2 = 2 (i.e., LS0, LS1). This value is synchronized to the LS2 entry in the invalid instruction queue. This step is a pseudo-launch: only invalid instruction information is written to the queue, without any actual launch operation, saving launch and pipeline overhead.

[0077] The counter remains at value 2 and does not change (only valid instructions are counted).

[0078] Step 4: LS3 decoding → transmission → counter incremented by 1.

[0079] LS3 is determined to be a valid instruction after the decoding stage and is issued to the memory access execution unit; The memory access instruction counter is incremented by 1, and the current counter value is 3. LS3 has entered the execution pipeline but has not yet been committed.

[0080] Step 5: LS4 decoding → invalidation (second invalid instruction) → write to invalid instruction queue.

[0081] If an instruction is determined to be invalid during the decoding stage, it will not be issued to the execution unit, but will be written into the invalid instruction queue, located after LS2. The second trigger reference value to be written is: the number of valid memory access instructions that have been issued but not committed before LS4 = 3 (i.e., LS0, LS1, LS3), which is then synchronized to the LS4 entry; The counter remains at value 3 and does not change.

[0082] Step 6: LS5 decoding → transmit → counter incremented by 1.

[0083] LS5 is determined to be a valid instruction after the decoding stage and is issued to the memory access execution unit; The memory access instruction counter is incremented by 1, and the current counter value is 4. LS5 has entered the execution pipeline but has not yet been committed.

[0084] Step 7: Valid instructions are submitted sequentially → the counter is decremented by 1 each time → LS2 pseudo-commit is triggered.

[0085] This step is the core linkage phase. Since the instruction execution counter is decremented by 1 after each memory access instruction is written back and committed, when the number of times the corresponding instruction execution counter is decremented is equal to the value of the instruction execution counter previously written to the invalid instruction queue, it means that all memory access instructions issued before the invalid instructions have been executed and committed. At this time, the instructions at the head of the invalid instruction queue will be read out, and the core logic of committing instructions will be performed immediately as if they were normally executed instructions. Specifically, it can be as follows: LS0 completes write-back and commit: memory access instruction counter decrements by 1, current value = 3; counter decrement count = 1; LS1 completes write-back and commit: memory access instruction counter decrements by 1, current value = 2; counter decrement count = 2; The counter decreases by 2 = the first trigger base value 2 when LS2 writes to the queue, indicating that all valid commands (LS0, LS1) issued before LS2 have been submitted. Triggering LS2 pseudo-commit: Read the LS2 from the head of the invalid instruction queue and complete the pseudo-commit according to the normal instruction commit process—only update the warp state, ensure the instruction commit order, and there is no actual execution / data interaction. After the pseudo-commit is completed, LS2 is removed from the invalid queue.

[0086] Continue submitting valid commands → triggering an LS4 pseudo-commit: LS3 completes write-back and commit: memory access instruction counter decrements by 1, current value = 1; counter decrement count = 3; The core condition is met: the counter decreases by 3, which equals the second trigger reference value of 3 when LS4 is written to the queue, indicating that all valid commands (LS0, LS1, LS3) issued before LS4 have been submitted. Triggering an LS4 pseudo-commit: Read the LS4 from the new head of the invalid instruction queue, complete the pseudo-commit, update the warp state, and remove the LS4 from the invalid queue after maintaining the order. LS5 completes write-back and commit: the memory access instruction counter is decremented by 1, the current value is 0, and all valid instructions have been committed.

[0087] Step 9: End of process.

[0088] All valid instructions (LS0, LS1, LS3, LS5) complete the entire process of issue → execute → write back → commit, while all invalid instructions (LS2, LS4) complete the simplified process of decoding → pseudo issue → pseudo commit. The instruction commit order is LS0→LS1→LS2→LS3→LS4→LS5, which is completely consistent with the original instruction sequence. This realizes the sequential issue and commit of instructions within the warp, and invalid instructions do not flow through the execution pipeline, saving dynamic power consumption overhead.

[0089] In some embodiments, the counter is a dedicated counter for target type instructions. The counter only counts valid memory access instructions that have been issued but not committed. The pseudo-issue and pseudo-commit processes of the first invalid instruction and the second invalid instruction do not change the count value of the counter.

[0090] Specifically, a separate counter can be configured for each target instruction type (such as memory access instructions) to avoid interference between different instruction types. The counter only counts valid instructions that have been issued but not committed; spurious issues and spurious commits of invalid instructions do not affect the counter value. Even if a large number of invalid instructions are processed through spurious issues, the counter value remains unchanged, ensuring that it accurately reflects the actual state of valid instructions.

[0091] Specifically, dedicated counters can be configured with independent counters for each target instruction type, ensuring they do not interfere with each other. For example, memory access instructions have their own independent counters, and arithmetic instructions have their own independent counters. The spurious issue and spurious commit processes of invalid instructions do not change the counter values, ensuring that the counters only reflect the true state of valid instructions.

[0092] The dedicated counter design avoids interference between different types of instructions, while ensuring that the counter only reflects the status of valid instructions, providing an accurate basis for the triggering base value of invalid instructions.

[0093] In some embodiments, the above true submission includes: The execution pipeline completes the execution operation corresponding to the valid instructions of the target type, writes the execution result back to the instruction execution unit, and feeds back the instruction execution completion status; After confirming execution and write-back, the program counter status and instruction completion status of the instruction execution unit are updated, and the counter is decremented.

[0094] Specifically, a true commit can include an execution completion phase, a result write-back phase, a status feedback phase, and a status update phase. The execution completion phase allows valid instructions to complete memory read / write operations in the instruction execution unit's pipeline. The result write-back phase writes the execution result back to the register file or a specified location in the instruction execution unit. The status feedback phase reports the instruction execution completion status to the instruction execution unit, such as success or an exception. The status update phase includes program counter updates, instruction completion status updates, and counter decrement updates. A program counter update moves the program counter to the next instruction, allowing the instruction flow to continue. An instruction completion status update marks the instruction as completed in the instruction completion status register. A counter decrement update triggers a counter decrement operation, indicating that a valid instruction has been committed.

[0095] A complete true commit process ensures that the execution results of valid instructions are correctly written back, while providing accurate completion signals for counter updates and invalid instruction triggering.

[0096] In some embodiments, the above-mentioned pseudo-submission operation may include: Remove the first invalid instruction from the head of the invalid instruction queue; Update the program counter state of the instruction execution unit where the first invalid instruction is located; Update the instruction completion status of the instruction execution unit where the first invalid instruction is located; Keep the current count value of the counter unchanged.

[0097] Specifically, a pseudo-commit operation can include a queue removal phase and a status update phase. The queue removal phase involves retrieving the first invalid instruction from the head of the invalid instruction queue and deleting it from the queue data structure; subsequent invalid instructions automatically move to the front as the new head. The status update phase can include a program counter update and an instruction completion status update. The program counter update moves the program counter to point to the next instruction after the invalid instruction, effectively "skipping" the invalid instruction without changing its basic counting mechanism. The instruction completion status update marks the invalid instruction as completed in the instruction completion status register, causing the upper-level software or hardware to believe that the instruction has been processed normally, without recording any execution result (because it was not executed). The counter for the pseudo-commit operation remains unchanged.

[0098] By using pseudo-commit, invalid instructions can be exited at minimal cost, only updating the necessary state without involving actual computation, which greatly reduces the overhead of handling invalid instructions.

[0099] In some embodiments, after the above-described response to a valid transmitted command completes a true commit, in a specific implementation, it may further include: When the instruction execution unit detects an abnormal event that affects the normal submission process of valid instructions, it triggers a counter abnormal calibration operation. The counter anomaly calibration operation includes: Pause the current counter increment / decrement updates and invalid instruction false commit checks; The number of valid instructions of the same type that have been launched into the execution pipeline but have not yet been truly committed is recounted to obtain the calibration count value; The current count value of the counter is calibrated to the calibration count value; After calibration, resume the increment and decrement updates of the counter, as well as the false commit detection.

[0100] In some embodiments, the above-mentioned abnormal events may include at least one of the following: execution pipeline blockage, instruction commit interruption, hardware reset, clock gating exit, and power state switching.

[0101] Specifically, the instruction execution unit continuously monitors for abnormal events that may affect the submission process. When an anomaly is detected, all counter-related operations are immediately paused, such as pausing counter incrementing when a valid instruction is issued, pausing counter decrementing when a valid instruction is submitted, and pausing the triggering of false submissions for invalid instructions, to ensure that the counters do not change during calibration. Then, it iterates through all valid instructions currently issued to the execution pipeline, checks the submission completion status of each instruction, counts the number of instructions that have not completed a true submission, and obtains an accurate calibration count value. Next, the current value of the counter is forcibly set to the calibration count value, overwriting any old values ​​that may have been incorrect due to an anomaly. Finally, the counter incrementing, decrementing, and false submission checks are re-enabled, and subsequent instructions are processed normally.

[0102] Abnormal events refer to special circumstances that affect the normal submission process of valid instructions. These can include pipeline blockage (resource conflicts, data dependencies causing pipeline pauses), instruction submission interruption (external interruption requests interrupting the submission process), hardware reset (local or global reset signals), clock gating exit (wake-up from low-power mode), and power state switching (voltage / frequency changes). These events may cause the counter to deviate from the actual execution state, requiring calibration. Counter abnormal calibration can proceed as follows: upon detecting an abnormal event, pause normal counter updates, recount the number of currently executing valid instructions, calibrate the counter to an accurate value, and then resume operation. The calibration process ensures that the counter maintains accuracy even under abnormal conditions.

[0103] For example: The target type is: memory access instruction, and the initial value of the counter is 0; the normal process is: issue LS0, LS1 (valid → counter increments to 2; issue LS2 (first invalid instruction) → bind the first trigger base value = 2; Abnormal event: The execution pipeline was blocked due to a memory access conflict, which caused LS1 to fail to complete a true commit but the counter was mistakenly triggered to decrement (the counter changed from 2 to 1, which is inconsistent with the actual number of 2 issued but not committed).

[0104] A "pipeline blockage" anomaly event was detected → Pause immediately: The counter for pausing valid command issuance is incremented and updated. The counter for pausing valid instruction submissions is decremented. Suspend LS2's false commit detection (to avoid triggering false commits based on error count values); Recount: Traverse the memory access execution pipeline and confirm that the actual valid memory access instructions that have been issued but not committed are LS0 and LS1 (2 in total) → Calibrate the count value = 2; Calibrate the counter: Correct the current counter value from the incorrect 1 to 2; Recovery process: Re-allow counter increment / decrement updates. LS2's pseudo-commit judgment is executed based on the calibrated count value of 2 (two valid instructions need to be submitted subsequently, and a pseudo-commit is triggered when the count decreases to 2).

[0105] The abnormal calibration mechanism ensures that the counter remains accurate even under abnormal conditions, avoiding confusion in the processing of invalid instructions due to counter errors.

[0106] The overall implementation process of this invention is described below: Step 1: Instruction determination and classification.

[0107] The instruction execution unit determines the validity of the received target type instruction. For valid instructions, they are dispatched to the execution pipeline of the memory access unit for normal processing, and the counter is updated simultaneously; for invalid instructions, a bypass processing mechanism is activated.

[0108] Step 2: Invalid command pseudo-launch.

[0109] When an instruction is determined to be the first invalid instruction, it is prohibited from being issued to the execution pipeline to avoid consuming pipeline resources. Simultaneously, the current counter value is recorded as the first trigger reference value, and the invalid instruction and its trigger reference value are written to the invalid instruction queue, completing a pseudo-issue. The pseudo-issue consumes only a small amount of resources written to the queue and does not occupy the execution pipeline.

[0110] Step 3: Submit valid instructions and update the counter.

[0111] After a valid issued instruction completes its execution in the pipeline, a true commit is performed. A true commit includes writing the execution result back, updating the program counter status, and updating the instruction completion status. After a true commit, the current count value of the counter is decremented, indicating that the number of valid issued but uncommitted instructions has decreased by one.

[0112] Step 4: Invalid command pseudo-commit triggers judgment.

[0113] Whenever a valid instruction completes a true commit, causing the counter to decrement, the system checks the trigger threshold of the head instruction in the invalid instruction queue. When the current counter decrement reaches the trigger threshold of the head instruction, it indicates that all valid instructions of the same type issued before this invalid instruction have been committed, and a false commit is triggered for this invalid instruction.

[0114] Step 5: Invalid command pseudo-commit.

[0115] An invalid instruction that meets the trigger condition is retrieved from the invalid instruction queue, and a pseudo-commit operation is performed. The pseudo-commit only updates the internal state of the instruction execution unit (such as the program counter); it does not perform any actual computation or change the counter's value. After the pseudo-commit is complete, the invalid instruction is removed from the queue, and subsequent invalid instructions become the new head of the queue.

[0116] Step 6: Handling Abnormal Situations.

[0117] When an abnormal event affecting the normal submission process of valid instructions is detected (such as pipeline blockage, instruction submission interruption, etc.), an abnormal counter calibration operation is triggered to recount the number of valid instructions that have been issued but not submitted, and to calibrate the counter value to ensure the accuracy of the counter.

[0118] By cyclically executing the above six steps, this invention achieves efficient bypass processing of invalid instructions, enabling invalid instructions to complete state updates without occupying pipeline resources, effectively avoiding pipeline blockage.

[0119] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. For details, please refer to the foregoing descriptions of the relevant processing embodiments; they will not be repeated here.

[0120] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0121] In a specific implementation scenario, refer to Figure 5 As shown, instructions within a warp can be dispatched to the memory access instruction issue queue. Internally, the warp maintains a counter that records the number of issued but uncommitted instructions. Different instruction types have their own independent counters (e.g., memory access instructions have a corresponding memory access instruction execution counter). When a memory access instruction is deemed valid during the decoding stage, it is issued to the memory access execution pipeline. When a memory access instruction is deemed invalid during the decoding stage, this invalid instruction will not be issued to the memory access unit's execution pipeline (memory access execution pipeline), but will be temporarily stored in an invalid instruction queue. Simultaneously, the queue needs to record how many other issued but uncommitted instructions of the same type existed before this invalid memory access instruction. Since the instruction execution counter is decremented by 1 after each memory access instruction is written back and committed, when the number of times the corresponding instruction execution counter is decremented is equal to the value of the instruction execution counter previously written into the invalid instruction queue, it means that all memory access instructions issued before the invalid instruction have been executed and committed. At this time, the instruction at the head of the invalid instruction queue will be read out and immediately committed as a normally executed instruction. Since invalid instructions do not involve actual instruction execution, this instruction commit can be regarded as a pseudo-commit, mainly to ensure the order of instructions.

[0122] For example, given five consecutive data read instructions LS0~5, where LS2 and LS4 are invalid instructions, then from... Figure 6We can see that LS0, LS1, LS3, and LS5 are normally issued into the memory access execution pipeline, while LS2 and LS4 are written to the invalid instruction queue. From Figure 7 As can be seen, LS2 and LS4 do not have issue, execution, or write-back phases. These two invalid instructions are only committed at the correct time to ensure the sequential issue and commit of this instruction sequence. Write-back refers to the instruction execution unit returning the specific execution status of the instruction, while commit is the warp updating its state based on the status returned by the execution unit; this is the internal work of the warp.

[0123] This invention introduces an invalid instruction queue to temporarily store invalid instructions that do not need to be executed. After the instructions issued before the invalid instruction are committed, the invalid instruction can immediately complete the commit of the instruction, thereby ensuring the sequential issuance and sequential commit of the warp instruction sequence. The invalid instruction does not involve issuance, but is written into a queue, which is equivalent to a pseudo-issue. This can save the overhead of actually issuing invalid instructions, as well as the overhead of dynamic power consumption caused by passing them in the execution pipeline.

[0124] It should be noted that this invention is not limited to the problem of preserving the order of memory access instructions in GPUs, but is applicable to other similar hardware architecture designs that rely on execution pipelines to guarantee instruction order.

[0125] Based on the same inventive concept, this specification also provides a GPU internal instruction dispatch control device in its embodiments, as described in the following embodiments. Since the principle by which the GPU internal instruction dispatch control device solves the problem is similar to that of the GPU internal instruction dispatch control method, the implementation of the GPU internal instruction dispatch control device can be found in the embodiments of the GPU internal instruction dispatch control method; repeated details will not be elaborated further. References Figure 8 As shown, this device can be applied to the instruction execution unit of a parallel computing processor. The instruction execution unit is configured with a counter and an invalid instruction queue. The device may include: The invalid instruction queue module 801 can be used to prevent the first invalid instruction from being issued to the execution pipeline of the memory access unit in response to the instruction of the target type being determined as the first invalid instruction, and to write the first invalid instruction and the first triggering reference value of the first invalid instruction into the invalid instruction queue to complete the pseudo-issue. The first triggering reference value is the count value of the issued but not submitted valid instructions of the same type counted by the counter at the time when the first invalid instruction is written into the invalid instruction queue. The first invalid instruction pseudo-submission module 802 can be used to respond to a valid instruction that has been issued to complete a true submission, and to update the current count value of the counter by decrementing it. When the number of times the current count value is reduced reaches the first triggering reference value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo-submission operation is performed. The pseudo-submission operation only updates the internal state of the instruction execution unit.

[0126] In some embodiments, the first invalid instruction pseudo-submission module 802 may also be used to respond to an instruction of the target type being determined to be a valid instruction, to issue the valid instruction to the execution pipeline, and to increment the current count value of the counter. The increment update is to increment the current count value of the counter by 1 when the valid instruction is issued but not submitted, and a single valid instruction issuance triggers only one counter increment operation.

[0127] In some embodiments, the decrementing update in the first invalid instruction pseudo-submission module 802 may include decrementing the current count value of the counter by 1 when the valid instruction is submitted, and a single valid instruction submission triggers only one decrementing operation of the counter.

[0128] In some embodiments, the decrease in the current count value in the first invalid instruction pseudo-submission module 802 is determined based on the number of submissions of valid instructions of the same type. The decrease in the current count value reaching the first triggering benchmark value indicates that all valid instructions of the same type issued before the first invalid instruction have been submitted.

[0129] In some embodiments, the first invalid instruction pseudo-submission module 802 may further be used to respond to an instruction of the target type being determined as a second invalid instruction, write the second invalid instruction and its second triggering reference value into the invalid instruction queue to complete a pseudo-launch, wherein the second triggering reference value is the count value of the issued but not submitted valid instructions of the same type counted by the counter at the time the second invalid instruction is written into the invalid instruction queue, the first invalid instruction is written to the head of the invalid instruction queue, and the second invalid instruction is written after the first invalid instruction; responding to the first invalid instruction completing the pseudo-submission operation and being removed from the invalid instruction queue, making the second invalid instruction the new head of the invalid instruction queue; when the decrease in the current count value reaches the second triggering reference value, retrieving the second invalid instruction from the new head of the invalid instruction queue and performing a pseudo-submission operation.

[0130] In some embodiments, the counter is a dedicated counter for target type instructions. The counter only counts valid memory access instructions that have been issued but not committed. The pseudo-issue and pseudo-commit processes of the first invalid instruction and the second invalid instruction do not change the count value of the counter.

[0131] In some embodiments, the true submission in the first invalid instruction pseudo-submission module 802 described above may include: The execution pipeline completes the execution operation corresponding to the valid instructions of the target type, writes the execution result back to the instruction execution unit, and feeds back the instruction execution completion status; After confirming execution and write-back, the program counter status and instruction completion status of the instruction execution unit are updated, and the counter is decremented.

[0132] In some embodiments, the pseudo-submission in the first invalid instruction pseudo-submission module 802 described above may include: Remove the first invalid instruction from the head of the invalid instruction queue; Update the program counter state of the instruction execution unit where the first invalid instruction is located; Update the instruction completion status of the instruction execution unit where the first invalid instruction is located; Keep the current count value of the counter unchanged.

[0133] In some embodiments, the first invalid instruction pseudo-submission module 802 described above can also be used to trigger a counter abnormal calibration operation when the instruction execution unit detects an abnormal event affecting the normal submission process of valid instructions; the counter abnormal calibration operation includes: pausing the current counter increment update, decrement update, and invalid instruction pseudo-submission judgment; recounting the number of valid instructions of the same type that have been issued to the execution pipeline but have not completed true submission, and obtaining a calibration count value; calibrating the current count value of the counter to the calibration count value; and resuming the counter increment update, decrement update, and pseudo-submission judgment after calibration.

[0134] In some embodiments, the abnormal event includes at least one of the following: execution pipeline blockage, instruction commit interruption, hardware reset, clock gating exit, and power state switching.

[0135] This specification also provides a GPU, including a streaming multiprocessor, wherein the streaming multiprocessor integrates the aforementioned instruction execution unit, and the GPU executes, through the instruction execution unit, as described above. Figure 4 The GPU internal instruction issue control method shown in the diagram allows each stream multiprocessor's instruction execution unit to independently complete instruction issue control.

[0136] In some embodiments, the instruction execution unit includes a decoding unit, an execution pipeline, a counter, an invalid instruction queue, and a commit unit. The decoding unit is used to determine the validity of instructions. The execution pipeline is used to issue, execute, and write back valid instructions. The counter is used to count the number of valid instructions of the same type that have been issued but not committed. The invalid instruction queue is used to temporarily store invalid instructions and their triggering base values. The commit unit is used to complete the true commit of valid instructions and the false commit of invalid instructions.

[0137] This specification also provides an embodiment of a chip, such as... Figure 9 As shown, the chip may include a processor 901 and a memory 902, wherein the processor 901 and the memory 902 can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0138] Processor 901 can be a parallel computing processor (CPU), specifically integrating the instruction execution unit described in the foregoing embodiments. This instruction execution unit is configured with a counter and an invalid instruction queue to implement the instruction issuance control method in the embodiments of the present invention. Processor 901 executes various functional applications and data processing by running non-transitory software programs, instructions, and modules stored in memory 902, thereby implementing the GPU internal instruction issuance control method in the above method embodiments.

[0139] The memory 902, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the instruction out-of-order execution method in the embodiments of the present invention.

[0140] Memory 902 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function. The data storage area may store data created by processor 901, including counter values, invalid instruction queue entries, program counter status, instruction completion status, etc. Furthermore, memory 902 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 902 may optionally include memory remotely located relative to processor 901, and these remote memories may be connected to processor 901 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0141] The one or more modules are stored in the memory 902, and when executed by the processor 901, they perform the following: Figure 4 The GPU internal instruction issuance control method is shown.

[0142] By integrating the instruction issuance control method of the present invention into the GPU chip through the aforementioned chip, a complete hardware solution can be formed, which can be deployed and applied in scenarios such as graphics rendering, scientific computing, and artificial intelligence inference, effectively reducing the dynamic power consumption caused by invalid instruction processing and improving the energy efficiency ratio of the processor.

[0143] For details regarding the chip, please refer to the relevant descriptions and effects in the above method embodiments; they will not be repeated here.

[0144] This specification also provides a computer storage medium storing computer program instructions, which, when executed, implement the steps of the above-described GPU internal instruction issuance control method.

[0145] This specification also provides a computer program product comprising a computer program that, when executed, implements the steps of the above-described GPU internal instruction issuance control method.

[0146] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0147] The various embodiments in this specification are described in a progressive manner. For the same or similar parts between the various embodiments, please refer to each other. The focus of each embodiment is to describe the differences from other embodiments.

[0148] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions.

[0149] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0150] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute certain parts of the methods of various embodiments of this application.

[0151] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer chips, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0152] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0153] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to the embodiments described herein by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A GPU internal instruction issue control method, applied to the instruction execution unit of a parallel computing processor, wherein the instruction execution unit is configured with a counter and an invalid instruction queue, characterized in that, include: In response to an instruction of the target type being determined as a first invalid instruction, the first invalid instruction is prohibited from being issued to the execution pipeline of the instruction execution unit. The first invalid instruction and its first triggering reference value are written into the invalid instruction queue to complete a pseudo-issue. The first triggering reference value is the count of issued but not submitted valid instructions of the same type when the first invalid instruction is written into the invalid instruction queue. In response to a valid instruction that has been issued completing a true commit, the current count value of the counter is decremented and updated. When the decrease in the current count value reaches the first triggering reference value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo-commit operation is performed. The pseudo-commit operation only updates the internal state of the instruction execution unit.

2. The method according to claim 1, characterized in that, The method further includes: In response to an instruction of the target type being determined to be a valid instruction, the valid instruction is issued to the execution pipeline, and the current count value of the counter is incremented. The incrementing update is performed by incrementing the current count value of the counter by 1 when the valid instruction is issued but not submitted, and the counter incrementing operation is triggered only once for each valid instruction issuance.

3. The method according to claim 1, characterized in that, The decrementing update includes decrementing the current count value of the counter by 1 when the valid instruction is submitted, and the counter decrementing operation is triggered only once for each valid instruction submission.

4. The method according to claim 1, characterized in that, The decrease in the current count value is determined based on the number of valid instructions of the same type submitted. When the decrease in the current count value reaches the first triggering benchmark value, it indicates that all valid instructions of the same type issued before the first invalid instruction have been submitted.

5. The method according to claim 1, characterized in that, The method further includes: In response to the target type instruction being determined as the second invalid instruction, the second invalid instruction and the second triggering reference value of the second invalid instruction are written into the invalid instruction queue to complete the pseudo-emission. The second triggering reference value is the count value of the same type of valid instructions that have been issued but not submitted, which is counted by the counter at the time when the second invalid instruction is written into the invalid instruction queue. The first invalid instruction is written to the head of the invalid instruction queue, and the second invalid instruction is written after the first invalid instruction. In response to the first invalid instruction completing the pseudo-commit operation and being removed from the invalid instruction queue, the second invalid instruction becomes the new head of the invalid instruction queue; When the number of times the current count value decreases reaches the second trigger baseline value, the second invalid instruction is retrieved from the new head of the invalid instruction queue and a pseudo-commit operation is performed.

6. The method according to claim 1, characterized in that, The counter is a dedicated counter for target type instructions. The counter only counts valid memory access instructions that have been issued but not committed. The pseudo-issue and pseudo-commit processes of the first invalid instruction and the second invalid instruction do not change the count value of the counter.

7. The method according to claim 1, characterized in that, The true commit includes: The execution pipeline completes the execution operation corresponding to the valid instructions of the target type, writes the execution result back to the instruction execution unit, and feeds back the instruction execution completion status; After confirming execution and write-back, the program counter status and instruction completion status of the instruction execution unit are updated, and the counter is decremented.

8. The method according to claim 1, characterized in that, The pseudo-submission operation includes: Remove the first invalid instruction from the head of the invalid instruction queue; Update the program counter state of the instruction execution unit where the first invalid instruction is located; Update the instruction completion status of the instruction execution unit where the first invalid instruction is located; Keep the current count value of the counter unchanged.

9. The method according to claim 1, characterized in that, The method further includes: When the instruction execution unit detects an abnormal event that affects the normal submission process of valid instructions, it triggers a counter abnormal calibration operation. The counter anomaly calibration operation includes: Pause the current counter increment / decrement updates and invalid instruction false commit checks; The number of valid instructions of the same type that have been launched into the execution pipeline but have not yet been truly committed is recounted to obtain the calibration count value; The current count value of the counter is calibrated to the calibration count value; After calibration, resume the increment and decrement updates of the counter, as well as the false commit detection.

10. The method according to claim 9, characterized in that, The abnormal event includes at least one of the following: execution pipeline blockage, instruction commit interruption, hardware reset, clock gating exit, and power state switching.

11. A GPU internal instruction issue control device, applied to the instruction execution unit of a parallel computing processor, wherein the instruction execution unit is configured with a counter and an invalid instruction queue, characterized in that, include: The invalid instruction queue module is used to respond to the first invalid instruction being determined as the first invalid instruction, prohibit the first invalid instruction from being issued to the execution pipeline of the memory access unit, and write the first invalid instruction and the first triggering reference value of the first invalid instruction into the invalid instruction queue to complete the pseudo-issue. The first triggering reference value is the count value of the issued but not submitted valid instructions of the same type when the first invalid instruction is written into the invalid instruction queue. The first invalid instruction pseudo-commit module is used to respond to the issued valid instruction completing the true commit by decrementing the current count value of the counter. When the decrease in the current count value reaches the first triggering benchmark value, the first invalid instruction is retrieved from the invalid instruction queue and a pseudo-commit operation is performed. The pseudo-commit operation only updates the internal state of the instruction execution unit.

12. A GPU, characterized in that, The system includes a streaming multiprocessor, which integrates an instruction execution unit. The GPU executes the method of any one of claims 1-10 through the instruction execution unit, and the instruction execution unit of each streaming multiprocessor independently completes instruction issuance control.

13. The GPU according to claim 12, characterized in that, The instruction execution unit includes a decoding unit, an execution pipeline, a counter, an invalid instruction queue, and a submission unit. The decoding unit is used to determine the validity of instructions. The execution pipeline is used to issue, execute, and write back valid instructions. The counter is used to count the number of valid instructions of the same type that have been issued but not submitted. The invalid instruction queue is used to temporarily store invalid instructions and their triggering base values. The submission unit is used to complete the true submission of valid instructions and the false submission of invalid instructions.

14. A chip, characterized in that, The method includes a processor and a memory storing processor-executable instructions, wherein the processor, when executing the instructions, implements the steps of the method according to any one of claims 1-10.

15. A computer storage medium, characterized in that, The computer storage medium stores computer program instructions, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

16. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

Images