Graphics processing system

Abstract

The invention relates to a graphics processing system. A graphics processor is provided comprising a programmable execution unit operable to execute a program for a group of respective execution threads. An eviction check circuit is provided configured to check an instruction as it is fetched from an instruction cache for execution to determine if the instruction comprises any conditional eviction condition which, if not satisfied, indicates that the program associated with the instruction should not continue to be executed for the group of execution threads. The eviction check circuit is then configured to check if any conditional eviction condition is satisfied at that time and to allow the execution unit to continue program execution or cause the group of threads to be evicted.

Description

Technical Field

[0001] The present invention generally relates to the operation of a graphics processing unit (GPU), and more particularly to the operation of a graphics processing unit including a programmable execution unit (e.g., a shader) operable to execute a set of instructions in a program to perform data processing operations. Background Technology

[0002] Many modern graphics processing units (GPUs) include one or more processing (shader) cores, which, for example, execute programmable processing stages (often referred to as "shaders") within a GPU-implemented graphics processing pipeline. For instance, a graphics processing pipeline may include one or more, and typically all, of the following: geometry shaders, vertex shaders, and fragment (pixel) shaders. These shaders are programmable processing stages that execute shader programs on input data values ​​to generate desired output datasets (such as appropriately shaded and rendered fragment data in the case of fragment shaders) for processing by the remainder of the graphics processing pipeline and / or for output.

[0003] It is also known to use graphics processors and graphics processing pipelines (and particularly their shader operations) to perform more general computational tasks, such as those requiring similar operations on a large number of different input data values. These operations are often called "computation shading" operations, and many specific computation APIs (such as OpenCL and Vulkan) have been developed for use when it is desirable to perform more general computational operations using graphics processors and graphics processing pipelines. Computation shading is used to compute arbitrary information. While computation shading can be used to process graphics-dependent data if needed, it is typically used for tasks not directly related to performing graphics processing.

[0004] Therefore, the graphics processor shader core is a processing unit that performs processing by running (usually small) programs for the various "work items" in the generated output. In the case of generating graphics output (such as a rendering target, such as a frame to be displayed), these "work items" are typically vertex or sampled positions (e.g., in the case of a fragment shader). In the case of computational shading operations, the various "work items" in the generated output will be, for example, data instances (items) in the workspace where the computational shading operation is being performed.

[0005] In graphics processor shader operations (including computational shader operations), each work "item" is processed by an execution thread that executes the instructions of the shader program in question for the work item in question.

[0006] In some cases, execution threads (each corresponding to a work item) are grouped together into a "group" or "bundle" of threads, where the threads in one group run in a lockstep manner, for example, one instruction at a time. This way, instruction fetching and scheduling resources can be shared among all threads in the group, thereby improving the execution efficiency of the shader program.

[0007] The applicant believes that there is still room for further improvement in efficiency when the (shader) program is executed within the graphics processor. Summary of the Invention

[0008] According to a first aspect of the present invention, a graphics processor is provided, the graphics processor comprising:

[0009] A programmable execution unit capable of operating to execute a program to perform processing operations, wherein, when executing a program, the execution unit executes the program for each group of one or more execution threads;

[0010] An instruction cache stores the instructions of a program to be executed by an execution unit, wherein, when executing a program for a corresponding group of one or more execution threads, the execution unit is arranged to fetch instructions from the instruction cache for execution; and

[0011] An eviction check circuit is configured to, for an instruction fetched from the instruction cache for the corresponding group of the execution thread, before executing the instruction:

[0012] Determine whether the instruction includes one or more "conditional eviction" conditions that, if not met, indicate that the program associated with the instruction should not continue execution for the group of the execution thread; and

[0013] When it is determined that the instruction includes one or more "conditional eviction" conditions that, if not satisfied, indicate that the program associated with the instruction should not continue to be executed for the group of the execution thread, determine whether the "conditional eviction" conditions are satisfied.

[0014] Among these, the determination of whether the "conditional expulsion" conditions are met includes:

[0015] When it is determined that the "conditional eviction" condition is met, the eviction check circuit allows the execution unit to continue executing the program for the group of execution threads;

[0016] When it is determined that the "conditional eviction" condition is not met, the eviction check circuit causes the execution unit to evict the group of execution threads associated with the instruction.

[0017] According to a second aspect of the present invention, a method for operating a graphics processor is provided.

[0018] The graphics processor includes:

[0019] A programmable execution unit, operable to execute a program to perform processing operations, wherein, when executing a program, the execution unit executes the program for each group of one or more execution threads; and

[0020] An instruction cache stores the instructions of a program to be executed by an execution unit, wherein, when executing a program for a corresponding group of one or more execution threads, the execution unit is arranged to fetch instructions from the instruction cache for execution.

[0021] The method includes the following steps:

[0022] When an instruction is fetched from the instruction cache for the appropriate group of the execution thread, before executing the instruction:

[0023] Determine whether the instruction includes one or more "conditional eviction" conditions that, if not met, indicate that the program associated with the instruction should not continue execution for the group of the execution thread; and

[0024] When it is determined that the instruction includes one or more "conditional eviction" conditions that, if not satisfied, indicate that the program associated with the instruction should not continue to be executed for the group of the execution thread, determine whether the "conditional eviction" conditions are satisfied.

[0025] In response to the determination of whether the "conditional expulsion" conditions are met, then:

[0026] When it is determined that the "conditional eviction" condition is met, the program continues to execute for the group of executing threads; or

[0027] When it is determined that the "conditional eviction" condition is not met, the group of execution threads associated with the instruction is evictioned.

[0028] The present invention relates to executing a program within a programmable execution unit (e.g., a shader) of a graphics processor.

[0029] Specifically, the present invention relates to instructions in a (shader) program that are processed when the instructions fetched for a group of execution threads include one or more "conditional eviction" conditions, which, if not met, indicate that the group of execution threads should not continue to execute the program associated with the instructions, and the instructions according to the invention may thus cause the execution unit to evict the group of execution threads associated with the instructions, for example, as will be explained further below.

[0030] For example, in a typical graphics processor, there may be multiple groups of execution threads executing corresponding shader programs to perform related (graphics) processing operations on the same output. In this case, there may be various processing (e.g., data) dependencies between the processing operations performed by the respective groups of execution threads, and these dependencies need to be managed appropriately, for example, to ensure that the processing of the output is consistent across different groups of execution threads.

[0031] These dependencies can (and preferably in this invention) be handled using one or more dependency counters (slots) maintained by the graphics processor and can be updated / cleared as processing operations proceed. Thus, in an implementation, the graphics processor is operable to track (e.g., by means of appropriate counters (slots)) any dependencies of one (and said) thread in a thread group executing a shader program, and then uses this dependency tracking to determine if any unresolved (unsatisfied) dependencies exist for an instruction. Therefore, an instruction with such a dependency can, for example and preferably as part of the instruction itself, include appropriate dependency conditions (e.g., in the form of a "wait" modifier), indicating, for example, which dependency counters (slots) need to be cleared before (e.g.) the next instruction in the program can be executed, and preventing the next instruction from being executed (i.e., causing the program to wait) until the relevant dependency counters (slots) are cleared.

[0032] Therefore, in an implementation, when the instructions fetched for execution include such conditional dependencies, it means that the next instruction in the program should not be executed until the relevant dependency counter (slot) has been checked / cleared.

[0033] In this context, to prevent the execution of instructions with unresolved (unsatisfied) dependencies, an execution unit may be evicted from the group of execution threads when an instruction is fetched for the group of execution threads that includes a dependency condition such as indicating that the next (or subsequent) instruction in the program should not be executed due to an unresolved dependency, rather than having the group of execution threads associated with the instruction wait for the dependency to be cleared (which may take, for example, multiple cycles).

[0034] Therefore, this approach can effectively utilize execution units. For example, in a typical shader program, instructions must be executed in a strict order, such that if the program must wait for a given instruction, the shader program cannot continue until the action causing the wait is completed. Therefore, if a shader program cannot proceed (e.g., due to unresolved dependencies), the group of execution threads is evicted to allow for checking dependencies and then appropriate rescheduling so that another group of execution threads can be scheduled to / from the execution unit more efficiently.

[0035] For example, when a group of execution threads is evicted, the evicted group of execution threads can then, for example, return to the thread group execution controller (scheduler) circuitry, so that the thread group can be rescheduled to / to the execution unit at a later time (e.g., when the dependency is cleared, at which point the instruction can be executed), and the program can then proceed through the processing obstacles (if any) associated with the instruction in question, for example, and execute the next instruction in the (shader) program, for example, to complete the data processing operation.

[0036] In this invention, the group of execution threads is not always evicted whenever an instruction includes one or more 'conditional' dependencies (eviction conditions), for example, so as to allow dependencies to be checked / updated when it is determined during instruction fetching that the instruction indicates one or more dependency conditions that need to be checked before the program can continue execution (e.g., by continuing to fetch the next instruction for execution), and then further checks are performed at this time to determine whether the dependencies have been satisfied.

[0037] Therefore, the present invention relates to situations where instructions may include one or more “conditional eviction” conditions (such as dependencies) that need to be checked. The present invention does not always evict the group of execution threads to allow condition checking, but rather includes eviction check circuitry configured to determine whether a “conditional eviction” condition is met.

[0038] In response to this determination, when the conditional eviction condition is not met (e.g., the instruction indicates a potential unresolved (unsatisfied) dependency, and the group of execution threads needs to wait before executing the instruction), the group of execution threads in question is evicted, for example, by clearing its corresponding execution unit slot, so that a new group of execution threads can be assigned to the execution unit to replace its position.

[0039] On the other hand, when the check determines that the conditional expulsion condition (which allows and should continue execution) has been met, the expulsion check circuit can thus enable the execution unit to fetch the next instruction for execution, for example, so that the execution of the program can continue accordingly.

[0040] In this way, instances of groups of execution threads that are unnecessarily evicted can be reduced, thereby providing improved shader performance, as will be explained further below.

[0041] For example, compared to the present invention, one method for handling such conditional eviction conditions (e.g., dependencies) that require checking would be to conservatively evict the corresponding group of execution threads whenever an instruction containing any conditional eviction condition is fetched. Therefore, whenever an instruction containing a dependency condition is fetched for a group of execution threads, the group of execution threads will always be evicted to allow the condition to be checked.

[0042] However, in this case, there may be instances where an instruction causes the execution thread to be evicted from its group to allow the dependency condition to be checked, even though the program could have safely continued execution (e.g., because the dependency had been satisfied).

[0043] For example, in this approach, the group of execution threads in question is always evicted whenever a dependency needs to be checked. However, the present invention recognizes that, typically, dependencies may already be satisfied when instructions are fetched, in which case program execution can safely continue, for example, by fetching the next instruction for execution.

[0044] Therefore, in some cases, the above conservative eviction method may result in the eviction of the execution thread group, necessitating a rescheduling of the execution thread group, even when fetching the next instruction and continuing program execution would actually be safe. This unnecessary eviction of execution threads can introduce latency, thereby degrading shader performance.

[0045] The eviction of a group of execution threads also incurs associated costs in terms of register bandwidth. For example, each execution thread is preferably allocated a set of one or more registers for its use while executing a shader program. When a group of execution threads is evicted (e.g., to check dependency slots), its registers are then preferably written back (e.g., to a register file). Therefore, it is also for this reason, such as to save register bandwidth, that it is desirable to reduce instances of unnecessary thread evictions.

[0046] Therefore, the present invention recognizes that the above-described method of conservatively evicting and rescheduling groups of execution threads whenever unresolved dependencies exist may be relatively inefficient in some cases.

[0047] In contrast, in this invention, by providing an eviction check circuit, the number of instances of a group of execution threads that are unnecessarily evicted can be reduced. This eviction check circuit is operable to and arranged to check an instruction when it is fetched to determine whether any “conditional eviction” conditions associated with the instruction are met.

[0048] In the graphics processor of the present invention, instructions are stored in a suitable instruction cache (e.g., a local instruction cache of the graphics processor), and the instructions can be retrieved from the instruction cache for group execution by execution threads in the execution unit.

[0049] Therefore, as will be further explained below, the graphics processor is operable to spawn a group of execution threads for executing individual shader programs, and then schedule the group of execution threads to / from execution units for execution. When the group of execution threads is scheduled to / from an execution unit, the execution unit is then arranged to fetch relevant instructions from its instruction cache for the group of execution threads to execute. In a preferred embodiment, when an execution unit issues a request for the (next) instruction to the group of execution threads (in parallel with the instructions provided to the execution threads), an eviction check circuit is arranged to check the fetched instructions while they are being fetched for execution.

[0050] In this way, the eviction check circuitry can check an instruction as it is issued to the execution unit for execution by the corresponding group of execution threads. Preferably, the eviction check circuitry is part of the execution unit itself. However, other (logical) arrangements are also possible.

[0051] According to the present invention, the inspection is preferably performed in two parts, as will be explained further below.

[0052] First, check if the instruction includes any conditions that might require evict the group from the executing thread.

[0053] This could be a conditional eviction condition (such as a dependency) that needs to be met before program execution can continue. For example, as described above, in an implementation, an instruction could include a conditional eviction condition (such as a dependency) that indicates that the next (following) instruction in the program should not be executed if the conditional eviction condition is not met. In this way, by adding a conditional eviction condition (e.g., a dependency) to a preceding instruction (meaning there is an unresolved dependency (meaning the next instruction should not be executed)), there is no need to fetch the next instruction (and therefore it is preferable not to fetch the next instruction). However, other arrangements are also possible; for example, the conditional eviction condition included in the instruction could indicate that the instruction itself should not be executed until the conditional eviction condition is met (rather than indicating that the next instruction should not be executed).

[0054] In addition, there may be various other conditions associated with instructions that could lead to the expulsion of a group from the execution thread.

[0055] Specifically, there may be certain conditions, if which mean that the group of executing threads should always be evicted, regardless of any other conditions (e.g., dependency conditions).

[0056] For example, it might be desirable to evict a group of execution threads from the program whenever (and whenever) a program includes a messaging instruction. For instance, in some implementations, messaging instructions are not executed by the (same) execution unit, so the group of execution threads should always be evicted when the program includes a messaging instruction. This can be appropriately indicated as part of the instruction itself, enabling instruction checking circuitry to determine whether the instruction corresponds to a messaging instruction based on the (current) instruction. Alternatively, in some implementations, this can be indicated in previous instructions, for example, enabling instruction checking circuitry to determine whether the next instruction in the program corresponds to a messaging instruction based on the (current) instruction. In either case, when it is determined that the current instruction or the next instruction corresponds to a messaging instruction, the execution unit can trigger an unconditional eviction of the group of execution threads (i.e., regardless of any unresolved processing dependencies).

[0057] Therefore, in an implementation, the execution unit can be configured to always (unconditionally) expel the execution thread from the group when the fetched instruction corresponds to a message passing instruction or when the next instruction in the fetched instruction instruction corresponds to a message passing instruction.

[0058] Another example where it might be expected to always trigger the eviction of the execution thread group is when the instruction is a branch instruction. For example, in this case, after the branch instruction is executed, it might be expected (or necessary) to evict the execution thread group so that the shader program can be appropriately rescheduled to execute, for example, a different sequence of instructions for the new branch. Similarly, in the case of a diverging execution thread group, it might be expected (or necessary) to evict the execution thread group to perform a branch reconvergence check, and thus this might also trigger an unconditional eviction of the execution thread group.

[0059] Other examples where unconditional eviction from a group of execution threads might be expected are when it can be determined that work items associated with the program being executed by that execution thread group can be discarded, for example, because they do not contribute to the output. In graphics processing operations, this might occur, for example, when a graphics fragment associated with a shader program is completely occluded by a fragment processed earlier. In this case, the graphics fragment can be appropriately culled, and the shader program can be terminated early (and accordingly eviction from the group of execution threads). Any such fragment culling operation can be tracked separately, and then a separate check can be performed to determine whether the work item of the shader program to which the instruction belongs can be discarded, in which case the execution unit can be eviction from the group of execution threads, regardless of the outcome of any other checks performed (e.g., dependency checks).

[0060] Therefore, whenever an instruction is associated with such a condition, it can cause the execution unit to unconditionally evict the group of execution threads. Thus, the existence of such an "unconditional eviction" condition can be indicated to the execution unit, thereby causing the execution unit to appropriately evict the group of execution threads.

[0061] In this case, even if the instruction includes one or more dependency conditions, there is no need to check whether the dependency conditions are met, because the execution thread should be evicted from the group anyway.

[0062] In other words, determining whether an instruction includes one or more “conditional eviction” conditions, and therefore subsequently determining whether any such “conditional eviction” conditions are met, is preferably conditional on the existence of any “unconditional eviction” conditions.

[0063] Therefore, in the implementation, the eviction check circuit is also configured to determine whether the instruction is associated with any unconditional eviction condition, and if such an unconditional eviction condition exists, to indicate that the group of execution threads associated with the instruction should always be evictioned.

[0064] In this configuration, the eviction check circuit is preferably configured to determine whether the instruction includes any unconditional eviction conditions before determining whether the instruction includes one or more conditional eviction conditions. When it is determined that the instruction includes any unconditional eviction conditions, the eviction check circuit then preferably evictions the execution unit from the group of execution threads without checking whether the instruction includes one or more conditional eviction conditions or whether any conditional eviction conditions are met.

[0065] On the other hand, in response to determining that the instruction is not associated with any such "unconditional eviction" condition, it is then preferably checked whether the instruction includes any "conditional eviction" condition, and if it is determined that the instruction does include one or more "conditional eviction" conditions, according to the invention, further checks are then performed to check whether the "conditional eviction" conditions have been met.

[0066] In other words, when it is determined that there are one or more “conditional eviction” conditions for an instruction that may still need to be checked (e.g., because there are no other “unconditional eviction” conditions that would otherwise cause the group of execution threads to be evictioned), the eviction check circuitry is arranged to determine whether the dependency conditions are actually met at this point, for example, rather than simply eviction of the group of execution threads in the more conservative manner discussed above.

[0067] When it is determined that the "conditional eviction" condition is not met, the eviction check circuit then causes the execution unit to evict the group of execution threads accordingly (e.g., after the execution of the current instruction), for example, to allow the group of execution threads to be appropriately rescheduled (e.g., when the "conditional eviction" condition is met).

[0068] However, when it is determined based on this further check that the "conditional eviction" condition has actually been met, the "conditional eviction" condition can be effectively ignored, so the execution unit can (and does) continue executing the program, for example by fetching the next instruction for execution, without eviction from the group of execution threads.

[0069] (Any instruction that does not include any such unconditional or conditional eviction condition (because such a condition does not exist, or because any conditional eviction condition (e.g., a dependency) has been cleared) can of course be fetched and executed, for example, as usual.)

[0070] Therefore, the present invention can check an instruction while it is being issued to an execution unit for execution. Accordingly, this pre-execution instruction check can be used to determine whether any conditions exist that would mean the execution thread group should be evicted. Furthermore, in cases where an instruction includes one or more "conditional eviction" conditions (e.g., dependencies) that need to be cleared before continuing program execution, it can be determined whether the conditions (dependencies) have been met. In such cases, the conditions (dependencies) can be safely ignored, and the next instruction can be fetched for execution, etc., without having to evict the execution thread group.

[0071] Therefore, the present invention can reduce the number of instances in which groups of execution threads are unnecessarily evicted (e.g., in cases where it is safe to continue program execution, the group of execution threads is evicted, for example because instruction checking circuitry allows (full) checking of any dependencies or other possible instruction-related "conditional eviction" conditions that could lead to the eviction of the group of execution threads while instructions are being fetched for execution).

[0072] This means that if, for example, the data dependency indicated by the instruction has been satisfied, there is no need to evict the group of execution threads to check if this is the case (as is done in some existing graphics processors), and program execution can safely continue without evictping the group of execution threads. The present invention can therefore provide improved and more efficient shader operation.

[0073] Furthermore, this eviction check can be implemented (entirely) within the microarchitecture, for example, by providing a suitable lookup interface that allows the instruction to be checked when it is fetched from the instruction cache, and, for example, and preferably, without modifying the instruction set.

[0074] Therefore, the present invention can provide various improvements in this respect.

[0075] The graphics processor operating in the manner of the present invention can be any suitable and desired graphics processor (graphics processing unit GPU) comprising one or more programmable execution units.

[0076] The graphics processing unit can perform any suitable and desired form of graphics processing, such as rasterization-based rendering, ray tracing, hybrid ray tracing, etc.

[0077] The execution unit of a graphics processor can be any suitable and desired execution unit operable for executing shader programs.

[0078] A graphics processor may include a single execution unit or may have multiple execution units. In the presence of multiple execution units, each execution unit may, and indeed does, operate in the manner described herein.

[0079] In the presence of multiple execution units, each execution unit can be provided as a separate circuit to the other execution units of the graphics processor, or the execution units can share some or all of the circuits (circuit elements) in their circuitry.

[0080] For example, in a preferred embodiment, the eviction check circuit is part of the execution itself. In the presence of multiple execution units, each execution can therefore have its own eviction check circuit. However, it is also possible for multiple execution units to share the eviction check circuit.

[0081] Each execution unit should, and indeed in the implementation, include appropriate circuitry (processing circuitry / logic) for performing the operations required by the execution unit.

[0082] Therefore, each execution unit will, for example and in implementation, include a set of at least one functional unit (circuit) operable to perform data processing operations of instructions being executed by the execution thread. Depending on the operation to be performed by the execution unit, the execution unit may include only a single functional unit, or it may include multiple functional units.

[0083] One or more functional units may include any desired and suitable one or more functional units operable to perform data processing operations in response to and according to program instructions. Therefore, one or more functional units in an implementation include one or more or all of the following: arithmetic units (arithmetic logic units) (addition, subtraction, multiplication, division, etc.), bit manipulation units (inversion, swapping, shifting, etc.), logical arithmetic units (AND, OR, NAND, NOR, NOT, XOR, etc.), load-type units (such as change, texture, or load units in the case of a graphics processor), storage-type units (such as hybrid or storage units), etc.

[0084] In cases where execution threads can be grouped into thread groups (“thread bundles”) (as explained further below), the functional units of a given programmable execution unit are configured and operable in an implementation to facilitate such a thread group arrangement. Thus, for example, in an implementation, the functional units are arranged as individual execution channels, one for each thread that a thread group (thread bundle) may contain (e.g., such that for a system where execution threads are grouped into eight threads (thread bundles), the functional units can operate as eight corresponding (and identical) execution channels), allowing the programmable execution unit to execute the same instruction in parallel for each thread of the thread group (thread bundle).

[0085] The graphics processor in the implementation also includes any other suitable and desired units and circuits required for the operation of the programmable execution unit, such as suitable control circuitry (control logic) for controlling the execution unit to induce and perform desired and appropriate processing operations.

[0086] Therefore, the graphics processor in the embodiment also includes appropriate thread group execution controller (scheduler) circuitry operable to issue thread groups to programmable execution units for execution and to control the scheduling of thread groups to / from programmable execution units for execution.

[0087] In this implementation, the graphics processor includes one or more of the following, and all of them in this implementation: one or more instruction decoding circuits operable to decode instructions to be executed; one or more instruction issuing circuits operable to issue instructions to be executed to a programmable execution unit so that the execution unit executes the required instructions of a thread group; one or more instruction fetching circuits (before the decoding circuits) operable to fetch instructions to be executed; an instruction cache for locally storing instructions to the programmable execution unit for execution by an execution thread executed by the programmable execution unit; an execution thread generator circuit that generates threads (groups) for execution; and an execution thread scheduler circuit that schedules threads (groups) for execution (this may be part of the thread generator).

[0088] The program being executed in this invention can be any suitable and desired program that can be executed by a graphics processor. For example, the program can be any suitable and desired shader program that can be executed by a graphics processor, such as a geometry shader program, a vertex shader program, a fragment shader program, a computation shader program, or any other form of shader program supported by the graphics API.

[0089] A group of one or more execution threads can be any suitable and desired group of one or more execution threads. The techniques described herein can be applied to the case of individual threads (in which case a group of one or more execution threads will include a single execution thread) (and this is the case in one implementation).

[0090] In implementations, a group of one or more execution threads includes multiple (two or more) execution threads, such as four, eight, or sixteen (or more, such as 32, 64, or 128) execution threads.

[0091] For example, in a preferred embodiment, to improve the efficiency of the shader program, execution threads (each thread corresponding to a work item) are grouped into "groups" or "bundles" of threads, where threads in one group run in a lockstep manner, for example, one instruction at a time. In this way, instruction fetching and scheduling resources can be shared among all threads in the group. (Other terms used for such thread groups include "thread bundle" and "wavefront." For convenience, the term "thread group" will be used herein, but unless otherwise stated, it is intended to cover all equivalent terms and arrangements.)

[0092] Therefore, in an implementation, the graphics processor and the programmable execution unit are operable to execute shader programs for a group (“thread bundle”) of multiple execution threads together in a lockstep manner, one instruction at a time, and a group of one or more execution threads that suspend the execution of the shader program includes such a thread bundle.

[0093] In implementations, a group of one or more execution threads includes multiple execution threads and corresponds to a thread group (thread bundle) that executes the shader program in a lockstep manner.

[0094] The actual data processing operations performed by the shader execution unit while executing the shader program are typically executed by various functional units (circuits) of the execution unit (such as the arithmetic unit (circuit)) in response to and under the control of the instructions in the (shader) program being executed. Thus, for example, appropriate functional units such as the arithmetic unit will perform data processing operations in response to and according to the requirements of the instructions in the (shader) program being executed.

[0095] When executing instructions in a program, an execution unit (e.g., an appropriate functional unit of the execution unit, such as an arithmetic unit) typically reads one or more input data values ​​(operands), performs processing operations using these input data values ​​to generate output data values, and then returns the output data values, for example, for further processing by subsequent instructions in the program being executed and / or for output (for use outside the execution of the program being executed).

[0096] The input data values ​​used when executing instructions are typically stored "locally" in the appropriate set of registers (register files) of the execution (function) unit and / or accessible to the execution (function) unit, and the output data values ​​generated by the execution (function) unit when executing instructions are written back to that storage (register file) accordingly.

[0097] To facilitate this operation, each execution thread will allocate one or more sets of registers for use by that thread when executing the shader program.

[0098] Therefore, when an instruction is executed, the executing thread reads the input data value (operand) from one or more registers in a set of one or more registers allocated to the thread, and writes its output value back to one or more registers allocated to the thread's registers.

[0099] Data will be loaded into registers and written out of registers, or written to or from the appropriate memory system of the graphics processor or accessible to the graphics processor (e.g., via an appropriate cache system (cache hierarchy)).

[0100] Therefore, in addition to the programmable execution unit, the graphics processor preferably includes a set of multiple registers (register file) operable for and intended to store data for the executing execution thread. Each thread in a group of one or more execution threads executing a shader program will have an associated set of registers used to store data for that execution thread (input data to be processed by the execution thread or output data generated by the execution thread), which is allocated to that execution thread from the entire set of registers (register file) accessible to the programmable execution unit (and the execution thread being executed by the programmable execution unit).

[0101] In the presence of multiple execution units, each execution unit may have its own distinct register set (register file), or multiple (e.g., some or all) separate execution units may share a single register set (register file).

[0102] A register set (register file) can take any suitable and desired form and be arranged in any suitable and desired manner, such as including a single or multiple memory banks.

[0103] The graphics processor will correspondingly include appropriate load / store units and communication paths to transfer data between registers / register files and the graphics processor's or graphics processor-accessible memory system (e.g., via an appropriate cache hierarchy in an implementation).

[0104] As described above, the graphics processor also includes an instruction cache to store instructions for the shader programs being executed by the group of execution threads. The execution units are therefore arranged to fetch instructions from the instruction cache.

[0105] The set (sequence) of instructions being executed by the program can be any desired and suitable instruction. For example, program instructions may include one or more or all of the following: arithmetic (mathematical) operations (addition, subtraction, multiplication, division, etc.), bit manipulation (inversion, swapping, shifting, etc.), logical operations (AND, OR, NAND, NOR, NOT, XOR, etc.), load-type instructions (such as change, texture, or load instructions in the case of graphics processing), and store-type instructions (such as mix or store instructions).

[0106] At least some instructions in a given shader program may include one or more "wait" modifiers, such as "wait" modifiers that prevent the program from continuing execution until one or more conditions (e.g., specified by the wait modifier) ​​are met. Specifically, instructions may include "wait" modifiers that prevent the next instruction in the program from being fetched / executed until one or more conditions (e.g., specified by the wait modifier) ​​are met.

[0107] For example, in a typical processing operation, when generating a given output, there may be a group of multiple execution threads performing related data processing operations in parallel. This means that there may be various processing dependencies that need to be handled appropriately. Therefore, each instruction may have an associated "wait" modifier, which indicates that the execution of the program should not continue (i.e., should wait) until one or more dependencies are satisfied.

[0108] The wait modifier then allows the execution unit to examine one or more associated dependencies indicated by the wait modifier for the instruction to determine if any unresolved dependencies exist. If no unresolved dependencies exist, program execution can safely continue and thus complete. On the other hand, if any unresolved dependencies exist, continuing program execution is unsafe, and the group of execution threads executing the program associated with the instruction should (and is) evicted.

[0109] For example, these dependencies can be tracked using an appropriate dependency counter (slot), which tracks and counts unresolved dependencies and indicates when they should be satisfied. Therefore, the dependency counter (slot) can be incremented / decremented as needed, for example, such that the counter (slot) is set to zero (cleared) when a dependency is satisfied. Once all dependencies have been cleared, the execution unit can then determine that executing the instruction is safe. On the other hand, if the dependency counter for any dependency that the program is waiting for is not zero (not yet cleared), the execution thread should be evicted and the group of execution threads should be appropriately rescheduled.

[0110] As described above, when an instruction includes one or more unmet "conditional eviction" conditions (such as dependencies), in response to the eviction check circuit determining that the "conditional eviction" conditions are not met, the execution unit evicts the group of execution threads that execute the program associated with the instruction (e.g., and preferably after the current instruction has been executed, as will be explained further below).

[0111] There may also be other conditions that cause an execution unit to be evicted from the group of execution threads. Specifically, as mentioned above, there may be certain "unconditional eviction" conditions that always result in the execution thread being evicted from the group whenever such an "unconditional eviction" condition exists, for example, regardless of whether any dependency conditions exist.

[0112] Therefore, in an implementation, even if all dependencies, such as those associated with instructions, are satisfied, and there are no dependency barriers preventing the safe execution of the program, various other conditions may still exist that would mean the group of execution threads should be evicted.

[0113] Various examples of this condition include cases where the program includes message passing instructions or branching instructions.

[0114] In this case, there is no need to check any dependencies (and it's best not to).

[0115] On the other hand, as long as there is no such "unconditional eviction" condition, whenever an instruction includes one or more "conditional eviction" conditions (e.g., unresolved dependencies), instead of simply evictioning the group of execution threads at that time, further checks are performed to determine if more "conditional eviction" conditions (e.g., dependencies) are satisfied, and when the conditions (e.g., dependencies) have been satisfied (so that program execution can continue safely), the conditions (e.g., dependencies) are ignored.

[0116] Therefore, in this invention, the fetched instructions are examined to determine whether they include any conditions that may or should cause the group of execution threads to be expelled, and based on these examinations, the execution unit is then allowed to continue executing the program (e.g., by fetching / executing the next instruction in the program), or the group of execution threads is expelled accordingly.

[0117] Preferably, the instruction is checked when it is fetched for execution (e.g., when it is read from the instruction cache). Preferably, the checking is performed in parallel with the instruction execution buffer that provides the instruction to the execution unit.

[0118] For example, in a preferred embodiment, the execution unit sequentially fetches instructions from the instruction cache when executing the program. The fetched instructions are then provided from the instruction cache to the execution unit for execution, and preferably allocated to the corresponding instruction buffer of the execution unit for execution by the corresponding execution thread group.

[0119] Simultaneously, when fetching instructions, a lookup is preferably performed to check whether one or more conditions that would cause the group of execution threads to be evicted are met. The result of this instruction check can then be provided to the execution unit to allow the group of execution threads to continue executing the program (e.g., by fetching the next instruction) or to cause the group of execution threads to be evicted, for example, as described above.

[0120] Preferably, each instruction is checked upon being retrieved. Therefore, although the implementation described above relates to checking individual instructions, it will be understood that this can be done for each instruction retrieved.

[0121] Instructions can and preferably be checked individually. However, in some cases, it may be desirable to check (at least some) conditions at a coarser level, for example, for a block of multiple instructions.

[0122] Therefore, in an implementation, the step of checking an instruction includes checking one or more conditions associated with a set of one or more instructions that include that instruction. Thus, in an implementation, any reference to fetching / checking / executing an instruction can refer to fetching / checking / executing a set of one or more instructions.

[0123] In cases where multiple conditions exist that could lead to the eviction of a group of execution threads, the eviction check circuit preferably checks all conditions. The determination of whether to eviction a group of execution threads is based on, for example, and preferably, determining which of one or more conditions associated with an instruction is satisfied.

[0124] For example, a graphics processor may manage multiple data dependency counters (slots), of which only some (a subset) apply to the instruction in question. In some implementations, checks are therefore performed only on the dependency counters (slots) that are actually applied to the instruction. This will provide the best results (e.g., minimal unnecessary evictions). However, in some cases, it may be desirable to check all dependency counters (slots) directly, regardless of whether they actually apply to the instruction in question, which is done in some implementations. For example, this approach can simplify checks and may be particularly beneficial when a large number of checks need to be performed in parallel.

[0125] Therefore, in an implementation, when it is determined that an instruction includes one or more dependency conditions that need to be checked before program execution can continue, the eviction check circuit is configured to check the dependency counter for all dependency conditions being tracked, without checking whether each dependency condition applies to the instruction in question, and eviction the group of execution threads of the program associated with the instruction when it is determined that any dependency condition being tracked by the dependency counter is not satisfied.

[0126] When an eviction check determines that the next instruction can and should be executed (the program can continue), the instruction is pushed to the instruction (execution) buffer for the execution thread's group to execute, and then the execution unit fetches the next instruction from the program. In this way, the execution unit can effectively ignore any wait modifiers that would otherwise cause the execution thread's group to be evicted.

[0127] On the other hand, when it is determined based on the eviction check that the next instruction cannot or should not be executed (the program cannot continue to execute) and the group of execution threads should be evictioned, the instruction is preferably pushed to the instruction (execution) buffer for the group of execution threads to execute. However, the execution unit then does not continue to fetch the next instruction in the program, but the eviction check circuit triggers the eviction of the group of execution threads.

[0128] Preferably, the eviction of the execution thread group is triggered by marking the instruction in question as the "final" instruction in the program. This means that when the execution thread receives the instruction, the shader program will complete and the execution thread group will be properly evictioned (e.g., without fetching the next instruction). Therefore, the execution thread group will be released, and a new execution thread group will be created at its location on the next instruction fetch.

[0129] Therefore, in an implementation, when it is determined that the program should not continue execution based on whether one or more conditions associated with the instruction are met, the (current) instruction is marked as the "last" instruction in the program, so that when the execution unit executes the instruction, it triggers the expulsion of the group of execution threads that execute the program associated with the instruction.

[0130] Other arrangements of evictping execution threads from a group are also possible.

[0131] For example, unlike waiting until the program executes to receive an instruction that triggers eviction, an eviction check circuit can trigger the immediate eviction of a group of execution threads. Therefore, in some implementations, when it is determined that the program should not continue execution based on whether one or more conditions associated with an instruction are met, the group of execution threads executing the program associated with that instruction can be immediately evicted.

[0132] When a group of execution threads is evicted, it is preferably provided to the appropriate thread group execution controller (scheduler) circuitry so that the shader program execution of the thread group can be restarted at a later time as needed. Therefore, in an implementation, when it is determined that a group of execution threads should be evicted due to one or more unresolved data dependencies, the group of execution threads is passed to the thread group execution controller (scheduler) circuitry. In this case, the group of execution threads is preferably subsequently rescheduled.

[0133] In an implementation, when a thread group is evicted due to one or more unmet "conditional eviction" conditions (e.g., dependencies), the group of executing threads, along with any other thread groups waiting for the one or more conditions in question, can be placed in a corresponding queue associated with that condition. When the condition is met, the queue can be released and rescheduled appropriately.

[0134] However, other rescheduling mechanisms can also be used. For example, the group of execution threads can be rescheduled immediately, so that the group of execution threads is placed in the queue of the group of execution threads to be executed, and the condition is checked again when the group of execution threads is reissued for execution (although in this case, the group of execution threads may be repeatedly evicted / rescheduled, which may be inefficient).

[0135] To facilitate rescheduling operations, when a group of executing threads is evicted, the contents of its associated registers are preferably written out, for example, to allow the shader program to be properly restored.

[0136] In this respect, all sorts of arrangements are possible.

[0137] In some embodiments, the graphics processor includes and / or communicates with one or more memories and / or memory devices that store the data described herein and / or software for performing the processes described herein. The graphics processor may also communicate with a host microprocessor and / or with a display for displaying images based on data generated by the graphics processor.

[0138] In one implementation, the graphics processor is part of an overall data processing system that includes one or more memories and / or memory devices, a host processor (and optionally a display). In another implementation, the host microprocessor is operable to execute applications that require data (e.g., graphics) to be processed by the graphics processor, which operates when processing is required for an application running on the host processor.

[0139] Of course, other arrangements are also possible.

[0140] The techniques described herein can be used by graphics processors (and processing pipelines) to generate all forms of output, such as rendering to texture output, in the case of graphics processing operation frames (images) used for display. In implementations, output data values ​​from processing are exported externally (e.g., to main memory) for storage and use, such as to frame buffers for display.

[0141] The techniques described herein are applicable to any suitable form or configuration of graphics processors and data processing systems. In implementation, the various functions of the techniques described herein are performed on a single data processing platform that generates and outputs data.

[0142] The techniques described herein can be implemented in any suitable system, such as a properly configured microprocessor-based system. In implementation, the techniques described herein are implemented in computer- and / or microprocessor-based systems.

[0143] The various functions of the techniques described herein can be performed in any desired and suitable manner. For example, the functions of the techniques described herein can be implemented in hardware or software as needed. Therefore, for example, unless otherwise stated, the various functional elements, stages, and "devices" of the techniques described herein can include one or more suitable processors, one or more controllers, functional units, circuits, processing logic, microprocessor arrangements, etc., operable to perform various functions, such as appropriate dedicated hardware elements (processing circuits) and / or programmable hardware elements (processing circuits) that can be programmed to operate in a desired manner.

[0144] It should also be noted that, as those skilled in the art will understand, the various functions of the techniques described herein can be copied and / or executed in parallel on a given processor. Similarly, processing levels can share processing circuitry if needed.

[0145] Depending on any hardware necessary to perform the specific functions described above, the data processing system and graphics processor may additionally include any or more or all of the commonly used functional units included in the data processing system and graphics processor.

[0146] Those skilled in the art will also understand that all described embodiments of the technology described herein may appropriately and indeed include any one or more or all of the optional features described herein.

[0147] The methods described herein can be implemented, at least in part, using software such as computer programs. Therefore, it will be seen that, when viewed from another embodiment, the techniques described herein provide computer software particularly suitable for performing the methods described herein when mounted on a data processor, computer program elements including computer software code portions for executing the methods described herein when the program elements are run on the data processor, and computer programs including code suitable for executing all steps of one or more methods described herein when the program is run on a data processing system. The data processor may be a microprocessor system, a programmable FPGA (Field-Programmable Gate Array), etc.

[0148] The techniques described herein also extend to computer software carriers that include software that, when used to operate a graphics processor, renderer, or microprocessor system including a data processor, causes the processor, renderer, or microprocessor system, together with the data processor, to perform the steps of the methods described herein. Such computer software carriers can be physical storage media such as ROM chips, CD-ROMs, RAM, flash memory, or disks, or signals such as wired electronic signals, optical signals, or radio signals such as those to satellites.

[0149] It will also be understood that not all steps of the methods described herein need to be performed by computer software. Therefore, according to other broad embodiments, the techniques described herein provide computer software and such software is installed on a computer software carrier to perform at least one step of the methods set forth herein.

[0150] Therefore, the techniques described herein can be suitably implemented as a computer program product for use with a computer system. Such implementation may include a series of computer-readable instructions fixed on a tangible, non-transitory medium, such as a computer-readable medium like a floppy disk, CD-ROM, ROM, RAM, flash memory, or hard disk. It may also include a series of computer-readable instructions that can be transmitted to a computer program via a modem or other interface device through a tangible medium (including, but not limited to, optical or analog communication lines) or invisibly using wireless technologies (including, but not limited to, microwave, infrared, or other transmission technologies). This series of computer-readable instructions implements all or some of the functions previously described herein.

[0151] Those skilled in the art will understand that such computer-readable instructions can be written in a variety of programming languages ​​for use with many computer architectures or operating systems. Furthermore, any current or future storage technology (including, but not limited to, semiconductor, magnetic, or optical) can be used to store such instructions, or any current or future communication technology (including, but not limited to, optical, infrared, or microwave) can be used to transmit such instructions. It is envisioned that such computer program products can be distributed as removable media with accompanying printed or electronic documentation, such as shrink-wrapped software, pre-installed computer systems (e.g., on system ROM or a fixed disk), or distributed from servers or electronic bulletin boards via networks (e.g., the Internet or the World Wide Web). Attached Figure Description

[0152] Several embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, wherein:

[0153] Figure 1 An exemplary computer graphics processing system is shown;

[0154] Figure 2 An exemplary graphics processing pipeline is shown;

[0155] Figure 3 The operation of a graphics processor shader core in an embodiment of the technology described herein is illustrated schematically; and

[0156] Figure 4 The flowchart illustrates an embodiment of the present invention. Detailed Implementation

[0157] Several implementations will now be described in the context of a graphics processor operable for executing graphics shader programs.

[0158] Figure 1 A typical computer graphics processing system is shown.

[0159] An application 2 (such as a game) running on the host processor (CPU) 1 will require graphics processing operations to be performed by the associated graphics processing unit (GPU) (graphics processor) 3, which executes the graphics processing pipeline. To this end, the application will generate API (Application Programming Interface) calls, which are interpreted by a driver 4 running on the host processor 1 for the graphics processor 3 to generate appropriate commands to the graphics processor 3, thereby producing the graphics output required by the application 2. To facilitate this, in response to commands from the application 2 running on the host system 1, a set of "commands" will be provided to the graphics processor 3 for graphics output (e.g., generating frames to be displayed).

[0160] like Figure 1 As shown, the graphics processing system will also include a suitable memory system 5 for use by the host CPU 1 and the graphics processor 3.

[0161] When displaying computer graphics images, they are typically first defined as a series of primitives (polygons), and then these primitives are divided (rasterized) into graphic segments for sequential rendering. During normal graphics rendering operations, the renderer modifies the (e.g., red, green, and blue, RGB) and transparency (alpha, α) data associated with each segment so that the segment can be displayed correctly. Once the segments have been fully traversed by the renderer, their associated data values ​​are stored in memory, ready for output (e.g., for display).

[0162] In this embodiment, graphics processing is performed in a pipelined manner, with one or more pipeline stages operating on the data to generate the final output (e.g., the displayed frame).

[0163] Figure 2 An exemplary graphics processing pipeline 10 that can be executed by the graphics processor 3 in this embodiment is shown. Figure 2 The graphics processing pipeline 10 shown is a tile-based system that will produce tile-based arrays of output data (such as output frames to be generated). (However, the techniques described herein are also applicable to other systems, such as real-time rendering systems.) The output data array may typically be output frames designed for display on a display device (such as a screen or printer), but may also include, for example, the graphics processor's "render to texture" output or other suitable arrangement.

[0164] Figure 2 The main components and pipeline stages of a graphics processing pipeline 10 according to this embodiment are shown. As those skilled in the art will understand, there may be Figure 2 Other components of the graphics processing pipeline not shown in the examples. It should also be noted here that... Figure 2 This is merely illustrative, and functional units and pipeline stages, as shown in practice, can share important hardware circuitry, even if they are in... Figure 2 The middle level is schematically shown as a separate level. Similarly, it is not necessary to provide... Figure 2 Some of the components described, and Figure 2 Only one example of the graphics processing pipeline 10 is shown. It will also be understood that... Figure 2 The various stages, components, and units of the graphics processing pipeline shown can be implemented as needed, and will accordingly include, for example, appropriate circuitry and / or processing logic, to perform the necessary operations and functions.

[0165] like Figure 2 The graphics processing pipeline shown will be executed and implemented on a graphics processing unit (GPU) 3, which will accordingly include the necessary functional units, processing circuits, etc., operable for executing the graphics processing pipeline stage.

[0166] Figure 2 The stage of the graphics processing pipeline is shown after the graphics processor's tiler (not shown) has prepared the primitive list (because graphics processing pipeline 10 is a tile-based graphics processing pipeline).

[0167] (In practice, the tiler determines which primitives need to be processed for different regions of the output. In this embodiment, these regions can, for example, represent tiles into which the overall output has been divided for processing purposes, or a collection of such tiles. To do this, the tiler compares the location of each primitive to be processed with the location of the region and adds the primitive to the corresponding primitive list of the regions into which the tiler determines the primitive may (potentially) fall. Any suitable and desired technique for classifying and binning primitives into the tile list (such as exact binning or bounding box binning, or any technique in between) can be used in the tiler process.)

[0168] Once the tiler has prepared the primitive list (the list of primitives to be processed for each region), it can refer to its associated primitive list to render each tile.

[0169] Therefore, each block is passed Figure 2 The graphics processing pipeline stage shown is processed.

[0170] Therefore, a fragment task iterator 20 is provided to schedule processing work to the graphics processing pipeline 10.

[0171] Therefore, the fragment task iterator 20 can schedule the graphics processing pipeline to generate a first output, which may be, for example, a frame to be displayed. In this embodiment, the graphics processing pipeline 10 is a tile-based system, wherein the output has been divided into multiple rendering tiles, and the graphics processing pipeline 10 iterates over the tile set of the first output to render each tile sequentially.

[0172] like Figure 2 As shown, the graphics processor 3 includes an overall controller in the form of a job manager circuit (command flow front-end circuit) (JM / CSF) 35, which is operable to receive tasks from the host processor 1 for processing. The job manager 35 can then transmit the relevant jobs (tasks) to the graphics processor and various components of the graphics processing pipeline 10 via appropriate buses / interconnects. In this embodiment, the bus / interconnect is in the form of a job control network (JCN) 36.

[0173] Therefore, as Figure 2 As shown, the job manager 35 will in particular issue fragment processing tasks to the fragment task iterator 20 so that the fragment task iterator 20 can then schedule and schedule appropriate fragment shading tasks onto the graphics processing pipeline 10.

[0174] For a given tile being processed, the primitive list reader (or "polygon list reader") 22 thus identifies the sequence of primitives (the primitives listed in the primitive list of the tile) that will be processed for that tile, and then publishes the ordered sequence of primitives of the tile to the graphics processing pipeline 10 for processing.

[0175] Resource allocator 23 then configures and manages memory space allocation for buffers 33, such as depth (Z) and color, of the tiles used for the output being generated. For example, these buffers may be provided as part of RAM located on-chip (locally) within the graphics processing pipeline.

[0176] Vertex loader 24 then loads the vertices of the primitive and passes them to primitive setting unit (or "triangle setting unit") 25, which operates to determine edge information representing the edge of the primitive based on the vertices of the primitive.

[0177] Before primitives are passed to rasterizer 27, it may be desirable to reorder primitives, for example, to improve rasterization efficiency, remove hidden surfaces, etc. Therefore, graphics processing pipeline 10 includes primitive reorderer unit 26, which contains primitive buffers that can be reordered.

[0178] The edge information of the reordered primitives is then passed to rasterizer 27, which rasterizes the primitives into a set of one or more sampling points and generates individual graphic fragments with appropriate positions (representing appropriate sampling positions) for rendering the primitives.

[0179] The segments generated by rasterizer 27 are then forwarded to the rest of the pipeline for processing.

[0180] For example, in this embodiment, the fragments generated by rasterizer 27 undergo an (early) depth (Z) / stencil test 29 to see if any fragments can be discarded (culled) at this level. To do this, the Z / stencil test level 29 compares the depth values ​​of the (associated) fragments published from rasterizer 27 with the depth values ​​of already rendered fragments (which are stored in a depth (Z) buffer as part of tile buffer 33) to determine whether the new fragment will be occluded (or not) by already rendered fragments. Simultaneously, an early stencil test is performed.

[0181] To facilitate this, the fragments can be further reordered in the ZS reorder buffer 28 upstream of the Z / template test level 29.

[0182] Before the remaining fragments are then passed to the fragment shader level in the form of shader kernel 31 for rendering, the fragments passed through the fragment early Z and stencil test level 29 can then be subjected to further culling operations (such as "forward pixel elimination" test 30, as described, for example, in U.S. Patent Application Publication No. 2019 / 0088009 (Arm Ltd).

[0183] Fragment shading level 31 processes fragments that have passed the early Z and stencil tests by performing appropriate fragment processing operations to generate appropriate render fragment data.

[0184] This fragment processing can include any suitable and desired fragment shading process, such as executing a fragment shader procedure on the fragment, applying textures to the fragment, applying fog or other operations to the fragment, to generate appropriate rendered fragment data.

[0185] In this embodiment, the fragment shader level takes the form of a shader pipeline (programmable fragment shader), and is therefore implemented by means of an appropriate shader (processing) core 31.

[0186] Therefore, as Figure 2As shown, in this embodiment, the fragment shader level (shader core) 31 includes a programmable execution unit (engine) 32 operable to execute fragment shader programs for each execution thread (where each thread corresponds to a work item, e.g., an individual fragment, of the output being generated) to perform desired fragment shading operations, thereby generating rendered fragment data. In this regard, the execution unit 32 can operate in any suitable and desired manner and include any suitable and desired processing circuitry, etc.

[0187] In this embodiment, execution threads can be arranged into "groups" or "bundles" of threads, where threads in a group run in a lockstep manner, one instruction at a time; that is, each thread in the group executes the same single instruction before proceeding to the next instruction. In this way, instruction fetching and scheduling resources can be shared among all threads in the group. Such a thread group may also be referred to as a "subgroup," "thread bundle," or "wavefront." For convenience, the term "thread group" will be used herein, but unless otherwise stated, it is intended to cover all equivalent terms and arrangements.

[0188] Figure 2 Accordingly, a thread group controller in the form of a thread bundle manager 34 is also shown, which is configured to control the allocation of work items (e.g., fragments) to individual thread groups for fragment coloring operations performed by execution unit 32, and to issue thread groups to execution unit 32 for execution of fragment coloring procedures for individual thread groups.

[0189] like Figure 2 As shown, the fragment shader level (shader core) 31 also communicates with the memory 5.

[0190] Once fragment shading is complete, the output rendered (shaded) fragment data is written to tile buffer 33, which can be output from the tile buffer to a frame buffer (e.g., in memory 5) for display. The depth values ​​of the output fragments are also appropriately written to the Z buffer within tile buffer 33. (The tile buffer stores color and depth buffers, which respectively store the appropriate color or Z values ​​of the respective sample points (essentially the sample points of the rendered tile being processed) represented by the buffers. These buffers store fragment data arrays representing a portion (tile) of the overall output (e.g., the image to be displayed), with each set of sample values ​​in the buffer corresponding to a corresponding pixel in the overall output (e.g., each 2×2 set of sample values ​​could correspond to an output pixel, where 4x multisampling is being used).

[0191] As mentioned above, the tile buffer 33 is typically provided as part of the RAM located on the graphics processor (locally).

[0192] Once the output tiles have been processed, the data from the tile buffer can then be written back to the external memory output buffer, such as the frame buffer of a display device (not shown), for example, in memory 5. (The display device may include, for example, a display comprising a pixel array, such as a computer monitor or a printer.)

[0193] Then process the next tile, and so on, until enough tiles have been processed to generate the entire output (e.g., the frame to be displayed (image)). Then repeat the process for the next output (e.g., the frame), and so on.

[0194] In a typical fragment shader operation, multiple execution threads can execute individual fragment shader programs for fragments within the same output (e.g., a frame).

[0195] In this context, various processing (e.g., data) dependencies may exist between fragment shader programs, and these dependencies need to be managed appropriately, for example, to ensure that the processing of output is consistent across groups of different execution threads.

[0196] Other shader operations can have similar dependencies, such as geometry shader programs, vertex shader programs, compute shader programs, or any other form of shader program supported by the graphics API. Such dependencies can be handled using one or more dependency slots managed by a suitable dependency counter. Therefore, instructions for handling dependencies can include appropriate "wait" modifiers, such as indicating which dependency slots need to be cleared before continuing program execution, and preventing the fetching / execution of the next instruction in the program (i.e., causing the program to wait) until the relevant dependency slots are cleared.

[0197] Below is a typical example of a shader program that includes instructions containing this wait modifier:

[0198] LOAD.32.slot0@r20,addr#increment dep slot 0

[0199] FMA r10, r0, r1, r2

[0200] FMA r11, r2, r3, r10

[0201] FMA.wait0 r12, r4, r5, r11

[0202] FMAr13, r20, r2, r12

[0203] In this example, the shader procedure includes a first load instruction configured to load the working set into the associated register file. The dependency slot (dep slot "0") is incremented.

[0204] Then a series of arithmetic operations (in this example, fused multiply-accumulate (FMA) operations) are performed, with the results written back to registers, for example, in the normal way that a shader program executes. However, the third arithmetic operation includes a wait modifier ("wait 0"), which causes the execution unit not to execute the next (fourth) instruction in the program until the indicated dependency slot (dep slot "0") is cleared (e.g., set to zero) (the message response eventually decrements that slot).

[0205] In this scenario, the execution unit can be configured to be a group of execution threads that are evicted, rather than waiting for dependencies to be cleared, in order to allow the scheduling of new execution threads.

[0206] As will be explained further below, this implementation focuses particularly on this eviction mechanism.

[0207] Figure 3 The graphics processor shader core execution unit (which can be used, for example, as needed) is shown in more detail. Figure 2 The implementation shown is of the execution unit 32 of the fragment shader level 31 in the graphics processing pipeline, but it can also be used as a computation shader core, or as any other form of shader core. (As those skilled in the art will understand, the shader core may include...) Figure 3 Other components and parts not shown in the diagram. Figure 3 The elements and components of the shader core related to the operation of this embodiment are simply illustrated.

[0208] Specifically, Figure 3 This illustrates the process of a thread group within the execution engine, from its creation to its deactivation.

[0209] like Figure 3 As shown, when a thread group (“warp_create”) is created, the initial program counter (PC) 34 is initialized to point to the start of each shader procedure. At this point, any thread group state can also be configured.

[0210] The resulting thread group will then check if PC 34 has hit instruction cache 35 and obtain the link of the cache line and the offset of the instruction. If there is no hit, it will wait until the instruction is loaded into instruction cache 35.

[0211] When the instructions of the shader program that generated the thread group are present in the instruction cache 34, the thread group can then be issued to the processing element 37 to execute the instructions in the shader program (“warp_issue”).

[0212] When processing element 37 receives a thread group, instruction fetch circuit 38 will begin requesting instructions (“Instr_request”) from instruction cache 35 using the provided link (and increment the offset for each fetched instruction). Then it will receive the fetched instruction data (“Instr_response”) returned from instruction cache 35 and put it into instruction execution buffer 41.

[0213] The execution unit fetches an instruction from the instruction execution buffer 41, processes it appropriately (e.g., by fetching the relevant operands, performing any desired (arithmetic) operations), and then writes the result back to its register file. The registers are stored in an operand buffer (not shown). When a thread group is evicted, its registers begin to be written back to the register file.

[0214] During instruction fetching, a portion of the fetched instruction (“Instr_response”) is “poke” (Instr_'poke') to check if the processing element may need to be evicted from the thread group (thread bundle). This could be because it’s necessary to check if the dependency slot indicated by the instruction has been cleared before executing the next instruction. Alternatively, it could be due to situations requiring branching to different locations in the shader, elimination, changing the channel mask, and some other reason.

[0215] The eviction check circuit (eviction circuit) 39 is therefore able to determine, based on instructions, whether a thread group (thread bundle) should be evicted.

[0216] When an eviction point is identified, the instruction is marked as the "last" instruction in the instruction cache, and the thread group (thread bundle) slot is released, allowing another thread group to take its place when fetching instructions. The instructions for the thread group (thread bundle) will be processed from the instruction execution buffer 41, and once the thread's "last" instruction has been processed, an eviction process will occur, returning to the scheduler 36.

[0217] In one approach, the instruction checking circuit (eviction circuit) 39 can be configured to evict the thread group (thread bundle) whenever a dependency exists (e.g., without checking whether the dependency is satisfied). However, this conservative eviction approach means that in some cases, the thread group (thread bundle) may be unnecessarily evicted, rescheduled, etc.

[0218] Therefore, in this embodiment, the thread group (thread bundle) is not always evicted whenever a condition that may need to be checked (e.g., a dependency) exists; the evicting check circuit (evicting circuit) 39 is also arranged to check whether the dependency is satisfied during instruction fetching. Figure 3 As shown, the instruction checking circuit (evictory circuit) 39 is therefore configured to send the thread group identifier (ID) of the thread group (thread bundle) in question to the external dependency checking unit 40 to check the dependency counter of the thread group, thereby determining whether the dependency has been satisfied and can therefore be ignored.

[0219] Therefore, in this embodiment, when a thread group (thread bundle) enters the thread group (thread bundle) slot in the instruction execution buffer 41 of the processing element 37, the expulsion check circuit (expulsion circuit) 39 performs a lookup of the dependency counter 40 for instructions from external thread group (thread bundle) dependency control in parallel.

[0220] Therefore, in this embodiment, when an unresolved dependency is determined, the eviction check circuit (eviction circuit) 39 continues to check whether the dependency is satisfied. When it is determined that there are no unresolved dependency slots, it can be determined that it is safe to continue eviction without eviction of the thread group (thread bundle).

[0221] In this way, this implementation avoids the conservative eviction of thread groups (thread bundles) to scheduler 36 when they do not need to be (because dependencies have been satisfied and instructions can be safely executed). It will be understood that such unnecessary thread group evictions can increase latency and register file bandwidth overhead (due to additional, unnecessary write-backs), therefore this implementation can provide more efficient shader performance.

[0222] Figure 4 It is a flowchart of retrieving instructions and determining the eviction point.

[0223] First, obtain a new thread group (thread bundle) for the current fetch slot (step 42). Then, enter the thread group (thread bundle) identifier (ID), for example, to allow dependency lookup (step 43), as explained later. Then, send a request to fetch instructions for execution (using links, offsets, etc.) (step 44).

[0224] During the instruction retrieval process, a portion of the instruction (“disposal”) is examined (step 45) to determine whether unconditional eviction of the thread group is required (step 46).

[0225] For example, this could be because the current or next instruction is a message passing instruction or because the instruction is a branch instruction. Or, for example, if the thread group (thread bundle) has diverged, it may be necessary to perform a branch reconvergence check (i.e., check the PC and call stack depth of all threads in the thread group and pick those with the highest priority).

[0226] Another example is when a thread group (thread bundle) has some work items that are completely discarded. In this case, it may be necessary to evict the thread group, for example, to make it possible to release "early" dependency slots, such as depth / color dependency slots, more quickly.

[0227] When an unconditional eviction point is identified (step 46 - Yes), the instruction is then marked as "last" (step 47) and pushed to the instruction execution buffer (step 51). In this case, when the processing element receives the instruction, because the instruction is marked as "last," this will cause the thread group (thread bundle) to be evicted to the scheduler, and the thread group (thread bundle) will be released on the next fetch (step 42).

[0228] If no unconditional expulsion point exists (step 46 - No), then check if the instruction is a conditional expulsion point (step 48). For example, this could be because the instruction has many unresolved (unsatisfied) dependencies, causing execution to wait.

[0229] If no conditional eviction point exists (step 48 - No) (e.g., because all dependencies are cleared (or because there are no dependencies)), the instruction is pushed to the instruction execution buffer for execution (step 52), and the offset is incremented to fetch the next instruction (step 44).

[0230] On the other hand, if there are (for example) unresolved dependencies (step 48 - Yes), it is checked whether the corresponding dependency slot can be cleared (or any other suitable condition that needs to be checked) (step 49) to determine whether the thread group (thread bundle) really needs to be evicted (step 50). If it is determined that the thread group (thread bundle) does not actually need to be evicted (step 50 - No), the instruction is pushed to the instruction buffer for execution (step 52), and the offset is incremented to fetch the next instruction (step 44).

[0231] Otherwise, if it is determined that the thread group (thread bundle) does need to be evicted (step 50 - yes), the instruction is marked as the "last" instruction (step 47), and then the instruction is pushed to the instruction buffer (step 51) without incrementing the fetch offset, so that the thread group is evicted to the scheduler and the thread group (thread bundle) will be released on the next fetch (step 42).

[0232] The foregoing detailed description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology described herein to the precise forms disclosed. In view of the foregoing teachings, many modifications and variations are possible. The described embodiments were chosen to best explain the principles of the technology described herein and its practical application, thereby enabling others skilled in the art to best utilize the technology described herein in various embodiments and with various modifications suitable for the intended particular use. The scope is intended to be defined by the appended claims.

Claims

1. A graphics processor, the graphics processor comprising: A programmable execution unit, operable to execute a program to perform processing operations, wherein, when executing the program, the programmable execution unit executes the program for each group of one or more execution threads; An instruction cache stores instructions for a program to be executed by the programmable execution unit, wherein, when executing the program for a corresponding group of one or more execution threads, the programmable execution unit is arranged to fetch the instructions from the instruction cache for execution; and An eviction check circuit is configured to, for instructions fetched from the instruction cache for the corresponding group of the execution thread, before executing the instruction: Determine whether the instruction includes one or more conditional eviction conditions that, if not satisfied, indicate that the program associated with the instruction should not continue execution for the group of execution threads; and When it is determined that the instruction includes one or more conditional eviction conditions that, if not satisfied, indicate that the program associated with the instruction should not continue to be executed for the group of execution threads, it is determined whether the conditional eviction condition is satisfied. The determination, in response to whether the conditional eviction condition is met, includes: When it is determined that the conditional eviction condition is met, the eviction check circuit allows the programmable execution unit to continue executing the program for the group of execution threads; When it is determined that the conditional eviction condition is not met, the eviction check circuit causes the programmable execution unit to evict the group of execution threads associated with the instruction.

2. The graphics processor of claim 1, wherein, The one or more conditional eviction conditions include one or more dependency conditions, wherein if the dependency conditions are not met, the next instruction in the program should not be executed for the group of execution threads.

3. The graphics processor of claim 2, wherein, The one or more dependency conditions include wait modifiers indicating that the execution of the program should wait for one or more data dependencies, and wherein determining whether the dependency conditions are met includes checking a corresponding one or more dependency counter that tracks the dependency conditions.

4. The graphics processor of claim 3, wherein, When it is determined that the instruction includes one or more dependency conditions that need to be checked before the next instruction in the program can be executed, the eviction check circuit is configured to: check the dependency counter for all dependency conditions being tracked, without checking whether each dependency condition applies to the instruction in question, and eviction the group of execution threads of the program associated with the instruction if it is determined that any dependency condition among the dependency conditions being tracked by the dependency counter is not satisfied.

5. The graphics processor of any one of claims 1 to 4, wherein, The eviction check circuit is further configured to: determine whether the instruction is associated with any unconditional eviction condition, and if such an unconditional eviction condition exists, indicate that the group of execution threads associated with the instruction should always be evictioned.

6. The graphics processor of claim 5, wherein, The eviction check circuit is configured to determine whether the instruction includes any unconditional eviction condition before determining whether the instruction includes one or more conditional eviction conditions, and wherein, when it is determined that the instruction includes any unconditional eviction condition, the eviction check circuit causes the programmable execution unit to eviction the group of execution threads without checking whether the instruction includes one or more conditional eviction conditions or whether any conditional eviction condition is met.

7. The graphics processor of claim 5, wherein, The unconditional eviction condition includes one or more of the following: (i) the instruction includes a message passing instruction; (ii) the next instruction in the program includes a message passing instruction; and (iii) the instruction includes a branch instruction.

8. The graphics processor of any one of claims 1 to 4, wherein, When it is determined, based on the determination of whether one or more dependency conditions associated with the instruction are met, that a group of execution threads should be evicted due to one or more unmet conditional eviction conditions, the evicted group of execution threads is passed to the thread group execution controller circuitry for subsequent rescheduling.

9. The graphics processor of any one of claims 1 to 4, wherein, When it is determined that a group of execution threads should be evicted, the instruction is marked as the last instruction in the program so as to trigger the eviction of the group of execution threads executing the program associated with the instruction when the programmable execution unit executes the instruction.

10. The graphics processor of any one of claims 1 to 4, wherein, When it is determined that a group of execution threads should be expelled, the group of execution threads executing the program associated with the instructions is immediately expelled.

11. A method for operating a graphics processor, The graphics processor includes: A programmable execution unit, operable to execute a program to perform processing operations, wherein, when executing the program, the programmable execution unit executes the program for each group of one or more execution threads; and An instruction cache stores instructions for a program to be executed by the programmable execution unit, wherein, when executing the program for a corresponding group of one or more execution threads, the programmable execution unit is arranged to fetch the instructions from the instruction cache for execution. The method includes the following steps: When an instruction is fetched from the instruction cache for the corresponding group of the execution thread, before executing the instruction: Determine whether the instruction includes one or more conditional eviction conditions that, if not satisfied, indicate that the program associated with the instruction should not continue to execute for the group of execution threads; When it is determined that the instruction includes one or more conditional eviction conditions that, if not satisfied, indicate that execution of the program associated with the instruction should not continue for the group of execution threads, it is determined whether the conditional eviction conditions are satisfied; and In response to the determination of whether the conditional eviction condition is met: When it is determined that the conditional eviction condition is met, the program continues to execute for the group of execution threads; or When it is determined that the conditional eviction conditions are not met, the group of execution threads associated with the instruction is evictped.

12. The method of claim 11, wherein, The one or more conditional eviction conditions include one or more dependency conditions, wherein if the dependency conditions are not met, the next instruction in the program should not be executed for the group of execution threads.

13. The method of claim 12, wherein, The one or more dependency conditions include wait modifiers indicating that the execution of the program should wait for one or more data dependencies, and wherein the step of determining whether the dependency conditions are satisfied includes checking a corresponding one or more dependency counter that tracks the dependency conditions.

14. The method of claim 13, wherein, When it is determined that the instruction includes one or more dependency conditions that need to be checked before the next instruction in the program can be executed, the method includes the steps of: checking the dependency counter for all dependency conditions being tracked, without checking whether each dependency condition applies to the instruction in question, and evictring the group of execution threads executing the program associated with the instruction when it is determined that any dependency condition among the dependency conditions being tracked by the dependency counter is not satisfied.

15. The method of any one of claims 11 to 14, further comprising the step of: Determine whether the instruction is associated with any unconditional eviction condition, and if such an unconditional eviction condition exists, indicate that the group of the execution thread associated with the instruction should always be evictioned.

16. The method of claim 15, comprising the steps of: Before determining whether the instruction includes one or more conditional eviction conditions, the method determines whether the instruction includes any unconditional eviction conditions, and wherein, when it is determined that the instruction includes any unconditional eviction conditions, the method further includes the step of eviction of the execution thread from the group without checking whether the instruction includes one or more conditional eviction conditions or whether any conditional eviction conditions are met.

17. The method of claim 15, wherein, The unconditional eviction condition includes one or more of the following: (i) the instruction includes a message passing instruction; (ii) the next instruction in the program includes a message passing instruction; and (iii) the instruction includes a branch instruction.

18. The method of any one of claims 11 to 14, wherein, When it is determined, based on the determination of whether one or more dependency conditions associated with the instruction are met, that a group of execution threads should be evicted due to one or more unmet conditional eviction conditions, the method includes the step of: passing the evicted group of execution threads to the thread group execution controller circuitry for subsequent rescheduling.

19. The method of any one of claims 11 to 14, wherein, When it is determined that a group of execution threads should be evicted, the method includes the following steps: marking the instruction as the last instruction in the program to trigger the eviction of the group of execution threads executing the program associated with the instruction when the programmable execution unit executes the instruction.

20. The method of any one of claims 11 to 14, wherein, When it is determined that a group of execution threads should be expelled, the method includes the steps of: immediately expelling the group of execution threads that are executing the program associated with the instructions.

Images