Constructing and scheduling tasks for parallel processing

Abstract

The present invention discloses building and scheduling tasks for parallel processing. A logic includes: a task builder for building tasks including data items, a task scheduler for scheduling tasks to be processed by a parallel processor, a data repository arranged to map the contents of each data item to an item ID, and a linked list RAM including entries for each item ID. For each new data item, the task builder creates a new task by starting a new linked list or adding the data item to an existing linked list. In each linked list, the entry record for each data item points to a pointer to the next item ID in the list. The task builder indicates when any one of the tasks is ready for scheduling. The task scheduler identifies the ready tasks based on the indication from the task builder and, in response, follows the pointer in the corresponding linked list to schedule the data items of the task for processing.

Description

Technical Field

[0001] The present invention relates to constructing and scheduling tasks for parallel processing. Background Art

[0002] A processor is a device for executing machine code instructions. A given processor is configured to recognize a specific predefined set of instruction types, referred to as the processor's instruction set. Each instruction type is defined by a corresponding opcode and zero or more operand fields. The processor is configured to fetch instructions from memory for execution. A processor may include many different types of subunits for performing different classes of operations depending on the type of instruction being executed. For example, a processor may include an integer arithmetic logic unit (ALU) for performing integer arithmetic operations in response to an arithmetic instruction type, a floating-point ALU for performing floating-point operations in response to a floating-point instruction type, and a load-store unit (LMU) for performing memory access operations in response to load and store instruction types.

[0003] For example, in a reduced instruction set computer (RISC) processor, a load instruction requires at least two operands: a source memory address and an identifier specifying a destination register in the processor's register file. When executed, the load instruction acts on a load-store unit to load the value from the source address into the destination register. Depending on the instruction type, logic instructions can take different numbers of operands. For example, a logic instruction such as an add or multiply instruction may take three operands: two specifying two corresponding source registers in the register file, and one specifying a destination register in the register file. When executed, the logic instruction acts on the associated logic unit, such as the integer or floating-point arithmetic logic unit, to perform the associated logic operation on the values ​​in the specified source registers and place the result in the specified destination register. The operation to be performed and which logic unit is triggered to perform the operation depends on the opcode of the associated instruction. Storing the result of the logic operation back to memory involves a store instruction. A store instruction requires at least two operands: one specifying the source register in the register file and one specifying the destination address in memory. When executed, a store instruction acts on a load-store unit to store the value in the specified source register to the destination memory address.

[0004] One way a specialized processor, such as a graphics processing unit (GPU), can be tailored for a specific application is to include one or more specialized instruction types in the processor's instruction set. Such instruction types will perform more complex operations than the simple load, store, add, or multiply operations triggered in response to a single instance of a single machine code instruction of the relevant type. For example, this could be a specific mathematical operation, such as a multiply-accumulate (MAC), which often appears in related applications. The same operation can be constructed using a combination of general-purpose add and multiply instructions, etc., but this will reduce code density compared to using instructions from a more specialized instruction set.

[0005] In certain types of processors, such as vector processors, SIMD (single instruction, multiple data), or SIMT (single instruction, multiple thread) processors, the processor includes multiple parallel processing channels (e.g., SIMD lanes). Each of the parallel processing channels may include a corresponding instance of at least one of the same type of logic unit. For example, each channel may include a corresponding arithmetic logic unit (ALU), such as an integer arithmetic logic unit (ALU) or a floating-point arithmetic logic unit (FLU). In response to the execution of the same instance of the same instruction extracted in a single fetch operation, some or all of the logic units in different parallel channels are triggered to perform the same operation on different data, such as performing the same operation on different elements of a vector in a vector register designated as the source of the operation. For example, each ALU may be operable to perform a multiply-accumulate (MAC), also known as a multiply-add operation. This requires two multiplication inputs (sometimes referred to as a multiplicand) and an addend input (also referred to as an accumulator), and adds the addend to the product of the two multiplication inputs. The MAC may be implemented as a fused multiply-add operation, thereby performing the multiply-accumulate operation in a single fused step. The result of the MAC for each parallel logic unit may be placed in a corresponding element of the destination vector register.

[0006] To take advantage of parallel processing resources, it may be desirable to group data to be processed together into tasks, where the data for a given task can be processed in parallel by the same program, and different tasks are to be processed by different programs.

[0007] An example arises in ray tracing. Ray tracing refers to a graphics processing technique that generates images by tracing the path of light through a modeled environment and simulating the effects of its encounters with objects along the way. Modeled rays are traced from a modeled light source to a modeled viewpoint (forward ray tracing), or vice versa, from a modeled viewpoint back to the modeled light source (i.e., reverse ray tracing, which is generally more efficient because forward ray tracing generally results in processing trajectories that ultimately never hit the viewpoint). A ray can be described by the coordinates of its starting point, a vector specifying the direction of the ray, the maximum and minimum range of the ray along that vector, and optionally the color of the ray. In the case of reverse ray tracing, ray tracing begins by casting a ray from each pixel in the image into the modeled environment. The objects that the ray can interact with in the modeled environment are divided into geometric primitives, such as triangular facets. For each ray, ray tracing involves finding the closest geometric primitive (if any) with which the ray interacts. In some graphics processors, this search is performed in fixed-function hardware. When an incoming ray intersects, it can then terminate, reflect, or refract. Reflection or refraction introduces one or more secondary rays with new directions relative to the incident ray that is terminated (ie, the reflected or refracted ray is modeled as a new ray). Secondary rays may also accumulate new values ​​(colors) relative to the incident ray.

[0008] Determining the effects of light interacting with geometric primitives is typically solved analytically in software. The programs that do this are called shader programs. There are often different shader programs running to handle different interaction scenarios.

[0009] For example, different shader programs may include: miss shader programs, nearest hit shader programs, any hit shader programs, and intersection shader programs. When a ray does not hit anything, the miss shader program is run. When a ray hits a geometry, the nearest hit shader program is run, where it is known that this hit will be maintained and the program is required to calculate the effect of the light at the hit point. When a ray hits a geometry, the any hit shader program is run, but the program is also required to decide whether to maintain the hit. If the hit is maintained, the nearest hit shader program will be run subsequently. When a ray hits a box with user-defined geometry in it, the intersection shader program is run, and the program is required to procedurally generate or load the geometry from memory, check which of these geometries is hit by the ray, and then decide whether to maintain the hit. If the hit is maintained, the nearest hit program will be run subsequently. The above is a classification derived from the ray tracing API standard. In one embodiment, the any hit shader and the intersection shader can be grouped together into a traversal shader.

[0010] In general, the operations performed to support ray tracing are: ray generation (generating rays), ray intersection (testing rays against primitives or boxes containing primitives), and ray traversal (searching a tree of said boxes or other such scene acceleration structures, and scheduling intersections along the tree's walk).

[0011] In order to take advantage of the availability of parallel processing resources such as parallel SIMD paths in a SIMD processor, different rays to be processed can be grouped together into tasks, where a given task can include multiple rays to be processed by the same shader program, and different tasks are processed by different shader programs. It is desirable to group rays to be processed by the same shader program together into tasks (where "ray" in this context refers to data representing optical rays). This process is called coherence aggregation. The execution of a shader program can be called by the intersection of rays or other things. It should also be noted that this is not necessarily just the rays processed by the shader program, but in embodiments, other factors associated with the rays are also included.

[0012] Sometimes this can include grouping rays that are to be processed by the same shader program and the same geometric primitives. For example, if different rays hit the same box or node of the acceleration structure, the shader will need to schedule intersection tests for all rays against all children of that box or tree node (although in other implementations this can be done in fixed-function hardware).

[0013] The processor module that groups rays together into tasks can be called a task builder. The module that takes the tasks built by the task builder and schedules them for processing can be called a task scheduler. In some processors, these can be implemented in fixed-function hardware.

[0014] When grouping rays into tasks, a trade-off arises. On the one hand, it is desirable to group rays together to the maximum number that can be processed in parallel by a parallel processor. For example, if a SIMD processing unit has 512 parallel SIMD lanes, it is desirable to group 512 rays together so that they can be processed in parallel with each other. On the other hand, it is also desirable to keep the processor busy, so if full-sized groups cannot be assembled quickly enough to keep the processor busy, it may be desirable to schedule smaller groups for execution. Another disadvantage of large tasks is that their data (e.g., rays) tends to be more divergent. This is due to branch divergence, where different instances of data follow different execution paths through the code. In short, if at least one instance follows a branch, all instances must follow that branch. Forced instances (instances that execute through a branch that would not have otherwise executed through the branch) execute the instructions of the branch, but these instructions have no effect on their state. The coherence aggregation mechanism also takes silicon occupancy into account. Summary of the Invention

[0015] Another potential source of stalls is in the interface between the task builder (producer) and the task scheduler (consumer). In known mechanisms in the prior art, tasks built by the task builder are queued in a first-in-first-out (FIFO) buffer, awaiting scheduling by the task scheduler. However, if the task builder produces tasks faster than the task scheduler consumes them, the FIFO may become full and thus stall the task builder. This may even cause further stalls in the pipeline. Including sufficient buffer capacity to avoid this situation would be very expensive in terms of silicon footprint. Therefore, it is desirable to provide an alternative interface between the task builder and the task scheduler.

[0016] According to one aspect disclosed herein, logic is provided that includes: a task builder for building a plurality of tasks, each task including a corresponding set of data items to be processed by a corresponding program; a task scheduler for scheduling each task to be processed by a corresponding program running on a parallel processing subsystem, whereby, for each task, at least some of the corresponding set of data items are processed in parallel; a data repository arranged to at least temporarily store the corresponding data content of each of the data items mapped to a corresponding item ID; and a linked list RAM including a corresponding entry for each item ID. The task builder is configured to build a task by: when a new data item is received into the data repository, determining whether there is an existing task for the new data item, and a) if not, creating a new task by starting a new corresponding linked list in the linked list RAM including the new data item, but b) if so, adding the new data item to the existing corresponding linked list in the linked list RAM, wherein in each linked list, the entry for each data item from the head data item to at least the last data item before the tail data item in the list records a pointer to the next item ID in the linked list. The task builder is further configured to indicate when any one of the tasks is ready for scheduling; and the task scheduler is arranged to identify the tasks that are ready for scheduling based on the indication from the task builder and, in response, follow the pointers in the corresponding linked lists to schedule the data items of the corresponding tasks for processing by the parallel processing subsystem.

[0017] By using a linked list, this provides a decoupling between the task builder (producer) and the task scheduler (consumer), enabling the task scheduler to run independently of the task builder, thereby alleviating the problem of stalling at this interface. Because the linked list RAM has a separate corresponding entry dedicated to each possible ray in the ray repository, only a relatively small amount of silicon is utilized, which makes it possible to accommodate any possible combination of grouping rays into tasks without the possibility of stalling between the task builder and the task scheduler. For example, in a ray tracing application, all rays in the system can theoretically be traversed and spliced ​​in the linked list without the scheduler consuming any of this data until it is ready to do so.

[0018] For the sake of completeness, please note that it is not excluded that some other tasks besides the plurality of tasks may consist of only a single data item. In this case, the head data item and the tail data item in the linked list RAM are identical.

[0019] In an embodiment, the task builder may be configured to perform said indication by asserting a corresponding flag in a linked list RAM to mark when any one of the tasks is ready for scheduling; and the task scheduler may be arranged to perform said identification by monitoring the linked list RAM to discover the asserted flag, and detect that one of the tasks is ready when the corresponding flag is asserted.

[0020] In an embodiment, the task builder may include a temporary storage device arranged to store one or more indications of tasks being built, and the task builder may be further configured to remove the indication of a selected task from the temporary storage device based on one or more predetermined criteria and indicate that the selected task is ready for scheduling.

[0021] In an embodiment, the temporary storage device may include a cache, the cache including a plurality of bins, each bin operable to cache one of the tasks by temporarily recording an indication of the task, wherein when a new task is created, the new task is cached in one of the bins, wherein the predetermined criteria may include an eviction policy, and the cache may be configured to evict tasks from the bins according to the eviction policy, and wherein the task builder may be configured to indicate that the selected task is ready for scheduling when the selected task is evicted from the cache.

[0022] In any embodiment, the logic may be embodied in hardware on an integrated circuit. A method of manufacturing a processor including the logic at an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided that, when processed in the integrated circuit manufacturing system, configures the system to manufacture the logic or processor. A non-transitory computer-readable storage medium may be provided that has a computer-readable description of the logic or processor stored thereon that, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit including the logic or processor.

[0023] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of a logic or processor; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit containing the logic or processor; and an integrated circuit generation system configured to manufacture the logic or processor based on the circuit layout description.

[0024] A computer program code for performing any of the methods described herein may be provided. A non-transitory computer readable storage medium may be provided having computer readable instructions stored thereon that, when executed at a computer system, cause the computer system to perform any of the methods described herein.

[0025] As will be apparent to those skilled in the art, the features described above may be combined as appropriate and with any aspects of the examples described herein.

[0026] This summary is provided solely to illustrate some of the concepts disclosed herein and their possible implementation. Not all of the information described in this summary is intended to limit the scope of this disclosure. Rather, the scope of this disclosure is limited solely by the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0028] Figure 1 is a schematic block diagram of a processor according to an embodiment of the present disclosure;

[0029] Figure 2 is a schematic block diagram of a graphics processor according to an embodiment of the present disclosure;

[0030] Figure 3 is a flowchart of a method performed by a task builder according to an embodiment of the present disclosure,

[0031] Figure 4 is a flowchart of a method performed by a task scheduler according to an embodiment of the present disclosure;

[0032] Figures 5a to 5c Schematically illustrates exemplary fields of a ray repository, a linked list RAM, and a task cache according to an embodiment of the present disclosure;

[0033] Figure 6 Schematically illustrates other exemplary fields of a task cache according to an embodiment disclosed herein;

[0034] Figures 7a and 7b Schematically shows a linked list being constructed and then closed;

[0035] Figure 8 is a schematic block diagram of a computer system in which a graphics processing system is implemented; and

[0036] Figure 9 is a schematic block diagram of an integrated circuit fabrication system for producing an integrated circuit that includes a graphics processing system.

[0037] The accompanying drawings show various examples. It will be understood by those skilled in the art that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent one example of boundaries. In some examples, it may be that an element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0038] The following description is given by way of example to enable those skilled in the art to make and use the invention. The present invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art.

[0039] The embodiments will now be described by way of example only.

[0040] Typically, the cache is used to collect coherence between rays hitting the same surface or different surfaces using the same shader for which the same shader is scheduled. For example, objects with the same material sometimes have the same shader or shader set. When a cache line is evicted due to a conflict or other reason, work is generated for scheduling. If the scheduler cannot process this work, the cache becomes stalled and unable to process any incoming lookup commands. For example, this stall can propagate upstream, affecting other logic responsible for traversing the acceleration structure.

[0041] Previous solutions have attempted to combat stalling by installing substantial buffers to minimize the likelihood of this occurring.

[0042] Embodiments disclosed herein use a cache to collect coherence between rays for which the same shader is to be scheduled. The cache uses a local ray array to build a ray list. A hit adds a ray to the linked list associated with a specific shader. After a cache line is evicted, its linked list is terminated and the entry point ray entering it is marked in the ray array. When searching for a ray marked as an entry point for a completed linked list, the scheduler simultaneously and independently scans through the ray array. The selected linked list is walked to read out its rays and schedule them. When the linked list is completely walked, the entry point ray flag is cleared to indicate that the linked list has been torn down. In some specific embodiments, a ray can only return to the coherence collector after it has been scheduled, and the ray sidebands entering the coherence collector do not propagate through the ray array and need to be obtained again by the scheduler. In practice, the scheduler can read the sideband information of only one of the rays in a task, because this information is the same for all rays in the task and is therefore task-specific.

[0043] Figure 1 FIG1 is a schematic block diagram of a processor 101 according to an embodiment of the present disclosure. The processor 101 includes a parallel processing subsystem 102 , a memory 104 , and coherence collection logic 105 .

[0044] Memory 104 may include one or more memory units, such as separate program memory and data memory. In an embodiment, memory 104 is internal to processor 101 (on the same chip, i.e., the same die). However, some or all of memory 104 may alternatively be external to processor 101 (either off-chip but in the same IC package, or external to the IC package). Memory 104 may employ one or more memory media, such as electronic media, such as EPROM, EEPROM, flash memory, or static or dynamic RAM; or one or more magnetic media, such as magnetic disks or tapes; or optical media, such as optical disks.

[0045] The parallel processing subsystem 102 includes one or more component processing units, each of which includes multiple parallel processing channels, such as SIMD paths. For example, in some embodiments, the parallel processing subsystem 102 may include two SIMD processing units, each of which includes multiple SIMD paths, such as 128 paths per SIMD unit. In an embodiment, one or more processing units may also be multi-threaded, i.e., a cylindrical thread unit capable of interleaving multiple concurrent threads in time through each path. For example, in some embodiments, each SIMD unit may be capable of interleaving up to 48 threads through each of the 128 SIMD paths. The embodiments of this document may be described based on the parallel processing subsystem 102, which is a SIMD subsystem comprising one or more SIMD units. However, more generally, in any of the embodiments below, the SIMD unit may be replaced by any form of parallel processor unit (e.g., a vector processing unit or a SIMT unit). For these purposes, “parallel processing” refers to data-level parallelism, i.e., the ability of different parallel channels (e.g., paths) of a given processing unit to execute instructions on different data items (which may also be referred to as data “instances”) fetched from memory 104 in the same instruction fetch.

[0046] Coherence collection logic 105 is coupled to parallel processing subsystem 102 and is configured to collect together different data instances (i.e., different data items) to be processed (i.e., operated on) by the same program so that they can be scheduled as batches for parallel processing by different parallel paths of parallel processing subsystem 102. That is, data instances are collected together into batches, where instances of a given batch are to be processed by the same program running on parallel processing subsystem 102, and at least some different tasks are to be processed by different corresponding programs. Batches of data instances may be referred to herein as "tasks," where work is to be performed on corresponding tasks by corresponding programs. Coherence collection logic 105 includes: a task builder 106, a task scheduler 108, a data repository 110 (e.g., a ray repository), and a linked list RAM 112. In an embodiment, processor 102 is a GPU, and each data instance may represent a corresponding ray of a ray tracing application. In this case, the program that processes a given task (ray batch) may be referred to as a shader program, and data repository 110 may be referred to as a ray repository.

[0047] By way of illustration, the following embodiments will be described in terms of such examples, but in any embodiment, more generally, GPU 102 may be any type of processor with parallel processing capabilities, and rays may be replaced by any data instances (i.e., any data items) to be collected together into a batch for parallel processing by any type of program. Another example is pixels covered by one or more identical primitives with the same pixel shader in rasterization.

[0048] The linked list RAM is operably coupled to both the task builder 106 and the task scheduler 108. The ray repository 110 is operably coupled to the task builder 106 and the parallel processing subsystem 102, and may also be operably coupled to the task scheduler 108.

[0049] Figure 5a An example of a ray repository 110 is shown in FIG. The ray repository 110 includes a plurality of ray repository entries 502, each entry including a ray ID (or more generally, an item ID or instance ID) 504 mapped to a corresponding ray description field 506, which is used to store the ray description of the corresponding ray (or more generally, the data of the corresponding data item, or "instance"). The ray ID 504 is the address of the ray repository 110, so the ray repository 110 can be addressed by the ray ID. For illustrative purposes, the ray ID is schematically represented as Figure 5a512 itself, but it should be understood that the ray ID is not a stored value stored in the entry 512 itself, but rather consists of a selectable combination of gates in the addressing circuitry of the ray repository 110, which, when selected, map to a value stored in a field (e.g., 506) of the entry 512. By way of illustration, in one embodiment, there may be approximately 8192 (=2^13) addresses in the ray repository. At any given time, some entries at some addresses may be occupied by ray descriptions, while some may not. Each ray description 506 includes information about the corresponding ray, such as the coordinates of its starting point, a vector describing its direction, its maximum and / or minimum extent, and / or an indication of the nearest geometric primitive with which the ray has intersected so far in the modeled environment.

[0050] In operation, new rays to be processed are received into the ray repository 110 (in this context, a "ray" refers to a data instance or item representing a ray). In an embodiment, directly or indirectly from an application running on a host processor ( Figure 1 These new rays are received by the parallel processing subsystem 102 (not shown). For example, they may be received from software running on the parallel processing subsystem 102 operating under the control of the host processor (e.g. via the command engine 206, see below). Alternatively, it is not excluded that the rays may be generated autonomously by the parallel processing subsystem 102, or may be received from another processing module internal or external to the processor 101. The task builder 106 is arranged to detect new rays arriving at the ray repository 110 and group them into tasks (i.e. batches), which are recorded in the form of linked lists in the linked list RAM 112, each linked list recording a different task in the task. An example of a linked list RAM 112 is shown in FIG. Figure 5b When a task is ready for scheduling, the task builder 106 marks it as such in the linked list RAM 112. The task scheduler 108 detects this and schedules the rays of the task via the parallel processing subsystem 102 for processing in parallel with each other.

[0051] More generally, the functionality of the linked list RAM can be distributed across one or more storage modules. For example, indicating that a task is ready can include sending a signal (e.g., including an identifier of the task, such as a ray ID from the task) to the task scheduler 108, wherein the task scheduler, upon receiving such a signal, stores a flag indicating that the task is ready elsewhere (e.g., in a storage device local to the task scheduler). In another example, rather than storing a flag indicating that a task is ready for scheduling, a separate list of ready tasks can be maintained, for example, in the form of a table indicating which tasks (identified by corresponding ray IDs) are ready.

[0052] Figure 2 Shown in more detail Figure 1However, it should be understood that this is given by way of example only and is not limiting. Figure 2 In the embodiment, the processor 101 is arranged as an accelerator for the host processor 202. Figure 1 In addition to the components described, the accelerator processor 101 includes a command engine 206, an intersection search block (e.g., a hierarchical search block) 212, and a processing interface 210. Each of these, as well as the task builder 106, the task scheduler 108, the ray repository 110, and the linked list RAM 112, are implemented in fixed-function hardware 208. The task scheduler 108, the ray repository 110, and the intersection search block 212 are operatively coupled to the parallel processing subsystem 102 via the processing interface 210. The processor 101 is operatively coupled to the host processor 202 via the ray command engine 206.

[0053] In operation, software running on the parallel processing subsystem 102 will initialize a new ray and then initiate an intersection search block 212 to process the ray. In an embodiment, the structure of the search is hierarchical, such as a hierarchy of boxes in the modeling space (box reference box, box reference box, etc.). Intersection detection (i.e., analytically determining the intersection of two objects (e.g., rays relative to boxes)) is an activity that is repeatedly performed while searching / traversing the hierarchy. More generally, the intersection search can use, for example, any accelerated structure search or geometric database search.

[0054] The output of the intersection search block 212 is the rays that need to have a new shader scheduled.The task builder 106 groups rays that need to run the same shader into tasks.

[0055] For example, the task scheduler 108 takes input from the host processor 202 via the ray command engine 206 and then runs various shader programs on the processing subsystem 102. This input specifies one or more new rays to be processed by the processor 101. The shader program running on the processing subsystem 102 then writes the new rays to the ray repository 110 via the interface 210. The shader program then initiates a search (in fixed-function hardware) to be performed by the intersection search block 212 to determine which is the closest geometric primitive (e.g., a triangle facet) that intersects the ray. In certain embodiments, this search may include a hierarchical search iteration, which includes a series of tests against an "acceleration structure" to find the closest geometric intersection along the ray. At the end of the search, the search block 212 stores information about the closest intersection in the ray description of the relevant ray in the ray repository 110 and also sends a signal to the task builder 106 to notify it that the intersection search for the new ray has completed (in this particular embodiment, this is how the task builder 106 detects new rays). The task builder 106 then determines whether to add the new ray to an existing task or to start a new task. Once a task is ready for scheduling, the task builder 106 sets a flag for the relevant linked list in the linked list RAM 112. The task scheduler 108 detects this flag, and the task scheduler 108 proceeds to schedule the task for processing by the processing subsystem 102.

[0056] The features described below can be applied to Figure 2 Processor 101 or Figure 1 The more general case.

[0057] The task builder 106 may be configured to perform the following operations: Figure 3 The task scheduler 108 may be configured to execute the following in operation: Figure 4 The method shown in .

[0058] In an embodiment, the task builder 106 and the task scheduler 108 are implemented in fixed-function hardware, i.e., dedicated circuits. However, it is not excluded that some or all of the functions of the task builder 106 and / or the task scheduler 108 may be implemented in software instead, which runs on the processing subsystem 102 of the processor 101 or the host processor (e.g., 202), or on another processing module inside or outside the processor 101.

[0059] Figure 33 shows a method for task builder 106. At step 310, task builder 106 detects that a new ray has been received in ray repository 110, for example, from host processor 202. In one embodiment, it detects this by receiving a signal from intersection search block 212, alerting it that the intersection search for the new ray has been completed and that the ray can therefore be included in the task. Alternatively, in other embodiments, the signal alerting task builder 106 of the new ray may come from elsewhere, or task builder 106 may be configured to detect the new ray by monitoring ray repository 110 for new occupied entries.

[0060] Regardless of the manner in which a new ray is detected, at step 320, the task builder 106 determines to which task the new ray is to be added. This may be an existing task or a new task. In embodiments, this determination may be based on the corresponding ray description 506 of the new ray in the ray repository 110. In some such embodiments, the ray repository 110 includes shader ID derivation logic 501 that is configured to automatically derive a shader ID from the corresponding ray description 506 of each new ray added to the ray repository 110. Alternatively, this logic may be implemented in the task builder 106 itself. Another option is to store the shader ID for each ray in the corresponding ray description in the ray repository 110.

[0061] The shader ID is the ID of the corresponding shader program for processing the ray. Therefore, each ray is mapped to a certain shader ID. The mapping of rays to shader IDs is many-to-one, so that multiple rays are mapped to the same shader ID. For example, rays that intersect with the same geometric primitive can be processed by the same shader ID. The derivation may also be more complicated than this. For example, in one embodiment, rays are grouped (e.g., cache tags are generated based on the following): shader ID, shader type (e.g., the most recent hit discussed in the background technology, etc.), and which SIMD engine (if multiple) generates the primary ray that is the initial ancestor of this ray.

[0062] Tasks are recorded as a linked list in the linked list RAM 112. If the shader ID of the new ray is the same as the shader ID of an existing task in the linked list RAM 112, the task builder 106 adds the new ray to the task. However, if there is no task in the linked list RAM 112 for this shader ID, the task builder 106 starts a new task in the linked list RAM.

[0063] Figure 5bAn exemplary embodiment of the linked list RAM 112 is shown. The linked list RAM 112 includes a plurality of list entries 512, each for an entry 502 in the ray repository 110, and thus for a ray ID 504 in the ray repository (the linked list RAM 112 has the same depth as the ray repository 110, e.g., 8192 entries). Each list entry 512 includes at least a ray ID 504 and a corresponding pointer field (next ray pointer) 514. Similar to the ray repository 110, the linked list RAM 112 is addressable by the ray ID 504. Like Figure 5a Thus, for illustrative purposes, the ray ID is schematically represented as Figure 5b , but it should be understood that the ray ID is not a stored value stored in entry 512 itself, but rather is composed of a selectable combination of gates in the addressing circuitry of linked list RAM 112. Pointer field 514 is operable to store a corresponding next ray pointer mapped to the corresponding ray ID 504. The next ray pointer is the ID of another ray in linked list RAM 112. Thus, linked list RAM 112 enables the creation of a linked list by recording, in its pointer field, the ID of the next ray in a given list for each ray except the last ray. The pointer field 514 for the last ray in the list (the tail) may point to itself, or may contain a null value, or in some embodiments may point back to the head of the list (in which case the task builder 106 sets the tail's next ray pointer when the task is ready for scheduling). The rays in the list link from head to tail. In one embodiment, the head is the most recently added ray, and the tail is the oldest added, but in alternative embodiments, this can be implemented in another manner. The members of the linked list (and therefore the members of the task represented by the linked list) can then be determined by following the pointers from one ray to the next in the linked list RAM 112. This process can be referred to as walking the list. The walk can start from the head, or from the tail, or anywhere in between when the tail points back to the head (i.e., a circular linked list embodiment).

[0064] The linked list RAM 112 also includes a mechanism for marking a linked list of tasks as ready for scheduling. In an embodiment, this is achieved by means of a separate valid flag (e.g., IsValid) 516 included in each entry 512 in the linked list RAM, so that when this flag is asserted, it indicates that the linked list tasks including this list entry are ready for scheduling. The flag can be a single bit, but it is not excluded that it can alternatively consist of more than one bit.

[0065] In an embodiment, each entry 512 in the linked list RAM may also include a corresponding entry point field 518 that is used to mark the entry as an entry point for walking along the list of which it forms a part, as will be discussed in more detail later (note that in this sense, "entry" is now used to refer to the point of entry into the list, rather than the list entry 512). For example, the entry point field may mark which entry is the head (e.g., an IsHead flag) or which entry is the tail (e.g., IsTail). However, this is not required, and in alternative embodiments, the entry point may be predetermined (e.g., always the head) or determined in some other manner.

[0066] Optionally, each entry in the linked list RAM 112 may also include a corresponding priority field 519 that maps to a corresponding ray ID. These will be discussed in more detail later.

[0067] At step 330, the task builder 330 adds the new ray to the determined task for that ray, either by starting a new linked list in the linked list RAM 112 for the new ray (if the new ray will be processed by a shader ID for which no existing task exists), or by adding the new ray to an existing linked list for an existing task in the linked list RAM 112 (if the new ray will be processed by a shader ID for which an existing task has already been started but not yet scheduled). When starting a new list, the first ray to be included in the list is initially both the head and the tail of the list (and sometimes some tasks may always include only one ray before being scheduled). When adding to an existing list, the new ray can be added to the head or tail of the list, depending on the implementation. In a specific embodiment, it is added to the head.

[0068] At step 340, the task builder 106 determines whether the task is ready for scheduling. In an embodiment, the task builder 106 includes a cache 114, which may be referred to as a task cache. The cache employed herein provides a fast method for checking whether a task already exists for a new ray, and furthermore, the cache eviction policy provides a convenient basis for determining when a task is ready for scheduling.

[0069] exist Figure 5cAn example of a task cache 114 is shown in FIG. The cache 114 includes a plurality of cells 522 (i.e., cache entries or "cache lines"). Each cell 522 includes at least one of a head pointer field 526h and a tail pointer field 526t that maps to a corresponding cell number 524. These are used to record the head pointer and tail pointer of the linked list of the corresponding task. This provides an indication of the corresponding linked list in the linked list RAM 112. Thus, each cell 522 can cache an indication of a different corresponding task in the task. In an embodiment, each cell 522 can include both a head pointer 526h and a tail pointer 526t. In an embodiment, there is a many-to-one mapping between a shader ID and a cache cell 522. When the task builder 106 receives an indication of a new ray's shader ID from logic 501 in the ray repository 110 (or in an alternative embodiment, when the shader ID derivation logic implemented in the task builder 106 itself does so), the task builder 106 performs a many-to-one transformation on the shader ID, such as a hash of the shader ID. The output of this transformation specifies one or more cache cells 522 to cache any tasks to be processed by that shader ID. Depending on the implementation, this can be a specific cell for the task or a subset of possible cells. If a new task is to be created for an incoming ray and one of these one or more cells is unoccupied (not already being used to cache a task), the unoccupied cell is used to cache an indication of the new task (by recording an indication at the head and / or tail of a new linked list for that task). On the other hand, if all one or more cells mapped to the new task's shader ID are already occupied, another existing task must be evicted from one of these cells to make room for the new task to be cached there. The existing evicted task is declared ready for scheduling based on being evicted from the cache.

[0070] Note: In embodiments where new rays are added to the head of the list and the head pointer is recorded in cache 114, the task builder will need to update the head pointer 526h in cache 114 each time a new ray is added to an existing task. Similarly, if new rays are added to the tail and the tail pointer is recorded in cache 114, the task builder 106 will need to update the tail pointer 526t each time a new ray is added to an existing task. If only the head pointer is recorded in the task cache 114 and a new ray is added to the tail of the corresponding task, or vice versa, then the pointer in the cache will not need to be updated each time. However, in some embodiments, it may be desirable to keep both the head pointer and the tail pointer in the cache, for example to assist in patching or stitching (see optional appendix discussed later).

[0071] Figure 6An exemplary embodiment of the task cache 114 is shown. Here, the cache 114 is arranged into sets and ways. A way is the previously mentioned cell 522, and each set 602 includes a corresponding subset of one or more cells. Figure 6 6. Each group of four ways is shown diagrammatically, but it should be understood that this is not limiting. When the task builder 106 receives a shader ID from the ray storage logic 501 (or, depending on the implementation, derives the shader ID itself), the task builder 106 performs a many-to-one transformation (e.g., a hash) on the shader ID. The output of this hash gives one of the groups 602. The task builder 106 also determines a tag for the shader ID, which distinguishes between different possible shader IDs that map to the same way. This is recorded as an additional field in each occupied way (cache cell). As previously mentioned, in some embodiments, the tag can be generated based on the shader ID and additional information such as the shader type and / or which of the multiple SIMD engines generated a ray.

[0072] For each new ray received from the ray repository 110, the task builder 106 determines whether a cache entry for the shader ID of the ray already exists. It does this based on the group number and tag, which uniquely map to the shader ID. If so, the task builder adds the ray to the task (i.e., ray batch) to be processed by the shader with that shader ID. However, if not, the task builder 106 will need to create a new task in the linked list RAM 112 and find a new way to cache this new task in the cache 114. To do this, it checks the many-to-one transformation (e.g., hash) of the shader ID to find the group 602 for that shader ID. If all ways 522 in the group 602 are not already occupied, the task builder 106 simply adds the new task to one of the unoccupied cells. However, if all ways 522 in the group 602 mapped to the shader ID are already occupied by other tasks, the task builder 106 will evict one of the existing tasks to accommodate the new task. Then, based on this, the evicted task is considered ready for scheduling. Depending on the implementation, the longest or shortest path in the group will be selected for eviction after a conflict, or the earliest or latest used path will be selected.

[0073] In some embodiments, there may be a maximum task length (where the length of a task is the number of items in its linked list), which may be based on the SIMD width of the processor. In this case, there are two options for solving this problem. First, the task builder 106 tracks the length of each task and then starts a new task when it reaches the maximum task length. The second alternative is that the builder 106 does not record the length of the task, but then in the scheduler 108, if the selected task is longer than the SIMD length, it splits the task during scheduling. To implement the first solution, the hardware maintains a counter for each cache entry. For the second solution, a single counter can be used on the selected task to be scheduled. The second option is cheaper to implement, but the former method has potential performance advantages.

[0074] After adding the new ray to the tasks in linked list RAM 112, if no tasks are ready for scheduling, the method loops back to step 310, where the task builder 106 continues to wait to detect more new rays being received into the ray repository 110. However, if the task is ready for scheduling, for example because it has been evicted from the task cache 114, the task builder 106 proceeds to step 350, where it marks the task as ready for scheduling in linked list RAM 112. This may also be described herein as closing the task (the task is referred to as closed). In one embodiment, this is accomplished by asserting a flag 516 of the list entry for one of the rays in the linked list. For example, in one embodiment, this may be the entry at the head of the list (marked with the IsHead flag) or the entry at the tail (marked with the IsTail flag), depending on the implementation. The method then loops back to step 310, where the task builder 106 continues to wait to detect more new rays being received into the ray repository 110.

[0075] The above is only one possible mechanism that may be used to check whether there is an existing task corresponding to the shader ID of the new ray. For example, more generally, similar functionality may be implemented using any temporary storage device arranged to store one or more indications of tasks being built, wherein the task builder 106 removes the indication of the selected task from the temporary storage device based on one or more predetermined criteria and indicates that the selected task is ready for scheduling when the indication is removed from the temporary storage device. Alternatively,

[0076] The task builder 106 could instead simply maintain a table of shader IDs that already have tasks in the linked list RAM 112, or it could record this in the linked list RAM 112 itself and check to see if a task exists each time a new ray is received. However, these approaches are less efficient in terms of speed and / or silicon.

[0077] Figure 6The arrangement is a particularly advantageous implementation because the many-to-one mapping allows X possible shader IDs to be accommodated in Y ways, where X >> Y. A buffer with a 1-to-1 mapping could be used, but this would require storage that can accommodate X shader IDs, which is very expensive in silicon terms.

[0078] Another alternative is to use a hash from "shader ID" to "cache line" to perform the mapping, but this will be more difficult to ensure that only unique mappings are used (even if a cache line is maintained for each ray in the ray repository). Another alternative is to read a subset of the cache line entries every cycle over multiple cycles (with the state machine searching all entries), but this will limit the rate at which input rays can be processed. Another alternative is to search the cache for a shader ID that matches the new ray by performing a comparison with each cached shader ID in parallel. However, this approach means that, in addition to the required parallel comparison logic being very expensive in terms of silicon area, RAM cannot be used to store the cached shader IDs (if it is required to read from all addresses in the same cycle), and flip-flops are used for the storage. Another alternative is to use a hash to map to a group, but with only one path, there is the risk that a series of rays will alternate between two shader IDs that map to the same group, so one group will be thrashed while all other groups remain unused.

[0079] By using a combination of hashes to the group, but then to multiple (e.g., 4) ways per group, it means that the 4 ways can be stored in parallel fields of the same RAM entry, and then 4 parallel comparisons performed to detect a hit. This attempts to limit the area cost associated with parallel comparisons, but good cache performance depends to some extent on the mapping function used, and the statistical distribution of the sequences of shader IDs associated with new rays. For example, the mapping should be performed using a hash that is chosen so that a typical sequence of shader IDs is reasonably distributed across all groups in the cache. If a series of shader IDs maps primarily to the same group, this can lead to cache "thrashing" (where "thrashing" refers to the repeated eviction of a cache line, which then needs to be reallocated a short time later), and therefore can lead to the scheduling of tasks that contain fewer items (e.g., rays) than they would otherwise.

[0080] In some embodiments, tasks or paths that become full simply stay in the cache until new rays are mapped to them, in which case they are evicted. However, in some other embodiments, cache 114 may employ alternative or additional cache eviction strategies to determine when to close tasks. To this end, each cache cell (or path) may include one or more additional fields. For example, these additional fields may include an age field 528 that records the time indication of when the corresponding task was added to the cache and / or a length field that records the length of the task in terms of the number of rays. Another alternative or additional example is a priority field 529 that records the priority level associated with the corresponding task. In an embodiment, the cache eviction strategy employed by cache 114 may additionally evict any task (regardless of whether it needs to be evicted to make room for a new task) in response to detecting that it exceeds a predetermined threshold age or length according to the corresponding field 528, and / or may randomly evict tasks. And / or, when it is necessary to select between tasks in multiple different ways of a given group to make room for a new task, the strategy may include evicting tasks among those tasks with the oldest age or longest length in the group according to the corresponding fields 528 in the cache 114, or randomly selecting tasks to evict from the group. As another example, the tasks selected for eviction in the group may include tasks with the highest priority level (most in need of scheduling) according to the corresponding priority fields 519. For example, tasks containing rays that are slowing down the pipeline or causing deadlocks because they are not scheduled may be assigned a high priority.

[0081] The cache 114 is also not limited to Figure 6 Another example of a possible cache-based mechanism is that any task can be cached in any cell of the task cache 114, and existing tasks are evicted only when the entire cache is full and any cell 522 can be evicted to accommodate a new task.

[0082] An alternative or additional method of determining whether a task is ready for scheduling, without necessarily using cache 114, is to determine that a task is ready once a threshold amount of time has passed since the task was created and / or once the task length exceeds a predetermined threshold number of rays. Another example is to randomly declare a task ready for scheduling. A combination of methods may also be used. For example, existing tasks may be evicted to accommodate new tasks or when they exceed a threshold age or length.

[0083] In an embodiment, the task scheduler 108 may include a "walking evictor" that is activated whenever the task scheduler runs low on available work. This mechanism will scan through the cache 114, trying to find a path containing the type of task that the scheduler urgently needs. The walking evictor is a background process that runs periodically to force work from the builder to the scheduler. The basis for selecting which to evict may include any of the factors discussed above or other factors, such as priority, age, length, or randomness.

[0084] Figure 4 4 shows a method for the task scheduler 108. At step 410, the task scheduler 108 monitors the linked list RAM 112 for any linked lists marked as closed (i.e., the tasks represented by the linked lists are ready for scheduling). In an embodiment, this includes monitoring any list entry 512 where the valid flag (IsValid) 516 is asserted. In some embodiments, this is also the list entry that will become the entry point for walking the list (labeled as IsHead or IsTail, depending on the implementation). As previously described, this can be indicated by a separate entry point tag field 518. In alternative embodiments, the valid flag 516 and the entry point tag can be the same field (i.e., entries marked with the valid flag are automatically used by the task scheduler 108 as entry points for the list). In other embodiments, each list entry 512 can include both the IsHead field and the IsTail field, so that both the head and tail of any given list are marked in the linked list RAM 112.

[0085] Monitoring can consist of scanning for rays with IsValid = 1 and IsHead = 1 (or IsValid = 1 and IsTail = 1). This is fast because it only requires scanning a bit vector whose length is equal to the number of rays, where each bit is the Boolean AND of the IsValid and IsHead flags (or IsValid = 1 and IsTail = 1).

[0086] At step 420, if no shutdown (i.e., ready) tasks are found, the method loops back to step 410, where the task scheduler 410 continues monitoring to find shutdown tasks. However, when a shutdown task is found, the task scheduler 108 proceeds to step 430, where it schedules the shutdown task's rays for processing by the parallel processing (e.g., SIMD) subsystem 102.

[0087] To do this, in embodiments where the task scheduler 108 walks the linked list starting at the entry marked with the entry point marker 518. For example, if the entry point marker 518 marks which entry holds the head of the linked list, the task scheduler may start walking the list from the head (following the head's next ray pointer field to the next ray in the list, then following the next ray pointer field of that ray's list entry to the next ray, and so on). Alternatively, if the entry point marker 518 marks the tail of the list (in embodiments where the tail's next ray pointer points back to the head), the task scheduler 108 may read the tail's next ray pointer to find the head's ray ID, and then walk the list starting from the head (or simply starting walking the list from the tail).

[0088] For each ray that task scheduler 108 encounters as it walks through the shutdown list, it supplies the ray ID of that ray to parallel processing subsystem 102. The ray ID may be supplied in raw or transformed form. For example, in some embodiments, scheduler 108 may package all the information required to launch a task 102 that includes a ray and then send that information to parallel processing subsystem 102 (i.e., scheduler 108 does not actually pass the ray ID in raw (untransformed) form). However, in other embodiments, task scheduler 108 may pass the ray ID in raw (untransformed) form.

[0089] The task scheduler 108 also receives shader IDs from the ray repository 110 and supplies them to the processing subsystem 102. In alternative variations, the processing subsystem 102 may read or receive the shader IDs directly from the ray repository 110 or some other element of the system. In any case, the shader ID points to a program in the memory 104, and each supplied ray ID points to a ray description in the ray repository 110, both of which the processing subsystem 102 can access. Thus, the processing subsystem runs the shader program pointed to by the supplied shader ID, thereby operating in parallel on the ray descriptions from the ray repository 110 corresponding to the supplied ray ID.

[0090] In other embodiments, each ray entry in linked list RAM 112 may also include a corresponding priority field for recording the priority level associated with the corresponding ray or its task. Depending on the implementation, the priority field may be populated only for one representative ray in the list (e.g., the head, tail, or entry point), thereby being set on a per-list (per-task) basis; or alternatively, it may be populated on a per-ray basis. In some embodiments, the priority may be set on a per-task basis and may be copied from the priority field of the ray task in cache 114. When determining which tasks or rays to schedule, task scheduler 106 may consider the priority levels in linked list RAM 112. For example, if a ray or task has a particular priority level, e.g., indicating that the ray or task is causing a deadlock or slowing down the pipeline, task scheduler 108 may choose to schedule the task or individual ray before task builder 106 marks the corresponding task as ready. (In some such embodiments, these deadlocked rays may bypass task builder 106 and linked list RAM 112 and proceed directly to scheduler 108 to be dispatched individually within the task, i.e., valid for a single instance of the task.) As another exemplary embodiment, if two or more tasks are ready within a short time span, the task scheduler 108 may schedule them in order of priority level (highest priority first).

[0091] Figure 7a shows an example of a linked list being built.

[0092] When the task builder 108 creates a new linked list, it sets the tail pointer 526t (TailPtr) and head pointer 526h (HeadPtr) of the new cell to the ray ID of the incoming ray. It then clears the tail flag (IsTail) of the ray (which in this example is the entry point flag 518) and also updates the next ray pointer 514 (NextPtr) of the tail ray, but does not reference itself as is sometimes done for the tail of a linked list. Instead, NextPtr is made to point to the actual cell 522 in the cache 114, whose identifier is the concatenation of the group number and the way number. This is an optional feature and will be discussed in more detail later (see "First Appendix").

[0093] When a ray arrives and hits a cell 522, the task builder 106 accumulates its ray ID 502 in the linked list by updating the cell's head pointer 526h (HeadPtr) and the ray's next ray pointer 514 (NextPtr). Whenever a new ray is added to a task, the task builder 106 asserts a valid flag ("IsValid") 516 for the corresponding ray's entry in the linked list RAM 112, indicating that the ray is now part of the linked list. The incoming ray's NextPtr is made to point to the old head ray, while the cell's new HeadPtr now points to the incoming ray.

[0094] Figure 7b The linked list is shown after it has been "closed" because its cell 522 has been evicted.

[0095] When closing a linked list, the task builder 106 updates the valid flag of the tail and also updates the next ray pointer 514 ("NextPtr") of the tail to point back to the head. The task scheduler 108 only considers linked lists that are ready and whose tail rays have the valid flag 512 asserted. Once a linked list is selected, the task scheduler 108 immediately starts by reading the NextPtr pointer of its tail ray.

[0096] When the cache 114 evicts cell 522, the task builder 106 closes its linked list by updating the NextPtr of its tail ray (oldest) to point to the head ray (newest). In this way, it creates a circular linked list that can be read in its entirety starting from any ray inside it. To distinguish between a tail ray or a head ray pointing to a cached cell, its IsValid flag is used, which was set when the task builder 106 closed the linked list. Note that the tail ray now points back to the head, and the cell no longer holds a reference to the linked list. The tail ray's isValid is now also 1.

[0097] In some embodiments, the disclosed logic 101 may optionally employ one or more additional features referred to herein as "appendices."

[0098] In the first optional appendix, the task scheduler 108 can use the information stored in the terminal ray of the linked list to implement the eviction of cache lines. That is, the scheduler 108 can signal the termination of the incomplete linked list. To this end, the last entry in a given task list points back to the cache cell 522 of the same task in the cache 114. In this way, if a consumer is working faster than the producer and is completely starved, the consumer can request the eviction of the cell and thus close its task so that new work can be provided to it before the task is marked as ready by the task builder 106. The tail of the task points back to its own cache cell 522 until it is marked as ready. Therefore, the task scheduler 108 can force it (i.e., the cell attached to the incomplete linked list) to be cleared and thus close the linked list so that the hungry downstream processor can consume it. The task will be forced to "close" and then it will only find its way to the scheduler along the pipeline (as usual). This is better than just signaling that it is starving and letting the producer (task builder 106) choose which region to evict, because the consumer can know what type of work it can or wants to do (e.g., if there are different priorities for work).

[0099] In a second optional addendum, the task scheduler 108 may choose to partially read out contiguous portions of the completed linked list while maintaining its structural integrity by patching it for subsequent access. That is, if the list becomes long (e.g., 100 rays), but the scheduler 108 or processing subsystem 102 can only process, for example, 64 rays at a time, the scheduler may truncate the list by scheduling only the top portion of the list and marking the remaining rays in the middle as the new head (or scheduling only the bottom portion of the list and marking the remaining rays in the middle as the new tail).

[0100] In a third optional appendix, the task scheduler can read out a single ray from anywhere in the linked list while maintaining its structural integrity by patching it for subsequent access. Normally, the scheduler 108 walks the linked list RAM 112 looking for anything marked as closed. However, in this appendix, the scheduler 108 can choose to query for a specific ray ID ("ray number X") or extract a specific ray for scheduling. To facilitate this, the tail points back to the head so that the scheduler can read the entire list without having to start at the head. If the task scheduler 108 does not necessarily know where the head is, for example, because the linked list RAM 112 does not include a head marker (such as Figure 5b ) and the tail does not (or at least not yet) point back to the head.

[0101] In a fourth optional appendix, completed linked lists can be stitched together in a meta-linked list based on priority or other criteria. This can be done by the task builder 106. This means that when scheduling, the scheduler 108 does not need to scan to find the next linked list, but only needs to follow the metadata linked list. Ray markers can be used to depict each linked list. In certain embodiments of this point, random access to each linked list is not possible because we only maintain entry points in the meta-linked list. These ray markers can be used to depict each linked list.

[0102] Figure 8 804, memory 806, and other devices 814, such as a display 816, speakers 818, and a camera 819. Processing blocks 810 (with Figure 1 802 in the processing subsystem 102). In other examples, the processing block 810 may be implemented on the CPU 802. The components of the computer system may communicate with each other via the communication bus 820. The repository 812 (which may correspond at least in part to the Figure 1 The memory 104 in is implemented as part of the memory 806.

[0103] Figures 1 to 7b The logic of the example is shown as including a number of functional blocks. This is illustrative only and is not intended to define a strict division between the different logical elements of such an entity. Each functional block may be provided in any suitable manner. It should be understood that intermediate values ​​described herein as being formed by the logic need not be physically generated by the logic at any point and may simply represent logical values ​​that conveniently describe the processing performed by the logic between its inputs and outputs.

[0104] The logic described herein can be included in hardware on an integrated circuit. The logic described herein can be configured to perform any of the methods described herein. Generally speaking, any of the functions, methods, techniques or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry) or any combination thereof. The terms "module," "function," "component," "element," "unit," "block," and "logic" can be used herein to generally represent software, firmware, hardware, or any combination thereof. In the case of software implementation, a module, function, component, element, unit, block, or logic represents a program code that performs a specified task when executed on a processor. The algorithms and methods described herein can be performed by one or more processors of an execution code that causes the processor to execute the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk storage, and other memory devices that can store instructions or other data using magnetic, optical, and other technologies and can be accessed by a machine.

[0105] As used herein, the terms computer program code and computer-readable instructions refer to any type of executable code for execution by a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code that defines an integrated circuit (e.g., a hardware description language or netlist), and code expressed in programming languages ​​such as C, Java, or OpenCL. Executable code can be, for example, any type of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, or run in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0106] A processor, computer, or computer system can be any kind of device, machine, or specialized circuit, or a collection or portion thereof, that has processing capabilities so that instructions can be executed. A processor can be any kind of general-purpose or specialized processor, such as a CPU, GPU, system on a chip, state machine, media processor, application-specific integrated circuit (ASIC), programmable logic array, field-programmable gate array (FPGA), etc. A computer or computer system can include one or more processors.

[0107] The present invention is also intended to encompass software that defines the configuration of hardware as described herein, such as hardware description language (HDL) software, for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided having encoded thereon computer-readable program code in the form of an integrated circuit definition data set that, when processed (i.e., executed) in an integrated circuit manufacturing system, configures the system to manufacture logic configured to perform any of the methods described herein, or to manufacture logic comprising any of the devices described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0108] Thus, a method of manufacturing logic as described herein at an integrated circuit manufacturing system may be provided. Furthermore, an integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, enables the method of manufacturing logic to be performed.

[0109] The integrated circuit definition data set may be in the form of computer code, for example, as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in the integrated circuit, including as register transfer level (RTL) code, as a high-level circuit representation (such as Verilog or VHDL), and as a low-level circuit representation (such as OASIS (RTM) and GDSII). Higher-level representations that logically define hardware suitable for fabrication in the integrated circuit (such as RTL) may be processed on a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining these elements to generate a manufacturing definition of the integrated circuit defined by the representation. As is typically the case when software is executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of the integrated circuit in order to execute the code that defines the integrated circuit in order to generate the manufacturing definition of the integrated circuit.

[0110] Now refer to Figure 9 An example of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system into manufacturing logic is described.

[0111] Figure 9An example of an integrated circuit (IC) manufacturing system 902 configured to manufacture logic as described in any of the examples herein is shown. Specifically, the IC manufacturing system 902 includes a layout processing system 904 and an integrated circuit generation system 906. The IC manufacturing system 902 is configured to receive an IC definition data set (e.g., defining logic as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., including logic as described in any of the examples herein) based on the IC definition data set. The processing of the IC definition data set configures the IC manufacturing system 902 to manufacture an integrated circuit including logic as described in any of the examples herein.

[0112] The layout processing system 904 is configured to receive and process an IC definition data set to determine a circuit layout. Methods for determining a circuit layout based on an IC definition data set are known in the art and may, for example, involve synthesizing RTL code to determine a gate-level representation of the circuit to be generated, such as for logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout can be determined based on the gate-level representation of the circuit. This can be done automatically or with user input to optimize the circuit layout. Once the layout processing system 904 has determined the circuit layout, the layout processing system may output the circuit layout definition to the IC generation system 1006. The circuit layout definition may be, for example, a circuit layout description.

[0113] As is known in the art, IC generation system 906 generates an IC based on a circuit layout definition. For example, IC generation system 906 may implement a semiconductor device manufacturing process to generate the IC, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that can be used in a photolithography process to generate the IC based on the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 906 may be in the form of computer-readable code, which IC generation system 906 may use to generate a suitable mask for generating the IC.

[0114] The various processes performed by IC manufacturing system 902 may all be performed at a single location, such as by one party. Alternatively, IC manufacturing system 902 may be a distributed system, such that some processes may be performed at different locations and by different parties. For example, some of the following stages may be performed at different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) generating a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0115] In other examples, processing of an integrated circuit definition data set at an integrated circuit manufacturing system may configure the system to manufacture logic without processing the IC definition data set to determine the circuit layout. For example, the integrated circuit definition data set may define the configuration of a reconfigurable processor, such as an FPGA, and processing of the data set may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading the configuration data into the FPGA).

[0116] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set may enable the integrated circuit manufacturing system to generate an apparatus as described herein. Figure 9 An integrated circuit manufacturing system can be configured in the manner described to manufacture the devices described herein.

[0117] In some examples, the integrated circuit definition data set may include software that runs on, or in combination with, hardware defined at the data set. Figure 9 In the example shown, the IC generation system can be further configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined in the integrated circuit definition dataset when manufacturing the integrated circuit, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0118] Compared to known implementations, the implementation of the concepts set forth in this application in devices, equipment, modules and / or systems (and in the methods implemented herein) can result in performance improvements. Performance improvements can include one or more of improved computing performance, reduced latency, increased throughput and / or reduced power consumption. During the manufacture of such devices, devices, modules and systems (e.g., in integrated circuits), a compromise can be made between performance improvements and physical implementations, thereby improving manufacturing methods. For example, a trade-off can be made between performance improvements and layout area, thereby matching the performance of known implementations, but using less silicon. For example, this can be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of a device, device, module and / or system. In contrast, the concepts of improvements (such as reduced silicon area) that result in physical implementations of devices, devices, modules and systems set forth in this application can be weighed against performance improvements. For example, this can be accomplished by manufacturing multiple instances of a module within a predefined area budget.

[0119] The applicant hereby independently discloses each individual feature described herein, as well as any combination of two or more such features, to the extent that such feature or combination can be implemented according to the common general knowledge of a person skilled in the art based on the present specification as a whole, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be clear to a person skilled in the art that various modifications can be made within the scope of the present invention.

[0120] According to one aspect disclosed herein, there is provided a logic as set forth in the Summary section.

[0121] In an embodiment, the eviction policy may include, when a new task is created and a set of cells suitable for caching the new task is full, evicting an existing task from one of the cells in the set to accommodate the new task.

[0122] In an embodiment, a cache may be arranged into groups and ways, each group including one or more of the ways, and the ways being a grid, wherein each group is mapped to a subset of tasks, and the cache is configured such that when a new task is created, the new task is added to a way of the group mapped to the new task; and the eviction policy may include, when a new task is created and all ways of the group mapped to the new task are full, evicting an existing task from a way of the group to accommodate the new task.

[0123] In an embodiment, each task may have an associated priority recorded in the cache indicating a priority for scheduling the corresponding task, and the existing task selected for eviction may be the task with the highest scheduling priority in the group.

[0124] Alternatively, in an embodiment, the existing task selected for eviction may be the task with the largest number of data items in the corresponding linked list.

[0125] As another possibility, each task may have an associated age recorded in the cache indicating the time since the task was created, and the existing task selected for eviction may be the task with the oldest age.

[0126] Alternatively or additionally, in an embodiment, each task may have an associated age recorded in the cache indicating the time since the task was created, and the eviction policy may include evicting the task if the age exceeds a threshold.

[0127] Alternatively or additionally, in an embodiment, the eviction policy may include evicting a task if the length of the corresponding linked list exceeds a threshold number of data items.

[0128] Alternatively or additionally, in an embodiment, the eviction strategy may include evicting tasks randomly.

[0129] In an embodiment, the indication of each task in the cache may include a pointer to the entry ID of the head and / or tail data item in the corresponding linked list.

[0130] In an embodiment, each entry in the linked list RAM may further include an entry point tag, wherein the task builder may be configured to, for each task ready for scheduling, assert one of the entry point tags to indicate which data item in the linked list will be used as the entry point for the list; and the task scheduler may be configured to start from the data item in the entry where the entry point tag is asserted when following the pointer of the corresponding linked list to perform said scheduling.

[0131] In an embodiment, the entry of the tail data item in each linked list may record a pointer to itself or include a null value.

[0132] Alternatively, the entry for the tail data item in each linked list records a pointer to the head data item of the corresponding linked list. In some such embodiments, the task scheduler may be operable to schedule any selected individual data item from a linked list for processing and stitch together the rest of the linked list for future scheduling by setting the pointer of the adjacent entry before the entry of the individual data item to point to the data item of the adjacent entry after the entry of the individual data item.

[0133] In an embodiment, the task builder may be operable to set the entry of the tail data item of the linked list of at least one task to point to the cache cell of the corresponding task in the cache; and wherein the task scheduler is configured such that if work is urgently needed, the corresponding task is scheduled from the cache cell pointed to by the tail before being indicated as ready by the task builder.

[0134] In an embodiment, the task scheduler is operable to schedule only a contiguous subset of data items from the beginning or end of a task and leave the remainder of the task for future scheduling by making one of the remaining data items the new head or tail item, respectively.

[0135] In an embodiment, the task builder may be operable to patch together two tasks that set the pointer in the entry of the tail data item in one of the two corresponding linked lists to point to the head data item of the other, thereby creating a meta-linked list, and may be configured to schedule the data items of the two tasks by following the pointer from one list to the next list in the meta-linked list.

[0136] In an embodiment, each data item may represent a graphical element.

[0137] For example, each graphics element may be a ray of a ray tracing application, and the data content of each data item may include a ray description.

[0138] In some such embodiments, each respective program may be a shader program for processing rays for the respective task.

[0139] In an embodiment, the task builder and the task scheduler may be implemented in fixed-function hardware circuitry.

[0140] According to another aspect disclosed herein, a processor may be provided, comprising: the logic of any embodiment, and a parallel processing subsystem.

[0141] In an embodiment, the processor may take the form of an accelerator processor acting as an accelerator for a host, the accelerator processor being configured to receive data items from the host.

[0142] In an embodiment, the logic or processor may be embodied in hardware on an integrated circuit.

[0143] According to another aspect, a method of manufacturing the logic or processor of any embodiment disclosed herein using an integrated circuit manufacturing system is provided.

[0144] According to another aspect, an integrated circuit definition data set is provided that, when processed in an integrated circuit manufacturing system, configures the integrated circuit manufacturing system to manufacture the logic or processor of any embodiment disclosed herein.

[0145] According to another aspect, an integrated circuit manufacturing system is provided, configured to manufacture the logic or processor of any embodiment disclosed herein.

[0146] According to another aspect disclosed herein, a method is provided, comprising: constructing a plurality of tasks, each task including a corresponding set of data items to be processed by a corresponding program; scheduling each task to be processed by a corresponding program running on a parallel processing subsystem, such that for each task, at least some of the data items in the corresponding set are processed in parallel; at least temporarily storing the corresponding data content of each data item mapped to a corresponding item ID in a data repository; and maintaining a linked list RAM including a corresponding entry for each item ID. Task construction is performed by: when a new data item is received into the data repository, determining whether there is an existing task for the new data item, and a) if not, creating a new task by starting a new linked list in the linked list RAM including the new data item, but b) if so, adding the new data item to the existing linked list in the linked list RAM, wherein in each linked list, the entry for each data item from the head data item to at least the last data item before the tail data item in the list records a pointer to the next item ID in the linked list. Task construction also includes indicating when any of the tasks is ready for scheduling. The scheduling includes identifying tasks ready for scheduling based on the indication from the build, and in response, following pointers in the corresponding linked lists to schedule data items of the corresponding tasks for processing by the parallel processing subsystem.

[0147] In an embodiment, the method may include steps corresponding to the operations of any embodiment of logic or processor disclosed herein.

[0148] According to another aspect, a graphics processing system configured to perform the method may be provided.

[0149] According to another aspect, a computer readable code is provided, the computer readable code being configured to cause the method to be performed when the code is executed.

[0150] According to another aspect, a computer-readable storage medium is provided, on which the computer-readable code is encoded.

[0151] According to other aspects disclosed herein, a corresponding method of operating logic or a processor and a corresponding computer program configured to operate the logic or processor may be provided. According to other aspects, a corresponding method of manufacturing logic or a processor, a corresponding manufacturing facility arranged to manufacture the logic or processor, and a corresponding circuit design data set contained on a computer-readable storage device may be provided.

[0152] For example, according to one aspect, a non-transitory computer-readable storage medium may be provided, on which a computer-readable description of the logic or processor of any embodiment of the present invention is stored. When the computer-readable description is processed in an integrated circuit manufacturing system, the integrated circuit manufacturing system: processes the computer-readable description of the logic or processor using a layout processing system to generate a circuit layout description of an integrated circuit containing the logic or processor; and uses the integrated circuit generation system to manufacture the logic or processor based on the circuit layout description.

[0153] According to another aspect, an integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of the logic or processor of any embodiment disclosed herein; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit containing the logic or processor; and an integrated circuit generation system configured to manufacture the logic or processor based on the circuit layout description.

[0154] According to another aspect, a method of manufacturing the logic or processor of any embodiment disclosed herein using an integrated circuit manufacturing system may be provided, the method comprising: processing a computer-readable description of the circuit using a layout processing system to generate a circuit layout description of an integrated circuit including the logic or processor; and manufacturing the logic or processor according to the circuit layout description using the integrated circuit generation system.

[0155] According to another aspect, a layout processing system may be provided, the layout processing system being configured to determine location information of logic components of a circuit derived from an integrated circuit description to generate a circuit layout description of an integrated circuit including the logic or processor of any embodiment disclosed herein.

[0156] Once the present disclosure is given herein, other variations, implementations, and / or applications of the disclosed technology may become apparent to those skilled in the art.The scope of the present disclosure is not limited by the above-described embodiments, but only by the claims.

Claims

1. A device for constructing and scheduling tasks for parallel processing, the device comprising: a task builder for building a plurality of tasks, each task including a corresponding set of data items to be processed by a corresponding program; a task scheduler for scheduling each of the tasks to be processed by the respective program running on the parallel processing subsystem, whereby for each task, at least some of the respective set of data items are processed in parallel; a data repository arranged to at least temporarily store the respective data content of each of said data items mapped to the respective item ID; as well as a linked list RAM comprising a corresponding entry for each project ID, wherein the linked list RAM has the same depth as the ray repository; wherein the task builder is configured to build the task in the following manner: when a new data item is received into the data repository, determine whether there is an existing task for the new data item, and a) if not, create a new task by starting a new corresponding linked list in a linked list RAM including the new data item, but b) if it exists, add the new data item to an existing corresponding linked list in the linked list RAM, wherein in each linked list, an entry for each data item from the head data item to at least the last data item before the tail data item in the list records a pointer to the next item ID in the linked list; wherein the task builder is further configured to indicate when any one of the tasks is ready for scheduling; and The task scheduler is arranged to identify tasks ready for scheduling based on indications from the task builder and, in response, follow pointers in corresponding linked lists to schedule data items of corresponding tasks for processing by the parallel processing subsystem.

2. The apparatus of claim 1 , wherein the task builder is configured to execute the indication by asserting a corresponding flag in the linked list RAM to mark when any one of the tasks is ready for scheduling; and Wherein the task scheduler is arranged to perform the identification by monitoring the linked list RAM for an asserted flag, and to detect that one of the tasks is ready when the corresponding flag is asserted.

3. An apparatus according to claim 1 or 2, wherein the task builder includes a temporary storage device arranged to store one or more indications of tasks being built, and the task builder is configured to remove the indication of a selected task from the temporary storage device based on one or more predetermined criteria and indicate that the selected task is ready for scheduling.

4. The apparatus of claim 3 , wherein the temporary storage device comprises a cache, the cache comprising a plurality of cells, each cell being operable to cache one of the tasks by temporarily recording an indication of the task, wherein when a new task is created, the new task is cached in one of the cells, wherein the one or more predetermined criteria comprise an eviction policy, and the cache is configured to evict tasks from the cells according to the eviction policy, and The task builder is configured to indicate that the selected task is ready for scheduling when the selected task is evicted from the cache.

5. The apparatus of claim 4, wherein the eviction strategy comprises: When a new task is created and a set of cells suitable for caching the new task is full, an existing task is evicted from one of the cells in the set to accommodate the new task.

6. The device according to claim 5, wherein: the cache being arranged into groups and ways, each group comprising one or more of the ways, and the ways being the grid, wherein each group is mapped to a subset of the tasks, and the cache being configured such that when a new task is created, the new task is added to one of the ways of the group mapped to the new task; and The eviction strategy includes: when a new task is created and all ways of the group mapped to the new task are full, evicting an existing task from one of the ways of the group to accommodate the new task.

7. The apparatus of claim 5, wherein one of the following: Each task has an associated priority recorded in the cache, the associated priority indicating a priority for scheduling the corresponding task, and wherein the existing task selected for eviction is the task in the group having the highest scheduling priority; or The existing task selected for eviction is the task in the corresponding linked list that has the largest number of data items; or Each task has an associated age recorded in the cache indicating the time since the task was created, and the existing task selected for eviction is the task with the oldest age.

8. The apparatus of claim 4, wherein one or more of the following: Each task has an associated age recorded in the cache, the associated age indicating a time since the task was created, and wherein the eviction policy comprises: If said age exceeds a threshold, the task is expelled; and / or The eviction strategy includes: evicting a task if the length of the corresponding linked list exceeds a threshold number of data items; and / or The eviction strategy includes a random eviction task.

9. The apparatus of claim 3, wherein the indication of each task in the cache comprises a pointer to an entry ID of a head and / or tail data item in a corresponding linked list.

10. The apparatus of claim 1 , wherein each entry in the linked list RAM further comprises an entry point tag, wherein the task builder is configured to, for each task ready for scheduling, assert one of the entry point tags to indicate which data item in the linked list will be used as an entry point for the list; and the task scheduler is configured to start from the data item in the entry in which the entry point tag is asserted when following the pointer of the corresponding linked list to perform the scheduling.

11. The apparatus according to claim 1 , wherein: The entry for the tail data item in each linked list records a pointer to the head data item of the corresponding linked list; and The task scheduler is operable to schedule any selected individual data item from one of the linked lists for processing, and stitch together the remainder of the linked list for future scheduling by setting a pointer to an adjacent entry preceding the entry of the individual data item to point to an adjacent entry following the entry of the individual data item.

12. An apparatus according to claim 4, wherein the task builder is operable to set the entry of the tail data item in the linked list of at least one task to point to the cache grid of the corresponding task in the cache; and wherein the task scheduler is configured so that if work is urgently needed, the corresponding task is scheduled from the cache grid pointed to by the tail before being indicated as ready by the task builder.

13. An apparatus according to claim 1, wherein the task scheduler is operable to schedule only a contiguous subset of the data items from the beginning or end of one of the tasks, and to leave the remainder of the task for future scheduling by using one of the remaining data items as a new head or tail item, respectively.

14. The device of claim 1 or 2, wherein the device is embodied on an integrated circuit.

15. A method for constructing and scheduling tasks for parallel processing, the method comprising: constructing a plurality of tasks, each task including a corresponding set of data items to be processed by a corresponding program; scheduling each of the tasks to be processed by the respective program running on the parallel processing subsystem whereby, for each task, at least some of the respective set of data items are processed in parallel; storing, at least temporarily, the corresponding data content of each data item mapped to the corresponding item ID in the data repository; and maintaining a linked list RAM including a corresponding entry for each project ID, wherein the linked list RAM has the same depth as the ray repository; wherein the construction of the task is performed in the following manner: when a new data item is received into the data repository, determining whether there is an existing task for the new data item, and a) if not, creating a new task by starting a new corresponding linked list in a linked list RAM including the new data item, but b) if it exists, adding the new data item to an existing corresponding linked list in the linked list RAM, wherein in each linked list, an entry for each data item from the head data item to at least the last data item before the tail data item in the list records a pointer to the next item ID in the linked list; The construction of the tasks further includes indicating when any one of the tasks is ready for scheduling; and The scheduling includes identifying tasks ready for scheduling based on the indication from the build, and in response, following pointers in the corresponding linked lists to schedule data items of the corresponding tasks for processing by the parallel processing subsystem.

16. A computer-readable storage medium having stored thereon a computer-readable description of the apparatus according to claim 1 or 2, wherein the computer-readable description, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit containing the apparatus.

17. A method of manufacturing the integrated circuit according to claim 14 using an integrated circuit manufacturing system.

18. An integrated circuit manufacturing system configured to manufacture the integrated circuit according to claim 14.

19. A graphics processing system configured to execute the method according to claim 15. 20 . A computer-readable storage medium having computer-readable code stored thereon, wherein the computer-readable code is configured to cause the method according to claim 15 to be executed when the code is executed.

Images