Compressing leaf nodes of a bounding volume hierarchy

Abstract

Techniques are provided for performing ray tracing operations that include identifying triangles to include in a compressed triangle block, storing data common to the identified triangles as common data of the compressed triangle block, and storing data specific to the identified triangles as specific data of the compressed triangle block.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to pending U.S. patent application Ser. No. 18 / 081,387, filed Dec. 14, 2022, the entire contents of which are incorporated herein by reference. [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 explanation 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. [Figure 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. [Figure 3] FIG. 1 illustrates a ray tracing pipeline for rendering graphics using ray tracing techniques, according to an example. [Figure 4] FIG. 1 is an illustration of a bounding volume hierarchy, according to an example. [Figure 5] FIG. 1 illustrates a system for generating a bounding volume hierarchy using compressed triangle data, according to an example. [Figure 6] FIG. 2 illustrates an exemplary compression operation. [Figure 7] FIG. 1 illustrates an exemplary compressed triangular block. [Figure 8] 1 is a flow diagram of a method for compressing triangles for BVH, according to an example. DETAILED DESCRIPTION OF THE INVENTION

[0005] Techniques are provided for performing ray tracing operations that include identifying triangles to include in a compressed triangle block, storing data common to the identified triangles as common data of the compressed triangle block, and storing data specific to the identified triangles as specific data of the compressed triangle block.

[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 also optionally includes an input driver 112 and an output driver 114. It should be understood that device 100 may include additional components not shown in FIG. 1 .

[0007] In various alternatives, processor 102 includes 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, memory 104 is located on the same die as processor 102 or is located separately from processor 102. Memory 104 may include volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache).

[0008] The storage devices 106 include fixed or removable storage devices (e.g., hard disk drives, solid state drives, optical disks, flash drives). The 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). The output devices 110 include, but are not limited to, a display device 118, a speaker, a printer, a haptic feedback device, one or more optics, an antenna, or a network connection (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. Note that the input driver 112 and the output driver 114 are optional components, and that the device 100 operates in the same manner without the input driver 112 and the output driver 114 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 computational and graphic rendering commands from the processor 102, process the computational and graphic rendering commands, and provide output pixels to the display device 118 for display. As described in further detail below, APD 116 includes one or more parallel processing units configured to perform computations according to the single-instruction-multiple-data (SIMD) paradigm. Accordingly, although various functions are described herein as being performed by or in conjunction with APD 116, in various alternatives, functions described as being performed by APD 116 are additionally or alternatively performed by other computing devices having similar capabilities that are not driven by a host processor (e.g., processor 102) and that are configured to provide (graphical) output to 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] 2 is a block diagram of device 100 showing additional details regarding the execution of processing tasks on APD 116. Processor 102 maintains, within 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 an application programming interface (API) for 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 unit 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 commands and programs for selected functions, such as graphics and non-graphics operations 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 commands 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 commands received from processor 102.

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

[0013] The basic unit of execution in compute unit 132 is the work item. Each work item represents a single instantiation of a program executing in parallel on a particular lane. Work items may execute simultaneously as a "wavefront" on a single SIMD processing unit 138. One or more wavefronts are included in a "workgroup," which includes a collection of work items designated to execute the same program. A workgroup is executed by executing each of the wavefronts that make up the workgroup. In alternative examples, wavefronts execute serially 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 execute simultaneously on a single SIMD unit 138. Thus, if commands received from processor 102 indicate that a particular program should be parallelized to the extent that the program cannot be executed simultaneously on a single SIMD unit 138, the program is divided into wavefronts that are either parallelized on two or more SIMD units 138 or serialized (or both parallelized and serialized, as appropriate) on the same SIMD unit 138. Scheduler 136 is configured to perform operations related to scheduling the various wavefronts on the different compute units 132 and SIMD units 138.

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

[0015] Computation unit 132 is also used to perform computational tasks that are not related to graphics or that are not performed as part of the "normal" operation of graphics pipeline 134 (e.g., custom operations performed to supplement the processing performed on the operation 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, which is a technique for rendering a 3D scene by testing for intersections between simulated rays and objects in the scene. Much of the work involved in ray tracing is performed by programmable shader programs running on SIMD units 138 within compute unit 132, as described in more detail below.

[0017] Figure 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 operations and entities involved in rendering a scene using ray tracing. A ray generation shader 302, an any hit shader 306, a closest hit shader 310, and a miss shader 312 are shader implementation stages that represent ray tracing pipeline stages whose functions are performed by shader programs executing within the SIMD unit 138. The specific shader programs at each specific shader implementation 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). An acceleration structure traversal stage 304 performs ray intersection tests to determine whether a ray hits a triangle.

[0018] 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 SIMD unit 138. Acceleration structure traversal stage 304 is implemented as software (e.g., as a shader program executing on SIMD unit 138), as hardware, or as a combination of hardware and software. 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 shader program executing on SIMD unit 138. Ray tracing pipeline 300 may be organized partially or fully in software, or partially or fully in hardware, by processor 102, scheduler 136, by a combination thereof, or partially or fully by any other hardware and / or software unit. As used herein, the term "ray tracing pipeline processor" refers to a processor that executes software to perform the operations of the ray tracing pipeline 300, a hardwired hardware circuit to perform the operations of the ray tracing pipeline 300, or a combination of hardware and software that together perform the operations of the ray tracing pipeline 300.

[0019] The ray tracing pipeline 300 operates as follows: A ray generation shader 302 is executed, which sets up ray data to test against triangles and calls upon an acceleration structure traversal stage 304 to test the ray for intersection with the triangle.

[0020] The acceleration structure traversal stage 304 traverses an 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 a hit, the ray tracing pipeline 300 can trigger the execution of any hit shader 306. Note that multiple triangles may be hit by a single ray. The acceleration structure traversal stage is not guaranteed to traverse the acceleration structure in order from closest to the ray origin to 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 ray origin that the ray hits, or triggers a miss shader if the triangle was not hit. Intersection shaders can be used to determine whether a ray intersects with a non-triangle leaf node. More specifically, intersection shaders provide a customizable way to define intersections with geometry at leaf nodes.

[0021] Note that either the hit shader 306 or the intersection shader can "reject" a hit from the ray intersection test unit 304; thus, the hit or miss unit 308 triggers the execution of the miss shader 312 if the 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 the triangle reporting the hit to the ray intersection test unit 304 is completely transparent. Because the ray intersection test unit 304 tests only geometry and not transparency, any hit shader 306 that is invoked for a hit on a triangle that has at least some transparency may determine that the reported hit is not actually a hit because it "hit" a transparent portion of the triangle. A typical use of the closest 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 a color set by a skybox. It should be understood that the shader programs defined for the closest hit shader 310 and miss shader 312 may implement a wide variety of techniques for coloring pixels and / or performing other operations.

[0022] A typical way that the ray generation shader 302 generates rays is using a technique called backward ray tracing. In backward ray tracing, the ray generation shader 302 generates rays that originate at the camera's location. The point at which the ray intersects a plane defined to correspond to the screen defines a pixel on the screen that is used to determine the ray's 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 pixel's final color is determined by some combination of the colors determined for each of the pixel's rays. As described elsewhere herein, each ray can generate multiple samples, with each sample indicating whether the ray hits a triangle or not. In one example, a ray is cast with four samples: two such samples hit the triangle and two do not. Thus, the color of a triangle only partially contributes (e.g., 50%) to the final color of a pixel, with the other portion of the color being determined based on triangles hit by other samples or by a miss shader if the triangle is not hit. In some examples, rendering a scene involves casting at least one ray for each of multiple pixels of an image to obtain a color for each pixel. In some examples, multiple rays are cast per pixel to obtain multiple colors per pixel for a multi-sample render target. In some such examples, at some later time, the multi-sample render 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 casting multiple rays per pixel, techniques are provided herein for obtaining multiple samples per ray such that multiple samples per pixel can be obtained by casting only one ray.Such a task can be performed multiple times to obtain additional samples per pixel, more specifically, multiple rays can be cast per pixel, obtaining multiple samples per ray such that the total number of samples obtained per pixel is the number of samples per ray multiplied by the number of rays per pixel.

[0023] Either the nearest hit shader 310 or the miss shader 312 can trigger their own rays that 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 ambient lighting or reflections. In one example, when the nearest hit shader 310 is invoked, it triggers rays in various directions. For each object or light hit by the triggered ray, the nearest hit shader 310 adds lighting intensity and color to the pixel corresponding to the nearest hit shader 310. While several examples of how a scene can be rendered using various components of the ray tracing pipeline 300 are described, it should be understood that any of a wide variety of techniques may alternatively be used.

[0024] As mentioned above, determining 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, how far from the origin the triangle hit is. To increase efficiency, ray tracing tests use a representation of space called a bounding volume hierarchy. This bounding volume hierarchy is the "acceleration structure" mentioned above. In a bounding volume hierarchy, each non-leaf node represents an axis-aligned bounding box that bounds the geometry of all of that node's children. In one example, a 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, each representing a mutually exclusive axis-aligned bounding box that subdivides the entire region. Each of those two children has two child nodes that represent axis-aligned bounding boxes that subdivide their parent's space, and so on. Leaf nodes represent triangles for which ray testing may be performed. It should be understood that when a first node points to a second node, the first node is considered to be the parent of the second node.

[0025] 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 a scene need to be tested against 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.

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

[0027] A spatial representation 402 of the bounding volume hierarchy is shown on the left side of Figure 4, and a tree representation 404 of the bounding 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." 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, the branch below that node is eliminated. For leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node.

[0028] In one example, the ray intersects O5 but not any other triangles. The test tests against N1 and determines that the test succeeds. In this example, the test tests against N2 and determines that the test fails. Note that the test eliminates all subnodes of N2 and tests against N3, which also succeeds. Note that the test tests N6 and N7, and N6 succeeds but N7 fails. Note that the test tests O5 and O6, and 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, N7) are performed. Note that rays can have various directions and can have origins in various locations. Therefore, the particular boxes that are or are not excluded depend on the origin and direction of the ray. However, testing a ray for intersection with a box generally eliminates some leaf nodes from consideration.

[0029] As described above, a bounding volume hierarchy includes many leaf nodes (node ​​"O" in FIG. 4). The data of these leaf nodes generally contains a large amount of redundant information and can therefore be compressed. In one example, triangles that share a parent node are geometrically close to each other, so such triangles generally include numerically similar coordinates. In one example, the x-coordinates of triangles that are close to each other have the same set of most significant bits. In another example, triangles have the same or similar associated primitive or geometry identifiers. A primitive identifier is an identifier that uniquely identifies a triangle, and a geometry identifier is an identifier that uniquely identifies a set of triangles that define one item of geometry. Thus, triangles may be grouped together in a compression unit, with common primitive and / or common geometry identifiers represented once, and differences between these values ​​represented with far fewer bits than the entire value. In another example, coordinates often have zeros in their least significant bits, such as with highly discretized geometry. Thus, these zeros can be represented by a single value indicating the number of zeros, rather than storing each zero as raw data. These and other techniques have the potential to significantly reduce the amount of data stored for the BVH.

[0030] 5 illustrates a system 500 for generating a bounding volume hierarchy using compressed triangle data, according to an example. The system 500 includes a BVH compressor 503 that accepts input data 501 and generates output data having compressed data. In various examples, the BVH compressor 503 is part of the BVH builder or is external to the BVH builder. In some examples where the BVH compressor 503 is external to the BVH builder, the BVH builder utilizes the BVH compressor 503 at some point during the generation of the BVH.

[0031] The BVH compressor 503 may be embodied as software running on a processor, as hardware (e.g., circuitry such as fixed-function circuitry and / or other types of circuitry), or as a combination of software and hardware running on a processor (e.g., a combination of software operating in cooperation with fixed-function hardware). In some examples, the BVH compressor 503 accepts a bounding volume hierarchy that has already been generated and compresses triangles in the BVH to generate a BVH that includes compressed triangle data. In other examples, the BVH compressor 503 accepts triangles that have not yet been incorporated into a BVH and compresses that data. In one example, the BVH compressor 503 accepts a geometrically sorted triangle list and compresses the triangles in the list to generate a compressed triangle list.

[0032] In some examples, the BVH data compressor 503 is included in the same system as the ray tracing pipeline 300 of Figure 3. In other examples, the BVH data compressor 503 is included in a different system. In some examples, the BVH data compressor 503 compresses triangle data for a scene being rendered, for example, with each frame, periodically, or at various times in conjunction with rendering using ray tracing.

[0033] The BVH data compressor 503 generates compressed triangle data as output data 502 based on the input triangle data 501. In some examples, the BVH data compressor 503 (or another entity) sorts the triangles before compressing them. In some examples, sorting includes sorting by Morton code. A Morton code is a single value generated from multiple coordinate values ​​of a three-dimensional vertex. In some examples, the Morton code is generated by interleaving the bits of the vertex coordinate values. In one example, the Morton code for a coordinate includes the most significant bit of the x-coordinate of the point, followed by the most significant bit of the y-coordinate of the point, followed by the most significant bit of the z-coordinate of the point, followed by the second most significant bit of the x-coordinate of the point, followed by the second most significant bit of the y-coordinate of the point, followed by the second most significant bit of the z-coordinate of the point, etc. In some examples, the number of bits for each dimension of the Morton code is the same, and in other examples, the number of bits is different for one or all dimensions. In some examples, a Morton code is generated for the centroid of a triangle. Because Morton codes are used, sorting based on Morton codes places coordinates that are similar in all dimensions close together in the sort order, resulting in a relatively large amount of common data in the most significant bits. The BVH data compressor 503 generates compressed triangle blocks by identifying triangles that are grouped together in such blocks, identifying common data for such triangles, and storing the common data and unique data as compressed triangle blocks. Additional details are now provided.

[0034] An exemplary compression operation is shown in Figure 6. In this example, the BVH data compressor 503 compresses triangle 603 of the input data 501 to generate a compressed triangle block 608 that includes compressed triangle 606. Although triangle 603 is shown as part of the BVH before being received by the BVH data compressor 503 in Figure 6, the BVH data compressor 503 may compress the triangle data prior to, or at least partially in parallel with, the generation of the BVH for those triangles.

[0035] The compression operation includes grouping triangles 603 into compressed triangle blocks 608. The BVH data compressor 503 generates the compressed triangle blocks 608 by identifying triangles 603 to be grouped together in the compressed triangle blocks 608 and storing common and unique data for each compressed triangle block 608. The BVH data compressor 503 may identify which triangles 603 to include together in the compressed triangle block 608 in any technically feasible manner. In some examples, the compressed triangle blocks 608 have a maximum size. In such examples, the BVH data compressor 503 limits the number of triangles included in each compressed triangle block 608 to not exceed that maximum size.

[0036] Each generated compressed triangle block 608 contains triangles pointed to by one or more box nodes 602. In other words, there is not necessarily a direct correspondence between how triangles are contained within a box node 602 and how triangles 606 are compressed into a compressed triangle block 608. In the example of FIG. 6, box node 1 602(1) has child compressed triangle 1 606(1) and child compressed triangle 2 606(2), which are part of compressed triangle block 608(1). Box node 2 602(2) has child compressed triangle 3 606(3) and child compressed triangle 4 606(4). Compressed triangle 3 606(3) is part of a different compressed triangle block 608(1) from compressed triangle 4 606(4), which is part of compressed triangle block 608(2). Thus, it can be seen that box node 2 602(2) has a child node that is part of a different compressed triangle block 608. Furthermore, compressed triangle block 608(1) has a compressed triangle 606 that is a child of a different box node 602. As can be seen, the BVH data compressor 503 generates compressed triangle block 608 from triangle 603 without reference to the location of triangle 603 within the BVH, because compressed triangle block 606 can contain compressed triangles that are children of different box nodes 602, and because box node 602 can have children that are in different compressed triangle blocks 608.

[0037] 7 illustrates an exemplary compressed triangle block 606. The compressed triangle block 606 includes common data 702 and unique data 704. The common data includes data common to all compressed triangles 606 in the compressed triangle block 606. The unique data 704 includes data unique to each triangle, such as unique data for triangle 1 706(1), unique data for triangle 2 706(2), etc. The data stored in the common data 702 and unique data 704 depends on the particular compression technique used. Several compression techniques are described below.

[0038] In the common prefix deduplication technique, the BVH data compressor 503 identifies a common prefix for each of the triangles 606 in the compressed triangle block 608. The BVH data compressor 503 stores the common prefix in the common data 702, and the specific data needed for reconstruction for each triangle is stored in the specific data 704. The prefix is ​​a set of the most significant bits of the triangle 706. In some examples, the BVH data compressor 503 includes a prefix for each coordinate axis (e.g., x, y, z) based on the fact that the coordinate values ​​of the triangle vertices on each axis are likely to be similar. In summary, the BVH data compressor 503 applies compression for the common prefix deduplication technique by determining, for each axis, the prefixes that are common among all vertices of all triangles in the compressed triangle block 606. The BVH data compressor 503 stores each such common prefix in the common data 702. The BVH data compressor 503 also stores other data for each triangle 706 required for decompression as specific data. Note that this specific data does not necessarily include all data other than the prefix, because the BVH data compressor 503 may apply additional compression techniques to that data. For decompression, the decompressor (e.g., acceleration structure traversal stage 304) generates the decompressed coordinate value by combining the common prefix data with other decompressed data for the coordinate value.

[0039] The common prefix size can vary between compressed triangle blocks 608. It is also possible to store multiple prefixes within a single compressed triangle block 608, along with an index for each triangle 706 indicating which prefix is ​​used for that triangle 706. In some embodiments, the second prefix is ​​not explicitly stored, but a single bit or other short value is stored to indicate whether to increment the stored common prefix by one. This single additional bit provides some additional precision for the stored common prefix and also allows flexibility in prefix storage, such as when values ​​within the compressed triangle block 608 straddle the origin and therefore vary between small negative and small positive numbers. Adding this additional bit allows for representing both positive and negative values ​​within the compressed triangle block 608, since positive and negative numbers have different prefixes, but positive numbers can be reconstructed by adding small increments to negative numbers. Decompressing a compressed triangle block 608 that includes this additional increment bit involves modifying the prefix as indicated by the increment bit (e.g., either incrementing or not incrementing based on the increment value) and combining the resulting value with other information derived from the unique data 704 and other common data 702.

[0040] In the trailing zero deduplication technique, the BVH data compressor 503 stores, for each coordinate axis value for each vertex of each triangle, a number indicating how many zeros are included in the trailing (least significant) bits of the coordinate axis value. For example, for the first vertex of the first triangle, the BVH data compressor 503 stores that the x coordinate has five trailing zeros, the y coordinate has seven trailing zeros, and the z coordinate has six trailing zeros. The BVH data compressor 503 includes this information in the unique triangle data 706 for each triangle. The decompressor decompresses this information by combining a specified number of zeros into the end of the decompressed value based on the common data 702 and other unique data 704 for the triangle, and based on the compression technique used.

[0041] Another technique is for compression of primitive identifiers (primitive IDs) and geometry identifiers (geometry IDs). A primitive ID is an identifier uniquely associated with a primitive (triangle). A geometry ID is an identifier uniquely associated with an item of geometry. An item of geometry is a geometry shape composed of one or more primitives. In some examples, each primitive (e.g., a triangle) has a primitive ID and a geometry ID. In some examples, the sorted list of triangles 602 to which compression is applied has a contiguous set of primitive IDs and geometry IDs. More specifically, the list is sorted according to certain parameters, and the primitive IDs and geometry IDs are effectively sorted in the sort order of the list. Thus, for any given compressed triangle block 608, the primitive IDs are consecutive and monotonically increasing. Vertices of the same triangle have the same primitive ID, and consecutive triangles in the sorted list have the same or very similar geometry IDs. In one example, in compressed triangle block 608(1), compressed triangle 1 606(1) and compressed triangle 2 606(2) have the same geometry ID, and compressed triangle 3 606(3) has a geometry ID that is one after the geometry ID of compressed triangle 2 606(2). A compression technique for primitive and geometry IDs is to store a base primitive ID and base geometry ID in common data 702 and store an offset from the base in each unique triangle data 706. The offset for a particular triangle 706 is a value that, when added to the base in common data 702, results in the primitive or geometry ID for that particular triangle 706. In some examples, an offset is not stored for the first triangle 706 in compressed triangle block 606 because the base primitive ID and base geometry ID implicitly indicate the primitive ID and geometry ID for that triangle.Decompressing the primitive ID and geometry ID information for a triangle represented by compressed triangle block 606 includes adding an offset associated with triangle 706 to a base for compressed triangle block 606 associated with triangle 706. The primitive ID and geometry ID information is used by ray tracing pipeline 300 to perform rendering. In one example, the primitive ID indicates which material to apply to a surface.

[0042] In another exemplary technique, the BVH data compressor 503 compresses the "midfixes" of triangle coordinate values. The midfix follows the prefix (most significant bits) but is a portion before the final value. Similar to prefix deduplication, the BVH data compressor 503, in some examples, stores in common data 702 a common midfix that is common to all coordinate values ​​(e.g., all x-values) that share an axis of the triangles 606 within the compressed triangle block 606. Decompression for such a technique involves generating coordinate values ​​for the particular vertices and axes that have the common midfix stored in common data 702. In some examples, the BVH data compressor 503 deduplicates any data for the triangles using the described deduplication technique. In such examples, the BVH data compressor 503 stores in common data 702 identical portions of data that have identical portions for each triangle in the compressed triangle block 608. The decompressor recovers the data for the triangles by combining the common data with other data generated by the decompression process.

[0043] In some examples, the BVH data compressor 503 stores the difference between the geometry of the current frame and the geometry of the previous frame, in addition to applying other techniques described herein, and decompression involves restoring the values ​​for the current frame by applying the difference to the geometry of the previous frame.

[0044] In some examples, the compressed triangle 606 is part of a triangle strip. A triangle strip is a set of triangles in which at least some of the triangles share vertices. To conserve space for triangle strips, the BVH data compressor 503 defines each triangle as a set of vertex indices, indexing each triangle to a set of unique indices. The unique indices are compressed and decompressed as described herein. Triangles that share at least one vertex are defined with at least one identical index. Referencing triangle data by index reduces the amount of data to be stored compared to a scheme in which all vertex data is stored for each vertex, regardless of whether the vertices are identical. Decompression for triangles stored as a strip includes recovering vertex values ​​for the triangle by identifying the compressed vertex data based on the index, decompressing the compressed vertex data, and thereby obtaining the final decompressed vertex values ​​for the triangle.

[0045] Any entity in device 100, such as acceleration structure traversal stage 304, applies the decompression described herein. The described compression and decompression schemes can be applied to various underlying data types, such as 32-bit floating point numbers, 16-bit floating point numbers, or other data types.

[0046] This disclosure contemplates the use of any combination of the compression techniques described herein.

[0047] 8 is a flow diagram of a method 800 for compressing triangles for BVH, according to an example. Although described with respect to the systems of FIGS. 1-7, one skilled in the art will understand that any system configured to perform the steps of method 800 in any technically feasible order is within the scope of the present disclosure.

[0048] In step 802, the BVH data compressor 503 identifies sets of triangles 602 to include together in a compressed triangle block 608. The compressed triangle block 608 contains data about triangles 602 that are similar in at least some respects, so that deduplication can be achieved for the common data 702. In some examples, the triangles 602 identified in step 802 are consecutive in a list of triangles that has been sorted by Morton code or some other factor. In some examples, the number of selected triangles 602, when compressed, will fit within a fixed amount of data.

[0049] In step 804, the BVH data compressor 503 stores data common to the identified triangles of the compressed triangle block as common data 702 for the compressed triangle block. Examples of common data are described herein. Some such examples include a common prefix, a common midfix, a primitive ID base, and a geometry ID base. A common prefix is ​​a prefix that is common to all coordinate components for a particular coordinate axis for the triangles of the compressed triangle block 608. In one example, all x-values ​​for all vertices in the compressed triangle block 608 have the same prefix. The BVH data compressor 503 stores this prefix in the common data 702 and does not store the information in the specific data 704. Other examples relating to other types of common data 702 are described herein.

[0050] In step 806, the BVH data compressor 503 stores data that is unique to the identified triangle as unique data for the compressed triangle block 608. This unique data is data that is not common to the triangles in the compressed triangle block 608 and is therefore not stored in the common data 702. In the common prefix technique, the unique data is data other than the common prefix. In one example, the unique data is the data that follows the prefix (i.e., the unique data includes bits less significant than the most significant bit that defines the prefix). In some examples, each item of triangle unique data 706 in the unique data 704 of the compressed triangle block 606 includes unique values ​​for the x-axis, y-axis, and z-axis of a triangle vertex. In examples where the trailing zeros column deduplication technique is used, the unique data includes the number of zeros in the least significant bits. In examples where separate compression of geometry IDs and primitive IDs is used, the unique data 704 stores, for each triangle, an offset from the base geometry ID and an offset from the base primitive ID.

[0051] It should be appreciated that the advantage of information stored as common data is that the amount of data represented by the common data is reduced in the compressed triangle block 606 compared to a scheme in which the common data is stored once for each triangle.

[0052] After compressing the triangles, an entity such as the acceleration structure traversal stage 304 decompresses the triangle data to reconstruct the triangles and performs operations using those triangles, such as testing the triangles for intersection with rays, as described elsewhere herein. Such decompression depends on the combination of compression techniques used, as described elsewhere herein. For a common prefix or midfix, the decompressor reconstructs the coordinate axis value for the vertex by combining the common prefix and / or midfix with other portions of that value derived from the common data and unique data. For a trailing zero string, the decompressor reconstructs the coordinate axis value for the vertex by generating the indicated number of zeros, along with other portions of that value derived from the common data and unique data. For separate compression of geometry IDs and primitive IDs, the decompressor increments the base value for the geometry ID or primitive ID by the offset stored for the triangle.

[0053] In some examples, decompression is applied after method 800. In one example, after geometry in a scene changes, the BVH data compressor 503 compresses triangles and the BVH builder builds the BVH if it has not already been built. During a ray tracing operation that includes testing a ray against a triangle, the ray tracing pipeline 300 traverses the BVH to arrive at a compressed triangle 606. The ray tracing pipeline 300 decompresses the compressed triangle 606 as described herein to test the ray for intersection with the triangle.

[0054] Each of the units shown in the figure represents hardware circuitry 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 ray tracing pipeline 300, ray generation shader 302, optional hit shader 306, hit or miss unit 308, miss shader 312, nearest hit shader 310, and accelerated structure traversal stage 304 may be implemented entirely in hardware, entirely in software running on a processing unit (such as compute unit 132), or as a combination thereof. In some examples, the accelerated structure traversal stage 304 is 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.

[0055] It should be understood that many variations are possible based on the disclosure herein, and although features and elements are described above in particular 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.

[0056] 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 processors may be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data (instructions that may be stored on a computer-readable medium), including a netlist. The result of such processing may be a mask work, which is then used in a semiconductor manufacturing process to produce a processor embodying aspects of the embodiments.

[0057] 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: identifying triangles to include in the compressed triangle block; storing data common to the identified triangles as common data for the compressed triangle block; storing the identified triangle specific data as specific data of the compressed triangle block. method.

2. identifying triangles that, when compressed, occupy less space than a maximum amount of space in the compressed triangle block; 10. The method of claim 1.

3. Box nodes in the bounding volume hierarchy reference triangles within multiple compressed triangle blocks.

10. The method of claim 1.

4. the common data includes one or more of common prefix data, common midfix data, a geometry identifier base value, and a primitive identifier base value; 10. The method of claim 1.

5. the data specific to the identified triangle includes a value indicating the number of trailing zeroes, a primitive identifier offset, and a geometry identifier offset; 10. The method of claim 1.

6. decompressing the compressed triangle blocks to generate decompressed triangles.

10. The method of claim 1.

7. testing whether a ray intersects the decompressed triangle; The method of claim 6.

8. the compressed triangle block includes data for two triangles that share at least one vertex, and each triangle of the two triangles includes a set of indices that reference vertex data; 10. The method of claim 1.

9. the triangles in the compressed triangle block are consecutive triangles in the sorted triangle list for the scene; 10. The method of claim 1.

10. 1. A system for performing ray tracing operations, comprising: a memory configured to store the compressed data; a processor configured to perform operations for compressing the bounding volume hierarchy; The operation is identifying triangles to be included in the compressed triangle block for storage in memory; storing data common to the identified triangles as common data for the compressed triangle block; storing the identified triangle specific data as specific data of the compressed triangle block. system.

11. identifying triangles that, when compressed, occupy less space than a maximum amount of space in the compressed triangle block; The system of claim 10.

12. Box nodes in the bounding volume hierarchy reference triangles within multiple compressed triangle blocks. The system of claim 10.

13. the common data includes one or more of common prefix data, common midfix data, a geometry identifier base value, and a primitive identifier base value; The system of claim 10.

14. the data specific to the identified triangle includes a value indicating the number of trailing zeroes, a primitive identifier offset, and a geometry identifier offset; The system of claim 10.

15. the operations include decompressing the compressed triangle blocks to generate decompressed triangles; The system of claim 10.

16. The operations include testing whether a ray intersects the decompressed triangle.

16. The system of claim 15.

17. the compressed triangle block includes data for two triangles that share at least one vertex, and each triangle of the two triangles includes a set of indices that reference vertex data; The system of claim 10.

18. the triangles in the compressed triangle block are consecutive triangles in the sorted triangle list for the scene; The system of claim 10.

19. 1. A computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform operations, comprising: The operation is identifying triangles to be included in the compressed triangle block for storage in memory; storing data common to the identified triangles as common data for the compressed triangle block; storing the identified triangle specific data as specific data of the compressed triangle block. A computer-readable storage medium.

20. identifying triangles that, when compressed, occupy less space than a maximum amount of space in the compressed triangle block; 20. The computer-readable storage medium of claim 19.

Images