Hierarchical acceleration structure for ray tracing systems

Abstract

The present invention relates to a hierarchical acceleration structure for a ray tracing system. A ray tracing system and a computer implemented method for generating a hierarchical acceleration structure for intersection testing are described. Nodes of the hierarchical acceleration structure are determined, each node representing a region in a scene, the nodes being linked to form the hierarchical acceleration structure. Data representing the hierarchical acceleration structure is stored. The stored data includes data defining the regions represented by multiple nodes of the hierarchical acceleration structure. At least one node of the hierarchical acceleration structure is an implicitly represented node, and the data defining the regions represented by the implicitly represented nodes is not explicitly included as part of the stored data, but can be inferred from the stored data. A ray tracing system and a computer implemented method for performing intersection testing determine whether to skip intersection testing of one or more rays with a region represented by a particular node of a subtree based on a condition in the ray tracing system. One or more rays are tested for intersection based on the determination.

Description

Technical Field

[0001] The present disclosure relates to a hierarchical acceleration structure for use in a ray tracing system. Background Art

[0002] Ray tracing is a computational rendering technique for rendering an image of a scene by tracing light paths ("rays") through the scene from a viewpoint from which the image of the scene is rendered. Rays can be modeled as originating from the viewpoint and entering the scene through pixels in the rendering space. Rays originating from the viewpoint are referred to as "primary rays." As a ray traverses a scene, it may intersect one or more objects within the scene. The intersections between a ray and the objects it intersects can be modeled to create realistic visual effects. For example, in response to determining that a ray intersects an object, a shader program (i.e., a portion of computer code) can be executed for the intersection. A programmer can write a shader program to define how the system reacts to intersections (which, for example, may result in one or more additional rays (called "secondary rays") being fired into the scene, e.g., to represent reflections of rays from intersecting objects or refractions of rays through objects (e.g., if the objects are transparent or translucent). As another example, a shader program may cause one or more rays to be fired into the scene for the purpose of determining whether an object is in shadow at the point of intersection. The result of executing the shader program (and processing any associated secondary rays) may be the calculation of a rendering value (e.g., a color value) for the pixel through which the ray passes. In this way, a rendering value representing an image of the scene may be determined.

[0003] In order to reduce the number of intersection tests that need to be performed, the ray tracing system can generate an acceleration structure, wherein each node of the acceleration structure represents an area within the scene. The acceleration structure is typically hierarchical (e.g., having a tree structure) such that it includes multiple levels of nodes, wherein the nodes near the top of the acceleration structure (i.e., nodes near the root) represent relatively large areas in the scene (e.g., the root node can represent the entire scene), and the nodes near the bottom of the acceleration structure (i.e., nodes near the leaves) represent relatively small areas in the scene. The hierarchical acceleration structure can be referred to as a "hierarchy." The leaf nodes of the acceleration structure represent areas in the scene that define one or more objects. The acceleration structure can have different structures in different examples, such as a grid structure, an octree structure, a spatial partitioning structure (e.g., a kd-tree), or a bounding volume hierarchy, to name a few. A node can represent a suitable shape or area in the scene (which can be referred to as a "box" in this article). For example, a node can represent an axis-aligned bounding box (AABB) in the scene.

[0004] Acceleration structures can be used to recursively perform intersection tests on rays. First, the ray is tested for intersection with the root node of the acceleration structure. If the ray is found to intersect the area represented by the parent node (e.g., the root node), the test can be performed on the child nodes of the parent node. In contrast, if the ray is found not to intersect with the parent node, the intersection test of the child nodes of the parent node can be avoided, thereby saving computational effort. If the ray is found to intersect with a leaf node, it can be tested against the objects within the area represented by the leaf node to determine which object(s) the ray intersects with. If the ray is found to have more than one intersection point, the intersection point closest to the ray's origin (i.e., the first intersection the ray encounters in the scene) can be identified, and the ray can be determined to intersect with the object at the closest identified intersection point. Using an acceleration structure (rather than directly testing the ray with all objects in the scene) reduces the number of intersection tests that need to be performed and simplifies the intersection tests. Intersection testing is simpler because the nodes of the acceleration structure represent basic shapes (e.g., axis-aligned bounding boxes or spheres), which are simpler than more complex object shapes, such as those defined by triangle primitives whose orientations are not predetermined.

[0005] Figure 1 A ray tracing system 100 is shown, including a ray tracing unit 102 and a memory 104. The ray tracing unit 102 includes a processing module 106, an intersection testing module 108, and processing logic 110. In operation, the ray tracing unit 102 receives geometric data defining objects within a 3D scene. The ray tracing unit 102 also receives an indication of a viewpoint from which an image of the scene is to be rendered. The processing module 106 is configured to generate an acceleration structure based on the geometric data and send the acceleration structure to the memory 104 for storage. After the acceleration structure has been stored in the memory 104, the intersection testing module 108 can retrieve nodes of the acceleration structure from the memory 104 to perform ray intersection tests on the retrieved nodes. The result of the intersection test indicates which object in the scene the ray intersected with, and the result can also indicate the location on the object where the ray intersected with the object, and can also indicate the distance along the ray at which the intersection occurred. The result of the intersection test is provided to the processing logic 110. The processing logic 110 is configured to process the result of the intersection test to determine rendering values for an image representing the 3D scene. The rendering values determined by the processing logic 110 may be transferred back to the memory 104 for storage therein to represent an image of the 3D scene. Summary of the Invention

[0006] This summary is provided to introduce some concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0007] A computer-implemented method for performing intersection testing in a ray tracing system for rendering an image of a scene, wherein the ray tracing system includes an intersection testing module including a plurality of test blocks configured to test intersection of a ray with a region in the scene, the method comprising:

[0008] receiving data representing a portion of a hierarchical acceleration structure, wherein the hierarchical acceleration structure comprises nodes, each node representing a region in a scene, wherein the nodes are linked to form the hierarchical acceleration structure, wherein the portion of the hierarchical acceleration structure represents a subtree within the hierarchical acceleration structure;

[0009] receiving an indication of one or more rays to be tested for intersection with a region represented by a particular node of the subtree, wherein the subtree includes descendants of the particular node;

[0010] determining whether to skip testing the one or more rays for intersection with the region represented by a particular node of the subtree based on a condition in the ray tracing system; and

[0011] Based on the determination, testing the intersection of the one or more rays using one or more of the test blocks of the intersection testing module, wherein testing the intersection of the one or more rays comprises:

[0012] If the determination is to skip testing the one or more rays for intersection with the area represented by the specific node of the subtree, then testing the one or more rays for intersection with the area represented by the descendants of the specific node at a specific level in the subtree, thereby skipping testing the one or more rays for intersection with the area represented by the specific node of the subtree.

[0013] The received data may include data defining regions of nodes in the portion of the hierarchical acceleration structure.

[0014] Testing the intersection of one or more rays may further comprise:

[0015] If the determination is not to skip testing the one or more rays for intersection with the area represented by the particular node of the subtree, then testing the one or more rays for intersection with the area represented by the particular node of the subtree.

[0016] A descendant of a particular node at a particular level in a subtree may be a child of the particular node in the subtree. A descendant of a particular node at a particular level in a subtree may be a grandchild of the particular node in the subtree.

[0017] The regions represented by the nodes of the hierarchical acceleration structure may be axis-aligned bounding boxes in the scene.

[0018] The particular node may be an implicitly represented node, wherein data defining the region represented by the implicitly represented node is not explicitly included as part of the received data representing the subtree, but may be inferred from the received data.

[0019] The method may further comprise:

[0020] If the determination is not to skip testing one or more rays for intersection with the area represented by the particular node of the subtree, data defining the area represented by the particular node is inferred from the received data.

[0021] If the determination is to skip testing one or more rays for intersection with the region represented by a particular node of the subtree, data defining the region represented by the particular node may not be inferred.

[0022] The data defining the region represented by the particular node may be inferred from data in the received data, the data defining the region represented by the particular node's descendants at a particular level in the subtree.

[0023] The data defining the region represented by a particular node may be inferred by determining, in each dimension of the scene, the minimum and maximum of the components defining the axis-aligned bounding box represented by the descendants of the particular node at a particular level in the subtree.

[0024] The received data representing a portion of a hierarchical acceleration structure may include data indicating how nodes of a subtree are linked, and wherein the data defining the region represented by a particular node may be inferred from the received data using at least some of the data indicating how nodes of the subtree are linked.

[0025] Receiving data representing a portion of the hierarchical acceleration structure may include receiving a data block, wherein the data block may include data representing a subtree within the hierarchical acceleration structure.

[0026] A data block may include: (i) data defining the region represented by the descendants of a particular node at a particular level in a subtree, and (ii) data indicating how the nodes of the subtree are linked.

[0027] The particular level may be the lowest level of a subtree.

[0028] The data block may include data defining a region represented by nodes having a shared ancestor in a hierarchical acceleration structure, wherein the data block may include an indication of a common starting region for the region represented by the shared ancestor, and wherein the data in the data block defining the region represented by the nodes having the shared ancestor in the hierarchical acceleration structure may include, for each node having the shared ancestor, one or more offsets from the common starting region. The shared ancestor may be a shared parent node, a shared ancestor node, or a shared great-ancestor node in the hierarchical acceleration structure.

[0029] The hierarchical acceleration structure may be constructed for the scene and stored in a memory before the intersection test begins rendering the scene image, wherein receiving data representing a portion of the hierarchical acceleration structure may include reading the data representing the portion of the hierarchical acceleration structure from the memory. A size of the data block may match a minimum burst size of the memory.

[0030] The determining whether to skip testing one or more rays for intersection with the region represented by a particular node of the subtree may be performed dynamically during an intersection testing phase of rendering an image of the scene in the ray tracing system.

[0031] The method may further comprise:

[0032] monitoring an amount of received data representing a portion of the hierarchical acceleration structure; and

[0033] monitoring a processing load on the test blocks of the intersection test module;

[0034] The conditions in the ray tracing system include a monitored data volume and a monitored processing load.

[0035] Determining whether to skip testing one or more rays for intersection with a region represented by a particular node of the subtree may include:

[0036] determining an indication of how many of the test blocks of the intersection test module would be free if the one or more rays were tested for intersection with the area represented by the particular node of the subtree; and

[0037] The determined indication is compared to a threshold value.

[0038] The conditions in the ray tracing system may include one or more of the following:

[0039] the number of rays to be tested for intersection with the region represented by a particular node of the subtree;

[0040] the coherence level of the rays to be tested for intersection;

[0041] Processing load on the test blocks of the intersecting test modules;

[0042] the workload in the work queue of the test block;

[0043] The number of test blocks of the intersection test module; and

[0044] An amount of data received from memory that reads data representing a portion of the hierarchical acceleration structure.

[0045] The results of testing the intersection of one or more rays may be used to determine rendering values for an image representing the scene.

[0046] The one or more rays may be grouped into groups to be tested for intersection with one or more regions in the hierarchical acceleration structure represented by one or more nodes received in a data block.

[0047] A method of rendering an image of a scene in a ray tracing system is provided, comprising:

[0048] Generate and store hierarchical acceleration structures;

[0049] performing intersection testing according to any of the methods described herein using the portion of the generated hierarchical acceleration structure; and

[0050] One or more shader programs are executed to process the results of the intersection test to determine rendering values for an image representing the scene.

[0051] An intersection test module configured to perform an intersection test in a ray tracing system for rendering a scene image is provided, the intersection test module comprising:

[0052] receiving logic, the receiving logic being configured to:

[0053] receiving data representing a portion of a hierarchical acceleration structure, wherein the hierarchical acceleration structure comprises nodes, each node representing a region in a scene, wherein the nodes are linked to form the hierarchical acceleration structure, wherein the portion of the hierarchical acceleration structure represents a subtree within the hierarchical acceleration structure; and

[0054] receiving an indication of one or more rays to be tested for intersection with a region represented by a particular node of the subtree, wherein the subtree includes descendants of the particular node;

[0055] node processing logic configured to determine whether to skip testing the one or more rays for intersection with a region represented by a particular node of the subtree based on a condition in the ray tracing system; and

[0056] a plurality of test blocks configured to test for intersection of the one or more rays based on the determination made by the node processing logic, wherein the intersection testing module is configured to cause the plurality of test blocks to test for intersection of the one or more rays by:

[0057] If the determination made by the node processing logic is to skip testing the one or more rays for intersection with the area represented by the specific node of the subtree, then testing the one or more rays for intersection with the area represented by the descendants of the specific node at a specific level in the subtree, thereby skipping testing the one or more rays for intersection with the area represented by the specific node of the subtree.

[0058] The particular node may be an implicitly represented node, wherein data defining the region represented by the implicitly represented node is not explicitly included as part of the received data representing the subtree, but may be inferred from the received data, and

[0059] The node processing logic may be further configured to:

[0060] If the determination is not to skip testing the one or more rays for intersection with the area represented by the particular node of the subtree, inferring data defining the area represented by the particular node from the received data; and

[0061] If the determination is to skip testing the one or more rays for intersection with the region represented by the particular node of the subtree, then inferring data defining the region represented by the particular node is skipped.

[0062] The receiving logic may be configured to receive data representing a portion of the hierarchical acceleration structure as a data block, wherein the data block may include data representing the subtree within the hierarchical acceleration structure.

[0063] The intersection testing module may further include a local memory configured to store the received data.

[0064] A ray tracing system configured to render an image of a scene is provided, the ray tracing system comprising:

[0065] a processing module configured to generate a hierarchical acceleration structure;

[0066] An intersection testing module as described herein, the intersection testing module configured to perform intersection testing using a portion of the generated hierarchical acceleration structure; and

[0067] Processing logic is configured to execute one or more shader programs to process results of the intersection test to determine rendering values for an image representing the scene.

[0068] An intersection testing module or a ray tracing system configured to perform any of the methods described herein is provided.

[0069] A computer-implemented method of generating a hierarchical acceleration structure to be used for intersection testing in a ray tracing system is described herein, the method comprising:

[0070] determining nodes of the hierarchical acceleration structure, wherein each of the nodes represents a region in a scene, and wherein the nodes are linked to form the hierarchical acceleration structure; and

[0071] storing data representing the hierarchical acceleration structure, wherein the stored data includes data defining regions represented by a plurality of nodes of the hierarchical acceleration structure,

[0072] Wherein at least one node of the hierarchical acceleration structure is an implicitly represented node, wherein data defining a region represented by the implicitly represented node is not explicitly included as part of the stored data but can be inferred from the stored data.

[0073] A processing module is described herein that is configured to generate a hierarchical acceleration structure for intersection testing in a ray tracing system, the processing module being configured to:

[0074] determining nodes of the hierarchical acceleration structure, wherein each of the nodes represents a region in a scene, and wherein the nodes are linked to form the hierarchical acceleration structure; and

[0075] causing data representing the hierarchical acceleration structure to be stored, wherein the stored data includes data defining regions represented by a plurality of nodes of the hierarchical acceleration structure,

[0076] Wherein at least one node of the hierarchical acceleration structure is an implicitly represented node, wherein data defining a region represented by the implicitly represented node is not explicitly included as part of the stored data but can be inferred from the stored data.

[0077] A computer-implemented method for performing intersection testing in a ray tracing system for rendering a scene image is provided, the method comprising:

[0078] receiving data representing at least a portion of a hierarchical acceleration structure, wherein the hierarchical acceleration structure includes nodes, each node representing a region in a scene, wherein the nodes are linked to form the hierarchical acceleration structure, wherein the received data includes data defining regions represented by a plurality of nodes of the hierarchical acceleration structure, and wherein the hierarchical acceleration structure includes implicitly represented nodes, wherein data defining regions represented by the implicitly represented nodes is not explicitly included as part of the received data but can be inferred from the received data;

[0079] inferring data defining the region represented by the implicitly represented node from the received data; and

[0080] Intersection testing is performed on rays in a scene by testing the rays for intersection with regions represented by nodes of a hierarchical acceleration structure, wherein performing intersection testing on rays in the scene includes using inferred data to test the rays for intersection with regions represented by nodes of an implicit representation of the hierarchical acceleration structure.

[0081] An intersection testing module configured to perform intersection testing in a ray tracing system for rendering a scene image is described herein, the intersection testing module comprising:

[0082] receiving logic configured to receive data representing at least a portion of a hierarchical acceleration structure, wherein the hierarchical acceleration structure comprises nodes, each node representing a region in a scene, wherein the nodes are linked to form the hierarchical acceleration structure, wherein the received data comprises data defining regions represented by a plurality of nodes of the hierarchical acceleration structure, and wherein the hierarchical acceleration structure comprises implicitly represented nodes, wherein data defining regions represented by the implicitly represented nodes is not explicitly included as part of the received data but can be inferred from the received data;

[0083] node processing logic configured to infer, from the received data, data defining the region represented by the implicitly represented node; and

[0084] One or more test blocks configured to perform intersection testing on rays in a scene by testing the rays for intersection with regions represented by nodes of a hierarchical acceleration structure, wherein at least one of the one or more test blocks is configured to use inferred data to test one or more of the rays for intersection with regions represented by nodes of an implicit representation of the hierarchical acceleration structure.

[0085] A computer-implemented method of generating a hierarchical acceleration structure to be used for intersection testing in a ray tracing system may be provided, the method comprising:

[0086] determining nodes of a hierarchical acceleration structure, wherein each of the nodes represents a region in the 3D scene, and wherein the nodes are linked to form the hierarchical acceleration structure; and

[0087] storing data for the node in a data block in a memory, wherein the data block includes data representing a subtree within the hierarchical acceleration structure, wherein the subtree includes one or more nodes at a plurality of levels within the hierarchical acceleration structure;

[0088] wherein the data block includes: (i) data defining the area represented by the nodes of the lowest level of the subtree, and (ii) data indicating how the nodes of the subtree are linked, and

[0089] wherein nodes of at least one level of the subtree above the lowest level of the subtree are implicitly represented by data in the data block, such that data defining at least one area represented by the corresponding at least one node is not explicitly stored in the data block, but can be inferred from: (i) at least some of the data defining the area represented by at least some of the nodes of the lowest level of the subtree, and (ii) at least some of the data indicating how said nodes of said subtree are linked.

[0090] The "lowest level" of a subtree is the level of the subtree that is furthest from the root of the hierarchical acceleration structure. A node at the lowest level of a subtree has no child nodes in the subtree.

[0091] A computer-implemented method of generating a hierarchical acceleration structure to be used for intersection testing in a ray tracing system may be provided, the method comprising:

[0092] determining nodes of a hierarchical acceleration structure, wherein each of the nodes represents a region in the 3D scene, and wherein the nodes are linked to form the hierarchical acceleration structure; and

[0093] Data for the node is stored in a data block in a memory, wherein the data block includes data representing a subtree within the hierarchical acceleration structure, wherein the subtree includes one or more nodes at multiple levels within the hierarchical acceleration structure.

[0094] The processing modules, intersection testing modules, and ray tracing systems described herein may be embodied in hardware on an integrated circuit. A method of manufacturing a processing module, intersection testing module, or ray tracing system as described herein in an integrated circuit manufacturing system may be provided. An integrated circuit definition dataset may be provided that, when processed in the integrated circuit manufacturing system, configures the system to manufacture the processing module, intersection testing module, or ray tracing system. A non-transitory computer-readable storage medium may be provided that stores a computer-readable description of the processing module, intersection testing module, or ray tracing system, which, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit that includes the processing module, intersection testing module, or ray tracing system.

[0095] An integrated circuit manufacturing system can be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of a processing module, an intersection testing module, or a ray tracing system as described herein; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit including the processing module, the intersection testing module, or the ray tracing system; and an integrated circuit generation system configured to manufacture the processing module, the intersection testing module, or the ray tracing system based on the circuit layout description.

[0096] 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, which, when executed at a computer system, cause the computer system to perform any of the methods described herein.

[0097] 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0098] The present invention will now be described by way of example with reference to the accompanying drawings, in which:

[0099] Figure 1 A prior art ray tracing system is shown;

[0100] Figure 2a shows a 2D example of regions and primitives within a scene for which ray intersection is to be tested;

[0101] Figure 2b Shown for representation Figure 2a The hierarchical acceleration structure of the region shown in ;

[0102] Figure 3shows a ray tracing system according to examples described herein;

[0103] Figure 4 is a flow chart of a method for generating a hierarchical acceleration structure for intersection testing in a ray tracing system;

[0104] Figure 5 shows a portion of a hierarchical acceleration structure, where two nodes are implicitly represented;

[0105] Figure 6 is a flow chart of a first method of performing intersection testing in a ray tracing system;

[0106] Figure 7a A first example of storing nodes of a hierarchical acceleration structure in data blocks is shown;

[0107] Figure 7b Shown Figure 7a The data format in the data block in the first example shown in ;

[0108] Figure 8a A second example of storing nodes of a hierarchical acceleration structure in data blocks is shown;

[0109] Figure 8b Shown Figure 8a The data format in the data block in the second example shown in ;

[0110] Figure 9a A third example of storing nodes of a hierarchical acceleration structure in data blocks is shown;

[0111] Figure 9b Shown Figure 9a The data format in the data block in the third example shown in ;

[0112] Figure 10a A fourth example of storing nodes of a hierarchical acceleration structure in a data block is shown, with some nodes being implicitly represented;

[0113] Figure 10b Shown Figure 10a The data format in the data block in the fourth example shown in ;

[0114] Figure 11a shows a subtree within a hierarchical acceleration structure;

[0115] Figure 11b Shown by Figure 11a The nodes of the subtree shown in represent regions within the scene;

[0116] Figure 12a Shown after flattening Figure 11a The subtree of

[0117] Figure 12b Shown by Figure 12a The nodes of the flattened subtree shown in represent regions within the scene;

[0118] Figure 13 is a flow chart of a second method of performing intersection testing in a ray tracing system;

[0119] Figure 14a shows a subtree of nodes within a hierarchical acceleration structure stored in a data block, with some nodes being implicitly represented;

[0120] Figure 14b Shown after flattening Figure 14a The subtree of

[0121] Figure 15 A computer system implementing a ray tracing unit is shown; and

[0122] Figure 16 An integrated circuit manufacturing system for producing an integrated circuit incorporating a ray tracing system as described herein is shown.

[0123] 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 the case 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 accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0124] The following description is given by way of example only to enable one 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 apparent to those skilled in the art. The embodiments are described by way of example only.

[0125] Similar to the ray tracing system 100 described in the Background section above, the ray tracing system described herein includes a ray tracing unit and a memory. The ray tracing unit is configured to generate an acceleration structure and send the acceleration structure to the memory for storage therein. Portions of the acceleration structure can then be read from the memory and used to perform intersection tests on the ray tracing unit. The results of the intersection tests are used to determine rendering values for an image representing the scene, which can then be written back to the memory. The amount of data used to represent the acceleration structure is large, for example, typically larger than the amount of data that can be stored in the memory on the ray tracing unit. This is why the acceleration structure is stored in a separate memory. For example, the memory storing the acceleration structure 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." The memory may also be referred to as "system memory" and may be used to store data for other processing units in the system, such as a central processing unit (CPU). Data transferred between the ray tracing unit and the memory travels on a communication bus. Writing data to and reading data from the memory are slow operations that consume relatively high power compared to the speed at which other operations are performed in the ray tracing unit. Therefore, reducing the amount of data used to represent the acceleration structure, and thereby reducing the amount of data transferred between the ray tracing unit and the memory, can be beneficial (in terms of reducing latency and power consumption of the ray tracing system). The rate at which data is transferred from the memory to the ray tracing unit can be referred to as "memory bandwidth." Reducing the amount of data used to represent the acceleration structure also reduces the amount of memory required to store the acceleration structure.

[0126] In the examples described herein, data representing an acceleration structure is stored, wherein at least one node of the acceleration structure is an implicitly represented node. Data defining the region represented by the implicitly represented node is not explicitly included as part of the stored data, but can be inferred from the stored data representing the acceleration structure. For example, the acceleration structure can be a hierarchical acceleration structure. A particular node can be an implicitly represented node (i.e., data defining the region represented by the particular node may not be explicitly included in the stored data), but data defining the region represented by the descendants of the particular node at a particular level in the hierarchical acceleration structure can be stored, which can be used to imply (i.e., "infer") data defining the region represented by the particular node. For example, the descendants of a particular node at a particular level in the hierarchical acceleration structure can be children of the particular node in the hierarchical acceleration structure. As another example, the descendants of a particular node at a particular level in the hierarchical acceleration structure can be grandchildren of the particular node in the hierarchical acceleration structure. If an intersection test is performed on an implicitly represented node, the ray tracing unit uses some of the data representing the acceleration structure, for example, data defining the region represented by the descendants of the implicitly represented node at a particular level in the hierarchical acceleration structure, to infer data defining the region represented by the implicitly represented node. For example, the bounds of a parent node can be inferred using the bounds of its children and information about the topology of the hierarchical acceleration structure. The information about the topology of the hierarchical acceleration structure defines how nodes are linked in the hierarchical acceleration structure, i.e., it defines the relationships between different nodes in the hierarchical acceleration structure, such as child-parent relationships or sibling relationships.

[0127] By not explicitly storing data defining the region represented by the implicitly represented nodes, the amount of data transferred between the ray tracing unit and memory, as well as the amount of data stored in memory, is reduced.

[0128] Furthermore, even when using acceleration structures, the workload involved in performing intersection tests in a ray tracing system remains substantial. For example, ray tracing can be used to render images of 3D scenes, where the images may have millions of pixels. A ray may be traced once for each sample location. In some examples, there may be one sample location per pixel location, while in other examples, there may be multiple sample locations per pixel location (e.g., to allow for processes such as multi-sample anti-aliasing (MSAA) when rendering the final pixel value). When a ray intersects an object in the scene, a shader program may be executed, which may result in another ray (i.e., a "secondary ray") being emitted into the scene. Each primary ray may result in the emission of many secondary rays, all of which are traced through the scene to determine their intersection points. Consequently, it is not uncommon for scenes to have tens or hundreds of millions of rays used to render an image. As graphics rendering technology advances, the complexity of scenes to be rendered tends to increase, so it is not uncommon for scenes to contain thousands of objects, each of which may be represented by many primitives. Furthermore, the image being rendered may represent a frame of a sequence of frames to be rendered in real time, e.g., for real-time display to a user. For example, a user may be playing a game, where the rendered image represents the user's view of a 3D scene while playing the game. To make the sequence of frames appear as a continuous stream of video data, many frames may be rendered per second, such as 24, 30, or 60 frames per second, to name a few. Therefore, it can be appreciated that the work involved in performing intersection testing in a ray tracing system to render a scene for output in real time is substantial.

[0129] One way to overcome this problem and perform ray tracing to render a scene to be output in real time is to have one or more supercomputers perform all the processing. This can be considered a "brute force" approach. However, in addition to the goal of having high performance, there is also the competing goal of reducing the size (e.g., silicon area) and power consumption of the ray tracing system in order to perform ray tracing to render a scene to be output in real time. For example, there may be a goal of implementing a ray tracing system on a mobile device such as a tablet or smartphone, which may have an acceptable size and power consumption that is much lower than a supercomputer. Therefore, when designing a ray tracing system, there may be a trade-off between performance, power consumption, and area. In some examples described herein, performance can be improved (i.e., latency can be reduced) without significantly increasing the power consumption or area of the ray tracing system.

[0130] The intersection test module can have multiple test blocks, each of which can perform intersection testing to test rays with regions in the scene. The rays can be grouped together into packets, where each ray in the packet is tested for intersection with regions in the scene by a corresponding test block of the intersection test module. The intersection test process typically has one of two bottlenecks that limit the rate at which intersection testing can be performed: (i) memory bandwidth is the limiting factor, for example, the rate at which data representing portions of the acceleration structure can be retrieved from memory to be tested for rays is the limiting factor, or (ii) the throughput of the intersection test module is the limiting factor, for example, the rate at which the intersection test module can perform intersection test operations is the limiting factor. Which of these two factors is the limiting factor will depend on conditions in the ray tracing system (e.g., operating conditions). For example, which of the two factors is the limiting factor may depend on the distribution of rays being tested for intersection. If the rays being tested for intersection are relatively coherent, a relatively large number of rays will be tested simultaneously for intersection with the same region of the scene; whereas if the rays being tested for intersection are relatively incoherent, a relatively small number of rays will be tested simultaneously for intersection with the same region of the scene. Rays are "coherent" if they are submitted for intersection testing at temporally close times and have similar starting points and similar directions. If the rays are relatively coherent, the number of rays tested for intersection with a particular region of the scene at a particular time will tend to be greater than if the rays were relatively incoherent. Therefore, when the rays are relatively incoherent, the limiting factor is more likely to be memory bandwidth—the rate at which data representing different regions of the scene can be retrieved from memory—and this means that some test blocks of the intersection test module may be idle in any given processing cycle. In contrast, when the rays are relatively coherent, the limiting factor is more likely to be the throughput of the intersection test module, and in this case, fewer test blocks are likely to be idle in any given processing cycle.

[0131] In the examples described herein, an intersection test module can dynamically decide whether to test or skip testing a particular node during intersection testing based on conditions in the ray tracing system. If the intersection test module decides to skip testing a particular node, it can instead test the child nodes of that particular node. In this way, the intersection test module can dynamically change the topology of the hierarchical acceleration structure being traversed. This can improve the performance of the ray tracing system. For example, if many test blocks of the intersection test module are idle during a particular processing cycle when testing for intersection of a particular node, the test for that particular node can be skipped, and instead the intersection of the child nodes of the particular node can be tested during that particular processing cycle. In this way, in examples where multiple levels of the acceleration structure are encoded together, the intersection test module can advance the levels in the hierarchical acceleration structure at little cost, such as zero cost (i.e., without incurring any additional delay). Skipping intersection testing for a particular node can be considered as skipping intersection testing for the levels in the subtree that include the particular node within the hierarchical acceleration structure. Skipping intersection testing for the levels in the subtree within the hierarchical acceleration structure can be referred to as "flattening" the subtree.

[0132] In some examples, the particular node is an implicitly represented node. In these examples, the intersection testing module can dynamically decide whether to generate the particular node (i.e., infer data defining the area represented by the particular node) during intersection testing based on conditions in the ray tracing system. Thus, the intersection testing module can dynamically decide whether to generate and test the implicitly represented node, or whether to test only the children of the implicitly represented node, based on current system conditions, for example, based on what the current bottleneck in the system is (e.g., based on a determination of whether some test blocks of the intersection testing module are idle if the implicitly represented node is generated and tested for intersection). The term "dynamically" is used herein to mean during the intersection testing phase of rendering an image of the scene (e.g., rather than during the acceleration structure generation phase of rendering an image of the scene).

[0133] Figure 2a 2D examples of regions and primitives within a scene for which ray intersections are tested are shown. In other examples, the scene and regions are three-dimensional, but for ease of illustration and understanding, Figure 2a A two-dimensional scene is shown with a two-dimensional area within the scene. Figure 2b Shown for representation Figure 2a Hierarchical acceleration structure for the region shown in . Figure 2a The directions of the x-axis and y-axis are shown. Figure 2a All regions shown in are axis-aligned bounding boxes (AABBs). Figure 2a Also shown are nine triangle primitives within the scene (in Figure 2aPrimitives are used to represent objects in the scene and can be of any shape, but typically a primitive is a planar polygon (e.g., a triangle), a line, or a point, which can be defined in terms of its vertices.

[0134] The root node (A) of the hierarchical acceleration structure represents region A', which is an AABB covering the entire scene. Node A has two child nodes in the hierarchical acceleration structure: nodes B and C. Node B represents region B', which is shown as facing Figure 2a AABBB on the left side of the scene shown in FIG. Node C represents area C', which is shown as facing Figure 2a Node B has two child nodes in the hierarchical acceleration structure: nodes D and E. Node D represents region D', which is the area of the scene. Figure 2a The dotted line at the bottom of the region B' shown in FIG represents the AABB. Node E represents region E', which is the region E' formed by the Figure 2a The AABB is represented by the dashed line on the upper left of the region B' shown in FIG. Node D has two child nodes in the hierarchical acceleration structure: nodes H and I. Node H represents region H', which is represented by a dotted line toward the left of region D' and contains Figure 2a The AABBs of primitives 1 and 2 are shown. Node I represents region I', which is represented by a dotted line pointing to the lower right of region D' and contains Figure 2a The AABB of primitive 3 is shown. Node E has two children in the hierarchical acceleration structure: nodes J and K. Node J represents region J', which is represented by a dotted line at the bottom of region E' and contains Figure 2a The AABB of primitive 4 is shown. Node K represents region K', which is represented by a dotted line toward the top of region E' and contains Figure 2a The AABB of primitive 5 is shown. Node C has two child nodes in the hierarchical acceleration structure: nodes F and G. Node F represents region F', which is a region that is created using Figure 2a The dotted line on the upper left of the region C' shown in FIG represents the AABB. Node G represents region G', which is a region that is formed using Figure 2a The AABB is represented by the dotted line at the bottom of the region C'. Node F has two child nodes in the hierarchical acceleration structure: nodes L and M. Node L represents region L', which is represented by the dotted line at the bottom of region F' and contains Figure 2a The AABB of primitive 6 is shown. Node M represents region M', which is represented by a dotted line on top of region F' and contains Figure 2aThe AABB of primitive 7 is shown. Node G has two child nodes in the hierarchical acceleration structure: nodes N and O. Node N represents region N', which is represented by a dotted line to the right of region G' and contains Figure 2a The AABB of primitive 8 is shown. Node O represents region O', which is represented by a dotted line pointing to the lower left of region G' and contains Figure 2a The AABB for primitive 9 is shown.

[0135] Figure 2b The primitives shown in are not actually part of the hierarchical acceleration structure, but are shown to illustrate how primitives relate to the nodes of the hierarchical acceleration structure. A "node" of the hierarchical acceleration structure represents a region (e.g., an AABB). A "tree node" is a node that has pointers to other nodes in the hierarchical acceleration structure (i.e., a tree node has child nodes in the hierarchical acceleration structure). A "leaf node" is a node that has one or more pointers to one or more primitives (i.e., a leaf node has no child nodes in the hierarchical acceleration structure). Reference Figure 2b , nodes A, B, C, D, E, F, and G are tree nodes of the hierarchical acceleration structure; nodes H, I, J, K, L, M, N, and O are leaf nodes of the hierarchical acceleration structure; and triangles 1 to 9 are not nodes of the hierarchical acceleration structure, but are in Figure 2b is shown to indicate which leaf nodes have pointers to which primitives.

[0136] Figure 3 A ray tracing system 300 according to the examples described herein is shown. The ray tracing system 300 includes a ray tracing unit 302 and a memory 304. The ray tracing unit 302 includes a processing module 306, an intersection testing module 308, processing logic 310, a scheduler 312, and a request queue 314. The intersection testing module 308 includes receiving logic 316, local memory 318, node processing logic 320, a test queue 322, a collection (or "array") of one or more test blocks (generally represented at 324), and a result processor 326. The request queue 314 and the test queue 322 can take the form of a buffer, such as a stack (i.e., a first-in-last-out (FILO) buffer) or a first-in-first-out (FIFO) buffer. The test block 324 can be implemented as a hardware unit (e.g., using fixed-function circuitry) or in software, such as shader code executed by the processing unit.

[0137] In operation, ray tracing unit 302 receives geometric data defining objects within a scene. For example, the scene can be a 3D scene or a 2D scene. Ray tracing unit 302 also receives an indication of a viewpoint from which to render an image of the scene. Processing module 306 is configured to generate an acceleration structure based on the geometric data and send data representing the acceleration structure to memory 304 for storage therein. Processing module 306 can be implemented in hardware (e.g., fixed-function circuitry) or in software (e.g., as computer code executed on a general-purpose processing unit).

[0138] Figure 4 A flowchart of a method for generating a hierarchical acceleration structure for intersection testing in a ray tracing system 300 is shown. In step S402, the processing module 306 determines the nodes of the hierarchical acceleration structure. As described above, each node represents a region in the scene, and the nodes are linked to form a hierarchical acceleration structure. The nodes are determined based on geometric data defining objects within the scene received at the ray tracing unit 302. Those skilled in the art will appreciate that there are many methods for determining the nodes of the hierarchical acceleration structure based on geometric data defining objects within the scene. The details of these methods are beyond the scope of this disclosure. In addition, the structure of the hierarchical acceleration structure can vary in different examples. For example, the hierarchical acceleration structure can be a bounding volume hierarchy (BVH), in which nodes represent regions of the scene that are tightly bound to objects or primitives in the scene. The regions represented by the nodes of the hierarchical acceleration structure having a BVH structure may not be of regular size and may not be continuous. For example, in a hierarchical acceleration structure having a BVH structure, the regions represented by the nodes at a particular level may not all be of the same size or shape and may not collectively cover the entire scene. Figure 2a and Figure 2b The hierarchical acceleration structure shown in has a BVH structure. For example, it can be seen that the areas D', E', F' and G' represented by the nodes of one level in the hierarchy do not all have the same size or shape and do not cover all scenes together. In contrast, the hierarchical acceleration structure may have a spatial subdivision structure, such as a multi-level grid structure or an octree structure, in which the nodes represent areas that are regularly subdivided scenes. The areas represented by the nodes of the hierarchical acceleration structure with a spatial subdivision structure have regular sizes and are continuous. For example, in a hierarchical acceleration structure with a spatial subdivision structure, the areas represented by the nodes of a particular level may all have the same size or shape and represent all scenes together.

[0139] In step S404, data representing the hierarchical acceleration structure is stored. Specifically, the processing module 306 stores the data representing the hierarchical acceleration structure in the memory 304 by sending the data to the memory 304. The stored data (i.e., the data representing the hierarchical acceleration structure) includes data defining the areas represented by the plurality of nodes of the hierarchical acceleration structure. However, in the examples described herein, at least one node of the hierarchical acceleration structure is an implicitly represented node, wherein the data defining the areas represented by the implicitly represented node is not explicitly included as part of the stored data, but can be inferred from the stored data. The implicitly represented nodes may be referred to herein as "implicit nodes."

[0140] The data defining the region represented by the implicitly represented node can be inferred from stored data using data (explicitly stored) defining the region represented by at least some of the other nodes of the hierarchical acceleration structure. For example, "at least some of the other nodes" can be descendants of the implicitly represented node at a particular level in the hierarchical acceleration structure, such as children or grandchildren of the implicitly represented node.

[0141] The stored data representing the hierarchical acceleration structure may include data indicating how nodes of the hierarchical acceleration structure are linked. At least some of the data indicating how the nodes of the hierarchical acceleration structure are linked may be used to infer data defining the region represented by the implicitly represented nodes, for example, by identifying which nodes in the hierarchical acceleration structure are descendants of the implicitly represented nodes at a particular level in the hierarchical acceleration structure (e.g., by identifying which nodes are children or grandchildren of the implicitly represented nodes).

[0142] As mentioned above, in the examples described herein, the regions represented by the nodes of the hierarchical acceleration structure are axis-aligned bounding boxes (AABBs) in the scene, such as Figure 2a As shown in the 2D example of . An AABB can be defined by specifying the minimum and maximum components along each axis. The data defining the area represented by an implicitly represented node can be inferred by determining the minimum and maximum components in each dimension of the scene that define an axis-aligned bounding box represented by the descendants of the implicitly represented node at a particular level in the hierarchical acceleration structure (e.g., represented by a child or grandchild of the implicitly represented node in the hierarchical acceleration structure).

[0143] For example, Figure 5 Shown in Figure 2b A portion of the hierarchical acceleration structure is shown in FIG, where two nodes (nodes D and E) are implicitly represented. The implicitly represented nodes are Figure 5 It is shown in dashed lines. Figure 5The data defining nodes D and E are not explicitly included as part of the data representing the hierarchical acceleration structure, but the data defining child nodes H, I, J, and K are explicitly included as part of the stored data and can be used to infer the region represented by nodes D and E.

[0144] Because data defining the region represented by the implicitly represented nodes is not explicitly included as part of the stored data, the amount of data used to represent the hierarchical acceleration structure is reduced compared to if none of the nodes of the hierarchical acceleration structure were implicitly represented.

[0145] Figure 6 3 is a flow chart of a first method for performing intersection testing in the ray tracing system 300. The scheduler 312 receives instructions to trace a group of one or more rays (i.e., perform intersection testing on them). These instructions can be received from a shader core in the GPU (e.g., from the processing logic 310 of the ray tracing unit 302) or from the CPU. For example, a shader program executing on a shader core (e.g., executing on the processing logic 310) can create rays and send them to the scheduler 312 to traverse them against the acceleration structure, i.e., perform intersection testing on them using the acceleration structure. In step S602, the scheduler groups the rays into groups to be tested for intersection. The scheduler 312 can do this to group rays that need to access the same block or portion of memory 304. For example, the scheduler 312 can group rays into groups to be tested for intersection with the area represented by the node in the hierarchical acceleration structure for which data is received in the data block. The block or portion of memory 304 can be a contiguous block of memory at a set of memory addresses that can be retrieved from memory 304 together. A group of rays that reference the same block of memory 304 may be referred to as a group. For example, rays that are to be tested against the same box or object may be grouped into a group so that the box or object data can be retrieved from memory 304 at once for intersection testing for all rays in the group. As an example, for the initial stage of intersection testing, it may be that all rays will intersect with the root node (e.g., Figure 2b ) and therefore need to access the same block of memory 304, and thus fall into one group. Once the scheduler 312 has grouped one or more rays into a group, the scheduler 312 will issue the group and add the group to the request queue 314, thereby requesting the node data for the group from memory 304 (i.e., requesting data describing the boxes corresponding to the appropriate nodes of the acceleration structure against which the rays of the group are to be tested for intersection).

[0146] In step S604, the grouped node data is retrieved from the memory 304 and passed to the intersection test module 308. That is, in step S604, the receiving logic 316 of the intersection test module 308 receives data representing at least a portion of the hierarchical acceleration structure. For example, the received data may represent Figure 5 The received data includes data defining regions represented by a plurality of nodes (e.g., nodes B, H, I, J, and K) of the hierarchical acceleration structure. However, data defining regions represented by implicitly represented nodes (e.g., nodes D and E) is not explicitly included as part of the received data. This data may be inferred from the received data.

[0147] The receiving logic 316 passes the node data (i.e., data defining a portion of the hierarchical acceleration structure) it receives from the memory 304 to the local memory 318 for storage therein. When the data is retrieved from the memory 304, the local memory 318 temporarily stores the node data so that this data can be reused, for example, to perform intersection tests of rays with nodes defined by the node data without having to re-retrieve the node data from the memory 304. The node data is provided from the local memory 318 to the node processing logic 320.

[0148] In step S606, the node processing logic 320 infers data defining the area represented by the implicitly represented node from the received data. For example, the node processing logic 320 may use the data defining the area represented by nodes H and I to infer data defining the area represented by the implicitly represented node D, and the node processing logic 320 may use the data defining the area represented by nodes J and K to infer data defining the area represented by the implicitly represented node E. For example, referring to Figure 2a 、 Figure 2b and Figure 5As can be seen, the minimum and maximum components in each of the x and y dimensions of the AABB represented by node D can be inferred by determining the minimum and maximum values of the components of nodes H and I (children of node D). Similarly, the minimum and maximum components in each of the x and y dimensions of the AABB represented by node E can be inferred by determining the minimum and maximum values of the components of nodes J and K (children of node E). Thus, in this example, step S606 involves inferring data defining the region represented by each implicitly represented node by determining the minimum and maximum values of the components of the region represented by the children of the implicitly represented node in each dimension. The node data for the node (either explicitly defined in the data retrieved from memory 304 or inferred in step S606) is passed to the test queue 322. In this example, the region represented by the node is an AABB, but in other examples, the region can be other shapes, such as a sphere or a polyhedron. In these other examples, a skilled person will appreciate how to use data defining other regions represented by other nodes in the hierarchical acceleration structure to infer the region represented by the implicitly represented node.

[0149] The receive logic 316 also receives an indication of one or more rays to be tested for intersection with a region represented by one of the nodes of the portion of the hierarchical acceleration structure. For example, at the receive logic 316, from a memory (e.g., memory 304) or from the request queue 314 (via a link, utilizing Figure 3 ) receives the ray data of the ray group to be associated with the corresponding node data at the test queue 322.

[0150] Upon receiving ray data and node data for ray groups for nodes to be tested for intersection with the rays grouped at the test queue 322, the intersection testing module 308 assigns the rays from the group to the test block 324. The intersection testing module 308 may sequentially assign rays to the test block 324. Once the grouped rays have been assigned to the test block, the test block performs an intersection test to determine whether the ray intersects the region corresponding to the node against which the ray was tested, for example, by performing an edge test on the appropriate edge of a box. In this manner, in step S608, the test block 324 performs intersection tests on rays in the scene by testing the rays for intersection with the regions represented by the nodes of the hierarchical acceleration structure. When the rays are being tested for intersection with implicitly represented nodes, step S608 includes using the data inferred in step S606 to test the rays for intersection with the regions represented by the implicitly represented nodes of the hierarchical acceleration structure. Methods for performing intersection tests to determine whether a ray intersects a region (e.g., an AABB) are known in the art and are not described in detail herein for the sake of brevity.

[0151] Each of the test blocks 324 outputs the results of the intersection tests they have performed to a result processor 326. The result processor 326 processes the results of the intersection tests. Specifically, if a ray is found not to intersect the node it is being tested against, the result processor 326 does not schedule an intersection test for the ray with respect to the children of the non-intersecting node. If the result processor 326 determines that the ray has intersected the node it is being tested against, the ray is output from the intersection test module 308 back to the scheduler 312, where the ray will be grouped into groups and scheduled for intersection testing with respect to the children of the intersecting node.

[0152] The process described above with reference to steps S602 to S608 is iteratively repeated until the ray has no more hits. In response to the ray intersecting a leaf node (e.g., Figure 2b ), each of the objects in the leaf node is scheduled for intersection testing with the ray. The intersection testing module 308 may include an object testing block ( Figure 3 ), which is configured to perform intersection tests for rays that intersect objects within the leaf nodes. Objects can be described by triangle primitives, such that the object test block is configured to test the intersection of rays with triangles in the scene. Those skilled in the art will know how to test the intersection of rays with triangle primitives, and the details of this process are not described in detail herein. If the result of all intersection tests for a ray is that the ray does not intersect with any object in the scene, then a "miss" result is returned and can be processed accordingly. If the result of all intersection tests for a ray is that the ray intersects with a single object, then the data for this intersection and a "hit" result can be returned and processed accordingly. If the result of all intersection tests for a ray is that the ray intersects with more than one object, then the intersection distances of the intersections (i.e., the distance from the ray origin to the intersection point) are compared to find the "nearest hit," i.e., the intersection point closest to the ray origin. The data for this nearest hit intersection and a "hit result" can be returned and processed accordingly. When determining a "hit" result, data related to the intersection can be determined by the object test block, such as an indication of the location of the intersection on the intersection primitive (e.g., as barycentric coordinates) and an indication of the distance of the intersection from the starting point of the ray.

[0153] The result of the intersection test (e.g., a hit result) is passed to processing logic 310. Processing logic 310 executes one or more shader programs to process the result of the intersection test to determine the rendering value of the image representing the scene. In this way, the effect of the intersection can be determined, that is, the rendering value of the image representing the scene can be determined using the intersection test result.

[0154] To render an image of a 3D scene, many intersection tests may be performed (e.g., millions or even billions of intersection tests). Therefore, for the performance of the ray tracing system 300, it is important that the intersection test module 308 can perform the intersection test quickly. This means that it may be beneficial to implement the intersection test module 308 in hardware (e.g., using fixed-function circuitry) so that the latency of the intersection test operation is relatively low compared to performing the intersection test in software. However, in some systems, the intersection test module 308 may be implemented in software executed on a general-purpose processing unit. Generally speaking, the processing logic 310 may be implemented in hardware or software, but it is generally beneficial to allow flexibility in the functions performed by the processing logic 310 to process the results of the intersection test, so the processing logic 310 is typically configured to execute a shader program, i.e., a module of computer code, to process the results of the intersection test. The processing logic 310 may be implemented as a single instruction multiple data (SIMD) processing unit, which is configured to execute instructions in parallel on multiple data items. The rendering values determined by processing logic 310 may be transferred back to memory 304 for storage therein to represent an image of the 3D scene.

[0155] In different examples, the format of the data stored to represent the hierarchical acceleration structure can vary. For example, the data representing the hierarchical acceleration structure includes two elements: (i) information defining the regions (e.g., AABBs) represented by the nodes of the hierarchical acceleration structure, and (ii) information about the topology of the hierarchy, e.g., information defining how the nodes are linked to form the hierarchical acceleration structure. Figure 7a and Figure 7b A simple example is shown in which the data of each node of the hierarchical acceleration structure is stored in a separate data block. Figure 7a The nodes that illustrate a portion of the hierarchical acceleration structure are circles, while the squares represent data blocks. Arrows illustrate links (sibling links or child links) between nodes in the hierarchical acceleration structure. In this example, the regions represented by the nodes are AABBs. Figure 7b The data format in the data block in this example is shown. Figure 7b As shown in , the data block includes data that defines the AABB represented by the node as the maximum and minimum component values in each of the X, Y, and Z dimensions. The data block also includes "child pointers" that point to child nodes and "next pointers" that point to sibling nodes. It should be noted that in this example, each node does not have more than one parent node in the hierarchical acceleration structure. Even if a node has multiple child nodes in the hierarchical acceleration structure, only one child pointer is used in the data block of the node in this example, and the "next pointer" indicates the node's sibling. The next pointer can be called a sibling pointer. For example, in Figure 7aIn the illustrated portion of the hierarchical acceleration structure, nodes D and E are siblings, and nodes H and I are children of node D. In the data block of node D, the child pointer points to node H, while the next pointer points to node E. Node H's next pointer points to node I. In this way, multiple child nodes form a linked list using sibling pointers. When an intersection test for a particular node returns a hit, each child node of the particular node is retrieved in turn by following the appropriate pointers, and then an intersection test is performed on each child node individually. Figure 7a The example shown in is a binary tree (i.e., each tree node has exactly two children), but Figure 7b The same data structure shown in can be used with hierarchical acceleration structures having a larger branching factor (i.e., where a node can have more than two children in the hierarchical acceleration structure). This is achieved by linking more than two siblings together using sibling pointers.

[0156] exist Figure 7b In the example shown, each field of the data block includes 32 bits, and there are 8 fields, so the data block has 32 bytes of data representing a single node in the hierarchy. Storing the nodes one by one in separate data blocks is often inefficient for memory reads from the memory 304, which can be implemented as a dynamic random access memory (DRAM), for example. The memory 304 has a minimum burst size, which is the minimum amount of data that can be read from the memory in a single read operation. In the example described herein, the minimum burst size of the memory 304 is 64 bytes, but in other examples, the minimum burst size can be larger or smaller than 64 bytes. The data for a single node in the hierarchical acceleration structure is often smaller than 64 bytes (for example, in Figure 7b In the example shown, it is 32 bytes), which is smaller than the minimum burst size of the memory 304. Therefore, having a single node in each data block with data would waste memory bandwidth.

[0157] To improve Figure 7a and Figure 7b In the basic scheme shown in , multiple sibling nodes can be stored in one contiguous block of memory (i.e., in one data block). When the intersection test of a node returns a hit result, all the children of the node are retrieved for intersection testing, so it may be beneficial to combine them into a single read if possible. For example, Figure 8a A second example of storing nodes of a hierarchical acceleration structure in data blocks is shown. Again, the nodes that form part of the hierarchical acceleration structure are shown as circles, while squares represent data blocks. Arrows indicate child links between nodes in the hierarchical acceleration structure. In this example, each data block contains data for a maximum of two nodes. In this example, if a data block contains multiple nodes, they are sibling nodes. This eliminates the need to store sibling links between nodes in the data block. Figure 8b Shown Figure 8a The data format in the data block in the example is shown in .

[0158] like Figure 8b As shown in , the data block now has 64 bytes of data and includes data representing two nodes of the hierarchical acceleration structure (with Figure 7b , where the data block has 32 bytes of data and includes data representing one node). Since the minimum burst size of the memory 304 is 64 bytes in this example, the use of Figure 8b Instead of the format shown in Figure 7b The format shown in is more efficient in terms of memory bandwidth.

[0159] Compression techniques can be used to represent more than two sibling nodes in a data block without increasing the size of the data block. For example, Figure 9a A third example is shown in which nodes of a hierarchical acceleration structure are stored in data blocks. Again, the nodes that form part of the hierarchical acceleration structure are shown as circles, while squares represent data blocks. Arrows indicate child links between nodes in the hierarchical acceleration structure. In this example, each data block contains data for up to four nodes. In this example, if a data block contains multiple nodes, they are sibling nodes. This eliminates the need to store sibling links between nodes in the data block. Figure 9b Shown Figure 9a The data format in the data block in the example is shown in .

[0160] In this example, the nodes stored in the data block are sibling nodes. This means that all nodes stored in the data block have the same parent node. For example, Figure 9a As shown in , nodes O and P are sibling nodes and both are children of node N; nodes Q, R, S, and T are sibling nodes and are all children of node O; and nodes U, V, W, and X are sibling nodes and are all children of node P. Figure 2a and Figure 2b As can be seen in the example shown in , nodes with the same parent are spatially close, i.e., they generally represent areas close to each other in the scene. The proximity of nodes within a data block can be used to compress the data defining the area represented by the nodes within the data block. For example, the bounds of an AABB represented by a node can be stored as an offset from a shared base value. For example, Figure 9bAs shown, the X, Y, and Z position components ("Pos X", "Pos Y", and "Pos Z") are stored to indicate the location (e.g., center location) of the common origin region (e.g., the parent AABB). The "SX", "SY", and "SZ" fields indicate the size of the common origin region. The data stored in the Pos X, Pos Y, Pos Z, SX, SY, and SZ fields indicate the approximate size and location of the AABB represented by the parent node of the four nodes whose data is stored in the data block. For example, with Figure 9b A data block in the format shown in can store data of nodes Q, R, S, and T, and the data stored in the Pos X, Pos Y, Pos Z, SX, SY, and SZ fields indicates the approximate size and position of the area represented by node O.

[0161] For data stored in data blocks and formatted as Figure 9b For each of the four nodes shown (e.g., for each of nodes Q, R, S, and T), the data block stores child pointers, as well as the minimum and maximum component offsets in each of the X, Y, and Z dimensions (denoted as "Max X," "Min X," "Max Y," "Min Y," "Max Z," and "Min Z") and an indication of how many children the node has in the hierarchical acceleration structure (denoted as "N"). Figure 9b In the format shown, the "Pos X", "Pos Y", "Pos Z" fields and the child pointer field have 32 bits; and the "SX", "SY", "SZ", "Max X", "Min X", "Max Y", "Min Y", "Max Z", "Min Z", and "N" fields have 8 bits. The values of the "Max X", "Min X", "Max Y", "Min Y", "Max Z", and "Min Z" fields are selected so as not to reduce the size of the box by representing these values using only 8 bits (rather than 32 bits). In particular, the minimum value is encoded as less than or equal to the true (32-bit) minimum value (e.g., when the number of bits used to represent the minimum value is reduced, a round-to-negative-infinity rounding mode is used), and the maximum value is encoded as greater than or equal to the true (32-bit) maximum value (e.g., when the number of bits used to represent the maximum value is reduced, a round-to-positive-infinity rounding mode is used). The total size of the data block is 64 bytes, matching the minimum burst size of the memory 304.

[0162] As described above, the SX, SY, and SZ values represent the size of the shared box (i.e., the common starting area) contained within each AABB for the four nodes (e.g., nodes Q, R, S, and T) for which data is stored in the data block. In this example, the SX, SY, and SZ values are stored as floating-point exponents, so the common starting area is limited to a power-of-two size. The location of the shared box (or "common starting area") is indicated by the data in the Pos X, Pos Y, and Pos Z fields. For example, the center of the shared box can be located at the location indicated by the data in the Pos X, Pos Y, and Pos Z fields. The 8-bit offset value ("Max X," "Min X," "Max Y," "Min Y," "Max Z," "Min Z") for a particular one of the four nodes for which data is stored in the data block defines the minimum and maximum components of the AABB represented by that particular node relative to the boundaries of the shared box.

[0163] In addition to compressing the data defining the boundaries of the region represented by the node, sibling pointers are not included in Figure 9b . Instead, an indication "N" is included, which indicates the number of child nodes that the node has in the hierarchical acceleration structure. The indication of the number of child nodes can be an indication of the number of child data blocks. In this case, if the number of child nodes that the node has is in the range of 1-4, then a "1" will be stored in the "N" field, if the number of child nodes that the node has is in the range of 5-8, then a "2" will be stored in the "N" field, and so on. Multiple data blocks for a sublist can be stored consecutively in memory to avoid the need for horizontal pointers, that is, to avoid the need for sibling pointers.

[0164] exist Figure 9a and Figure 9b In the example shown, nodes in a data block must have the same parent node; cousin nodes cannot be packed together. Because of this, when a hierarchical acceleration structure contains nodes with large branching factors (e.g., a branching factor of at least 4), Figure 9a and Figure 9b The format shown in is particularly useful. The branching factor of a node is the number of child nodes that the node has. The branching factor of each node in a hierarchical acceleration structure does not have to be the same. Figure 9a In the example shown, nodes O and P each have four child nodes to increase Figure 9b. However, the inventors of the present application have determined that a lower branching factor (e.g., a branching factor of 2) is often better for minimizing the number of intersection tests performed by the intersection test module 308. This is because the more boxes there are, the more likely a ray will hit them because they are "overlapping" from the ray's perspective. However, being able to pack more nodes into a data block is better for memory bandwidth. Therefore, when determining an appropriate branching factor, there is a trade-off between reducing the number of intersection tests and reducing memory bandwidth.

[0165] Even if Figure 9b , memory bandwidth (i.e., the amount of data transferred between the ray tracing unit 302 and the memory 304) may sometimes also be an issue, for example, it may still be a limiting factor in the speed at which intersection tests can be performed. To address this issue, the format of the data block can be modified so that data for nodes from multiple levels of the hierarchical acceleration structure are included in a single data block. For example, a data block may include data representing a subtree within the hierarchical acceleration structure, where the subtree includes one or more nodes from multiple levels within the hierarchical acceleration structure. In some examples, a data block may include data representing multiple subtrees within the hierarchical acceleration structure. The data block encoding the subtree can be cached locally near the test block 324 as the test block traverses the subtree. For example, the data block encoding the subtree can be stored in the local memory 318 while intersection tests are performed on the nodes of the subtree. Because nodes from multiple levels of the hierarchical acceleration structure can be retrieved in a single data block, the memory bandwidth between the ray tracing unit 302 and the memory 304 can be reduced. For example, when the intersection test module 308 determines that a ray intersects a particular node, the data for the particular node's children may already be located in the local memory 318 and therefore do not need to be retrieved from the memory 304 .

[0166] While test block 324 sequentially tests nodes in multiple levels of the subtree represented by the data in the data block, local memory 318 stores the data block. Local memory 318 is smaller and has lower latency, so it is easier to achieve high throughput when retrieving node data from local memory 318 than when retrieving node data from memory 304. This means that fewer reads are performed to obtain data from memory 304, which may result in increased performance of ray tracing system 300, for example, when memory bandwidth is a limiting factor on the performance of ray tracing system 300.

[0167] However, if we simply pack each node of the subtree into a larger data block, there is a possibility that the ray will miss the first level of the subtree and not need to be tested for intersection with nodes in the next level. If this happens, a lot of bandwidth is wasted because a large data block including data for many nodes is fetched from memory 304, but only a few nodes are used in the intersection test.

[0168] Therefore, instead of storing a large block of data, the inventors have realized that if the data defining the area represented by its child nodes is stored in the data block, then the data defining the area represented by the parent node does not need to be explicitly stored in the data block. In other words, if the child nodes of the parent node are stored, then the parent node does not need to be stored. In this case, the parent node is stored as a node implicitly represented in the data representing the hierarchical acceleration structure. As described above, the data defining the AABB represented by the implicitly represented parent node can be inferred from the minimum and maximum components of the AABBs represented by all of its child nodes, and can be calculated at runtime during the intersection test phase, rather than being stored with the hierarchical acceleration structure determined in the acceleration structure generation phase. The computational cost of inferring the AABB represented by the parent node is amortized over each ray in the ray group to be tested for intersection with the AABB, so it is not too expensive, especially when the rays are relatively coherent, so that a relatively large number of rays are included in the ray group.

[0169] Figure 10a An example of storing the nodes of a hierarchical acceleration structure in a data block is shown, where some nodes are implicitly represented. Figure 10a , nodes A, D, E, F, and G are shown with dashed lines to indicate that they are implicitly represented nodes. Figure 10b Shown Figure 10a The data format in the data block in the example is shown in . Figure 9b and Figure 10b The only difference between the formats shown in is that Figure 10b The format shown in includes an additional field representing a parent group labeled "PG". The data in the PG field indicates how the nodes are subdivided into parent groups, i.e. it indicates which nodes in the data block share an implicitly represented parent node. In this example, the data for the nodes in the data block are ordered so that nodes with the same parent node are adjacent to each other, so the group (PG) field only indicates where a node in the data block changes from having one parent node to having another parent node. In the examples described herein, it is possible to have data blocks with zero, one, or two implicit parent nodes, and in other examples it is possible to have data blocks with even more than two implicit parent nodes. It should be noted that "implicitly represented nodes" may also be referred to as "implicit nodes" herein. In Figure 10a and Figure 10bIn the example shown, the data block stores data for two subtrees: (i) a first subtree including an implicitly represented node D and its children: nodes H and I; and (ii) a second subtree including an implicitly represented node E and its children: nodes J and K. Nodes D and E are children of node B. In this example, data defining the area represented by the four nodes (nodes H, I, J, and K) is included in the data block. There are four possible groupings in which the four nodes can be grouped, and one of the four possible groupings is defined using data in the PG field. In this example, the PG field has only two bits to indicate one of the four possible groupings ( Figure 10a Only one of them is shown in the data block). For example, if PG has a first value (e.g., 00), then there is no implicitly represented node represented by the data in the data block; if PG has a second value (e.g., 01), then there is one implicitly represented node represented by the data in the data block, i.e., the parent node of nodes I, J, and K; if PG has a third value (e.g., 10), then there are two implicitly represented nodes (e.g., D and E) represented by the data in the data block, wherein one of the implicitly represented nodes (e.g., node D) is the parent node of nodes H and I, and the other of the implicitly represented nodes (e.g., node E) is the parent node of nodes J and K; and if PG has a fourth value (e.g., 11), then there is one implicitly represented node represented by the data in the data block, i.e., the parent node of nodes H, I, and J. It should be noted that in Figure 10a In the example shown, the PG field would have a third value (eg, 10).

[0170] In other examples, the data in the PG field can be in a different format. For example, a PG indication can be used for each implicitly represented parent node, and the value of the PG indication of the implicitly represented parent node can be the number of child nodes it has, that is, the number of nodes in its "parent group". In this example, the grouping of nodes is allowed to span more than one data block. For example (this is not Figure 10a ), the data block may include two PG values, whose values are two and three. This may mean that one implicitly represented node has children H and I, and another implicitly represented node has children J, K, and L. The data block includes data defining the area represented by nodes H, I, J, and K, but the data defining the area represented by node L is included in the next data block. Therefore, the "parent group" of the second implicitly represented node spans into another data block. Each parent group simply follows the previous parent group, so the nodes are sorted into parent groups when they are written to the data block. The format in this example can allow data to be packed more tightly into the data block, but it increases the complexity of the system when determining how to pack the data and decompress the data from the data block.

[0171] It should be noted that Figure 10a and Figure 10b The example encoding shown in includes a larger subtree of nodes A through O (ie, fifteen nodes) having only three 64-byte data blocks.

[0172] As described above, a data block may include data representing one or more subtrees within a hierarchical acceleration structure (e.g., a subtree with nodes D, H, and I, and a subtree with nodes E, J, and K). Each of the subtrees includes one or more nodes at multiple levels within the hierarchical acceleration structure. The data block includes: (i) data defining the region represented by the nodes at the lowest level of the subtree (e.g., for nodes H, I, J, and K), and (ii) data indicating how the nodes of the subtree are linked. The "lowest level" of a subtree is the level of the subtree that is farthest from the root node of the hierarchical acceleration structure.

[0173] exist Figure 10a In the example shown, at least one node of the subtree at a level higher than the lowest level of the subtree is an implicitly represented node that is implicitly represented by data in the data block. For example, node D is implicitly represented by data in the data block. Data defining at least one area represented by the corresponding at least one implicitly represented node (e.g., node D) is not explicitly stored in the data block, but can be inferred from: (i) at least some of the data defining the area represented by at least some of the nodes in the lowest level of the subtree (e.g., nodes H and I that are children of node D), and (ii) at least some of the data indicating how the nodes of the subtree are linked (e.g., G data indicating that nodes H and I are children of node D).

[0174] In this example, the data block includes data defining a region represented by nodes having a shared ancestor in the hierarchical acceleration structure. For example, the shared ancestor can be a shared parent node, a shared ancestor node, or a shared great-ancestor node in the hierarchical acceleration structure. Figure 10a In the example shown, the data block includes data defining the region represented by nodes H, I, J, and K, which have a common ancestor: node B. As described above, the data block includes an indication of the common starting region using data in the Pos X, Pos Y, Pos Z, SX, SY, and SZ fields. The data in the data block defining the region represented by nodes (e.g., nodes H, I, J, and K) with a common ancestor (e.g., node B) in the hierarchical acceleration structure includes one or more offsets from the common starting region for each node (e.g., nodes H, I, J, and K) with the common ancestor (e.g., node B). For example, the common starting region can represent the region represented by the shared ancestor (e.g., node B).

[0175] As described above, data representing the hierarchical acceleration structure is stored in memory 304 and can be read from memory 304 for use by intersection testing module 308 in performing intersection testing in ray tracing system 300. Furthermore, in the above example, the size of the data block matches the minimum burst size of memory 304. For example, the size of the data block and the minimum burst size of memory 304 can be 64 bytes.

[0176] exist Figure 10a In , nodes A, D, E, F, and G are all represented implicitly, i.e., the data defining the regions represented by these nodes are not explicitly stored and can be computed (i.e., inferred) during runtime in intersection tests if they are needed. Figure 10a In the example shown, nodes at each other level are implicitly represented nodes. In other examples, nodes at different levels can be implicitly represented. In some examples, nodes at two successive levels of a hierarchical acceleration structure can be implicitly represented so that the data for some nodes in a block can be used to infer the data for their parent and ancestor nodes. When considering which nodes to implicitly represent, there are many factors to weigh, such as how much data must be read when decoding (multiple) data blocks, the hardware cost of generating the implicitly represented node, and the cost of testing the intersection of rays with the node. For example, an ancestor node can have between 4 and 16 grandchildren, so if an ancestor node is implicitly represented, inferring the AABB of the ancestor node requires considering all grandchildren. When inferring the area represented by the implicitly represented node, this additional complexity may outweigh the benefit of not having to explicitly store the data defining the area represented by the implicitly represented node. Therefore, the decision about which nodes to implicitly represent in the data representing the hierarchical acceleration structure is an implementation decision and may differ in different implementations.

[0177] The examples described in detail above illustrate how data defining the regions represented by implicitly represented nodes need not be explicitly included in the data stored to represent the hierarchical acceleration structure. This reduces the amount of data used to represent the hierarchical acceleration structure, which can reduce the amount of data transferred between the ray tracing unit 302 and the memory 304, i.e., reduce memory bandwidth.

[0178] We now proceed to describe in detail an example where a subtree can be flattened.

[0179] For example, the subtree may be flattened by the processing module 306 during construction of the hierarchical acceleration structure. The branching factor of the nodes of the subtree affects the number of intersection tests performed by the intersection testing module 308 when performing intersection tests by traversing the hierarchical acceleration structure. The branching factor of the subtree nodes also affects the amount of data transferred between the ray tracing unit 302 and the memory 304 (i.e., affects the memory bandwidth). When the data block has a format that can store a fixed number of nodes, where the fixed number is greater than one, the memory bandwidth cost does not increase each time a node is added to the hierarchical acceleration structure; instead, the memory bandwidth cost increases as we add data blocks, and therefore, in terms of keeping the memory bandwidth low, it may be beneficial to keep the average number of nodes per data block high, for example, close to the fixed number of nodes that can be included in the data block. In other words, it may be beneficial to fill most (e.g., all) time slots in the data block.

[0180] As described above, when determining an appropriate branching factor, there is a tradeoff between reducing the number of intersection tests and reducing memory bandwidth. The processing module 306 is aware of the format of the data block and can balance the goals of this tradeoff when determining the nodes of the hierarchical acceleration structure, such as in step S402. As a result, the branching factor of nodes near the root of the hierarchical acceleration structure is relatively low (for example, for nodes near the root node, the branching factor can be two, making the hierarchy more binary near the root), and the branching factor of nodes near the leaves of the hierarchical acceleration structure is relatively high (for example, the branching factor of nodes near the leaf node can be greater than two (for example, four or more), making the hierarchy wider near the leaf). Nodes near the root have the greatest impact on the number of intersection tests performed because more rays will be tested for intersection with nodes near the root than with nodes near the leaves. In addition, the scheduler 312 can construct large groups of rays for testing against nodes near the root, so memory bandwidth is less of an issue because the bandwidth cost associated with extracting node data can be amortized over a large number of rays. Therefore, in terms of balancing the tradeoff between reducing the number of intersection tests and reducing memory bandwidth, it makes sense to have a lower branching factor (e.g., a branching factor of two) for nodes near the root node. In contrast, nodes near leaves have the smallest impact on the number of intersection tests performed because fewer rays will be tested for intersection with nodes near leaves than with nodes near the root. Additionally, the scheduler 312 can construct smaller groups of rays for testing against nodes near leaves, so memory bandwidth is more of an issue because the bandwidth cost associated with fetching node data can only be amortized over a smaller number of rays. Therefore, in terms of balancing the tradeoff between reducing the number of intersection tests and reducing memory bandwidth, it makes sense to have a higher branching factor (e.g., a branching factor of four or greater) for nodes near leaf nodes.

[0181] Figure 11a Shown Figure 2b A subtree within the hierarchical acceleration structure shown in . Figure 11b Shown by Figure 11a The nodes of the subtree shown in represent areas within the scene. The root node of the subtree (node B) represents area B'. Nodes D and E are child nodes of node B, where node D represents area D' shown in dotted lines at the bottom of area B', and node E represents area E' shown in dotted lines at the upper left of area B'. Nodes H and I are child nodes of node D, where node H represents area H' shown in dotted lines to the left of area D', and node I represents area I' shown in dotted lines to the right of area D'. Nodes J and K are child nodes of node E, where node J represents area J' shown in dotted lines at the bottom of area E', and node K represents area K' shown in dotted lines at the top of area E'.

[0182] Figure 12a Shown after flattening Figure 11a subtree of , and Figure 12b Shown by Figure 12a The nodes of the flattened subtree shown in represent regions within the scene. The process of omitting parent nodes is referred to herein as "subtree flattening" because the multiple levels of the subtree are collapsed into a simple list. Figure 12a and Figure 12b In the example shown, nodes D and E have been omitted. When a node is omitted, the child nodes of the omitted node become the child nodes of the parent node of the omitted node. It should be noted that Figure 11a and Figure 12a The lines in represent parent-child relationships, not actual pointers stored in the data blocks. Figure 12a and Figure 12b In the example, the root node of the subtree (node B) represents region B'. Nodes H, I, J, and K are child nodes of node B. Node H represents region H', indicated by a dotted line pointing to the lower left of region B'; node I represents region I', indicated by a dotted line pointing to the lower right of region B'; node J represents region J', indicated by a dotted line pointing to the left of region B'; and node K represents region K', indicated by a dotted line pointing to the upper left of region B'.

[0183] When generating a hierarchical acceleration structure based on one or more heuristics, the processing module 306 can decide whether to flatten the subtree (e.g., whether to omit nodes D and E). For example, the surface area heuristic (SAH) can be used to estimate the expected number of intersection tests that will be performed on the subtree. The surface area heuristic (SAH) is defined as:

[0184]

[0185] This equation can be adapted to define the bandwidth heuristic (BWH) as:

[0186]

[0187] Bandwidth heuristics (BWH) can be used to estimate the expected number of data blocks that must be fetched from memory during intersection testing. In these equations, N is the set of nodes in a subtree or hierarchical acceleration structure, n is the number of nodes in set N, r is the root node of the hierarchical acceleration structure, a(n) is the surface area of node n, a(n) / a(r) represents the probability that a ray will hit node n given that it hits the root node r, c(n) is the number of children of node n, and b(n) is the number of data blocks required to pack the children of node n.

[0188] Using these two heuristics (SAH and BWH), the processing module 306 can Figure 11a and Figure 12a The subtree costs (in terms of number of intersection tests and memory bandwidth) between the subtrees shown in (i.e., with and without nodes D and E) are compared to determine whether it is more appropriate to omit nodes D and E, i.e., whether it is more appropriate to flatten the subtree.

[0189] The surface area heuristic (SAH) and bandwidth heuristic (BWH) are measured across all nodes in the hierarchy, but small changes to the hierarchy can be evaluated locally because they only affect the scores of a few nodes. Therefore, when considering whether to flatten a subtree, it is sufficient for the node set N to include the nodes of the subtree, without having to include other nodes of the hierarchical acceleration structure.

[0190] For example, Figure 11a The SAH of the unflattened subtree shown in can be calculated as and Figure 12a The SAH of the flattened subtree shown in can be calculated as Node A is the parent of node B. Therefore, if 2a(B)>2a(D)+2a(E), then Figure 12a The estimated number of intersection tests for the flattened subtree shown in will be higher than Figure 11a However, if 2a(B)<2a(D)+2a(E), then Figure 12a The estimated number of intersection tests for the flattened subtree shown in will be less than Figure 11a The unflattened subtree shown in . The bandwidth cost depends on how the nodes are stored in the data block. For example, if nodes D and E are stored as Figure 10a The nodes of the implicit representation shown are Figure 11a The unflattened subtree shown in Figure 12a The bandwidth cost will be the same for the flattened subtree shown in . The processing module 106 utilizes these two heuristics to determine whether to flatten a subtree.

[0191] In the examples described herein, subtree flattening can be performed dynamically, for example, during the intersection testing phase of rendering, rather than during the acceleration structure construction phase of rendering. For example, the multi-level tree format of the data block means that nodes from multiple levels of the hierarchical acceleration structure are received together, which means that the intersection testing module 308 can perform subtree flattening at runtime. Specifically, the intersection testing module 308 can receive a subtree that includes a particular node and all of its child nodes. The intersection testing module 308 can dynamically decide whether to test a particular node during intersection testing or whether to test only the child nodes of the particular node. This decision is made based on current system conditions, for example, based on current bottlenecks in the ray tracing system 300, and / or based on whether some of the node testers would be idle if the particular node were tested. In this way, the topology of the subtree being traversed can be changed during runtime (i.e., during intersection testing) to adapt to the needs of the system (e.g., to adapt to current conditions in the ray tracing system 300).

[0192] Bottlenecks in the system can depend significantly on the distribution of rays being tested for intersection. Specifically, as described above, the intersection testing process typically has one of two bottlenecks that limit the rate at which intersection testing can be performed: (i) memory bandwidth is the limiting factor, e.g., the rate at which data representing portions of the acceleration structure can be retrieved from memory 304 for rays being tested, or (ii) the throughput of the intersection testing module 308 is the limiting factor, e.g., the rate at which the intersection testing module 308 can perform intersection testing operations. Which of these two factors is the limiting factor will depend on conditions in the ray tracing system (e.g., operating conditions). For example, if the rays being tested for intersection are relatively coherent, a relatively large number of rays will be tested simultaneously for intersection with the same region of the scene; whereas, if the rays being tested for intersection are relatively incoherent, a relatively small number of rays will be tested simultaneously for intersection with the same region of the scene. Rays are "coherent" if they are submitted for intersection testing at temporally close times and have similar starting points and similar directions. If the rays are relatively coherent, the number of rays grouped together by scheduler 312 to be tested for intersection with a particular region of the scene tends to be greater than if the rays are relatively incoherent. Consequently, if the rays are relatively coherent, a greater number of rays are tested against a node each time its node data is retrieved from memory 304 than if the rays are relatively incoherent. Thus, for relatively coherent rays, the memory bandwidth cost of retrieving node data from memory 304 is reduced per ray, but the test cost of performing intersection tests can be independent of the ray distribution. Thus, when the rays are relatively coherent, the limiting factor may be the throughput of intersection test module 308, and in this case, a relatively small number of test blocks 324 may tend to be idle in any given processing cycle; whereas, when the rays are relatively incoherent, the limiting factor may be memory bandwidth, and in this case, a relatively large number of test blocks 324 may tend to be idle in any given processing cycle.

[0193] The ray tracing system 300 (e.g., the node processing logic 320) can monitor the memory bandwidth and the computational throughput of the node tester to determine what is limiting the throughput of the intersection test module 308. With this information, the node processing logic 320 can make an intelligent decision as to whether the intersection test module 308 should test a particular parent node or skip it entirely. As described above, if the rays are incoherent, the test block 324 may be underutilized, so testing with respect to a particular parent node can be skipped and all of its child nodes can be tested instead. If a particular parent node is being tested for intersection, and the node data for the child nodes of that particular parent node has already been fetched from memory 304, some of the tester slots may already be idle, so testing the child nodes instead of that particular parent node means that the test is pushed further down the hierarchical acceleration structure at zero cost (i.e., without incurring any additional latency). The term "tester slot" is used herein to refer to one of the test blocks 324 in a particular processing cycle. In contrast, if the rays are coherent, then it is less likely that the tester time slot will be idle and the throughput of the intersection test module 308 is likely to be the limiting factor, so it is beneficial to minimize the number of intersection tests that need to be performed, so it often makes sense to test a specific parent node to potentially avoid having to test all of its child nodes.

[0194] Monitoring subsystem utilization (e.g., monitoring the utilization of test block 324 by monitoring how many test blocks 324 are idle) and dynamically choosing to flatten subtrees can improve the performance of ray tracing system 300 without requiring a priori knowledge of the ray distribution during tree construction performed by processing module 306.

[0195] Figure 13 is a flow chart of a method for performing intersection testing in the ray tracing system 300. In step S1302, the intersection testing module 308 (eg, the receiving logic 316) receives a portion of a hierarchical acceleration structure (eg, Figure 11a This data is received from the memory 304. As described above, the node data of the subtree is stored in the local memory 318.

[0196] In step S1304, the intersection testing module 308 (e.g., receiving logic 316) receives an indication of one or more rays to be tested for intersection with the region represented by a particular node of the subtree. For example, the particular node may be Figure 11a Node D of the subtree shown in . A subtree includes the descendants (e.g., children or grandchildren) of a particular node. For example, Figure 11aThe subtree shown in includes nodes H and I, which are children of node D. As described above, a packet of rays to be tested for intersection with the region represented by a particular node may be received from memory 304 or from request queue 314 at receive logic 316. It should be noted that receive logic 316 may be implemented as a plurality of different modules, e.g., a first module for receiving node data representing a subtree, and a second module for receiving an indication of one or more rays to be tested for intersection.

[0197] In step S1306, the node processing logic 320 determines whether to skip testing one or more rays for intersection with the region represented by the particular node of the subtree based on conditions in the ray tracing system 300. In other words, the node processing logic 320 determines whether to flatten the subtree by omitting the particular node based on conditions in the ray tracing system 300.

[0198] For example, the node processing logic 320 can monitor the amount of data received that represents a portion of the hierarchical acceleration structure. In other words, the node processing logic 320 can monitor memory bandwidth. In addition, the node processing logic 320 can monitor the processing load on the test block 324 of the intersection test module 308. The monitored amount of data received from the memory 304 and the monitored processing load on the test block 324 represent conditions in the ray tracing system 300 that can be used in step S1306 to determine whether to skip testing one or more rays for intersection with the region represented by a particular node of the subtree.

[0199] In some examples, the node processing logic 320 can determine whether to skip intersection testing of one or more rays with the area represented by a particular node of the subtree by determining an indication of how many of the test blocks 324 of the intersection testing module 308 would be idle if the one or more rays were tested for intersection with the area represented by the particular node of the subtree, and comparing the determined indication to a threshold. For example, the threshold can be equal to (or greater than) or less than the number of child nodes that the particular node has minus one. If the number of test blocks 324 that are idle when testing one or more rays for intersection with the area represented by the particular node of the subtree is above the threshold, testing of the particular node can be skipped, and the child nodes of the particular node can be tested instead. For example, node D has two child nodes (nodes H and I). If the node processing logic 320 determines that if node D were tested for intersection during a particular processing cycle, one or more of the test blocks 324 would be idle during that particular processing cycle, testing of node D can be skipped, and the intersection of nodes H and I can be tested instead. This allows the intersection testing process to proceed down the subtree at zero cost.

[0200] The conditions of the ray tracing system on which the node processing logic 320 makes its decision may vary in different implementations and may include one or more of the following:

[0201] the number of rays to be tested for intersection with the region represented by a particular node of the subtree;

[0202] the coherence level of the rays to be tested for intersection;

[0203] Processing load on the test blocks of the intersecting test modules;

[0204] the workload in the test queue 322;

[0205] The number of test blocks of the intersection test module; and

[0206] The amount of data received from memory 304.

[0207] Based on the determination, an intersection test is performed on the one or more rays (in steps S1312 or S1314) using one or more of the test blocks 324 of the intersection test module 308. If the test for the particular node (e.g., node D) is not skipped, the method proceeds from step S1308 to S1312. Between steps S1308 and S1312 is step S1310, which is performed if the particular node is an implicitly represented node, but not performed if the particular node is not an implicitly represented node, as described below.

[0208] In step S1312, one or more of the test blocks 324 test the intersection of the corresponding one or more rays with the area represented by a particular node of the subtree (e.g., node D). As described above, methods for testing the intersection of rays with areas (e.g., AABBs) are known in the art, and the specificity of these methods is beyond the scope of this disclosure. If the ray intersects the area represented by the particular node (e.g., node D), the ray is tested for intersection with the child nodes of the particular node (e.g., nodes H and I). Because the node data defining the area represented by nodes H and I is stored in the local memory 318, the ray can be tested for intersection with the child nodes (e.g., nodes H and I) without retrieving further data from the memory 304. If the ray does not intersect with the area represented by the particular node (e.g., node D), the ray is not tested for intersection with the child nodes of the particular node (e.g., nodes H and I).

[0209] If the test for the particular node (e.g., node D) is to be skipped, the method proceeds from step S1308 to step S1314. In step S1314, one or more of the test blocks 324 test the intersection of the corresponding one or more rays with the region represented by the descendants (e.g., nodes H and I) of the particular node (e.g., node D) at a particular level in the subtree, thereby skipping the intersection test of the one or more rays with the region represented by the particular node (e.g., node D) of the subtree. Therefore, if the node processing logic 320 determines that the intersection test of the one or more rays with the region represented by the particular node of the subtree is to be skipped, the one or more rays are not tested for intersection with the region represented by the particular node of the subtree.

[0210] After step S1312 or S1314, the test blocks 324 can each output the results of the intersection tests they have performed to the result processor 326. The result processor 326 processes the results of the intersection tests. Specifically, if a ray is found not to intersect the node for which it is being tested, the result processor 326 does not schedule an intersection test for the ray with respect to the children of the non-intersecting node. If the result processor 326 determines that the ray has intersected the node for which it is being tested, the ray is output from the intersection test module 308 back to the scheduler 312, where the ray will be grouped into groups and scheduled for intersection testing with respect to the children of the intersecting node.

[0211] The process described above with reference to steps S1302 to S1314 is repeated iteratively until there are no more hits for the ray. In response to the ray intersecting a leaf node, the objects (e.g., triangle primitives) within the leaf node are scheduled to perform intersection testing with the ray. As described above, the intersection testing module 308 may include an object testing block ( Figure 3(not shown) which is configured to perform intersection tests on rays that intersect with the leaf node for (one or more) objects within the leaf node, and those skilled in the art will know how to test the intersection of rays with triangle primitives, so the details of this process are not described in detail herein. If the result of all intersection tests for the ray is that the ray does not intersect with any object in the scene, then a "miss" result is returned and can be processed accordingly. If the result of all intersection tests for the ray is that the ray intersects with a single object, then the data for this intersection and a "hit" result can be returned and processed accordingly. If the result of all intersection tests for the ray is that the ray intersects with more than one object, then the intersection distances of the intersections (i.e., the distance from the ray origin to the intersection point) are compared to find the "nearest hit," i.e., the intersection point closest to the ray origin. The data for this nearest hit intersection and a "hit result" can be returned and processed accordingly. When determining a "hit" result, data related to the intersection can be determined by the object test block, such as an indication of the location of the intersection on the intersection primitive (e.g., as barycentric coordinates) and an indication of the distance of the intersection from the starting point of the ray.

[0212] The results of the intersection test (e.g., hit results) are passed to processing logic 310. Processing logic 310 executes one or more shader programs to process the results of the intersection test to determine the rendering value of the image representing the scene. In this way, the effect of the intersection can be determined, that is, the results of the intersection test are used to determine the rendering value of the image representing the scene. Thus, the results of testing the intersection of one or more rays are used to determine the rendering value of the image representing the scene.

[0213] In some examples, the particular node is an implicitly represented node. For example, a hierarchical acceleration structure may include Figure 14a The nodes shown in . Figure 14a shows how different nodes are stored in a data block, where two squares represent two data blocks. The format of the data block can be as described in detail above, for example, as described above with reference to Figure 10a and Figure 10b As stated. Figure 14a In the example shown, nodes A, D, and E are implicitly represented nodes. Figure 14b Shown after the subtrees within the hierarchical acceleration structure have been flattened Figure 14a The hierarchical acceleration structure shown in . In this example, the implicitly represented nodes D and E have been omitted, flattening the subtree.

[0214] In this example, if the node processing logic determines in step S1306 not to skip testing that one or more rays intersect the area represented by the implicitly represented nodes D and E, the method proceeds from step S1308 to step S1310, where the node processing logic 320 infers from the received data data defining the area represented by nodes D and E. Methods for inferring data defining the area represented by implicitly represented nodes (e.g., using data defining the area represented by descendants (e.g., children or grandchildren) of a particular node at a particular level in a subtree) are described in detail above.

[0215] If the node processing logic determines in step S1306 that the test of one or more rays for intersection with the regions represented by the implicitly represented nodes D and E is to be skipped, then data defining the regions represented by nodes D and E is not inferred. In other words, step S1310 is not executed on the "yes" path of the decision in step S1308. In this manner, if the implicitly represented node does not require intersection testing, then the intersection testing module 308 does not infer data defining the regions represented by the implicitly represented node. Therefore, in this case, no data is stored to represent the implicitly represented node (thereby reducing memory bandwidth and the amount of memory used to store data representing the hierarchical acceleration structure), and the operations involved in inferring the implicitly represented node are not performed in the intersection testing module 308, and the operations involved in testing rays for intersection with the regions represented by the implicitly represented nodes are not performed in the intersection testing module 308 (thereby reducing the amount of work performed by the intersection testing module 308, which can reduce latency and power consumption of the intersection testing module 308).

[0216] Figure 15 15. A computer system is shown in which the ray tracing system described herein may be implemented. The computer system includes a CPU 1502, memory 304, ray tracing unit 302, and other devices 1504, such as a display 1506, speakers 1508, and a camera 1510. The components of the computer system may communicate with each other via a communication bus 1512.

[0217] The ray tracing system 300 is shown as including several functional blocks. This is merely illustrative and is not intended to define a strict division between different logical elements of such entities. 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 need not be physically generated by the ray tracing system at any point, and may simply represent logical values that conveniently describe the processing performed by the ray tracing system between its inputs and outputs.

[0218] The ray tracing system described herein can be included in hardware on an integrated circuit. The ray tracing system 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" may be used herein to generally refer to software, firmware, hardware, or any combination thereof. In the case of a software implementation, a module, function, component, element, unit, block, or logic represents 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 that execute code that causes the processor to perform 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 use magnetic, optical, and other technologies to store instructions or other data and can be accessed by a machine.

[0219] 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.

[0220] 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.

[0221] 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 a ray tracing system configured to perform any of the methods described herein, or to manufacture a ray tracing system including any of the apparatus described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0222] Thus, a method of manufacturing a ray tracing system as described herein in an integrated circuit manufacturing system may be provided. Furthermore, an integrated circuit definition data set may be provided which, when processed in an integrated circuit manufacturing system, enables the method of manufacturing a ray tracing system to be performed.

[0223] 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.

[0224] Now refer to Figure 16 An example of processing an integrated circuit definition dataset at an integrated circuit fabrication system to configure the system to fabricate a ray tracing system is described.

[0225] Figure 16An example of an integrated circuit (IC) manufacturing system 1602 is shown that is configured to manufacture a ray tracing system as described in any of the examples herein. Specifically, IC manufacturing system 1602 includes a layout processing system 1604 and an integrated circuit generation system 1606. IC manufacturing system 1602 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., embodying a ray tracing system as described in any of the examples herein) based on the IC definition dataset. Processing of the IC definition dataset configures IC manufacturing system 1602 to manufacture an integrated circuit embodying a ray tracing system as described in any of the examples herein.

[0226] The layout processing system 1604 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. When the layout processing system 1604 has determined the circuit layout, it can output the circuit layout definition to the IC generation system 1606. The circuit layout definition may be, for example, a circuit layout description.

[0227] As is known in the art, IC generation system 1606 generates an IC based on a circuit layout definition. For example, IC generation system 1606 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 1606 may be in the form of computer-readable code, which IC generation system 1606 can use to generate a suitable mask for generating the IC.

[0228] The various processes performed by IC manufacturing system 1602 may all be performed at a single location, such as by one party. Alternatively, IC manufacturing system 1602 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.

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

[0230] 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 16 Configuring an integrated circuit manufacturing system in the manner described can result in the devices described herein being manufactured.

[0231] 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 16 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 program code to the integrated circuit for use by the integrated circuit.

[0232] 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 cause 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, equipment, modules and systems (e.g., in integrated circuits), a trade-off can be made between performance improvements and physical implementations to improve manufacturing methods. 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. 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. On the contrary, the concepts of improvements (such as silicon area reduction) in the physical implementations of devices, equipment, 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.

[0233] 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.

Claims

1. A computer-implemented method for performing intersection testing in a ray tracing system for rendering an image of a scene, wherein: The ray tracing system includes an intersection testing module including a plurality of test blocks configured to test intersection of a ray with an area in a scene, the method comprising: receiving data representing a portion of a hierarchical acceleration structure, wherein the hierarchical acceleration structure comprises nodes, each node representing a region in a scene, wherein the nodes are linked to form the hierarchical acceleration structure, wherein the portion of the hierarchical acceleration structure represents a subtree within the hierarchical acceleration structure; receiving an indication of one or more rays to be tested for intersection with a region represented by a particular node of the subtree, wherein the subtree includes descendants of the particular node; determining whether to skip testing the one or more rays for intersection with the region represented by a particular node of the subtree based on a condition in the ray tracing system; and Based on the determination, testing the intersection of the one or more rays using one or more of the test blocks of the intersection testing module, wherein testing the intersection of the one or more rays comprises: If the determination is to skip testing the one or more rays for intersection with the area represented by the specific node of the subtree, then testing the one or more rays for intersection with the area represented by the descendants of the specific node at a specific level in the subtree, thereby skipping testing the one or more rays for intersection with the area represented by the specific node of the subtree.

2. The method according to claim 1, wherein The testing the intersection of the one or more rays further comprises: If the determination is not to skip testing the one or more rays for intersection with the area represented by the particular node of the subtree, then testing the one or more rays for intersection with the area represented by the particular node of the subtree.

3. The method according to claim 1 or 2, wherein: The descendants of the particular node at a particular level in the subtree are any of the following: A) the children of the particular node in the subtree; or B) Grandchildren of the specific node in the subtree.

4. The method according to any one of claims 1 or 2, wherein the particular node being an implicitly represented node, wherein data defining the region represented by the implicitly represented node is not explicitly included as part of the received data representing the subtree, but can be inferred from the received data, Wherein, if the determination is not to skip testing the one or more rays for intersection with the area represented by the specific node of the subtree, inferring data defining the area represented by the specific node from the received data.

5. The method according to claim 4, wherein The data defining the area represented by the particular node may: A) if the determination is to skip testing the one or more rays for intersection with the region represented by the particular node of the subtree, then not being inferred; B) inferring from data in said received data, said data defining a region represented by descendants of said particular node at a particular level in said subtree.

6. The method according to claim 5, in, The region represented by the node of the hierarchical acceleration structure is an axis-aligned bounding box in the scene; wherein data defining the area represented by the particular node can be inferred by determining, in each dimension of the scene, the minimum and maximum components of the components defining the axis-aligned bounding box represented by the descendants of the particular node at a particular level in the subtree.

7. The method according to any one of claims 1 to 2, wherein: The received data representing a portion of the hierarchical acceleration structure includes data indicating how the nodes of the subtree are linked, and wherein the data defining the area represented by the particular node is capable of being inferred from the received data using at least some of the data indicating how the nodes of the subtree are linked.

8. The method according to any one of claims 1 to 2, wherein: The receiving data representing a portion of the hierarchical acceleration structure includes receiving a data block, wherein the data block includes data representing the subtree within the hierarchical acceleration structure.

9. The method according to claim 8, wherein The data block includes: (i) data defining the region represented by the descendants of the particular node at a particular level in the subtree, and (ii) data indicating how the nodes of the subtree are linked.

10. The method according to claim 8, wherein The data block includes data defining a region represented by nodes having a shared ancestor in the hierarchical acceleration structure, wherein the data block includes an indication of a common starting region for the region represented by the shared ancestor, and wherein the data in the data block defining the region represented by nodes having a shared ancestor in the hierarchical acceleration structure includes, for each node having a shared ancestor, one or more offsets from the common starting region.

11. The method according to any one of claims 1 to 2, wherein: The determining whether to skip testing the one or more rays for intersection with the region represented by a particular node of the subtree is performed dynamically during an intersection testing phase of rendering an image of the scene in the ray tracing system.

12. The method according to any one of claims 1-2, further comprising: monitoring an amount of received data representing a portion of the hierarchical acceleration structure; as well as monitoring a processing load on the test blocks of the intersection test module; The conditions in the ray tracing system include a monitored data volume and a monitored processing load.

13. The method according to any one of claims 1 to 2, wherein: The determining whether to skip testing the one or more rays for intersection with the region represented by the specific node of the subtree comprises: determining an indication of how many of the test blocks of the intersection test module would be free if the one or more rays were tested for intersection with the area represented by the particular node of the subtree; and The determined indication is compared to a threshold value.

14. The method according to any one of claims 1 to 2, wherein: The conditions in the ray tracing system include one or more of the following: the number of rays to be tested for intersection with the region represented by a particular node of the subtree; the coherence level of the rays to be tested for intersection; Processing load on the test blocks of the intersecting test modules; the workload in the work queue of the test block; The number of test blocks of the intersection test module; as well as An amount of data received from memory that reads data representing a portion of the hierarchical acceleration structure.

15. A method for rendering an image of a scene in a ray tracing system, comprising: Generate and store hierarchical acceleration structures; performing an intersection test according to the method of claim 1 or 2 using a portion of the generated hierarchical acceleration structure; as well as One or more shader programs are executed to process the results of the intersection test to determine rendering values for an image representing the scene.

16. An intersection test module configured to perform an intersection test in a ray tracing system for rendering a scene image, the intersection test module comprising: receiving logic, the receiving logic being configured to: receiving data representing a portion of a hierarchical acceleration structure, wherein the hierarchical acceleration structure comprises nodes, each node representing a region in a scene, wherein the nodes are linked to form the hierarchical acceleration structure, wherein the portion of the hierarchical acceleration structure represents a subtree within the hierarchical acceleration structure; and receiving an indication of one or more rays to be tested for intersection with a region represented by a particular node of the subtree, wherein the subtree includes descendants of the particular node; node processing logic configured to determine whether to skip testing the one or more rays for intersection with a region represented by a particular node of the subtree based on a condition in the ray tracing system; and a plurality of test blocks configured to test for intersection of the one or more rays based on the determination made by the node processing logic, wherein the intersection testing module is configured to cause the plurality of test blocks to test for intersection of the one or more rays by: If the determination made by the node processing logic is to skip testing the one or more rays for intersection with the area represented by the specific node of the subtree, then testing the one or more rays for intersection with the area represented by the descendants of the specific node at a specific level in the subtree, thereby skipping testing the one or more rays for intersection with the area represented by the specific node of the subtree.

17. The intersection test module according to claim 16, wherein: The particular node is an implicitly represented node, wherein data defining the region represented by the implicitly represented node is not explicitly included as part of the received data representing the subtree, but can be inferred from the received data, and The node processing logic is further configured to: If the determination is not to skip testing the one or more rays for intersection with the area represented by the particular node of the subtree, inferring data defining the area represented by the particular node from the received data; and If the determination is to skip testing the one or more rays for intersection with the region represented by the particular node of the subtree, then inferring data defining the region represented by the particular node is skipped.

18. The intersection test module according to claim 16 or 17, wherein: The receiving logic is configured to receive data representing a portion of the hierarchical acceleration structure as a data block, wherein the data block includes data representing the subtree within the hierarchical acceleration structure.

19. A ray tracing system configured to render an image of a scene, the ray tracing system comprising: a processing module configured to generate a hierarchical acceleration structure; The intersection test module according to any one of claims 16 or 17, the intersection test module being configured to perform intersection testing using a portion of the generated hierarchical acceleration structure; as well as Processing logic is configured to execute one or more shader programs to process results of the intersection test to determine rendering values for an image representing the scene.

20. A computer-readable storage medium, wherein any one of the following items is stored on the computer-readable storage medium: A) Computer program code for executing the method according to any one of claims 1 to 2; or, B) An integrated circuit definition data set which, when processed in an integrated circuit manufacturing system, configures the integrated circuit manufacturing system to manufacture the intersection testing module or the ray tracing system according to any one of claims 16 or 17.

Images