Early culling for ray tracing

Abstract

Techniques for performing ray tracing operations are provided that include reading descendant shared type metadata for a non-leaf node of a bounding volume hierarchy, identifying one or more culling types for ray intersection testing of a ray, and determining whether to treat the non-leaf node as unintersected based on whether the one or more culling types include at least one type specified by the descendant shared type metadata.

Description

Technical Field

[0002]

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Application No. 63 / 044,686, filed Jun. 26, 2020, entitled “EARLY CULLING FOR RAY TRACING”, and U.S. Patent Application No. 17 / 008,462, filed Aug. 31, 2020, entitled “EARLY CULLING FOR RAY TRACING”, the entire disclosures of which are incorporated herein by reference.

Background Art

[0002] Ray tracing is a type of graphics rendering technique where simulated rays are projected to test for object intersections and pixels are colored based on the results of the ray projections. Ray tracing is computationally more expensive than rasterization - based techniques but produces more physically accurate results. Improvements to ray - tracing operations are constantly being made.

[0003] A more detailed understanding will become possible from the following description given as an example together with the accompanying drawings.

Brief Description of the Drawings

[0004] [Figure 1] It is a block diagram of an exemplary device capable of implementing one or more features of the present disclosure. [Figure 2] It is a block diagram of a device showing additional details regarding the execution of a processing task on the acceleration processing device of FIG. 1 according to an example. [Figure 3] It is a diagram showing a ray - tracing pipeline for rendering graphics using ray - tracing technology according to an example. [Figure 4] It is a diagram showing a bounding volume hierarchy according to an example. [Figure 5]This is a block diagram of an acceleration structure traversal stage, as an example. [Figure 6A] This is a block diagram of a boundary volume hierarchy that includes type metadata within non-leaf nodes to enable early culling of boundary volume hierarchy nodes, as an example. [Figure 6B] This figure shows an exemplary boundary volume hierarchy that includes type metadata within non-leaf nodes. [Figure 7] This is a flowchart illustrating an example of a method for performing ray tracing. [Modes for carrying out the invention]

[0005] A technique for performing ray tracing operations is provided. This technique includes reading descendant-shared type metadata for non-leaf nodes in a boundary volume hierarchy, identifying one or more culling types for ray crossing tests, and determining whether to treat non-leaf nodes as non-crossing based on whether one or more culling types include at least one type specified by the descendant-shared type metadata.

[0006] Figure 1 is a block diagram of an exemplary device 100 capable of implementing one or more features of the present disclosure. Device 100 includes, for example, a computer, a game device, a handheld device, a set-top box, a television, a mobile phone, or a tablet computer. Device 100 includes a processor 102, memory 104, storage device 106, one or more input devices 108, and one or more output devices 110. Device 100 also optionally includes an input driver 112 and an output driver 114. It should be understood that device 100 includes additional components not shown in Figure 1.

[0007] In various alternatives, the processor 102 includes a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, each of which may be a CPU or a GPU. In various alternatives, the memory 104 may be located on the same die as the processor 102 or separately from the processor 102. The memory 104 includes volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache).

[0008] The storage device 106 includes fixed or removable storage devices (e.g., hard disk drives, solid-state drives, optical discs, flash drives). The input device 108 includes, but is not limited to, a keyboard, keypad, touchscreen, touchpad, detector, microphone, accelerometer, gyroscope, biometric scanner, or network connectivity (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals). The output device 110 includes, but is not limited to, a display device 118, speaker, printer, haptic feedback device, one or more lights, antennas, or network connectivity (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals).

[0009] The input driver 112 communicates with the processor 102 and the input device 108, enabling the processor 102 to receive input from the input device 108. The output driver 114 communicates with the processor 102 and the output device 110, enabling the processor 102 to send output to the output device 110. Note that the input driver 112 and the output driver 114 are optional components, and that device 100 can be operated in the same manner even if the input driver 112 and the output driver 114 are not present. The output driver 114 includes an accelerated processing device ("APD") 116 coupled to the display device 118. The APD 116 is configured to accept computation and graphics rendering commands from the processor 102, process those computation and graphics rendering commands, and provide pixel output to the display device 118 for display. As will be described in more detail below, the APD116 includes one or more parallel processing units configured to perform computations according to the single-instruction-multiple-data (SIMD) paradigm. Thus, although various functions are described herein as being performed by or in conjunction with the APD116, in various alternative examples, functions described as being performed by the APD116 are not driven by the host processor (e.g., processor 102) but are additionally or alternatively performed by other computing devices having similar capabilities configured to provide (graphic) output to the display device 118. For example, it is intended that any processing system that performs processing tasks according to the SIMD paradigm can be configured to perform the functions described herein. Alternatively, it is intended that a computing system that does not perform processing tasks according to the SIMD paradigm can perform the functions described herein.

[0010] Figure 2 is a block diagram of device 100 showing additional details regarding the execution of processing tasks on APD116. The processor 102 maintains one or more control logic modules for execution by the processor 102 in system memory 104. The control logic modules include an operating system 120, a driver 122, and an application 126. These control logic modules control various characteristics of the operation of the processor 102 and APD116. For example, the operating system 120 communicates directly with the hardware and provides an interface to the hardware for other software running on the processor 102. The driver 122 controls the operation of APD116 by providing an application programming interface ("API") to software running on the processor 102 (e.g., application 126) to access various functions of APD116. In some embodiments, the driver 122 includes a just-in-time compiler that compiles programs for execution by the processing components of APD116 (such as the SIMD unit 138, which will be described in more detail below). In other embodiments, a just-in-time compiler is not used to compile the program; instead, a standard application compiler compiles the shader program for execution on the APD116.

[0011] The APD116 executes commands and programs for selected functions, such as graphics operations and non-graphics operations, that are suitable for parallel and / or non-sequential processing. Based on commands received from the processor 102, the APD116 is used to perform graphics pipeline operations such as pixel operations, geometric calculations, and rendering images to the display device 118. The APD116 also performs computational operations that are not directly related to graphics operations, such as operations related to video, physical simulations, computational fluid dynamics, or other tasks, based on commands received from the processor 102.

[0012] The APD116 includes a compute unit 132 which includes one or more SIMD units 138 that operate in a parallel manner according to the SIMD paradigm at the request of the processor 102. The SIMD paradigm is such that multiple processing elements share a single program control flow unit and program counter and thus execute the same program, but can execute that program with different data. In one example, each SIMD unit 138 includes 16 lanes, each lane executing the same instruction simultaneously with other lanes in the SIMD unit 138, but executing that instruction with different data. Lanes can be switched off by prediction if not all lanes need to execute a given instruction. Prediction can also be used to execute a program with branch control flows. More specifically, for a program with conditional branches or other instructions where the control flow is based on calculations performed by individual lanes, prediction of lanes corresponding to control flow paths not currently being executed and serial execution of different control flow paths enable arbitrary control flows. In an embodiment, each of the compute units 132 may have a local L1 cache. In an embodiment, multiple compute units 132 share an L2 cache.

[0013] The basic unit of execution within the computing unit 132 is a work item. Each work item represents a single instance of a program to be executed in parallel on a specific lane. Work items can be executed simultaneously as a "wavefront" on a single SIMD unit 138. One or more wavefronts constitute a "work group," which is a collection of work items designated to execute the same program. A work group is executed by executing each of the wavefronts that make up the work group. In an alternative example, wavefronts are executed sequentially on a single SIMD unit 138, or partially or fully in parallel on different SIMD units 138. A wavefront can be thought of as the largest collection of work items that can be executed simultaneously on a single SIMD unit 138. Therefore, if a command received from processor 102 indicates that a particular program is parallelized to such an extent that it cannot be executed simultaneously on a single SIMD unit 138, the program is divided into wavefronts that are parallelized on two or more SIMD units 138, or serialized (or both parallelized and serialized as needed) on the same SIMD unit 138. The scheduler 136 is configured to perform operations related to scheduling various wavefronts on different computing units 132 and SIMD units 138.

[0014] The parallel processing provided by the computing unit 132 is suitable for graphics-related operations such as pixel value calculation, vertex transformation, and other graphics operations. Therefore, in some cases, the graphics pipeline 134, which accepts graphics processing commands from the processor 102, provides computing tasks to the computing unit 132 for parallel execution.

[0015] Furthermore, the compute unit 132 is used to perform computational tasks that are not related to graphics or are not performed as part of the "normal" operation of the graphics pipeline 134 (for example, custom operations performed to supplement the processing performed on the operation of the graphics pipeline 134). An application 126 or other software running on the processor 102 sends a program that defines such computational tasks to the APD 116 for execution.

[0016] Computation unit 132 implements ray tracing, a technique for rendering 3D scenes by testing the intersections between simulated rays and objects in the scene. Much of the work involved in ray tracing is performed by programmable shader programs that run on SIMD unit 138 within computation unit 132, as will be described in more detail below.

[0017] Figure 3 shows an example of a ray tracing pipeline 300 for rendering graphics using ray tracing technology. The ray tracing pipeline 300 provides an overview of the operations and entities involved in rendering a scene using ray tracing. In some embodiments, the ray generation shader 302, any hit shader 306, closest hit shader 310, and miss shader 312 are shader implementation stages representing ray tracing pipeline stages whose functions are performed by shader programs executed within the SIMD unit 138. Any particular shader program in each particular shader implementation stage is defined by application-provided code (i.e., code provided by the application developer, pre-compiled by the application compiler and / or compiled by the driver 122). In other embodiments, the ray generation shader 302, the arbitrary hit shader 306, the nearest hit shader 310, and the miss shader 312 are all implemented as software performing the operations described herein, circuits performing the operations described herein, or a combination of hardware circuits and software running on a processor, running on any type of processor. The acceleration structure traversal stage 304 performs a ray crossing test to determine whether a ray hits a triangle.

[0018] The ray tracing pipeline 300 refers to the path through which ray tracing operations flow. To render a scene using ray tracing, a rendering orchestrator, such as a program running on processor 102, specifies a collection of geometric shapes as the "scene." The various objects in the scene are represented as a collection of geometric primitives, which are often triangles but can be any geometric shape. As used herein, the term "triangle" refers to these geometric primitives that make up the scene. The rendering orchestrator renders the scene by specifying the camera position and image, and by requesting that rays be traced from the camera through the image. The ray tracing pipeline 300 performs various operations described herein to determine the color of the rays. The color is often derived from the triangles through which the rays intersect. As described elsewhere herein, rays that do not hit a triangle invoke the miss shader 312. One possible operation of misshader 312 is to color rays with a color from a "skybox," which is an image designated to represent the surrounding scene where no geometric shapes exist (for example, a scene without geometric shapes will only render the skybox). The color of pixels in the image is determined based on the intersection between the ray and the image position. In some examples, after a sufficient number of rays have been traced and the pixels in the image have been colored, the image is displayed on the screen or used in some other manner.

[0019] In some embodiments where the shader stages of the ray tracing pipeline 300 are implemented in software, various programmable shader stages (ray generation shader 302, arbitrary hit shader 306, nearest hit shader 310, miss shader 312) are implemented as shader programs executed on the SIMD unit 138. The accelerated structure crossing stage 304 is implemented as software (e.g., as a shader program executed on the SIMD unit 138), as hardware, or as a combination of hardware and software. The hit or miss unit 308 is implemented in any technically feasible manner, such as as part of any other unit, as a hardware-accelerated structure, or as a shader program executed on the SIMD unit 138. In various embodiments, the ray tracing pipeline 300 may be organized partially or entirely in software, or partially or entirely in hardware, by the processor 102, the scheduler 136, a combination thereof, or partially or entirely by any other hardware and / or software units. In the examples, traverses through the ray tracing pipeline 300 are performed either autonomously or under the control of the processor 102, partially or completely by the scheduler 136, or partially or completely by a shader program (such as a bounding volume hierarchy traversal shader program) running on one or more of the SIMD units 138. In some examples, testing rays against boxes and triangles (inside the accelerating structure traversal stage 304) is hardware-accelerated (meaning that fixed-function hardware units perform the steps of those tests). In other examples, such tests are performed by software, such as a shader program, running on one or more of the SIMD units 138.In this specification, when the expression "the ray tracing pipeline does [a certain action]" is used, this means that the hardware and / or software implementing the ray tracing pipeline 300 does that action. Although described as being executed on the SIMD unit 138 of FIG. 3, in other embodiments, other hardware (e.g., the processor 102), with or without SIMD capabilities, may alternatively execute the shader program of the ray tracing pipeline 300 being described.

[0020] The ray tracing pipeline 300 operates in the following manner. A ray generation shader 302 is performed. The ray generation shader 302 sets data for the rays to test against the triangles and requests an acceleration structure traversal stage 304 to test the rays for intersection with the triangles.

[0021] The acceleration structure traversal stage 304 traverses an acceleration structure, which is a data structure describing the scene volume and the objects (such as triangles) within the scene, and tests the rays against the triangles within the scene. In various examples, the acceleration structure is a bounding volume hierarchy. In some embodiments, a hit or miss unit 308, which is part of the acceleration structure traversal stage 304, determines whether the results of the acceleration structure traversal stage 304 (which may include raw data such as barycentric coordinates and possible hit times) actually indicate a hit. For the hit triangle, the ray tracing pipeline 300 triggers the execution of any hit shader 306. Note that multiple triangles can be hit by a single ray. The acceleration structure traversal stage is not guaranteed to traverse the acceleration structure in order from the one closest to the ray origin to the one farthest from the ray origin. The hit or miss unit 308 triggers the execution of the closest hit shader 310 for the triangle closest to the origin of the ray that the ray hits, or, if the triangle does not hit, triggers the miss shader.

[0022] It should be noted that any hit shader 306 can "reject" a hit from the ray crossing test unit 304, and therefore, a hit or miss unit 308 will trigger the execution of a miss shader 312 if the hit is not found or accepted by the ray crossing test unit 304. An exemplary situation in which any hit shader 306 can "reject" a hit is when at least a portion of the triangle that the ray crossing test unit 304 reports as a hit is completely transparent. Since the ray crossing test unit 304 only tests geometry and not transparency, for a hit on a triangle that has at least some transparency, any called hit shader 306 may determine that the reported hit is not a hit because it actually "hit" a transparent portion of the triangle. A typical use of the nearest hit shader 310 is to color a material based on the material's texture. A typical use of the miss shader 312 is to color a pixel with the color set by the skybox. It should be understood that the nearest hit shader 310 and miss shader 312 may implement a wide variety of techniques for coloring pixels and / or performing other actions. If these shaders are implemented as programmable shader stages that execute shader programs, different shader programs used in the same application may color pixels in different ways.

[0023] A typical method by which the ray generation shader 302 generates rays is to use a technique called backward ray tracing. In backward ray tracing, the ray generation shader 302 generates rays originating from a point on the camera. The point where the ray intersects a plane defined to correspond to the screen defines a pixel on the screen used to determine the color of the ray. If the ray hits an object, the pixel is colored based on the nearest hit shader 310. If the ray does not hit an object, the pixel is colored based on the miss shader 312. Multiple rays may be projected for each pixel, and the final color of the pixel is determined by several combinations of colors determined for each ray of the pixel. As described elsewhere in this specification, it is possible for an individual ray to generate multiple samples, each sample indicating whether the ray hits a triangle or not. In one example, a ray is projected with four samples. Two such samples hit triangles, and two do not. Therefore, the color of a triangle contributes only partially (e.g., 50%) to the final color of a pixel, with the remaining portion of the color determined based on triangles hit by other samples, or, if no triangles are hit, by a miss shader. In some examples, rendering a scene involves projecting at least one ray onto each of multiple pixels in an image to obtain a color for each pixel. In some examples, multiple rays are projected per pixel to obtain multiple colors per pixel for a multisample rendering target. In some such examples, at some later time, the multisample rendering target is compressed through color blending to obtain a single sample image for display or further processing. While it is possible to obtain multiple samples per pixel by projecting multiple rays per pixel, techniques are provided herein for obtaining multiple samples per ray, such that multiple samples per pixel are obtained by projecting only one ray.To obtain additional samples per pixel, it is possible to perform such tasks multiple times. More specifically, it is possible to project multiple rays per pixel and obtain multiple samples per ray such that the total number of samples obtained per pixel is the product of the number of samples per ray and the number of rays per pixel.

[0024] Any of the arbitrary hit shader 306, the closest hit shader 310, and the miss shader 312 can cause a unique ray to enter the ray tracing pipeline 300 at the ray test point. These rays can be used for any purpose. One common use is to implement environmental lighting or reflections. In one example, when the closest hit shader 310 is called, the closest hit shader 310 causes rays in various directions. For each object or light hit by the caused rays, the closest hit shader 310 adds lighting intensity and color to the pixel corresponding to the closest hit shader 310. Although some examples of how to render a scene using various components of the ray tracing pipeline 300 have been described, it should be understood that any of a wide variety of techniques can alternatively be used.

[0025] As described above, determining whether a ray hits an object is referred to herein as a “ray crossing test.” A ray crossing test involves emitting a ray from a starting point, determining whether the ray hits a triangle, and if so, determining the distance from the starting point to the triangle hit. To improve efficiency, ray tracing tests use a spatial representation called a boundary volume hierarchy, which is the “accelerated structure” described above. In a boundary volume hierarchy, each non-leaf node represents an axis-aligned bounding box that borders the geometry of all of its children. In one example, a base node represents the maximum extent of the entire region where ray crossing tests are being performed. In this example, the base node has two children, each representing a mutually exclusive axis-aligned bounding box that subdivides the entire region. Each of those two children has two child nodes, each representing an axis-aligned bounding box that subdivides the space of its parent, and so on. Leaf nodes represent triangles on which ray tests can be performed.

[0026] The boundary volume hierarchical data structure allows for a reduction in the number of ray-triangle intersections (which is complex and therefore expensive in terms of processing resources) compared to scenarios where such a data structure is not used and therefore all triangles in the scene must be tested for rays. Specifically, if a ray does not intersect a particular bounding box, and that bounding box borders a large number of triangles, all triangles within that box can be excluded from testing. Thus, ray intersection testing is performed as a series of tests of rays against axis-aligned bounding boxes, followed by testing for triangles.

[0027] Figure 4 shows an example of a boundary volume hierarchy. For simplicity, the hierarchy is shown in 2D. However, it should be understood that the extension to 3D is straightforward, and the tests described herein are generally performed in three dimensions.

[0028] The spatial representation 402 of the boundary volume hierarchy is shown on the left side of Figure 4, and the tree representation 404 of the boundary volume hierarchy is shown on the right side of Figure 4. In both the spatial representation 402 and the tree representation 404, non-leaf nodes are represented by the letter "N", and leaf nodes are represented by the letter "O". Ray crossing tests are performed by traversing through the tree 404, and for each non-leaf node tested, if the box test for that non-leaf node fails, the branch below that node is eliminated. For leaf nodes that are not eliminated, a ray-triangle crossing test is performed to determine whether the ray intersects the triangle at that leaf node. For non-leaf nodes that are not eliminated, the ray crossing test intersects the ray with such non-eliminated node to determine whether the child of such node is eliminated from consideration. For eliminated leaf or non-leaf nodes, the ray crossing test does not perform a ray crossing test with such node. In short, to perform cross-testing for rays, the ray tracing pipeline 300 starts with one or more initial non-leaf nodes and tests one or more of those non-leaf nodes for intersection with the ray. The ray tracing pipeline 300 traverses the edges of the boundary volume hierarchy, testing non-leaf nodes for the ray and deciding whether to exclude or not exclude the children of those nodes. For leaf nodes that the ray tracing pipeline 300 encounters, it tests the ray against such nodes to determine whether the ray intersects with the geometry associated with such leaf nodes.

[0029] In one example, the ray intersects O5 but not with any other triangles. The test is performed on N1 and determined to be successful. The test is performed on N2 and determined to be a failure (because O5 is not in N1). Note that this test eliminates all subnodes of N2 and is performed on N3, which is successful. Note that this test is performed on N6 and N7, and N6 is successful but N7 is a failure. Note that this test is performed on O5 and O6, and O5 is successful but O6 is a failure. Instead of performing eight triangle tests, two triangle tests (O5 and O6) and five box tests (N1, N2, N3, N6, N7) are performed.

[0030] As described herein, non-leaf nodes are associated with bounding boxes that define the geometry of their children. Leaf nodes are associated with the geometry of the scene in which rays are tested. Various geometry types can exist. Some exemplary geometry types for leaf nodes are triangles and procedural geometry, but this is not an exhaustive list. Procedural geometry is a geometry in which intersection with a ray is defined procedurally rather than as data. More specifically, procedural geometry represents a geometry associated with a leaf node in which a ray is tested to determine whether it hits the geometry of such a leaf node. In the process of traversing the bounding volume hierarchy, when the ray tracing pipeline 300 encounters a leaf node with an associated procedural geometry, the ray tracing pipeline 300 triggers the execution of a procedure, such as one specified in the shader program (or by other means), to determine whether the ray intersects with that procedural geometry. Thus, testing for intersection with a procedure is procedurally defined.

[0031] Figure 5 is a block diagram of an example of an accelerating structure cross-section stage 500. In some embodiments, the accelerating structure cross-section stage 304 in Figure 3 is the accelerating structure cross-section stage 500 in Figure 5.

[0032] The accelerating structure crossing stage 500 includes a crossing unit 502 and an intersecting unit 504. The crossing unit 502 accepts a request to test rays for intersection with geometric shapes in the scene. The crossing unit 502 crosses the nodes of the accelerating structure 506, requests node data from the accelerating structure 506, obtains the node data, and requests that the intersecting test be performed by the intersecting unit 504. The intersecting unit 504 performs the requested intersecting test to the crossing unit 502 and returns the results of the intersecting test to the crossing unit 502.

[0033] In one example, the crossing unit 502 receives a ray to test its intersection with the geometry of the scene represented by the accelerating structure 506. The crossing unit 502 reads a first non-leaf node from the accelerating structure 506 (in one example, N2 of the boundary volume hierarchy 404 in Figure 4) and requests the intersection unit 504 to test the ray against the geometry of that node. The intersection unit 504 performs the test and returns the test result to the crossing unit. The result shows that the ray does not intersect the box and therefore excludes the child of the non-leaf node from consideration. Subsequently, the crossing unit 502 reads another non-leaf node from the accelerating structure 506 (in one example, N3) and requests the intersection unit 504 to test the ray against the geometry of that node. The intersection unit 504 performs the test and returns the test result to the crossing unit 502. The test results show that the ray intersects with the box associated with that node, and therefore the transverse unit 502 continues to test the children of its non-leaf nodes (nodes N6 and N7 in this example).

[0034] In various embodiments, the crossing unit 502 and the intersection unit 504 are implemented as software, hardwired circuitry, or a combination thereof, running on a programmable processor. In one exemplary embodiment, the crossing unit 502 is a shader program (crossing shader program) running on one or more computing units 132. The intersection unit 504 is a dedicated hardware circuit configured to perform intersection tests, such as ray-triangle and ray-box intersection tests. The crossing shader program executes instructions of an instruction set architecture, including at least one instruction to request the intersection unit 504 to perform intersection tests on rays. In some embodiments, for procedural geometry, the crossing shader program triggers the execution of a set of instructions for testing rays against the procedural geometry. In other embodiments, the crossing unit 502 is a hardwired circuitry unit performing the operations described herein.

[0035] In some situations, a culling request entity, such as an application, or one of the shader programs or hardware units described herein, requests that certain types of geometry be culled from the scene. Culling means that geometry exists in the scene but is not rendered. With respect to a boundary volume hierarchy, the geometry to be culled is the geometry specified by (or associated with) a leaf node. During ray crossing tests for rays, including traversing the boundary volume hierarchy and testing rays against nodes in the boundary volume hierarchy, the traversing unit 502 considers geometry to be culled as not intersecting the ray.

[0036] In various situations, one or more culling entities request that a specific geometric shape type be culled. In these situations, the ray tracing pipeline 300 culls all geometric shapes of the requested type. In some embodiments, the types of geometric shapes that can be culled include opaque geometric shapes, non-opaque geometric shapes, triangles, or procedural geometric shapes.

[0037] During ray crossing testing, a specific leaf node geometry can be culled by noting that the geometry is of the type that the culling requesting entity requested to be culled, and accordingly determining that rays do not intersect that geometry without performing ray crossing testing on that geometry. More specifically, the ray tracing pipeline 300 determines that the culled geometry should not be rendered. Similarly, if rays do not intersect a geometry, that geometry is not rendered. Therefore, the determination that a geometry should be culled has the same effect as the determination that the geometry does not intersect a ray.

[0038] In addition, in certain situations, a non-leaf node can be culled based on the determination that all of its descendants have a type that one or more culling request entities have requested to be culled. For example, all of a box node's children are opaque, and the culling request entities have requested that opaque geometric shapes be culled. In such situations, it is possible to cull such a non-leaf node by treating it as non-intersecting, without performing an actual cross-test, or even if such a cross-test determines that a ray intersects with the non-leaf node.

[0039] Figure 6A is a block diagram of a boundary volume hierarchy 600 that includes type metadata within non-leaf nodes to enable early culling of boundary volume hierarchy nodes, as an example. The boundary volume hierarchy 600 includes non-leaf nodes 602 and leaf nodes 606. Non-leaf node 602 contains child type metadata 604, and leaf node 606 is associated with leaf node type data 608.

[0040] The leaf node type data 608 indicates the type of the associated leaf node 606. As described elsewhere in this specification, in some embodiments, the type includes aspects such as the geometric shape of the leaf node (e.g., triangular or procedural) and whether the leaf node is opaque or opaque. Any other leaf node type is possible. In one example, the leaf node includes arbitrary application-defined masking information. In one example, such masking information defines different layers in rendering, such as foreground and background objects. In such an example, the node is either background or foreground, and the type includes either background or foreground. Other similar application-defined type information may also be used.

[0041] The child type metadata 604 associated with a non-leaf node 602 indicates whether each leaf node descendant of the non-leaf node 602 has a particular leaf node type. More specifically, the child type metadata 604 of a given non-leaf node 602 indicates, for one or more leaf node types, whether each leaf node descendant of that given non-leaf node 602 has that leaf node type. The first node is a descendant of the second node in either the situation where the first node is a child of the second node, or the situation where the first node is a child of a descendant of the second node.

[0042] Referring together to Figures 5 and 6A, in operation, the accelerating structure crossing stage 500 crosses a boundary volume hierarchy (e.g., boundary volume hierarchy 600) in response to the requirement to test rays for intersections in the following manner: The crossing unit 502 obtains information indicating which one or more leaf node types should be culled. In one example, such information includes whether to cull triangles, procedural geometry, opaque geometry, or non-opaque geometry.

[0043] Upon receiving information about which of one or more leaf node types should be culled and which rays should be tested for crossing, the crossing unit 502 traverses the boundary volume hierarchy. The crossing unit 502 provides the crossing unit 504 with information about which leaf node types should be culled. The crossing unit 502 traverses the boundary volume hierarchy, starting from a specific node under consideration (e.g., the top-level node). For any specific node under consideration, the crossing unit 502 sends a request to the crossing unit 504 to test for crossing of a ray or with that node, and the crossing unit 504 performs the test and returns the result to the crossing unit 502. For a non-leaf node 602, if the result from the crossing unit 504 indicates that the ray does not cross with the non-leaf node 602, the crossing unit 502 does not consider any of its children (where "consider" means testing for crossing with a ray). If the intersection unit 504 indicates that a ray intersects with a non-leaf node 602, the crossing unit 502 is permitted (and will do so in certain circumstances) to consider the children of that non-leaf node 602. Note that the intersection unit 504 may not consider such children for other reasons, such as terminating the crossing of the boundary volume hierarchy early. In the case of leaf nodes 606, the results of the intersection test are used for rendering purposes in any technically feasible manner, such as by determining the color of the pixel or determining the illumination contribution to the pixel.

[0044] For a non-leaf node 602 having metadata 604 that matches at least one type of culling, the intersection unit 504 returns the result that the ray does not intersect the non-leaf node 602, even if geometrically the ray would actually intersect the non-leaf node 602. More specifically, if metadata 604 indicates that all leaf node descendants of a non-leaf node 602 have a certain type and that culling occurs for leaf nodes of that particular type, the intersection unit 504 indicates to the crossing unit 502 that no intersection occurs for that non-leaf node 602. This behavior occurs because if all descendants of a non-leaf node 602 are culled, there is no reason to consider any of its descendants.

[0045] As described above, the crossing unit 504 receives information on which leaf node types should be culled and reports the crossing test results to the crossing unit 502 based on that information; however, in other embodiments, the crossing unit 502 does not provide such information to the crossing unit 504. In such embodiments, the crossing unit 502 examines metadata 604 for non-leaf nodes 602 to determine whether the non-leaf nodes 602 should be treated as not intersecting with the rays. In some embodiments, the crossing unit 502 and the crossing unit 504 are the same entity.

[0046] It should be noted that no specific order is described for traversing the boundary volume hierarchy 600. This is because it is possible to traverse the boundary volume hierarchy 600 in any technically feasible order. The acceleration structure simply supports the elimination of specific nodes in the boundary volume hierarchy through testing against non-leaf nodes 602.

[0047] Figure 6B shows an exemplary boundary volume hierarchy 650 containing type metadata 604 within a non-leaf node 602. The illustrated metadata and type data are for illustrative purposes only and should not be construed as limiting. The metadata "(none)" for the non-leaf node 602 indicates that there are no triangle types among the available triangle types that are shared among all descendant leaf nodes 606 of the non-leaf node 602.

[0048] In this example, there are eight leaf nodes 606, namely 606(11) to 606(18). Leaf node 606(11) has triangular and opaque type data 608(11). Leaf node 606(12) has triangular and opaque type data 608(12). Leaf node 606(13) has triangular and opaque type data 608(13). Leaf node 606(14) has procedural and opaque type data 608(14). Leaf node 606(15) has triangular and opaque type data 608(15). Leaf node 606(16) has triangular and opaque type data 608(16). Leaf node 606(17) has procedural and opaque type data 608(17). Leaf node 606(18) has procedural and opaque type data 608(18).

[0049] Non-leaf node 602(13) includes metadata 604(13) indicating that each descendant of non-leaf node 602(13) shares the “triangle” type. These descendants do not share the “opaque” or “non-opaque” type, so that information is not included in metadata 604(13). Non-leaf node 602(14) includes metadata 604(14) indicating that type data is not shared among all descendants of non-leaf node 602(14). Non-leaf node 602(15) includes metadata 604(15) indicating that each leaf node descendant of non-leaf node 602(15) has “triangle” and “opaque” type data 608. Non-leaf node 602(16) includes metadata 604(16) indicating that each leaf node descendant of non-leaf node 602(16) has “procedural” and “opaque” type data. A non-leaf node 602(11) includes metadata 604(11) indicating that there are no leaf node types shared among all of the leaf node descendants of the non-leaf node 602(11). A non-leaf node 602(12) includes metadata 604(12) indicating that all of the leaf node descendants of the non-leaf node 602(12) have the leaf node type "opaque".

[0050] In one example, the accelerating structural crossing stage 500 culls triangles during operation. In such an example, the accelerating structural crossing stage 500 does not perform ray crossing tests on any descendants of non-leaf node 602(13) or non-leaf node 602(15). In another example, the accelerating structural crossing stage 500 culls opaque geometry. In such an example, the accelerating structural crossing stage 500 does not perform ray crossing tests on any descendants of non-leaf node 602(12). In yet another example, the accelerating structural crossing stage 500 culls opaque geometry and triangles. In such an example, the accelerating structural crossing stage 500 does not perform ray crossing tests on any descendants of non-leaf node 602(12) or non-leaf node 602(13).

[0051] Figure 7 is a flowchart of a method 700 for performing ray tracing operations, as an example. While the systems described in Figures 1 to 6B are used, those skilled in the art will understand that any system configured to perform the steps of method 700 in any technically feasible order is within the scope of this disclosure.

[0052] Method 700 describes the steps for considering a specific non-leaf node 602, which is used during traversing the boundary volume hierarchy. Thus, Method 700 begins with the accelerated structure traversal stage 500 considering a single non-leaf node 602 of the boundary volume hierarchy.

[0053] In step 702, the accelerated structure crossing stage 500 reads the descendant shared type metadata 604 for the non-leaf node 602. In various examples, this metadata 604 is stored in the same data structure as other information for the boundary volume hierarchy, or it is stored separately as "side-band" information. The metadata indicates whether any particular leaf node type is shared among all leaf node descendants of the non-leaf node 602, and if so, which leaf node types are shared.

[0054] In step 704, the accelerated structure crossing stage 500 determines one or more culling types for ray crossing testing. More specifically, the accelerated structure crossing stage 500 obtains information about which types of leaf nodes should be culled, for example, from an application, shader program, or hardware unit. In some examples, this information is obtained before the accelerated structure crossing stage 500 begins traversing the boundary volume hierarchy.

[0055] In step 706, the accelerated structure crossing stage 500 determines whether to treat a non-leaf node as not intersecting based on whether one or more culling types include at least one type of the descendant shared type metadata. If metadata 604 includes at least one type to be culled, the accelerated structure crossing stage 500 determines that none of the children of the non-leaf node 602 should be crossed. In some embodiments, the accelerated structure crossing stage 500 treats the non-leaf node 602 as not intersecting with the ray, even if the geometry of the ray actually intersects with the geometry associated with the non-leaf node 602. If metadata 604 does not include any types to be culled, the accelerated structure crossing stage 500 performs a normal ray-box cross test and proceeds with the accelerated structure crossing as normal (for example, if the cross test determines that the ray intersects with the non-leaf node 602, it considers the child nodes of the non-leaf node 602, or if the cross test determines that the ray does not intersect with the non-leaf node 602, it excludes those child nodes from consideration).

[0056] Each illustrated unit represents a hardware circuit configured to perform the operations described herein, software configured to perform the operations described herein, or a combination of software and hardware configured to perform the steps described herein. For example, the accelerating structure crossing stage 304 may be implemented entirely in hardware, entirely in software running on a processing unit (e.g., computing unit 132), or as a combination thereof. In some examples, the accelerating structure crossing stage 304 may be implemented partially in hardware and partially in software. In some examples, a portion of the accelerating structure crossing stage 304 that crosses the boundary volume hierarchy may be software running on a processor, while a portion of the accelerating structure crossing stage 304 that performs ray-box crossing and ray-triangle crossing tests may be implemented in hardware. In addition, any stage of the ray tracing pipeline 300 may, in various embodiments, be implemented as hardware circuitry, software running on a processor, or a combination thereof. In addition, any unit in Figure 1 or Figure 2 may, in various embodiments, be implemented as hardware circuitry, software running on a processor, or a combination thereof. When a particular stage of the ray tracing pipeline 300 is said to be "invoked," this invocation involves either performing hardware functionality if the stage is implemented as hardware circuitry, or executing a shader program (or other software) if the stage is implemented as a shader program that runs on the processor.

[0057] It should be understood that many modifications are possible based on the disclosures herein. Although features and elements are described above in specific combinations, each feature or element can be used alone without other features and elements, or in various combinations with or without other features and elements.

[0058] The provided method can be implemented in a general-purpose computer, processor, or processor core. Suitable processors include, by example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines. Such processors can be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data such as netlists (such instructions can be stored in a computer-readable medium). The results of such processing may also be maskwork, which is used in a subsequent semiconductor manufacturing process to manufacture a processor that implements an aspect of the embodiment.

[0059] The methods or flowcharts provided herein can be implemented in computer programs, software, or firmware embedded in a non-temporary computer-readable storage medium for execution by a general-purpose computer or processor. Examples of non-temporary computer-readable storage media include read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROM disks and digital versatile disks (DVDs)).

Claims

1. A method for performing ray tracing operations, Reading descendant share type metadata for non-leaf nodes in a boundary volume hierarchy, In a ray crossing test, determine one or more culling types, The process includes determining whether to treat the non-leaf node as not intersecting the ray, based on whether the one or more culling types include at least one type specified by the descendant shared type metadata, method.

2. The one or more culling types include at least one type specified by the descendant shared type metadata, Determining whether to treat the non-leaf node as not intersecting includes determining that the non-leaf node is not intersecting. The method according to claim 1.

3. The one or more culling types mentioned above do not include the types specified by the descendant shared type metadata. Determining whether to treat the non-leaf node as not intersecting includes determining whether to treat the non-leaf node as not intersecting, The method according to claim 1.

4. The aforementioned one or more culling types include one or more of the following: triangles, procedural geometric shapes, opaque geometric shapes, and non-opaque geometric shapes. The method according to claim 1.

5. Treating the non-leaf node as not intersecting includes generating an index that the non-leaf node does not intersect with the ray, The method according to claim 1.

6. The further includes transmitting the indicator to the crossing unit in response to the crossing unit requesting to test the ray for crossing to the non-leaf node, The method of claim 5.

7. The crossing unit is configured to run a crossing shader program that requires testing the rays for crossing to the non-leaf nodes as part of the ray crossing test. The method according to claim 6.

8. The process further includes performing the read operation and the determination operation for multiple nodes of the boundary volume hierarchy while traversing the boundary volume hierarchy. The method according to claim 1.

9. The crossing test of the ray for a non-leaf node that is determined not to intersect with the non-leaf node further includes omitting the consideration of the children of the non-leaf node. The method of claim 8.

10. It is a system, Accelerating structural cross-sectional stage, Equipped with memory, The aforementioned acceleration structure crossing stage is Reading descendant share type metadata for non-leaf nodes in a boundary volume hierarchy, In a ray crossing test, determine one or more culling types, Determining whether to treat the non-leaf node as not intersecting the ray based on whether the one or more culling types include at least one type specified by the descendant shared type metadata, It is configured to do the following: The aforementioned memory is It is configured to store at least a portion of the boundary volume hierarchy, system.

11. The one or more culling types include at least one type specified by the descendant shared type metadata, Determining whether to treat the non-leaf node as not intersecting includes determining that the non-leaf node is not intersecting. The system according to claim 10.

12. The one or more culling types mentioned above do not include the types specified by the descendant shared type metadata. Determining whether to treat the non-leaf node as not intersecting includes determining whether to treat the non-leaf node as not intersecting, The system according to claim 10.

13. The aforementioned one or more culling types include one or more of the following: triangles, procedural geometric shapes, opaque geometric shapes, and non-opaque geometric shapes. The system according to claim 10.

14. Treating the non-leaf node as not intersecting includes generating an index that the non-leaf node does not intersect with the ray, The system according to claim 10.

15. The aforementioned acceleration structure crossing stage is The system is further configured to transmit the indicator to the crossing unit in response to the crossing unit requesting to test the ray for crossing to the non-leaf node. The system according to claim 14.

16. The crossing unit is configured to run a crossing shader program that requires testing the rays for crossing to the non-leaf nodes as part of the ray crossing test. The system according to claim 15.

17. The aforementioned acceleration structure crossing stage is The system is further configured to perform the reading and determination for multiple nodes of the boundary volume hierarchy while traversing the boundary volume hierarchy. The system according to claim 10.

18. The aforementioned acceleration structure crossing stage is The crossing test of the light ray with respect to a non-leaf node that is determined not to intersect with the non-leaf node is further configured to omit considering the children of the non-leaf node. The system according to claim 17.

19. A computer-readable storage medium for storing instructions, When the aforementioned instruction is executed by the processor, Reading descendant share type metadata for non-leaf nodes in a boundary volume hierarchy, In a ray crossing test, determine one or more culling types, Determining whether to treat the non-leaf node as not intersecting the ray based on whether the one or more culling types include at least one type specified by the descendant shared type metadata, The processor is made to perform the following: Computer-readable storage medium.

20. The one or more culling types include at least one type specified by the descendant shared type metadata, Determining whether to treat the non-leaf node as not intersecting includes determining that the non-leaf node is not intersecting. A computer-readable storage medium according to claim 19.

Images