STACK-based ray traversal with dynamic multi-node iteration

By dynamically adjusting the number of nodes tested in each iteration based on the completion of wavefront work items, the technique enhances cross-test parallelization and utilization of acceleration structure traversal units in ray tracing, addressing inefficiencies in existing methods.

JP2025510454APending Publication Date: 2025-04-15ADVANCED MICRO DEVICES INC +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024535893
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2022-06-20
Filing Date
2023-02-22
Publication Date
2025-04-15

AI Technical Summary

Technical Problem

Existing ray tracing techniques face inefficiencies in cross-test parallelization, particularly when non-terminated work items are encountered, leading to reduced utilization of acceleration structure traversal units.

Method used

The technique involves increasing cross-test parallelization for non-terminated work items by detecting when the cross-stage work items of a wavefront threshold number have ended, and subsequently adjusting the number of nodes tested in each iteration to maximize utilization of the crossing unit.

Benefits of technology

This approach enhances the utilization of crossing units by converting parallelism across work items into parallelism within work items, thereby improving the efficiency of ray tracing operations.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025510454000001_ABST
    Figure 2025510454000001_ABST
Patent Text Reader

Abstract

Techniques are provided for performing ray tracing operations that include increasing intersection test parallelism of non-finished work items in response to detecting that a threshold number of traversal stage work items of a wavefront have finished.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 322,082, filed March 21, 2022, entitled "STACK-BASED RAY TRAVERSAL WITH DYNAMIC MULTIPLE-NODE ITERATIONS," and U.S. Provisional Patent Application No. 17 / 844,677, filed June 20, 2022, entitled "STACK-BASED RAY TRAVERSAL WITH DYNAMIC MULTIPLE-NODE ITERATIONS," the entireties of which are incorporated by reference herein as if fully set forth herein. [Background technology]

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

[0003] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of an example device that may implement one or more features of the present disclosure. [Diagram 2] 2 is a block diagram of the accelerated processing device of FIG. 1 illustrating additional details regarding the execution of processing tasks on the device, according to an example. [Diagram 3] FIG. 1 illustrates a ray tracing pipeline for rendering graphics using ray tracing techniques, according to one example. [Figure 4] FIG. 2 illustrates a bounding volume hierarchy, according to an example. [Diagram 5] FIG. 2 is a block diagram of an acceleration structure traversal stage, according to an example. [Figure 6] This figure illustrates reducing intersection utilization as work items of a traversal shader program finish. [Figure 7] FIG. 13 illustrates an increase in intersection utilization after a decrease in utilization associated with the termination of a traverse shader program. [Figure 8] FIG. 1 illustrates a single test mode for traversing a bounding volume hierarchy. [Figure 9] FIG. 13 illustrates a dual test mode for traversing a bounding volume hierarchy. [Figure 10] 1 is a flow diagram of a method for performing a ray tracing operation, according to an example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] Techniques are provided for performing ray tracing operations that include increasing intersection test parallelism for non-terminating work items in response to detecting that a threshold number of traversal stage work items of a wavefront have terminated.

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

[0007] In various alternatives, the processor 102 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a CPU and a 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 may be separate from the processor 102. The memory 104 may include volatile or non-volatile memory (e.g., Random Access Memory (RAM), Dynamic Random Access Memory (RAM), cache).

[0008] Storage 106 includes fixed or removable storage devices (e.g., hard disk drives, solid state drives, optical disks, flash drives). Input devices 108 include, but are not limited to, a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals). Output devices 110 include, but are not limited to, a display device 118, a speaker, a printer, a haptic feedback device, one or more optical, antennae, or network connections (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, allowing 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, allowing the processor 102 to send output to the output device 110. It should be noted that the input driver 112 and the output driver 114 are optional components, and that the device 100 operates in the same manner when 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 a display device 118. The APD 116 is configured to accept computational and graphics rendering instructions from the processor 102, process the computational and graphics rendering instructions, and provide pixel output to the display device 118 for display. As described in further detail below, the APD 116 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 APD 116, in various alternative examples, functions described as being performed by the APD 116 are additionally or alternatively performed by other computing devices having similar capabilities that are not driven by a host processor (e.g., the processor 102) and that are configured to provide (graphical) output to the display device 118. For example, it is contemplated that any processing system that performs processing tasks according to the SIMD paradigm may be configured to perform the functions described herein. Alternatively, it is contemplated that computing systems that do not perform processing tasks according to the SIMD paradigm perform the functions described herein.

[0010] FIG. 2 is a block diagram of device 100 showing additional details regarding the execution of processing tasks on APD 116. Processor 102 maintains, in system memory 104, one or more control logic modules for execution by processor 102. The control logic modules include operating system 120, drivers 122, and applications 126. These control logic modules control various aspects of the operation of processor 102 and APD 116. For example, operating system 120 communicates directly with hardware and provides an interface to the hardware for other software executing on processor 102. Driver 122 controls the operation of APD 116, for example, by providing application programming interfaces ("APIs") to software executing on processor 102 (e.g., applications 126) to access various features of APD 116. In some embodiments, driver 122 includes a just-in-time compiler that compiles programs for execution by processing components of APD 116 (such as SIMD units 138, described in more detail below). In other embodiments, a just-in-time compiler is not used to compile the programs, and a regular application compiler compiles the shader programs for execution on the APD 116.

[0011] APD 116 executes instructions and programs for selected functions, such as graphics and non-graphics processing, that are suitable for parallel and / or out-of-order processing. APD 116 is used to perform graphics pipeline operations, such as pixel processing, geometry calculations, and rendering of images to display device 118, based on instructions received from processor 102. APD 116 also performs computational operations not directly related to graphics processing, such as operations related to video, physics simulation, computational fluid dynamics, or other tasks, based on instructions received from processor 102.

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

[0013] The basic unit of execution within the compute units 132 is a work item. Each work item represents a single instantiation of a program that executes in parallel on a particular lane. Work items may execute simultaneously as a "wavefront" on a single SIMD unit 138. One or more wavefronts are included in a "work group," which includes 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 the alternative, a wavefront executes sequentially on a single SIMD unit 138, or partially or fully in parallel on different SIMD units 138. Although a wavefront may be considered a collection of work items that may execute simultaneously on a single SIMD unit 138, it is also possible to divide a wavefront into sets of work items that each execute simultaneously on a single SIMD unit 138. The scheduler 136 is configured to handle operations related to scheduling the various wavefronts on different compute units 132 and SIMD units 138.

[0014] The parallel processing provided by the compute units 132 is well suited to graphics-related operations such as pixel value calculations, vertex transformations, and other graphics operations. Thus, in some cases, a graphics pipeline 134, which accepts graphics processing instructions from the processor 102, provides computational tasks to the compute units 132 for execution in parallel.

[0015] Computation units 132 are also used to perform computational tasks that are not related to graphics or that are not performed as part of the "normal" processing of graphics pipeline 134 (e.g., custom processing performed to supplement processing performed to that of graphics pipeline 134). Applications 126 or other software executing on processor 102 send programs defining such computational tasks to APD 116 for execution.

[0016] Compute unit 132 performs ray tracing, a technique for rendering a 3D scene by testing intersections between simulated rays and objects in the scene. Much of the work involved in ray tracing is performed by programmable shader programs executing on SIMD units 138 within compute unit 132, as described in more detail below.

[0017] FIG. 3 illustrates a ray tracing pipeline 300 for rendering graphics using ray tracing techniques, according to an example. The ray tracing pipeline 300 provides an overview of the processes and entities involved in rendering a scene utilizing ray tracing. In some embodiments, the ray generation shader 302, any hit shader 306, closest hit shader 310, and miss shader 312 are shader execution stages that represent ray tracing pipeline stages whose functions are performed by shader programs executing within the SIMD units 138. Any of the specific shader programs at each specific shader execution stage are defined by application-provided code (i.e., by code provided by the application developer that is pre-compiled by the application compiler and / or compiled by the driver 122). In other embodiments, any of the ray generation shaders 302, any hit shaders 306, nearest hit shaders 310, and miss shaders 312 are implemented as software running on any type of processor and performing the operations described herein, circuitry performing the operations described herein, or a combination of hardware circuitry and software running on a processor. The acceleration structure traversal stage 304 performs ray intersection tests to determine whether a ray hits a triangle.

[0018] Ray tracing pipeline 300 refers to the path through which the ray tracing process flows. To render a scene using ray tracing, a rendering orchestrator, such as a program executing on processor 102, specifies a collection of geometric shapes as a "scene." 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 a scene. The rendering orchestrator renders the scene by specifying a camera position and an image, and requesting that rays be traced from the camera through the image. Ray tracing pipeline 300 performs various processes described herein to determine the color of the rays. Ray tracing pipeline 300 assigns colors to pixels of the image based on the results of the ray tracing process for rays traced through the image. For example, a ray that strikes a green triangle and passes through a particular screen location in the image may cause the pixel corresponding to that screen location to be colored green.

[0019] The color is often derived from the triangle that the ray intersects. As described elsewhere herein, rays that do not hit a triangle invoke the miss shader 312. One possible operation of the miss shader 312 is to color the ray with a color from a "skybox," which is an image that is specified as representing the surrounding scene in which no geometry exists (e.g., a scene without geometry renders only the skybox). The color of a pixel in the image is determined based on the intersection point between the ray and the image location. In some examples, after a sufficient number of rays have been traced and the pixels of the image assigned colors, the image is displayed on a screen or used in some other manner.

[0020] In some embodiments in which the shader stages of the ray tracing pipeline 300 are implemented in software, the various programmable shader stages (ray generation shader 302, any hit shader 306, nearest hit shader 310, miss shader 312) are implemented as shader programs executing on the SIMD unit 138. The acceleration structure traversal stage 304 is implemented in software (e.g., as a shader program executing on the SIMD unit 138), in 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 of the other units, or as a hardware accelerated structure, or as a shader program executing on the SIMD unit 138. The ray tracing pipeline 300, in various embodiments, may be partially or fully in software, or partially or fully in hardware, organized by the processor 102, the scheduler 136, by a combination of these, or partially or fully by any other hardware and / or software units. In one example, the traversal through the ray tracing pipeline 300 is performed partially or completely by the scheduler 136, either autonomously or under control of the processor 102, or partially or completely by a shader program (such as a bounding volume hierarchy traversal shader program) executing on one or more of the SIMD units 138. In some examples, testing rays against boxes and triangles (inside the accelerated structure traversal stage 304) is hardware accelerated (meaning that a fixed function hardware unit performs those testing steps). In other examples, such testing is performed by software, such as a shader program, executing on one or more of the SIMD units 138.As used herein, when the phrase "the ray tracing pipeline does [an action]" is used, it means that the hardware and / or software implementing the ray tracing pipeline 300 performs that action. Although illustrated as being executed on the SIMD unit 138 of FIG. 3, it should be understood that in other embodiments, other hardware (e.g., processor 102), with or without SIMD capabilities, may alternatively execute the shader programs of the illustrated ray tracing pipeline 300.

[0021] The ray tracing pipeline 300 operates in the following manner: A ray generation shader 302 is executed, which sets up data for rays to test against triangles in the scene and calls upon an acceleration structure traversal stage 304 to test the ray for intersecting with a triangle.

[0022] The acceleration structure traversal stage 304 traverses the acceleration structure, which is a data structure that describes the scene volume and objects (such as triangles) in the scene, and tests the ray against triangles in 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 triangles that are hit, the ray tracing pipeline 300 triggers the execution of any hit shaders 306. Note that multiple triangles may be hit by a single ray. It is not guaranteed that the acceleration structure traversal stage traverses the acceleration structure in order from closest to the ray origin to furthest 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 ray origin that the ray hits, or triggers a miss shader if the triangle was not hit.

[0023] Any hit shader 306 may "reject" a hit from the ray intersection test unit 304, and thus the hit or miss unit 308 triggers the execution of a miss shader 312 if a hit is not found or accepted by the ray intersection test unit 304. An exemplary situation in which any hit shader 306 may "reject" a hit is when at least a portion of a triangle that reports to the ray intersection test unit 304 as having been hit is completely transparent. Because the ray intersection test unit 304 only tests geometry and not transparency, any hit shader 306 that is invoked for a hit to a triangle that has at least some transparency may determine that the reported hit is not actually a hit because it was "hitting" a transparent portion of the triangle. A typical use of the closest hit shader 310 is to color a material based on the texture of the material. A typical use of the miss shader 312 is to color a pixel with a color set by a skybox. It should be understood that the closest hit shader 310 and miss shader 312 may implement a wide variety of techniques for coloring pixels and / or performing other processing. When these shaders are implemented as programmable shader stages that execute shader programs, different shader programs used for the same application may color pixels in different ways.

[0024] A typical way that the ray generation shader 302 generates rays is through a technique called inverse ray tracing. In inverse ray tracing, the ray generation shader 302 generates rays that have their origin at a point on the camera. The point where the ray intersects with a plane defined to correspond to the screen ("image" above) defines a pixel on the screen where the ray is used to determine its color. If the ray hits an object, the pixel is colored based on the closest 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 cast per pixel, and the final color of the pixel is determined by some combination of the colors determined for each of the pixel's rays. As described elsewhere herein, each individual ray can generate multiple samples, with each sample indicating whether the ray hits a triangle or does not hit the triangle. In one example, the ray is cast with four samples. Two such samples hit the triangle and two do not. Thus, the color of the triangle only partially contributes (e.g., 50%) to the final color of the pixel, with the other portion of the color being determined based on the triangles hit by other samples, or by a miss shader if the triangle is not hit. In some examples, rendering the scene involves casting at least one ray for each of multiple pixels of the image to obtain a color for each pixel. In some examples, for multisample render targets, multiple rays are cast per pixel to obtain multiple colors per pixel. In some such examples, at some later time, the multisample render target is compressed through color blending to obtain a single sample image for display or further processing.

[0025] Any of the hit shaders 306, the nearest hit shader 310, and the miss shader 312 may spawn their own rays that enter the ray tracing pipeline 300 at the ray test points. These rays may be used for any purpose. One common use is to perform environmental lighting or reflections. In one example, when the nearest hit shader 310 is called, it spawns rays in various directions. For each object or light that is hit by the spawned ray, the nearest hit shader 310 adds lighting intensity and color to the pixel that corresponds to the nearest hit shader 310. Although several examples of how the various components of the ray tracing pipeline 300 may be used to render a scene are described, it should be understood that any of a wide variety of techniques may alternatively be used.

[0026] As mentioned above, the determination of whether a ray hits an object is referred to herein as a "ray intersection test." A ray intersection test involves firing a ray from an origin and determining whether the ray hits a triangle, and if so, what is the distance from the origin of the triangle hit. To increase efficiency, the ray tracing test uses a representation of space referred to as a bounding volume hierarchy. This bounding volume hierarchy is the "acceleration structure" described above. In an exemplary bounding volume hierarchy, each non-leaf node represents an axis-aligned bounding box that bounds the geometry of all of the node's children. In one example, the base node represents the maximum extent of the entire region over which ray intersection testing is performed. In this example, the base node has two children that each represent mutually exclusive axis-aligned bounding boxes that sub-divide the entire region. Each of those two children has two child nodes that represent axis-aligned bounding boxes that sub-divide their parent's space, and so on. The leaf nodes represent triangles over which ray testing may be performed.

[0027] The bounding volume hierarchical data structure allows the number of ray-triangle intersections (which are complex and therefore expensive in terms of processing resources) to be reduced compared to a scenario in which such a data structure is not used and therefore all triangles in the scene need to be tested for the ray. Specifically, if a ray does not intersect with a particular bounding box and that bounding box bounds a large number of triangles, all triangles within that box may be eliminated from testing. Thus, ray intersection testing is performed as a series of tests of the ray against axis-aligned bounding boxes, followed by tests against the triangles.

[0028] 4 is a diagram illustrating a bounding volume hierarchy, according to an example. For simplicity, the hierarchy is shown in 2D. However, it should be understood that extension to 3D is straightforward, and the tests described herein are generally performed in three dimensions.

[0029] A spatial representation 402 of the bounding volume hierarchy is shown on the left side of FIG. 4, and a tree representation 404 of the bounding volume hierarchy is shown on the right side of FIG. 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". A ray intersection test is performed by traversing through the tree 404, and for each non-leaf node tested, if the box test for that non-leaf node fails, eliminate the branch below that node. For non-eliminated leaf nodes, a ray-triangle intersection test is performed to determine whether a ray intersects a triangle at that leaf node. For non-eliminated non-leaf nodes, the ray intersection test intersects rays with such non-eliminated nodes to determine whether children of such nodes should be eliminated from consideration. For excluded leaf or non-leaf nodes, the ray intersection test does not perform a ray intersection test with such nodes. In brief, to perform an intersection test for a ray, the ray tracing pipeline 300 begins with one or more starting non-leaf nodes and tests one or more of those non-leaf nodes for intersection with the ray. The ray tracing pipeline 300 follows the edges of the bounding volume hierarchy, tests the non-leaf nodes for the ray, and either excludes or does not exclude the children of those nodes. For any leaf nodes that the ray tracing pipeline 300 encounters, the ray tracing pipeline 300 tests the ray against such nodes to determine whether the ray intersects with the geometry associated with such leaf nodes.

[0030] In one example, the ray intersects O5 but not any other triangle. A test tests against N1 and determines that the test succeeds. A test tests against N2 and determines that the test fails (because O5 is not in N1). Note that the test eliminates all subnodes of N2 and tests against N3 and that test succeeds. A test tests N6 and N7 and note that N6 succeeds but N7 fails. A test tests O5 and O6 and note that O5 succeeds but O6 fails. Instead of testing eight triangle tests, two triangle tests (O5 and O6) and five box tests (N1, N2, N3, N6, and N7) are performed.

[0031] As described herein, non-leaf nodes are associated with bounding boxes that bound the geometry of the children of those non-leaf nodes. Leaf nodes are associated with scene geometry against which rays are tested. There may be a variety of geometry types. Some exemplary geometry types for leaf nodes are triangles and procedural geometry, but this is not an exhaustive list. Procedural geometry is geometry whose intersection with a ray is defined procedurally, rather than as data. More specifically, procedural geometry is associated with a leaf node and represents geometry against which rays are tested to determine whether the ray hits the geometry of such leaf node. In the process of traversing the bounding volume hierarchy, in response to the ray tracing pipeline 300 encountering a leaf node with an associated procedural geometry, the ray tracing pipeline 300 triggers the execution of a procedure, such as one specified in a shader program (or via other means), to determine whether the ray intersects with the procedural geometry. Thus, the test for crossover with the procedure is procedurally defined.

[0032] 5 is a block diagram of an acceleration structure traversal stage 500, according to an example. In some embodiments, the acceleration structure traversal stage 304 of FIG. 3 is the acceleration structure traversal stage 500 of FIG.

[0033] The acceleration structure traversal stage 500 includes a traversal unit 502 and an intersection unit 504. The traversal unit 502 accepts requests to test rays for intersection with geometry in a scene. The traversal unit 502 traverses nodes of the acceleration structure 506, requests node data from the acceleration structure 506, obtains node data, and requests an intersection test to be performed by the intersection unit 504. The intersection unit 504 performs the requested intersection test for the traversal unit 502 and returns the result of the intersection test to the traversal unit 502. Although specific hardware configurations (the traversal unit 502 and the intersection unit 504) are shown, the processing described as being performed by these units may be performed by any hardware, software, or combination of hardware and software.

[0034] In one example, the traversal unit 502 receives a ray to test for intersection with the geometry of the scene represented by the acceleration structure 506. The traversal unit 502 reads a first non-leaf node from the acceleration structure 506 (in one example, N2 from the bounding volume hierarchy 404 of FIG. 4) and requests that the intersection unit 504 test the ray against the geometry of that node. The intersection unit 504 performs that test and returns the test result to the traversal unit. The result indicates that the ray does not intersect with the box, thus eliminating the children of the non-leaf node from consideration. The traversal unit 502 subsequently reads another non-leaf node from the acceleration structure 506 (in one example, N3) and requests that the intersection unit 504 test the ray against the geometry of that node. The intersection unit 504 performs that test and returns the test result to the traversal unit 502. The test result indicates that the ray intersects the box associated with that node, so traversal unit 502 continues to test the children of that non-leaf node (in this example, nodes N6 and N7).

[0035] In various embodiments, the traversal unit 502 and the intersection unit 504 are implemented as software running on a programmable processor, hardwired circuitry, or a combination thereof. In an exemplary embodiment, the traversal unit 502 is a shader program (traversal shader program) running on one or more of the compute 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 traversal shader program executes instructions of an instruction set architecture that includes at least one instruction to request that the intersection unit 504 perform intersection tests on rays. In some embodiments, in the case of procedural geometry, the traversal shader program triggers the execution of a set of instructions to test the ray against the procedural geometry. In other embodiments, the traversal unit 502 is a hardwired circuit unit that performs the processing described herein.

[0036] As described above, in some embodiments, the traversal unit 502 traverses the bounding volume hierarchy using traversal shader programs to determine intersection information for rays. These traversal shader programs are executed in a SIMD manner in the compute units 132. Each work item is executed for a single ray. As described above, the work items are executed in parallel such that multiple work items traverse the bounding volume hierarchy for multiple rays in parallel.

[0037] Executing the traverse shader program involves executing a series of iterations. In each iteration, the traverse shader program identifies at least one node in the BVH (Bounding Volume Hierarchy) to test the ray against and requests the intersection unit 504 to test the ray against that node. If the identified node is a box node and it is determined that the ray intersects with that node, the traverse shader program identifies children of the box as nodes to test in subsequent iterations and requests that the ray be tested against those children in subsequent iterations. If a hit is detected against a leaf node, the intersection unit 504 triggers execution of the appropriate shader program, as described with respect to FIG. 3.

[0038] To the extent possible, the traverse shader program executes in “lockstep” in a SIMD manner, with each work item representing a different ray. More specifically, performing ray tracing involves testing multiple rays against the scene and coloring pixels according to the results of such tests. The multiple rays are parallelized in a SIMD manner, and the work of testing such rays against the scene is performed as multiple wavefronts. In one example, the traverse shader program identifies nodes to be tested in parallel for each work item (and thus each ray) of the wavefront, requests that intersection tests be performed in parallel by intersection unit 504, and performs other processing in parallel. Thus, intersection unit 504 has a particular capacity, in that intersection unit 504 can perform a particular number of intersection tests over a particular period of time. The acceleration structure traversal stage 304 is considered to have a higher occupancy rate if the acceleration structure traversal stage 304 is performing a greater number of intersection tests within a given time, and is considered to have a lower occupancy rate if the acceleration structure traversal stage 304 is performing a lesser number of intersection tests within a given time.

[0039] Work items executing traverse shaders as a wavefront may finish execution at different times. This is due to the nature of ray tracing and BVH traversal. More specifically, intersection tests may be specified to finish at various points. For example, some intersection tests may be specified to finish after any hit with a leaf node occurs, other intersection tests may be specified to finish after the nearest hit with a leaf node occurs, and other variations are possible. These different modes, and the fact that different rays point in different directions and therefore intersect with different geometry, mean that different rays require a different number of iterations through the traverse shader before completing. This fact means that as a wavefront executing traverse shaders advances, the intersection unit 504 may have lower and lower utilization. More specifically, as more work items finish, fewer intersection tests are required at the intersection unit 504, resulting in lower utilization of the intersection unit 504.

[0040] FIG. 6 illustrates the difference in utilization as a wavefront executing a traverse shader progresses, according to one example. SIMD utilization 602 shows work items (abbreviated as "WI") proceeding to completion. Each work item corresponds to an arrow, and the endpoint of the arrow corresponds to the end of execution of the work item. It can be seen that the utilization of the intersection unit decreases as more work items proceed to completion. As work items complete, the intersection unit 504 is used less. The space not occupied by work item bars in the intersection unit utilization graph 604 corresponds to idle time for the intersection unit 504.

[0041] FIG. 7 illustrates a technique for improving intersection unit 504 utilization, according to one example. In FIG. 7, when SIMD utilization falls below a threshold 706 (e.g., below 50%), the traverse shader switches to wide mode. In wide mode, each work item increases intersection unit utilization such that the total utilization of intersection unit 504 increases. In some examples, the threshold is 50% and the work items increase intersection unit utilization by 2x (e.g., each work item requests twice as many intersection tests to be performed). The term "SIMD utilization" refers to the ratio of the number of work items of a wave front that are still running to the number of work items that the wave front has started. The SIMD utilization for a wave front decreases as threads of the wave front terminate. In FIG. 7, when two of the four work items terminate (indicated by the threshold), work item 2 and work item 3 request twice as many intersection tests. The term "utilization of the intersection unit 504" may be used herein. This term refers to the utilization of hardware resources used to perform intersection tests. In some examples, a SIMD unit contains a certain number of copies of such hardware resources, and as work items finish, more of those hardware resources become idle. It can be seen that SIMD utilization graph 702 indicates that work-item 1 and work-item 4 finish. At this point, intersection unit utilization graph 704 indicates that work-item 2 and work-item 3 increase the utilization of intersection unit 504.

[0042] In some examples, the work item increases the intersection unit utilization by increasing the number of ray intersection tests per iteration. More specifically, in some examples, the traverse shader performs a series of iterations. In each iteration, the traverse shader fetches a node from a node data structure that represents a set of acceleration structure nodes that are ready for testing and tests the ray for intersection with the node. If the node is a box node and the ray intersects with the box node, the traverse shader places all children of the box node into the node data structure. If the node is a box node and the ray does not intersect with the box node, the traverse shader does not modify the node data structure. In the case of a ray intersection test against a non-leaf node, the traverse shader performs processing depending on the intersection testing mode for the traverse shader. For example, if the mode is one that terminates after any hit is detected, the traverse shader terminates execution after detecting a hit with a leaf node. If the mode is to determine the closest hit, the traverse shader terminates execution after a hit with a leaf node if the traverse shader determines that a closest hit has been found. In some cases, the traverse shader terminates after determining that no hit with a leaf node has occurred. If the traverse shader has not terminated after the intersection test has been performed and there are still nodes in the node data structure, the traverse shader returns to the beginning of the iteration and repeats these steps. If there are no nodes remaining in the data structure, the traverse shader terminates.

[0043] In some examples, the traverse shader increases the usage of the intersection unit 504 after the number of finished work items reaches a threshold by increasing the number of nodes tested for intersection with a ray in each iteration. At this point, each work item that is still running is performing multiple intersection tests in parallel. In essence, the technique converts parallelism across work items into parallelism within a work item. In other words, initially, the intersection unit 504 is used in parallel by each different work item. Thus, the intersection unit 504 performs intersection tests in parallel for different work items (and thus for different rays). After the threshold number of work items are finished, each work item exhibits some parallelism in the usage of the intersection unit 504 resulting from performing ray intersection tests for multiple nodes of the BVH in each iteration.

[0044] 8 and 9 show examples where different numbers of nodes are tested in each iteration. In FIG. 8, one node is tested in each iteration, and in FIG. 9, two nodes are tested in each iteration. The iterations are labeled with the letter I, and then with the iteration number. For example, iteration 1 is labeled I1, iteration 2 is labeled I2, and so on. In each iteration, a work item tests one node or tests multiple nodes simultaneously. In one example, testing multiple nodes simultaneously means that a work item requests intersection unit 504 to perform tests on multiple nodes in at least partially overlapping time periods. In one example, intersection unit 504 is pipelined such that if a work item requests two intersection tests to be performed on two rays in rapid succession (e.g., by executing two instructions in succession if an instruction requests intersection unit 504 to perform an intersection test), the work for the first such intersection test is still being processed in intersection unit 504 while the second intersection test is sent to intersection unit 504 for processing. Both tests then continue processing until completion in intersection unit 504. In another example, an instruction may specify multiple intersection tests simultaneously, whereby intersection unit 504 may process multiple intersection tests simultaneously. As discussed above, intersection unit 504 can process tests for multiple work items (e.g., 16) simultaneously, although this capability may be utilized by fewer work items requiring a larger number of intersection tests, as described elsewhere herein.

[0045] FIG. 8 illustrates a mode in which a work item performs a single intersection test per iteration. In iteration 1, node N1 is tested and passes, and therefore nodes N2 and N3 are placed into the node data structure. In iteration 2, node N2 is tested and passes, and therefore nodes N4 and N5 are placed into the node data structure. In iteration 3, node N3 is tested and fails. Additional iterations are not shown, but would continue in a similar pattern. As can be seen, the work item depicted in FIG. 8 performs one test per iteration and places any node that is a result of that test into the node data structure as a result of that test. Specifically, if the node is a box node and the test passes, the work item places the children of that node into the node data structure. If the node is a box node and the test fails, the work item does not place the children of that node into the node data structure.

[0046] 9 illustrates a mode in which a work item performs multiple intersection tests per iteration. In iteration 1, node N1 is tested and passes, so nodes N2 and N3 are placed into the node data structure. In iteration 2, nodes N2 and N3 are tested; N2 passes and N3 fails; so nodes N4 and N5 are placed into the node data structure. In iteration 3, nodes N4 and N5 are tested and both pass; so nodes O1, O2, O3, and O4 are placed into the node data structure.

[0047] It should be appreciated that Figure 8 illustrates a processing mode before the wavefront has not yet reached a threshold amount of utilization (and thus each work item is performing work for one intersection test in each iteration). In contrast, Figure 9 illustrates a processing mode after the wavefront has reached a threshold amount of utilization, and thus each work item is performing work for multiple intersection tests in each iteration.

[0048] It can be seen that in the dual test mode of Figure 9, the utilization of the intersection unit 504 is doubled compared to the single test mode of Figure 8. Thus, switching to the mode shown in Figure 9 improves the utilization of the intersection unit 504 after the total utilization of the workgroup decreases beyond a threshold.

[0049] The processes described herein may violate the determinism requirement of certain graphics rendering application programming interfaces. Here, "determinism" means that given the same ray and BVH, the same result will occur. Determinism can potentially be violated because the order of traversals through the BVH depends on whether double-test or single-test mode is being executed, and which test is used may change while the traversal shader is running. To ensure determinism, the following rules are applied. First, if an iteration places a box node and a triangle node from the same parent node into the node data structure, the triangle node must be placed into the node data structure such that it is popped out of the data structure before the box node. In an example where the node data structure is a stack, the box node is pushed onto the stack, and then the triangle node is pushed onto the stack. Second, if an iteration obtains a triangle node after obtaining any number of box nodes, the iteration should not test the triangle, or any nodes obtained after the triangle, for intersection. In effect, the above rules perform a depth first testing of the triangle nodes, which ensures determinism.

[0050] Although a mode of testing two nodes per iteration is described, it should be understood that a mode of testing more than two nodes per iteration (such as four or eight) is alternatively or additionally contemplated. In some examples, instead of one threshold, multiple thresholds are used, such as two or three. For example, when the number of running work items drops to half the total, two nodes are tested per iteration. When the number of running work items drops to a quarter of the total, four nodes are tested per iteration, and so on.

[0051] 10 is a flow diagram of a method 1000 for performing ray tracing, according to one example. Although described with respect to the systems of FIGS. 1-9, one of ordinary skill in the art will recognize that any system configured to perform the steps of method 1000 in any technically feasible order is within the scope of this disclosure.

[0052] In step 1002, the work item performs intersection tests for a first number of intersection nodes. In some examples, step 1002 represents the single test mode of FIG. 8. In some examples, the first number of intersection nodes is one. Thus, in this example, in this iteration, the work item requests one intersection test to be performed. In some examples, the work item executes in parallel with other work items in the wavefront in a SIMD manner. Thus, in this example, each work item in the wavefront performs one intersection test in an iteration. However, multiple intersection tests are being executed in parallel because the work items in the wavefront execute in parallel.

[0053] In step 1004, in response to the parallel resource utilization falling below the utilization threshold, the work items at least partially concurrently perform intersection tests for a second number of intersection nodes. The second number is greater than the first number. In some examples, the second number is two nodes. In some examples, the parallel resource utilization represents a number of work items still executing within the wavefront. In some examples, the utilization threshold represents a parallel resource utilization value that is low enough for the work items to begin performing multiple cross-validations per iteration.

[0054] The described "iterations" represent iterations of a loop or other similar iterative construct. More specifically, each work item that is still executing executes the iteration body in each iteration. When the iteration body is completed, if there are still nodes to test for intersection with the ray (e.g., if the node data structure still contains the nodes), the work item executes the next iteration with the new nodes. Thus, each work item loops, executing iterations while there are still nodes to test. After parallel resource utilization falls below a threshold, the work items that are still executing execute iterations with more ray intersection tests per iteration.

[0055] Each of the units illustrated in the figure represents a hardware circuit configured to perform the processes described herein, software configured to perform the processes described herein, or a combination of software and hardware configured to perform the steps described herein. For example, the accelerated structure traversal stage 304 may be implemented entirely in hardware, entirely in software running on a processing unit (such as the computational unit 132 of the set of computational units 202), or as a combination thereof. In some examples, the accelerated structure traversal stage 304 may be implemented partially as hardware and partially as software. In some examples, the portion of the accelerated structure traversal stage 304 that traverses the bounding volume hierarchy is software running on a processor, and the portion of the accelerated structure traversal stage 304 that performs ray-box intersection tests and ray-triangle intersection tests is implemented in hardware. Additionally, any of the stages of the ray tracing pipeline 300 may be implemented as hardware circuitry, software running on a processor, or a combination thereof, in various embodiments. Additionally, any of the units of FIG. 1 or FIG. 2 may be implemented as hardware circuits, software running on a processor, or a combination thereof, in various embodiments. When a particular stage of the ray tracing pipeline 300 is said to be "invoked," the invocation involves executing a hardware function if the stage is implemented as a hardware circuit, or executing a shader program (or other software) if the stage is implemented as a shader program running on a processor. The illustrated elements of the APD 116 of FIG. 2 (e.g., scheduler 136, graphics processing pipeline 134, compute unit 132, and SIMD unit 138) represent hardware elements, such as hardware circuits. The acceleration structure traversal stage 500 may represent hardware (e.g., circuits), software (e.g., shader programs), or a combination thereof. The acceleration structure 506 represents data in memory.

[0056] It should be understood that many variations are possible based on the disclosure herein, and although features and elements have been described above in particular combinations, each feature or element can be used alone without the other features and elements, or in various combinations, with or without the other features and elements.

[0057] The provided methods may be implemented in a general purpose computer, processor, or processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), and / or a state machine. Such a processor may be manufactured by configuring a manufacturing process using the results of processed Hardware Description Language (HDL) instructions and other intermediate data, including a netlist (instructions that may be stored on a computer readable medium). The result of such processing may be a mask work, which is then used in a semiconductor manufacturing process to manufacture a processor implementing aspects of the embodiments.

[0058] The methods or flow charts provided herein may be implemented in a computer program, software, or firmware embodied in a non-transitory computer-readable storage medium for execution by a general purpose computer or processor. Examples of non-transitory computer-readable storage media include Read Only Memory (ROM), Random Access Memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs).

Claims

1. 1. A method for performing a ray tracing operation, comprising: increasing intersection test parallelism of non-finished work items in response to detecting that a threshold number of traversal stage work items of the wavefront have finished. method.

2. Maintaining determinism by performing a depth-first boundary volume hierarchy traversal; 2. The method of claim 1.

3. increasing the intersection test parallelism includes having the non-terminated work items perform additional ray intersection tests for each intersection test iteration.

2. The method of claim 1.

4. a work item performs one intersection test per intersection test iteration before the threshold number of work items are finished; The method of claim 3.

5. an iteration of the intersection test includes an iteration of the loop executed by the work item; The method of claim 4.

6. A work item finishes when it has completed traversing the acceleration structure for ray tracing.

2. The method of claim 1.

7. increasing the crossover test parallelism includes requiring crossover test circuitry to perform a plurality of crossover tests at least partially concurrently.

2. The method of claim 1.

8. the crossover test circuitry is configured to perform a plurality of crossover tests in parallel; The method of claim 7.

9. the intersection test circuitry is pipelined; The method of claim 7.

10. 1. A system for performing ray tracing operations, comprising: A memory configured to store instructions; a processor configured to execute a wavefront; The performing increasing intersection test parallelism of non-finished work items in response to detecting that a threshold number of traversal stage work items of the wavefront have finished. system.

11. The processor, configured to maintain determinism by performing a depth-first bounding volume hierarchy traversal; The system of claim 10.

12. increasing the intersection test parallelism includes having the non-terminated work items perform additional ray intersection tests for each intersection test iteration. The system of claim 10.

13. a work item performs one intersection test per intersection test iteration before the threshold number of work items are finished; The system of claim 12.

14. an iteration of the intersection test includes an iteration of the loop executed by the work item; The system of claim 13.

15. A work item finishes when it has completed traversing the acceleration structure for ray tracing. The system of claim 10.

16. increasing the crossover test parallelism includes requiring crossover test circuitry to perform a plurality of crossover tests at least partially concurrently. The system of claim 10.

17. the crossover test circuitry is configured to perform a plurality of crossover tests in parallel; 17. The system of claim 16.

18. the intersection test circuitry is pipelined; 17. The system of claim 16.

19. 1. A computer-readable storage medium, comprising: storing instructions that, when executed by a processor, cause the processor to perform operations including, in response to detecting that a threshold number of traversal stage work items of a wavefront have finished, increasing intersection test parallelism of non-finished work items; A computer-readable storage medium.

20. The instruction: configured to cause the processor to maintain determinism by performing a depth-first bounding volume hierarchy traversal.

20. The computer readable storage medium of claim 19.