Memory allocation in a ray tracing system

Abstract

The invention relates to memory allocation in a ray tracing system. A method of processing a ray in a ray tracing system, the method comprising allocating a memory block for a task on a task basis; processing the ray in the task such that at least one subray is emitted; writing intermediate data of the task to the memory block; suspending the processing of the task; and when the task is ready to resume, reading the intermediate data of the task from the memory block and resuming the processing of the task.

Description

Technical Field

[0001] This disclosure relates to allocating memory for recursive processing in a ray tracing system. Background Technology

[0002] Ray tracing is a computational rendering technique used to render an image of a scene by tracing the path of light (“rays”) through the scene from the viewpoint where the scene image is being rendered. Rays can be modeled as originating from the viewpoint and entering the scene through sampling locations in the rendering space. Each pixel of the rendered image may correspond to one or more sampling locations in the rendering space. Rays originating from the viewpoint are called “first-order rays”. Figure 1 This illustrates how light is handled in a ray tracing system. In step S102, a ray-generating shader is executed for one or more primary rays to process the rays(s). A “shader” (which may be referred to as a “shader program”) is a software module that includes one or more computer-readable instructions that can be executed on a processing unit. The functionality performed by the shader is flexible and defined by the programmer who writes the shader code. As a ray traverses a scene, it may intersect with one or more objects within the scene. The intersection between the ray and the objects it intersects can be modeled to create realistic visual effects. For example, the first shader executed for a primary ray (“ray-generating shader”) may include instructions (“TraceRay” instructions) that, in step S104, cause an intersection testing process to be performed to find one or more intersection points of the ray with one or more objects in the scene. The intersection testing process can be performed in hardware or software, but is typically performed in hardware (e.g., using fixed-function circuitry) because processing efficiency is generally considered more important than the flexibility of the functionality of the intersection testing process. In step S106, in response to finding the intersection of a ray and an object, a shader is executed for that intersection. The shader executed (or “runs”) in step S106 can be a most recently hit shader, a missed shader, an intersecting shader, or any hit shader as defined in the Vulkan and DirectX ray tracing specifications. The programmer writes the shader program to define how the system reacts to the intersection. The shader executed in step S106 may include a TraceRay instruction that causes one or more additional rays (called “secondary rays”) to be emitted into the scene, for example, to represent reflections of light from intersecting objects or refractions of light through objects (e.g., if the objects are transparent or translucent). As another example, the shader program may cause one or more rays to be emitted into the scene to determine whether an object is in shadow at the intersection. Therefore, the method can return from step S106 to step S104, as in Figure 1The dashed line representing "TraceRay" is shown in step S104. When an intersection of secondary rays is found (in step S104), another shader can be executed (in step S106). In this way, the method is recursively performed between steps S106 and S104 when the shader executed in step S106 includes a TraceRay instruction.

[0003] A ray is described by data defining its origin, direction, maximum culling distance (“Tmax”), and minimum culling distance (“Tmin”). Rays are accompanied by user-defined payloads, which are modifiable as the ray interacts with geometry in the scene and are visible to the caller of the TraceRay instruction. Furthermore, according to the Vulkan and DirectX ray tracing specifications, the shader executed in step S106 may include one or more “CallShader” instructions that cause another shader to be executed. Therefore, one shader can call another shader, allowing the method to be performed recursively between different shaders, such as... Figure 1 The dashed line representing "CallShader" indicates the first ray. Once all shaders for a first ray have completed, the output of that ray is provided. This output can be a rendering value (such as pixel color), which will be used for the pixels corresponding to that ray. In this way, the rendering values ​​for the pixels representing the scene's image are determined.

[0004] Vulkan and DirectX are application programming interfaces (APIs) for 3D graphics processing, featuring ray tracing extensions that define how programmers can use ray tracing systems to render images of 3D scenes. These APIs pioneered the concept of shader recursion for use in ray tracing systems. As described above, shader recursion occurs when instructions implemented within a shader cause one or more other shaders to be invoked. The called shader (which may be referred to as the "child" shader) is treated similarly to a function call, where control eventually returns to the calling shader (which may be referred to as the "parent" shader). Payload data can be passed from the parent shader to the child shader, and the child shader can communicate in reverse with the parent shader by updating the payload data.

[0005] When using shader recursion, some intermediate data is maintained in the parent shader so that the parent shader can continue its execution while the child shader has finished. Many rays can be processed in parallel within a ray tracing system. Furthermore, to achieve realistic rendering results, ray tracing systems can allow large recursion depths, such as a maximum recursion depth of up to 31. Therefore, the lifetime of the parent shader's intermediate data can be very long, and at any given time, there may be many shaders maintaining intermediate data. Summary of the Invention

[0006] This summary is provided to introduce, in a simplified form, a series of concepts further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0007] According to a first aspect of the invention, a method for processing light rays in a ray tracing system is provided, the method comprising: allocating a memory block for a task on a task-by-task basis; processing light rays in the task such that at least one sub-ray ray is emitted; writing intermediate data of the task into the memory block; pausing processing of the task; and when the task is ready to resume, reading the intermediate data of the task from the memory block and resuming processing of the task.

[0008] A memory block can be a contiguous block of memory reserved for storing intermediate data for a task.

[0009] Intermediate data for a task can be stored independently of intermediate data generated for any other task.

[0010] A task may include multiple instances of a shader program corresponding to the multiple rays for which a shader program is to be executed.

[0011] Intermediate data from multiple instances of a task can be written to the allocated memory block of the task.

[0012] The memory block for a task can be allocated on a task-by-task basis by performing a single allocation operation, wherein intermediate data for each of the multiple instances can be written into the memory block.

[0013] Intermediate data can be written to and read from memory blocks in units of one or more finite-sized data bursts.

[0014] Intermediate data for a task can be written to a contiguous region of a memory block.

[0015] The intermediate data of a task may include state data shared by multiple rays of the task.

[0016] The intermediate data of a task may include task information shared by multiple rays of the task.

[0017] The intermediate data for a mission can include payload data for each ray of the mission.

[0018] The processing of light in the task can be performed by processing logic implemented on the chip, and the memory block of the task can be allocated in memory that is not physically located on the same chip as the processing logic.

[0019] Between writing intermediate data of a task to a memory block and reading intermediate data of a task from a memory block, the intermediate data can be updated based on the processing of at least one sub-ray.

[0020] According to a second aspect of the invention, a ray tracing system configured to process light is provided, wherein the ray tracing system includes: processing logic; and a memory; wherein the processing logic is configured to: allocate a memory block in the memory on a task-by-task basis; process light in the task such that at least one sub-ray is emitted; write intermediate data of the task into the memory block; suspend processing of the task; and when the task is ready to resume, read the intermediate data of the task from the memory block and resume processing of the task.

[0021] A memory block can be a contiguous block of memory reserved for storing intermediate data for a task.

[0022] Intermediate data for a task can be stored independently of intermediate data generated for any other task.

[0023] A task may include multiple instances of a shader program corresponding to the multiple rays for which a shader program is to be executed.

[0024] Intermediate data from multiple instances of a task can be written to the allocated memory block of the task.

[0025] The memory block for a task can be allocated on a task-by-task basis by performing a single allocation operation, wherein intermediate data for each of the multiple instances can be written into the memory block.

[0026] Intermediate data can be written to and read from memory blocks in units of one or more finite-sized data bursts.

[0027] Intermediate data for a task can be written to a contiguous region of a memory block.

[0028] The processing logic can be implemented on the chip, and the memory may not be physically located on the same chip as the processing logic.

[0029] Between writing intermediate data of a task to a memory block and reading intermediate data of a task from a memory block, the intermediate data can be updated based on the processing of at least one sub-ray.

[0030] The ray tracing system can be included in hardware on an integrated circuit. A method for manufacturing a ray tracing system at an integrated circuit manufacturing system can be provided. An integrated circuit definition dataset can be provided, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a ray tracing system. A non-transitory computer-readable storage medium can be provided, on which a computer-readable description of a ray tracing system is stored, which, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit including the ray tracing system.

[0031] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium storing a computer-readable description of a ray tracing system thereon; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit including the ray tracing system; and an integrated circuit generation system configured to manufacture the ray tracing system according to the circuit layout description.

[0032] Computer program code for performing any of the methods described herein may be provided. A non-transitory computer-readable storage medium may be provided, on which computer-readable instructions are stored, which, when executed at a computer system, cause the computer system to perform any of the methods described herein.

[0033] As will be apparent to those skilled in the art, the above features can be appropriately combined, and can be combined with any aspect of the examples described herein. Attached Figure Description

[0034] The example will now be described in detail with reference to the accompanying drawings, in which:

[0035] Figure 1 This demonstrates a method for recursively processing rays in a ray tracing system;

[0036] Figure 2 A ray tracing system according to an example described herein is shown;

[0037] Figure 3 This is a flowchart illustrating a method for recursively processing rays in a ray tracing system, based on the examples described herein;

[0038] Figure 4 The memory allocation per task and memory allocation per instance for the same task were compared.

[0039] Figure 5 A computer system in which a ray tracing system is implemented is shown; and

[0040] Figure 6An integrated circuit manufacturing system for producing integrated circuits that include a ray tracing system is shown.

[0041] The accompanying drawings illustrate various examples. Those skilled in the art will understand that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the drawings represent one example of a boundary. In some examples, it may be that one 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 drawings to indicate similar features. Detailed Implementation

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

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

[0044] As described in the background section above, shader recursion can be used in ray tracing systems to cause a parent shader to call a child shader. When a parent shader executes a shader recursion instruction, the parent shader calls the child shader. The term "shader recursion instruction" is used herein to refer to any instruction in a shader that calls another shader. Examples of shader recursion instructions are: (i) the "TraceRay" instruction, which causes a ray to be emitted and causes an intersection test to be performed on the emitted ray, where the shader will be executed based on the result of the intersection test on the emitted ray; and (ii) the "CallShader" instruction, which directly calls another shader (with a callable shader type) without performing any ray traversal (i.e., intersection test). In some implementations, the instruction that calls "any hit" shader can be a shader recursion instruction; for example, the DirectX ray tracing specification calls these instructions "ReportHit" instructions, and the Vulkan ray tracing specification calls these instructions "OpReportIntersctionKHR" instructions. All these types of shader recursion instructions cause the child shader to be called. When a shader recursion instruction is executed as part of a parent shader to call a child shader, some intermediate data of the parent shader is maintained so that the parent shader can be restored when the child shader finishes its execution.

[0045] In the examples described herein, a task is executed to perform a shader program for multiple rays, wherein the task comprises multiple instances corresponding to the multiple rays for which the shader program is executed. That is, a task can be generated comprising multiple instances of the shader program corresponding to the multiple rays for which the shader program is to be executed. For example, a task can be generated by aggregating (e.g., collecting) multiple instances of the shader program corresponding to the multiple rays for which the shader program is to be executed. The task can be executed on a Single Instruction Multiple Data (SIMD) processing unit, such that the instructions of the shader program are executed in parallel for each instance of the task. Thus, as described herein, a “task” is a set of instances to be executed in parallel; and an “instance” is a collection of data to which a series of operations are to be performed. In the examples described herein, instances of a task correspond to the corresponding rays to which the same series of operations (defined by the shader program) are to be performed.

[0046] Instead of writing all intermediate data of the parent task (corresponding to the parent shader) to memory (e.g., Dynamic Random Access Memory - DRAM), it is possible to keep the parent task in a "de-scheduled wait state" on the ray tracing unit while executing all its child tasks (corresponding to child shaders) and further descendant tasks. While a task is in a "de-scheduled wait state," its intermediate data can be stored in buffers, caches, or registers easily accessible to the shader, and / or the shader can remain configured to process the task. However, the entire "ray processing" operation (including the execution of recursive shaders) for processing a single ray is expected to take a considerable amount of time (potentially on the order of 10,000 processing cycles). If this entire process is completed while the task is in a "de-scheduled wait state," it will be difficult to run enough tasks in parallel to achieve the target ray traversal performance. Furthermore, each instance in the initial task can intersect with different primitives that you wish to launch different shader programs for. Therefore, instead of keeping the parent task in an unscheduled waiting state while its subtasks are being executed, the intermediate data of the parent task is written to memory (e.g., DRAM memory) and the parent task is paused (i.e., its execution is temporarily terminated on the ray tracing unit) when the shader recursive instruction is executed. The intermediate data can be stored in on-chip resources (i.e., on-chip memory on which the ray tracing unit is implemented). That is, in these examples, the amount of such on-chip resources may need to be greater than typically implemented in non-recursive ray tracing systems, or the performance of the ray tracing system is expected to be affected. Therefore, at least some of the intermediate data (e.g., most or all of the intermediate data) can be stored in off-chip memory. Specifically, devices with limited processing resources (e.g., mobile devices) often do not have sufficient on-chip storage capacity to store intermediate data on-chip, so the intermediate data will tend to be stored in off-chip memory. When its subtasks have completed, the intermediate data of the parent task can be read back from memory, and the execution of the parent task can resume. When the parent task resumes, the ray tracing unit reschedules the parent task to continue its execution from its paused point.

[0047] Intermediate data stored for the parent task may include: (i) status data, (ii) payload data, and (iii) task information.

[0048] State data represents information about the state of a parent task at its execution pause point. For example, state data can include any data stored in temporary registers (which can be instance-based or task-based temporary registers) that needs to be accessed when the task resumes. As some examples, these temporary registers could store intersection indices and / or centroids. As another example, if multiple rays are cast from associated intersections to model some form of light scattering, then some form of material property could be stored as state data for future ray casting associated with a single intersection, for example, since it's possible that only one ray is cast at a time. Material properties could be, for example, refractive index, opacity, or surface normals.

[0049] Payload data is instance-specific data associated with the individual rays being processed. Specifically, payload data includes application-defined payload objects for the rays. For example, each ray (i.e., each instance) may have an application-defined ray payload. Child shaders are able to modify (i.e., update) the payload data provided by the parent shader. The size of the payload depends on the application (typically on the order of three or four double words (“dwords”), for example, to store pixel colors with three or four channels of 32-bit values ​​per channel (e.g., in floating-point format), but may be larger or smaller than this). The size of the payload data is not fixed.

[0050] Task information is designed to store information about which shader procedure should be rescheduled, at which program offset the procedure should be resumed, and to define the order in which the initial rays are packed into the task. In other words, the parent task's task information indicates how to resume the execution of the parent task, such as specifying the program counter of the parent shader procedure to be resumed, and specifying information about the mapping between rays and task instances (e.g., using ray IDs).

[0051] When the execution of a parent task is paused, a simple way to store the parent task's intermediate data is to allocate memory on a "by ray" or "by instance" basis. That is, each instance's intermediate data will be stored independently of any other instance's intermediate data. In this simple approach, each instance will be allocated a different block of memory, such as a separate block. The amount of memory to be allocated to each instance will be determined based on the "worst-case" storage requirements. The amount of intermediate data (i.e., status data, payload data, and task information) can vary significantly between tasks. If the amount of memory allocated to each instance happens to match the amount of intermediate data for that instance, then each allocated memory block will be of different sizes and will therefore begin at irregularly spaced memory addresses. This will cause memory to become fragmented over time. For example, if an instance is allocated 12 bytes of memory sandwiched between other memory allocations, and that memory is vacated after processing, if the next instance to be allocated memory needs 13 bytes of memory, it cannot use the vacated 12 bytes and will need to be allocated memory elsewhere. When memory becomes fragmented in this way, tracking and allocating these irregularly spaced free areas of memory can be computationally expensive. Therefore, a “worst-case” memory requirement for an instance is typically determined (e.g., 48 bytes)—and the same amount of memory is allocated to each instance based on that “worst-case” memory requirement. The worst-case memory requirement for an instance can be predetermined. That is, the worst-case memory requirement is not typically determined in real-time during task execution. Instead, for example, the worst-case memory requirement can be set by the user of the ray tracing system based on an assumption or pre-calculated worst-case memory requirement for the instance based on the graphics data they intend to process. Since each allocated memory block has the same size, they can begin at regularly spaced memory addresses. By allocating the same amount of “worst-case” memory to each instance, tracking and allocating such regularly spaced memory blocks is much less computationally expensive. This simple approach can be advantageous in some respects because each instance can resume processing as soon as its child instances have finished processing (rather than having to wait until all child instances associated with all other instances within the task have finished processing). In other words, processing of an instance whose child instances have been processed can resume, regardless of whether one or more other instances within the task cause recursion up to or close to the maximum recursion depth. However, this simplistic approach can lead to sparse and inefficient memory usage, exceeding necessary storage requirements.

[0052] According to the examples described herein, memory is allocated on a "task-by-task" basis for storing intermediate data. That is, the intermediate data for each task is stored independently of the intermediate data for any other task. However, the intermediate data of multiple instances within a task is stored in the same memory block. In the examples described herein, the memory block is a contiguous block of memory reserved for storing the intermediate data of the task. In the examples described herein, memory blocks are allocated in off-chip memory (i.e., memory that is not physically located on the same chip as the ray tracing unit). However, it should be understood that the principles described herein also apply to memory allocation in on-chip memory (i.e., memory that is physically located on the same chip as the ray tracing unit).

[0053] The amount of memory to be allocated to a task can be determined based on the "worst-case" storage requirements. The worst-case storage requirements for a task can be predetermined. However, the "worst-case" storage requirements for a task may be less than the sum of the "worst-case" storage requirements for each instance of that task. This is because several instances of a task may share some common state data and / or task information. That is, some state data and / or task information may be relevant to all instances of the task. Therefore, this common state data and / or task information can be stored once within a "task-based" memory block and shared by each instance of the task, rather than (as in the simpler approach described herein) being copied between multiple "instance-based" memory blocks. In other words, allocating memory on a "task-based" basis reduces the total amount of memory required to store the intermediate data for each task—as referenced herein. Figure 4 Further detailed description.

[0054] Data is typically written to and read from memory in units of "bursts." A burst is a finite-sized block of data that can be written to or read from memory in a single memory transaction. Data is typically written to and read from memory in an integer number of bursts. For example, a burst may include 64 bytes of data. When using "aligned bursts," access to off-chip memory can be most efficient, where the finite-sized blocks of data to be transferred start at an offset that is an integer multiple of the finite-sized blocks.

[0055] As described in this article, the "per-instance" approach typically reserves an amount of memory for each instance based on "worst-case" storage requirements. In practice, some (e.g., often most) instances do not actually require that much storage. This means that memory will become sparsely filled. That is, there may be a large amount of empty storage space between the "per-instance" data actually stored in memory. For example, within a memory block allocated to an instance on a "per-instance" basis, at a given time, it may be that 10% of the block contains stored intermediate data, while 90% of the block is still empty. Therefore, if intermediate data is allocated to memory on a "per-instance" basis, gaps often exist between the portions of memory storing intermediate data for different instances. Furthermore, it is not uncommon for the amount of intermediate data stored for an instance to be smaller than the burst size used to write and / or read data from and / or read data from memory. For these reasons, bursts used to read / write data from / to memory are often inefficiently used if intermediate data is allocated to memory blocks on a "per-instance" basis. For example, if an instance has 12 bytes of intermediate data, but the worst-case memory allocation for that instance is equal to or greater than 64 bytes, then the 64-byte burst used to transmit that intermediate data will only transmit 12 bytes of meaningful data.

[0056] When memory blocks are allocated on a "task-by-task" basis as described in the examples herein, data within that memory block can be packed more densely. That is, intermediate data from multiple instances within a task can be written to contiguous memory locations within the memory block. In this way, bursts used for reading / writing data to / from memory are used more efficiently. Specifically, bursts used for reading / writing data to / from memory are more likely to be fully or almost fully packed, as described in this article. Figure 4 This will be described in further detail. Therefore, based on the examples described herein, when allocating memory to intermediate data on a "by task" basis, fewer data bursts may be required to read / write task-related intermediate data to memory compared to allocating memory to each instance within the task on a "by instance" basis.

[0057] As mentioned above, the Vulkan and DirectX ray tracing specifications define different types of shaders, including "ray-generating" shaders, "recently hit" shaders, "missed" shaders, "intersection" shaders, and "any hit" shaders. A ray-generating shader runs for a single ray and can include shader recursive instructions, such as calling the TraceRay instruction of one or more other (child)shaders. A recently hit shader runs for the most recent committed hit (i.e., the most recent intersection) found during the entire ray traversal. A "hit" occurs when a ray intersects the geometry of a triangle. However, a ray may not always interact with that triangle. For example, a triangle may have transparent parts. A hit is said to be "committed" when it is determined that the ray's interaction with the triangle may require further action. For example, a committed hit occurs when a ray intersects an opaque triangle, or a partially or completely opaque part of a partially transparent triangle. Therefore, a recently hit shader will only run once for a ray.

[0058] When the intersection test module finds an intersection of a ray with an opaque triangle, this automatically provides an "intent" hit; when an intersection with a non-opaque primitive is found, the "any hit" shader is run to determine if a hit is considered. If the intersection test for a ray does not find an intent hit, the miss shader is run. When the intersection test module finds an intersection with a "procedural primitive," the intersection shader is run. Procedural primitives can have complex shapes. Procedural primitives can be represented as bounding volumes with simple geometry, such as boxes (e.g., AABBs) or spheres, which define the shape of the procedural primitive, allowing the intersection test module to perform intersection tests on the shape of the bounding volume. The application submitting the geometry to the ray tracing system defines the bounding box (or other simple bounding geometry) of the procedural primitive. For example, an AABB can be defined by the application using minimum and maximum component values ​​in three dimensions (e.g., in the instance space of the object containing the procedural primitive). In response to the intersection test module finding an intersection point with the bounding volume of a procedural primitive, an intersection shader is run to determine whether a ray intersects the shape of the procedural primitive. The intersection test module can be implemented in fixed-function hardware, while the shader (e.g., the intersection shader) is implemented in software. Therefore, programmers can define how to find intersection points with procedural primitives of a specific shape by writing appropriate intersection shaders, rather than simply defining the specific shape of the procedural primitive by using a simple primitive shape (e.g., a triangle) that the intersection test module is configured to handle.

[0059] Ray generator shaders, most recently hit shaders, and missed shaders can include TraceRay instructions. However, "any hit" shaders and intersecting shaders cannot include TraceRay or CallShader instructions.

[0060] Memory can be allocated to tasks associated with shaders that can call one or more other (sub)shaders, according to the principles described herein. For example, memory can be allocated to tasks associated with ray generation shaders, recently hit shaders, and missed shaders, according to the principles described herein. Memory can also be left unallocated to tasks associated with any hit or missed shaders, according to the principles described herein. This is because any hit or missed shader does not call one or more other (sub)shaders, therefore there is no need to pause processing of tasks associated with these shaders and write intermediate data of these tasks to memory.

[0061] Figure 2 A ray tracing system 202 is illustrated, including a ray tracing unit 204 and a memory 206. For example, the memory 206 may be dynamic random access memory (DRAM). The ray tracing unit 204 includes an intersection test module 208 and processing logic 210. The intersection test module 208 is configured to perform intersection tests between rays and geometry. The geometry may be associated with nodes of an acceleration structure and may represent regions within a scene (e.g., bounding volumes such as axis-aligned bounding boxes (AABBs), or the geometry may be primitives representing surfaces of objects within the scene to be rendered (e.g., triangle primitives). The intersection test module 208 may be implemented in hardware, such as in fixed-function circuitry, enabling it to perform intersection tests efficiently (e.g., in terms of latency and power consumption). The processing logic 210 is configured to execute computer code, such as instructions from a shader program (or other program). Therefore, the functionality performed by the processing logic 210 is defined by the program executed by the processing logic 210, rather than defined in the hardware of the processing logic 210. The ray tracing unit 204 may include... Figure 2Other components, not shown, include modules for generating accelerated structures to represent objects within the scene. Memory 206 includes memory blocks 212. Memory blocks 212 can be implemented as contiguous blocks of memory reserved for a specific purpose. Ray tracing unit 204 can be implemented on an integrated circuit. Ray tracing unit 204 can be implemented on a chip, and memory 206 may not be physically located on the same chip as the ray tracing unit and may be referred to as "external memory" or "off-chip memory." Memory may also be referred to as "system memory," and it can be used to store data for other processing units in the system, such as a central processing unit (CPU). Data transferred between ray tracing unit 204 and memory 206 travels on a communication bus within ray tracing system 202. Writing data to and reading data from memory 206 is a relatively power-consuming and slow operation compared to the speed at which other operations are performed in ray tracing unit 204. Therefore, reducing the amount of data transferred between ray tracing unit 204 and memory 206 (in terms of reducing latency and power consumption of ray tracing system 202) may be beneficial. The rate at which data is transferred between memory 206 and ray tracing unit 204 can be referred to as "memory bandwidth".

[0062] Figure 3 A flowchart illustrating a method for processing rays in a ray tracing system 202 is shown. (Refer to...) Figure 3 In the described example, multiple rays are processed in parallel by executing tasks that include multiple instances of a shader program, each instance corresponding to a ray for which the shader program is to be executed. However, it should be noted that in other examples, rays are not necessarily processed in parallel.

[0063] The following paragraphs will describe, with reference to the processing of basic individual tasks. Figure 3 A basic task is a task that does not have a parent task; for example, the task that implements the ray generation shader is a basic task. However, it should be understood that multiple tasks can be associated with each shader program. For example, there is usually an upper limit to the number of instances included in a task. A task typically includes a maximum of a power of two, but tasks can be partially packed and include fewer than that number of instances. For example, a typical task can include a maximum of 128 (i.e., 2^32) instances. 7The maximum number of instances in a task may be caused by hardware limitations (e.g., a limit on how many instances can be processed in parallel on the available processing logic). In this example, if more than 128 rays are to be processed according to the same shader program, more than one task will be associated with that shader program. For example, if 300 rays are to be processed according to the same shader program, three tasks can be associated with that shader program (two of which can be fully packaged and the third partially packaged). Each task associated with a shader program can be configured according to the references herein. Figure 3 The same principle applies.

[0064] In step 302, memory blocks are allocated to the basic tasks. In the example described herein, this is done in off-chip memory (i.e., memory that is not physically located on the same chip as the ray tracing unit), for example... Figure 2 Memory blocks are allocated in memory 206. However, it should be understood that the principles described herein also apply to on-chip memory (i.e., memory physically located on the same chip as the ray tracing unit). Figure 2 Memory allocation (not shown in the image).

[0065] A basic task can be assigned a unique task identifier. The unique task identifier can provide a mapping to the assigned memory block (e.g., a direct mapping). That is, the unique task identifier can indicate the memory address or range of memory addresses in memory (e.g., memory 206) where the memory block assigned to the basic task can be found.

[0066] In step S302, memory is allocated to the base task on a "by task" basis for storing intermediate data. That is, memory blocks are allocated such that intermediate data generated during the execution of two or more instances of the base task can be stored in the same memory block. In other words, the memory block for the base task is allocated on a task-by-task basis by performing a single allocation operation. Intermediate data for each of the multiple instances included in the base task can be written to the allocated memory block. This contrasts with allocating memory on a "by ray" or "by instance" basis, where a separate memory allocation operation is performed for each instance included in the base task, resulting in multiple memory allocation operations for the base task. The memory allocation in step S302 ensures that the intermediate data of the base task is stored independently of the intermediate data of any other task.

[0067] refer to Figure 4 The two advantages of allocating memory on a "task-based" basis for storing intermediate data can be understood. The figure compares task-based memory allocation with instance-based memory allocation for the same task. Figure 4Consider allocating memory to a task comprising eight instances. Such a task is provided only as an example. As described herein, tasks typically consist of a number of instances equal to or greater than a power of two, but tasks can be partially packed and include fewer than that number of instances. For example, a typical task could include up to 32 (i.e., 2^32) instances. 5 ) instances, 64 (i.e., 2 6 ) instances or 128 (i.e., 2 7 ) instances.

[0068] exist Figure 4 In section 412-1, a task-based memory allocation of memory blocks according to the example described herein is shown. This is schematically compared to the set of eight memory blocks allocated in the eight instance-based memory allocations for eight instances in the task shown at section 412-2.

[0069] Considering 412-1, as described in this paper, the amount of memory to be allocated to a task can be determined based on the "worst-case" storage requirements. The amount of memory allocated can be referred to as the size of the memory block. Figure 4 The amount of memory allocated to a task is shown as 401a. In practice, some (e.g., often most) tasks do not actually require the "worst-case" memory requirements. Therefore, in Figure 4 In the example shown at 412-1, the amount of memory blocks actually allocated for storing intermediate data is shown by shaded area 401b, while area 401c shows the amount of allocated memory blocks that are still empty.

[0070] Considering 412-2, as described herein, the amount of memory to be allocated to each instance can be determined based on the "worst-case" storage requirements. Since the task comprises eight instances, 412-2 illustrates eight memory blocks allocated to these eight instances respectively. Figure 4 In the example shown at 412-2, each memory block includes a shaded area and an unshaded area. The shaded area indicates the amount of memory block actually allocated for storing intermediate data, and the unshaded area indicates the amount of allocated memory block that is still empty.

[0071] like Figure 4As shown in Figure 412-1, the size of the memory block allocated on a task-by-task basis is smaller than the total size of the eight memory blocks allocated to the eight instances of the task shown in Figure 412-2. This is because several instances of a task may share some common state data and / or task information. That is, some state data and / or task information may be relevant to all instances of the task. Therefore, this common state data and / or task information can be stored once within a "task-by-task" memory block and shared by each instance of the task, as in Figure 412-1, instead of being copied between multiple "instance-by-instance" memory blocks as in Figure 412-2. In other words, allocating memory on a task-by-task basis reduces the total amount of memory required to store the intermediate data for each task. In this way, the overall memory requirements (e.g., memory footprint) of the ray tracing system can be reduced.

[0072] As described in this article, data is typically written to and read from memory in units of "data bursts" (e.g., DRAM bursts). A burst is a finite-sized block of data that can be written to or read from memory in a single memory transaction. For example, a data burst may include 64 bytes of data. Data is typically written to and read from memory in an integer number of bursts. For instance, in... Figure 4 The diagram shows the boundaries of several finite-sized data bursts 403a-k, which overlap memory blocks 412-1 and 412-2. Figure 4 In this example, for simplicity, the size of each data burst is equal to the size of each memory block allocated on an instance-by-instance basis. This is just an example. Typically, there is no fixed relationship between the size of a data burst and the size of a memory block allocated on an instance-by-instance basis.

[0073] When memory blocks are allocated on a "by task" basis according to the examples described herein, the data within the memory block can be packed more densely (as shown in 412-1) compared to when multiple memory blocks are allocated on a "by instance" basis (as shown in 412-2). That is, intermediate data from multiple instances within a task can be written to contiguous memory locations within the memory block, as shown in 401b. Therefore, data bursts used for writing data to memory can be used more efficiently. In other words, data bursts used for writing data to memory are more likely to be completely or almost completely packed. For example, as... Figure 4As shown, all intermediate data stored in memory block 412-1 can be written to memory using three data bursts 403a, 403b, and 403c. Data bursts 403a and 403b are fully packed, while data burst 403c is partially packed. That is, a portion of data burst 403c carries a portion of the stored intermediate data 401b (shown in shaded mode), while the remaining portion of the data burst does not carry meaningful data. Since memory region 401c does not contain intermediate data, no additional data bursts are needed to write the task's intermediate data to memory.

[0074] In contrast, when memory blocks are allocated on an "instance-by-instance" basis, the memory itself becomes sparsely filled, as shown in 412-2. Figure 4 As shown, writing intermediate data for each of the eight instances of the task to memory requires eight data bursts 403d-k. None of these eight data bursts 403d-k are fully packed. That is, all eight data bursts 403d-k are partially packed. In other words, the utilization of each data burst is inefficient.

[0075] like Figure 4 As shown in the examples described herein, when memory is allocated to intermediate data on a "per-task" basis (rather than on a "per-instance" basis to each instance within the task), writing task-related intermediate data to memory can require fewer data bursts. Because fewer data bursts are required, this means that the time spent transferring intermediate data to memory and / or the associated latency can be reduced by allocating memory on a "per-task" basis. Although not discussed in detail in the preceding paragraphs, when memory is allocated to intermediate data on a "per-task" basis according to the examples described herein, equivalent advantages are achieved when reading that intermediate data from memory.

[0076] Although referenced in this article Figure 3The text describes allocating memory to a single task, but it should be understood that memory can be allocated to multiple tasks using the same principle. In some examples, processing logic 210 can allocate a memory "heap" for multiple tasks (e.g., thousands of tasks), which is then (e.g., in memory hardware) subdivided into multiple memory blocks, one for each task. For example, the processing logic can define a base memory address for the memory heap, and a "step" that defines the size of each memory block. The step can be used to determine where each memory block within the heap "begins." For example, the first memory block in the heap can begin at the base memory address (e.g., have its first memory address located there). The first memory address of each subsequent memory block can be offset from the first memory address of its preceding memory block by this step. Thus, a unique integer index can be assigned to a task, which, when multiplied by the step, calculates an offset relative to the base memory address of the task's memory block.

[0077] It should be understood that no memory allocation is required before the task is executed, such as Figure 3 As shown in the diagram. Conversely, memory can be allocated at any suitable time according to the principles described herein. For example, memory can be allocated immediately before the intermediate data of the task is written to memory (e.g., between steps S306 and S310, this will be discussed in further detail herein).

[0078] return Figure 3 In step S304, instructions for a basic task are executed on processing logic 210. Specifically, in this first iteration, a basic task is performed for multiple rays. In this example, the basic task includes at least one instance that includes a shader recursive instruction that calls a sub-shader. For example, processing an instance of a basic task can cause at least one sub-ray to be emitted. As mentioned above, two examples of shader recursive instructions are the TraceRay instruction and the CallShader instruction.

[0079] In step S306, processing logic 210 determines whether the execution of any instance of the basic task has reached the recursive instruction. If not, the method proceeds to step S308, where processing logic 210 determines whether the execution of the task has reached the end of the shader program, i.e., whether there are still more task instructions to be executed. If not (i.e., if there are still more basic task instructions to be executed), the method returns to step S304 and continues to execute the basic task instructions.

[0080] When the basic task reaches the shader recursion instruction, the method proceeds from step S306 to step S310. In step S310, intermediate data of the basic task is written to the allocated memory block. Memory block 212 is used to hold the intermediate data of the basic task and may update parts of it (e.g., stored payload data) by the sub-shader associated with the sub-ray emitted by the basic task. The basic task uses memory block 212 to save information (i.e., state data, task information, and payload data) for use after the shader recursion instruction reached in step S306. Since the basic task has been paused (i.e., terminated on processing logic 210), the current state of the basic task (including state data, task information, and payload data) is maintained, so that when the basic task resumes (as described in further detail below), this state of the basic task can be repaired so that execution of the basic task can be resumed.

[0081] In step S312, the execution of the basic task for multiple rays is paused (i.e., temporarily terminated). In this way, the execution of the basic task is paused in response to a shader recursive instruction. In some cases (e.g., if the shader recursive instruction is a TraceRay instruction), at least one sub-ray can be emitted. Furthermore, in step S312, a counter can be initialized for the basic task to track how many sub-rays emitted by the task have not yet been processed. For example, the counter can be incremented once for each sub-ray emitted by the basic task but not yet processed.

[0082] After pausing the execution of the basic task in step S312, the method proceeds to step S313. In step S313, multiple sub-rays to be processed according to the same sub-shader procedure are collected to form an auxiliary task. An auxiliary task is a task with a parent task (e.g., in this iteration, the parent task is the basic task). An auxiliary task is a task that includes multiple instances of a sub-shader procedure corresponding to the multiple sub-rays for which the sub-shader procedure is to be executed. Each of the multiple sub-instances in the auxiliary task may correspond to a sub-ray emitted from the same parent task (e.g., the basic task). This can occur when multiple rays associated with the basic task interact with the same object. Alternatively, the auxiliary task may include multiple sub-instances corresponding to sub-rays emitted from two or more different parent tasks (e.g., the basic task and one or more other tasks).

[0083] In step S314, processing logic 210 determines whether the new auxiliary task is ready to be scheduled. This may happen, for example, when no more instances of the task are being added, but different systems will use different criteria to determine when to schedule the task.

[0084] After determining in step S314 that a new auxiliary task is ready to be scheduled, the method proceeds to step S315, where a memory block is allocated for the auxiliary task. The memory block is allocated according to the principles described herein (e.g., as described with reference to step S302).

[0085] In step S304, instructions for an auxiliary task are executed on processing logic 210. As described above, the shader recursive instructions indicate the payload data for each ray to be processed according to the auxiliary task. Executing the auxiliary task in step S304 can update the indicated payload data in the memory block 212 allocated to the basic task.

[0086] The method continues from step S304 for the auxiliary task in the same manner as described above for the basic task. If the auxiliary task includes at least one instance of invoking a shader recursive instruction, the loop around steps S310 to S315 can be executed again, such that one or more instances of the auxiliary task invoke another auxiliary task (e.g., a task whose parent is that auxiliary task). Each instance of the basic task can continue recursively until the maximum recursion depth, where any further recursion is prevented. Figure 3 (Not shown in the image). The API can define a maximum recursion depth. For example, the maximum recursion depth can be 31.

[0087] At some point, the method will execute step S308 for the auxiliary task and will determine that the end of the auxiliary task has been reached, causing the "yes" route to be taken from step S308. The payload provided to the auxiliary task from its parent task (e.g., the base task or an earlier auxiliary task from previous iterations from steps S310 to S315) may have been modified by executing the auxiliary task or by executing any task that is a descendant of the auxiliary task.

[0088] Then, the method proceeds to step S316, where it is determined whether the task is a basic task. In other words, it is determined whether the basic task (i.e., the initial parent task, such as implementing the ray generation shader) is currently active. In this iteration, the task is an auxiliary task, so the method proceeds to S318.

[0089] In step S318, for each instance of a completed auxiliary task, the counter initialized in step S310 for its parent task is decremented (as described herein, an auxiliary task may include instances associated with one or more parent tasks). If an instance from a completed auxiliary task causes the counter of one or more of the auxiliary task's parent tasks to decrement to 0 (e.g., indicating that all sub-rays emitted by that parent task have been processed), this indicates in step S319 that the parent task is ready to resume.

[0090] In step S320, processing logic 210 reads intermediate data of the parent task to be restored. For example, one or more of the task's state data, task information, and payload data can be read from the memory block allocated to the parent task. The method can then return to step S304 to execute further instructions of the parent task, i.e., instructions of the parent task following the shader recursive instruction that causes one or more child rays to be emitted. In this way, the parent task is restored. Using the task information of the parent task, processing logic 210 is able to determine the program counter for the next instruction of the parent shader program to be executed (which will correspond to the next instruction in the parent shader program following the shader recursive instruction that causes one or more child rays to be emitted). For example, task information can be read from memory first to restore the parent task. Once the task has been restored, state data can be read from memory to configure the ray tracing unit to process the task. During task execution in step S304, payload data of the task can be read from memory for processing by the shader.

[0091] The method can then continue from step S304 as described above. When the method reaches step S316 and determines that the task is the base task (i.e., the initial parent task is active), processing for the base task is complete, as shown in step S322. At this point, the ray tracing system 202 may have determined rendering values ​​for multiple sampling locations in the rendering space, which could be, for example, pixel color values ​​of pixels in the image being rendered. The ray tracing system can process more rays until all pixel values ​​of the image being rendered are determined.

[0092] Figure 5 A computer system in which the ray tracing system described herein can be implemented is shown. The computer system includes a CPU 502, a memory 206, a ray tracing unit 204, and other devices 504, such as a display 506, a speaker 508, and a camera 510. The memory 206 includes memory blocks 212. Components of the computer system can communicate with each other via a communication bus 512.

[0093] Figure 2 The ray tracing system 202 is shown as comprising several functional blocks. This is merely illustrative and is not intended to define a strict division between 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 ray tracing system do not need to be physically generated by the ray tracing system at any point in time, and may simply represent logical values ​​that conveniently describe the processing performed by the ray tracing system between its inputs and outputs.

[0094] The ray tracing system described herein can be contained in hardware on an integrated circuit. The ray tracing system described herein can be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., a fixed logic circuit system), or any combination thereof. The terms “module,” “function,” “component,” “element,” “cell,” “block,” and “logic” are used herein to generally denote software, firmware, hardware, or any combination thereof. In the case of a software implementation, a module, function, component, element, cell, block, or logic represents program code that, when executed on a processor, performs a specified task. The algorithms and methods described herein can be executed by one or more processors executing 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 disk, flash memory, hard disk storage, and other memory devices that can use magnetic, optical, and other techniques to store instructions or other data and can be accessed by a machine.

[0095] As used herein, the terms computer program code and computer-readable instructions refer to any kind of executable code for a processor, comprising code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, bytecode, code defining integrated circuits (e.g., hardware description languages ​​or netlists), and code expressed in programming languages ​​such as C, Java, or OpenCL. Executable code can be, for example, any kind 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 the processor of a computer system that supports the executable code to perform the tasks specified by that code.

[0096] A processor, computer, or computer system can be any kind of device, machine, or special-purpose circuit, or a collection or part thereof, that has the processing capability to execute instructions. A processor can be or includes any kind of general-purpose or special-purpose processor, such as a CPU, GPU, NNA, 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 may include one or more processors.

[0097] This invention also intends to cover software, such as hardware description language (HDL) software, that defines the configuration of hardware as described herein for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided on which computer-readable program code in the form of an integrated circuit definition dataset is encoded, which, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture a ray tracing system configured to perform any of the methods described herein, or to manufacture a ray tracing system including any of the devices described herein. The integrated circuit definition dataset may be, for example, an integrated circuit description.

[0098] Therefore, a method for manufacturing a ray tracing system as described herein can be provided at an integrated circuit manufacturing system. Furthermore, an integrated circuit definition dataset can be provided, which, when processed in the integrated circuit manufacturing system, enables the execution of the method for manufacturing a ray tracing system.

[0099] Integrated circuit definition datasets can be in the form of computer code, such as as a netlist, code for configuring programmable chips, or as a hardware description language suitable for manufacturing at any level in integrated circuits, including as register-transfer level (RTL) code, as high-level circuit representations (such as Verilog or VHDL), and as low-level circuit representations (such as OASIS(RTM) and GDSII). Higher-level representations (such as RTL) that logically define hardware suitable for manufacturing in integrated circuits can be processed on a computer system configured to generate manufacturing definitions of integrated circuits within the context of a software environment that includes definitions of circuit elements and rules for combining these elements to generate the manufacturing definition of the integrated circuit defined by that representation. As is typically the case where software executes 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 the manufacturing definition of the integrated circuit, executing code that defines the integrated circuit to generate the manufacturing definition of the integrated circuit.

[0100] Now refer to Figure 6 This describes an example of processing integrated circuit definition datasets at an integrated circuit manufacturing system in order to configure the system for manufacturing ray tracing systems.

[0101] Figure 6An example of an integrated circuit (IC) manufacturing system 602 is shown, configured to manufacture a ray tracing system as described in any of the examples herein. Specifically, the IC manufacturing system 602 includes a layout processing system 604 and an integrated circuit generation system 606. The IC manufacturing system 602 is configured to receive an IC definition dataset (e.g., defining a ray tracing system as described in any of the examples herein), process the IC definition dataset, and generate an IC (e.g., containing a ray tracing system as described in any of the examples herein) based on the IC definition dataset. The processing of the IC definition dataset configures the IC manufacturing system 602 to manufacture an integrated circuit containing a ray tracing system as described in any of the examples herein.

[0102] The layout processing system 604 is configured to receive and process an IC definition dataset to determine a circuit layout. Methods for determining a circuit layout based on an IC definition dataset are known in the art and may involve, for example, synthesizing RTL code to determine the gate-level representation of the circuit to be generated, for example, in relation to 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 intervention to optimize the circuit layout. When the layout processing system 604 has determined the circuit layout, it can output the circuit layout definition to the IC generation system 606. The circuit layout definition may be, for example, a circuit layout description.

[0103] As is known in the art, IC generation system 606 generates ICs according to a circuit layout definition. For example, IC generation system 606 can implement a semiconductor device manufacturing process for generating ICs, 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, which can be used in the photolithography process to generate ICs according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 606 may be in the form of computer-readable code, which IC generation system 606 can use to form a suitable mask for generating ICs.

[0104] The various processes performed by the IC manufacturing system 602 can all be implemented in one location, for example, by one party. Alternatively, the IC manufacturing system 602 can be a distributed system, allowing some processes to be performed at different locations and by different parties. For example, some of the following stages can be performed at different locations and / or by different parties: (i) synthesizing RTL codes representing an IC definition dataset to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0105] In other examples, processing of an integrated circuit definition dataset at an integrated circuit manufacturing system can configure the system to manufacture a ray tracing system without processing the IC definition dataset to determine circuit layout. For example, an IC definition dataset can define the configuration of a reconfigurable processor, such as an FPGA, and processing of that dataset can configure the IC manufacturing system (e.g., by loading the configuration data into the FPGA) to generate a reconfigurable processor with the defined configuration.

[0106] In some embodiments, when an integrated circuit manufacturing definition dataset is processed in an integrated circuit manufacturing system, it can enable the integrated circuit manufacturing system to generate apparatuses as described herein. For example, using an integrated circuit manufacturing definition dataset, as referenced above... Figure 6 The method described herein enables the configuration of an integrated circuit manufacturing system to manufacture devices as described herein.

[0107] In some examples, an integrated circuit definition dataset may include software running on hardware defined at the dataset, or software running in combination with hardware defined at the dataset. Figure 6 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 during the manufacturing of the integrated circuit, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0108] Compared to known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules, and / or systems (and in the methods implemented herein) can lead to performance improvements. Performance improvements may include one or more of increased computational performance, reduced latency, increased throughput, and / or reduced power consumption. During the manufacture of such devices, apparatuses, modules, and systems (e.g., in integrated circuits), trade-offs can be made between performance improvements and physical implementation methods, thereby improving the manufacturing process. For example, a trade-off can be made between performance improvements and layout area to match the performance of known implementations but using less silicon. This can be accomplished, for example, by reusing functional blocks serially or sharing functional blocks among elements of a device, apparatus, module, and / or system. Conversely, the concepts set forth in this application that lead to improvements in the physical implementation of devices, apparatuses, modules, and systems (such as reduced silicon area) can be traded off for performance improvements. This can be accomplished, for example, by manufacturing multiple instances of a module within a predefined area budget.

[0109] The applicant has independently disclosed each individual feature described herein, as well as any combination of two or more such features, to the extent that such features or combinations can be implemented based on the specification as a whole, in accordance with the common knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein. In view of the foregoing description, those skilled in the art will understand that various modifications can be made within the scope of this invention.

Claims

1. A method for processing light in a ray tracing system, the method comprising: Allocate memory blocks to tasks on a task-by-task basis; Process the light rays in the task so that at least one sub-ray ray is emitted; Write the intermediate data of the task into the memory block; Pause processing of the task. as well as When the task is ready to resume, the intermediate data of the task is read from the memory block, and the processing of the task is resumed.

2. The method according to claim 1, wherein, The memory block is a contiguous block of memory reserved for storing intermediate data for the task.

3. The method according to claim 2, wherein, The intermediate data for the task is stored independently of the intermediate data generated for any other task.

4. The method according to any one of claims 1 to 3, wherein, The task includes multiple instances of shader programs corresponding to the corresponding multiple rays for which shader programs are to be executed.

5. The method according to claim 4, wherein, Intermediate data from multiple instances of the task is written into the memory block allocated to the task.

6. The method according to claim 4, wherein, The memory block for the task is allocated on a task-by-task basis by performing a single allocation operation, wherein intermediate data for each of the plurality of instances is written into the memory block.

7. The method according to any one of claims 1 to 3, wherein, The intermediate data is written to and read from the memory block in units of one or more data bursts of finite size.

8. The method according to any one of claims 1 to 3, wherein, Intermediate data of the task is written to a contiguous region of the memory block, and / or Some of the intermediate data of the task is common to multiple instances of the task, and this common intermediate data is stored once in the memory block.

9. The method according to any one of claims 1 to 3, wherein, The intermediate data for the task includes status data and / or task information shared by multiple rays of the task.

10. The method according to any one of claims 1 to 3, wherein, The intermediate data for the mission includes the payload data for each ray of the mission.

11. The method according to any one of claims 1 to 3, wherein, The processing of light in the task is performed by processing logic implemented on the chip, and the memory block for the task is allocated in a memory that is not physically located on the same chip as the processing logic.

12. The method according to any one of claims 1 to 3, wherein, Between writing the intermediate data of the task to the memory block and reading the intermediate data of the task from the memory block, the intermediate data is updated according to the processing of the at least one sub-ray.

13. A ray tracing system configured to process light, wherein, The ray tracing system includes: Processing logic; and Memory; The processing logic is configured as follows: Allocate memory blocks in the memory to tasks on a task-by-task basis; Process the light rays in the task so that at least one sub-ray ray is emitted; The intermediate data of the task is written into the memory block; Pause processing of the task; and When the task is ready to resume, the intermediate data of the task is read from the memory block, and processing of the task is resumed.

14. The ray tracing system according to claim 13, wherein, The memory block is a contiguous block of memory reserved for storing intermediate data for the task.

15. The ray tracing system according to claim 14, wherein, The intermediate data for the task is stored independently of the intermediate data generated for any other task.

16. The ray tracing system according to any one of claims 13 to 15, wherein, The task includes multiple instances of shader programs corresponding to the corresponding multiple rays for which shader programs are to be executed.

17. The ray tracing system according to claim 16, wherein, Intermediate data from multiple instances of the task is written into the memory block allocated to the task.

18. The ray tracing system according to claim 16, wherein, The memory block for the task is allocated on a task-by-task basis by performing a single allocation operation, wherein intermediate data for each of the plurality of instances is written into the memory block.

19. The ray tracing system according to any one of claims 13 to 15, wherein, The processing logic is implemented on the chip, and the memory is not physically located on the same chip as the processing logic.

20. A non-transitory computer-readable storage medium storing computer-readable instructions, which, when executed on a computer system, cause the computer system to perform a method for processing light in a ray tracing system, the method comprising: Allocate memory blocks to tasks on a task-by-task basis; Process the light rays in the task so that at least one sub-ray ray is emitted; Write the intermediate data of the task into the memory block; Pause processing of the task. as well as When the task is ready to resume, the intermediate data of the task is read from the memory block, and the processing of the task is resumed.

Images