Patent ID: 12198248

DETAILED DESCRIPTION

Examples described in this disclosure relate to systems and methods with ray tracing acceleration structure level of detail processing. As noted earlier, increasingly as part of video games and other such applications the acceleration structures for ray tracing are explicitly edited or regenerated by the software to reflect the current set of potentially visible geometry. Such acceleration structures are now competing for storage (both persistent (e.g., flash memory) and non-persistent (e.g., RAM)) with other data, such as geometry and texture data. This growth in the share of the memory by the acceleration structures has resulted in systems with significantly large memory requirements. Moreover, the bandwidth required to fetch the large amount of data for acceleration structures has also proportionally gotten bigger. The systems and methods described herein help minimize the space required for ray tracing acceleration structures.

To address such problems, one solution is to have a more manageable pool of data associated with the acceleration structures. To have a more manageable pool, the acceleration structures can be managed with levels of detail for different geometry segments resident in the random access memory (RAM). This can be enhanced by letting the graphics processing unit (GPU) determine, in a current frame N, the projected size of each bounding volume in the acceleration structure that is hit by primary rays. This may need to be performed only once per bounding volume. The results of this determination may be collected in a table, or a linked list, organized by bounding volumes, where each bounding volume can be identified via a unique identifier. Software may use this list, so that it can adjust the amount of detail needed in frame N+1 for the enclosed geometry. One way this can be implemented is to let the needed level of detail (LOD) and any coarser LODs be concurrently resident in the acceleration structure pool, and by letting the software simply adjust pointers from the bounding volume to the required LOD. Another way this can be implemented is to just store the most detailed representation required; there is no downside to storing and pointing to a too-detailed LOD other than requiring unnecessary storage.

In certain examples described herein, such improvements are realized by using a residency map and a recording map to select only a subset of the acceleration structures. Initially, the residency map may be created by the CPU with one entry in the residency map per bounding volume. Each entry in the residency map may point to at least one location (e.g., via a pointer or via an index) of a level of detail for each existing sub-tree for a bounding volume in a geometry node pool created by the CPU. A sub-tree is a collection of nodes in a bounding volume hierarchy of objects. Each sub-tree may contain all of the nodes for the acceleration structure(s) corresponding to that sub-tree. Alternatively, the geometry node pool and the corresponding residency map may initially hold only entries for the coarsest levels of detail of each sub-tree. The recording map may be configured to store integer values representative of levels of detail for the nodes as determined by the GPU. The recording map may be maintained and created by the GPU to keep a record of the processing of the various sub-trees. After the completion of the processing of a frame, the recording map for that frame may be transferred to the host memory associated with the CPU. Both residency maps and recording maps may be indexed by a bounding volume ID.

In summary, a software-allocated and managed pool of resident bounding volume node data that contains the best level of detail (LOD) values for current and next frames to be shaded is created by the CPU. In one example, a process on the host CPU is used to evict unneeded sub-tree LODs (e.g., sub-tree LODs with too high a level of detail) and bring in needed sub-tree LODs from a backing store. A hardware LOD residency map with an entry per sub-tree is loaded into the GPU. The recording map maintained by the GPU is cleared to a value representing “empty,” for example to the highest possible LOD value, before every frame. The residency map clamps the needed-LOD to the value of the resident LOD (i.e., the level needed may not have been brought into the memory pool). Then the resulting clamped LOD value is used to perform the shader processing in the GPU. The LOD recording map is read back to the host (or only portions of the map that were actually used are read) after the shader has finished processing. The host (e.g., the CPU) uses this to guide the eviction/fill of the managed geometry node pool.

FIG.1shows a diagram of a system environment100including a central processing unit (CPU)102and a graphics processing unit (GPU)104with ray tracing acceleration structure level of detail processing in accordance with one example. System environment100may further include memory106, presentation component(s)108, application engine110, graphics libraries112, networking interfaces114, and I/O port(s)116, which may be interconnected via one or more busses (e.g., bus120) to each other and to CPU102and GPU104. CPU102may execute instructions stored in memory106. Memory106may be any combination of non-volatile storage or volatile storage (e.g., flash memory, DRAM, SRAM, or other types of memories). GPU104may read/write to memory106either directly or via a direct memory access (DMA) process. Presentation component(s)108may include displays, holographic devices, or other presentation devices. Displays may be any type of display, such as LCD, LED, or other types of display.

Still referring toFIG.1, application engine110may include the graphics application and graphics libraries112may include the related libraries for use with application engine110and GPU104. Network interface(s)114may include communication interfaces, such as Ethernet, cellular radio, Bluetooth radio, UWB radio, or other types of wireless or wired communication interfaces. I/O port(s)116may include Ethernet ports, Fiber-optic ports, wireless ports, or other communication or diagnostic ports. AlthoughFIG.1shows system environment100as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. As an example, system environment100may include components such as sensors and user interface components. In addition, the functionality associated with system environment100may be distributed, as needed.

FIG.2shows a diagram of a graphics processing system200with the data and the components on the CPU-side210and the data and the components on the GPU-side240with ray tracing acceleration structure level of detail processing in accordance with one example. In this example, the CPU-side210of graphics processing system200may include geometry node pool212, command list214, frame N sub-tree LOD residency map222, and frame N−1 sub-tree LOD recording map224. Geometry node pool212may be a fixed-size pool of acceleration structures related data stored in the host memory (e.g., memory106ofFIG.1) associated with the CPU (e.g., CPU102ofFIG.1).

Geometry node pool212may include a bounding volume hierarchy (BVH) having a tree structure with one or more sub-trees per node. In one example, there may be a bounding box node, pointers to child nodes, and geometry (e.g., triangles) at the leaf nodes. As an example, geometry node pool212may include sub-trees with varying levels of detail (e.g., from the most detailed level to the least detailed level). A sub-tree includes at least one bounding volume at the “root” and at least one geometry leaf node. Certain sub-trees may correspond to an intermediate level of detail. The number of triangles per leaf node may be a measure of the level of detail. The data structures for the geometry may be loaded from a bulk storage (not shown) into the host memory as part of the geometry node pool212. Once the initial objects in a scene are determined, the CPU may determine the initial bounding volume hierarchy (BVH) and build acceleration structures for the different LODs. The bounding volume hierarchy may be a tree structure with bounding box nodes, each having pointers to child nodes, and geometry at the leaf nodes. Having created the geometry node pool212, the CPU (e.g., in response to directions from application engine110ofFIG.1) may also set up a command list214for processing on the GPU-side240. Command list212may include ray tracing commands.

The CPU-side210may further include a residency map for each frame (e.g., frame N sub-tree LOD residency map222) in geometry node pool212with at least one entry in the residency map per sub-tree. A sub-tree includes at least one bounding volume at the “root” and at least one geometry leaf node. Each entry in the residency map may contain an integer level of detail value for comparison with a calculated LOD value. Moreover, each entry in the residency map may also point to at least one location (e.g., via a pointer or via an index) of a level of detail for the sub-trees in a geometry node pool created by the CPU. The recording map may be configured to store integer values representative of levels of detail for the sub-trees as determined by the GPU. The recording map (e.g., frame N sub-tree (current frame) LOD recording map254) may be maintained and created by the GPU to keep a record of the processing of the various sub-trees. After the completion of the processing of a frame, the recording map for that frame may be transferred to the host memory associated with the CPU. This then becomes the frame N−1 recording map224.

With continued reference toFIG.2, in this example, the GPU-side240of graphics processing system200may include geometry node cache242, traversal engine244, shader246, frame buffer248, LOD processor250, sub-tree LOD residency map252, and sub-tree LOD recording map254. During processing of a scene only portions of the scene that are relevant for the frame or frames about to be drawn may be fetched by the GPU from geometry node pool212. As an example, the fetched geometry may be stored in a geometry node cache242.

FIG.3shows one example of fetched sub-trees300of the acceleration structure for a frame. The fetched geometry in geometry node cache242may include recently used or frequently used sub-trees for different portions of scene geometry. In one example, geometry node cache242may be implemented as a system level cache. As an example, as shown inFIG.3, sub-trees300include sub-trees310, sub-trees330, and sub-trees350. Sub-trees310,330, and350may correspond to different objects in a scene. A given sub-tree may have multiple LODs, and thus multiple sets of indices. In the example shown inFIG.3, sub-trees310may have the following indices: LOD0 indices312, LOD1 indices314, and LODN indices316. Each of the indices may point to sub-trees with differing levels of detail. Thus, LOD0 indices312may point to sub-trees with the highest level of detail. LOD1 indices314may point to vertices sub-trees with an intermediate level of detail and LODN indices316may point to sub-trees with the lowest level of detail. Sub-trees330may have the following indices: LOD0 indices332, LOD1 indices334, and LODN indices336. Each of the indices may point to sub-trees with differing levels of detail. Thus, LOD0 indices332may point to sub-trees with the highest level of detail. LOD1 indices334may point to sub-trees with an intermediate level of detail and LODN indices336may point to vertices with the lowest level of detail. Sub-trees350may have the following indices: LOD0 indices352, LOD1 indices354, and LODN indices356. Each of the indices may point to sub-trees with differing levels of detail. Thus, LOD0 indices352may point to sub-trees with the highest level of detail. LOD1 indices354may point to sub-trees with an intermediate level of detail and LODN indices356may point to sub-trees with the lowest level of detail. Since the LOD indices themselves do not take up a lot of storage (e.g., only a few bytes), a substantial number of LOD indices may be kept in the geometry node pool, which may point to certain other pointers, which then may point to the sub-trees. In addition, althoughFIG.3shows multiple sub-trees corresponding to a set of indices, a single sub-tree may be identified by a set of indices, as well.

Referring back toFIG.2, a graphics processing pipeline including traversal engine244and shader246may be implemented as part of the GPU that can execute multiple threads in parallel using stream processing. Shader246may output the processed frame data into frame buffer248. Other types of parallel processing may also be used to increase the performance of the graphics processing pipeline. Additional details concerning the interactions among LOD processor250, sub-tree LOD residency map252, and sub-tree LOD recording map254are provided with respect toFIGS.4and5. AlthoughFIG.2shows a certain number of components of graphics processing system200arranged in a certain manner, there could be more or fewer components arranged differently. Moreover, the residency map may be implemented as either (1) a linked list where each list item contains a currently resident bounding volume ID and its associated memory pointer, (2) a fixed-length array with valid memory pointer entries for all currently resident bounding volume IDs, or (3) another implementation.

FIG.4shows a processing timeline400for the tasks being performed on the CPU-side210ofFIG.2in accordance with one example. Processing timeline400may include: (1) a first set of tasks (e.g., tasks402,404,406,408, and410) after which the processing moves on to the GPU-side240, and (2) a second set of tasks (e.g., tasks412,414,416, and418) that are performed after the GPU-side240has completed the tasks described with respect to processing timeline500ofFIG.5. As part of task402, the CPU may determine initial objects and objects present in a scene. As part of task404, the CPU may determine the initial bounding volume hierarchy (BVH). As explained earlier, the bounding volume hierarchy (BVH) may have a tree structure with one or more selectable sub-trees per node. In one example, there may be a bounding box node, pointers to child nodes, and geometry (e.g., triangles) at the leaf nodes. Next, as part of step406, the CPU may build acceleration structure trees and sub-trees for different levels of detail (LODs). The acceleration structures may include both top-level acceleration structures (TLAS) and bottom-level acceleration structures (BLAS). As part of task408, the CPU may set up an initial residency map. Once the CPU submits the ray trace command as part of task410, the processing moves to the GPU-side240.

FIG.5shows a processing timeline500for the tasks being performed on the GPU-side240ofFIG.2in accordance with one example. Processing timeline500may be performed as a loop for a set of frames (e.g., N frames). As part of task502, the traversal engine (e.g., traversal engine244ofFIG.2) may fetch the residency map for each frame. As explained earlier, each entry in the residency map may point to at least one location (e.g., via a pointer or via an index) of a level of detail for the sub-trees fetched into geometry node cache242ofFIG.2or stored in geometry node pool212ofFIG.2. The residency map may also point to multiple locations for different levels of detail for the sub-trees indexed by bounding volumes. As part of task504, the GPU may clear the recording map. As explained earlier, the recording map may be configured to store integer values representative of levels of detail for sub-trees as determined by the GPU. The recording map may be maintained and created by the GPU to keep a record of the processing of acceleration structures for the various sub-trees.

With continued reference toFIG.5, task506may include performing the algorithm shown inFIG.5for each ray in a scene. The algorithm may include the traversal engine (e.g., traversal engine244ofFIG.2) for each bounding volume (e.g., BV indexed by volume v) in the acceleration structure (AS), testing the ray against bounding volume. If the traversal engine determined that there was no intersection between the ray and the bounding volume, then the next bounding volume is processed by the traversal engine. If, however, there is an intersection, between the ray and the bounding volume, then, the traversal engine checks the status of the LOD test flag (LTF). If the LTF is set (e.g., LTF=1), then several sub-tasks labeled A, B, C, D, and E are performed as part of the algorithm.

Still referring toFIG.5, as part of sub-task A, LOD processor250ofFIG.2may perform a level of detail (LOD) evaluation function or look up a table. The evaluation function may map bounding volume size to LOD values. An example evaluation function may be LODc=maxLOD−log2(max(dx, dy, dz)), where LODcis the calculated LOD value, maxLOD is a constant representing the maximum permissible (i.e., coarsest) level of detail value, and where dx, dy, and dz are the three dimensions of the bounding volume in screen space. Alternatively, instead of performing the evaluation function, the LOD processor250ofFIG.2may look up a table that may store the LOD values for various bounding volume sizes. The determined LOD value is referred to as the computed LOD (LODc). Next, as part of sub-task B, the LOD processor may look up the residency map indexed by bounding volume to determine the resident LOD (LODr).

Still referring toFIG.5, as part of sub-task C, the LOD processor (e.g., LOD processor250ofFIG.2) may update the recording entry for the sub-tree to the minimum value of the current LOD in the recording map (e.g., sub-tree LOD recording map254ofFIG.2) and the computed LOD (LODc). As part of this, the LOD processor may perform a read-modify-write to record the higher level of detail corresponding to the minimum value of the current LOD in the recording map and the computed LOD (LODc). In one example, the recording map may be set up as a searchable list that can be searched based on an identifier associated with a bounding volume. The entries in the searchable list may be hashed such that a hash search could be made to first determine whether the recording map contains an entry corresponding to the bounding volume.

With continued reference toFIG.5, as part of sub-task D of the algorithm, traversal engine may look up a child pointers list that is indexed by volume and level of detail. As an example, Table 1 shows one such child pointer list that may be maintained by the traversal engine. As shown in Table 1, for each node ID associated with a bounding volume, the child pointers list may include the LOD for the node ID and children nodes, if any, of the bounding volume indexed by the node ID. Table 1 shows the bounding volume having node ID 2.1 as having an LOD of 0 and children with node IDs of 3.1a and 3.1b.

TABLE 1Node IDLODChildren2.1a03.1a, 3.1b2.1a1a3, null2.1b. . .. . .2.1a. . .. . .. . .. . .. . .

Next, as part of sub-task E of the algorithm, the traversal engine may choose child nodes from the acceleration structure tree with an LOD value that is the maximum of the computed LOD value (LODc) and the resident LOD value (LODr). In one example, the final LOD value (LODf) may be communicated to the traversal engine by the LOD processor after determining the maximum of the computed LOD value (LODc) and the resident LOD value (LODr). This way the final LOD value corresponds to a coarser representation because only the coarser representation is resident in the random access memory (RAM).

The traversal engine may then trace child nodes of the bounding volume v down to the leaf nodes.FIG.6shows traversal of the child nodes for an example frame when a higher level of detail is selected. In contrast,FIG.7shows the traversal of the child nodes for an example frame when a lower level of detail is selected.FIG.6shows the acceleration structure tree as including both a top level acceleration structure (TLAS) and a bottom level acceleration structure (BLAS). In this example, the top level acceleration structure (TLAS) includes: BV node 1.1, BV node 1.N, BV node 2.1A, and BV node 2.1B. The bottom level acceleration structure (BLAS) includes: BV node 3.1A, BV node 3.1B, geometry node A1 and geometry node A2.FIG.6shows only a portion of the acceleration structure tree. TheFIG.6example assumes that the higher level of detail is selected for bounding volume node 2.1A. As a result, child nodes BV node 3.1A and one of geometry node A1 or geometry node A2 are traced.

FIG.7also shows the acceleration structure tree as including both a top level acceleration structure (TLAS) and a bottom level acceleration structure (BLAS). In this example, the top level acceleration structure (TLAS) includes: BV node 1.1, BV node 1.N, BV node 2.1A, and BV node 2.1B. The bottom level acceleration structure (BLAS) includes: geometry node A3.FIG.7also shows only a portion of the acceleration structure tree. TheFIG.7example assumes that a lower level of detail is selected for bounding volume node 2.1A. As a result, child node geometry node A3 is traced. In one example, the traversal engine may also interpolate between levels. This can be accomplished by calculating LODcto include fractional precision. The magnitude of the fraction can be used, for example, to smoothly interpolate, or merge, fine detail geometry so that the number of primitives is between the finer and coarser integer LODs.

Finally, as part of task508, the LOD processor may store the recording map for the frame (e.g., frame N−1) into the system memory. As an alternative, the system may be designed so that the CPU and GPU have shared access to the residency map and the recording map, obviating the need for copying; instead, the maps may be double buffered and exchanged via pointer swapping. As an example, sub-tree LOD recording map254may be stored into the CPU-side210system memory as frame N−1 sub-tree LOD recording map224. Advantageously, the recording map for use with the CPU now contains LODs that are actually used even if they were not resident in the residency map previously, which in turn helps the CPU in determining the correct level of detail for the sub-trees for frame N (the next frame) to bring into the geometry node pool. This in turn helps reduce the amount of storage (e.g., DRAM) needed for storing the geometry node pool. In addition, there are bandwidth savings in terms of the GPU not having to fetch geometry for sub-trees from the geometry node pool that will not be required as part of processing the next frame. In sum, building the history of use of the sub-trees via the recording map and the residency map allows for substantial savings in terms of both memory capacity and memory bandwidth. Moreover, the LOD processor included in the GPU-side240helps off-load LOD processing from the CPU to the GPU. AlthoughFIG.5shows the processing timeline500with a certain number of tasks and sub-tasks being performed in a certain order, the processing timeline500may include additional or fewer tasks and sub-tasks performed in a different order.

Referring back toFIG.4, once the GPU-side240has completed the tasks described with respect to the processing timeline500ofFIG.5, the CPU-side210may perform additional tasks. As part of task412, the CPU may determine sub-tree LODs to discard and/or add to the geometry node pool. As part of this process, the CPU may rely upon the historical usage data associated with the various LOD values as recorded via the recording map (e.g., frame N−1 sub-tree LOD recording map224ofFIG.2, and possibly saved copies from frame N−2, frame N−3, etc.). As part of task414, the CPU may fetch new sub-tree LODs from the storage into geometry node pool. As part of task416, the GPU may rebuild/update acceleration structures. Next, as part of task418, the CPU may update the residency map stored in the system memory (e.g., memory106ofFIG.1or another suitable system memory) to reflect the resident level of detail values. The tasks described with respect to the processing timelines inFIGS.4and5may be performed with both immediate mode rendering GPUs and tile-based deferred rendering (TBDR) style GPUs. AlthoughFIG.4shows the processing timeline400with a certain number of tasks and sub-tasks being performed in a certain order, the processing timeline400may include additional or fewer tasks and sub-tasks performed in a different order.

FIG.8shows a flow chart800of a method implemented by a graphics processing system in accordance with one example. In one example, the steps described in this method may be performed by the graphics processing system200described earlier with respect toFIG.2. Step810may include retrieving a first level of detail value for a sub-tree from a level of detail residency map corresponding to a bounding volume hierarchy of objects. In one example, this step may include performing task502described earlier with respect toFIG.5. As part of task502, the traversal engine (e.g., traversal engine244ofFIG.2) may fetch the residency map for the frame including the sub-trees for the bounding volume being processed. As explained earlier, each entry in the residency map may point to at least one location (e.g., via a pointer or via an index) of a level of detail for each existing sub-tree for a bounding volume in a geometry node pool created by the CPU. Each sub-tree may contain all of the nodes for the acceleration structure(s) corresponding to that sub-tree.

Step820may include determining a second level of detail value for the sub-tree. As explained earlier, in one example, this step may be performed only when the LOD test flag is set to a true value. This step may include performing sub-task A of the algorithm described as part of task506detailed earlier with respect toFIG.5. As explained earlier, as part of sub-task A, LOD processor250ofFIG.2may perform a level of detail (LOD) evaluation function or look up a table. The evaluation function may map bounding volume size to LOD values. An example evaluation function may be LODc=maxLOD−log2(max(dx, dy, dz)). Alternatively, as part of step820, instead of performing the evaluation function, the LOD processor250ofFIG.2may look up a table that may store the LOD values for various bounding volume sizes. The determined LOD value is referred to as the computed LOD (LODc).

Step830may include selecting a final level of detail value for the sub-tree based on a comparison between the first level of detail value for the sub-tree and the second level of detail value for the sub-tree. In one example, step830may include performing sub-task E of the algorithm of task506ofFIG.5. As explained earlier, in one example, the final LOD value (LODf) may be communicated to the traversal engine by the LOD processor after determining the maximum of the computed LOD value (LODc) and the resident LOD value (LODr). This way the final LOD value corresponds to a coarser representation.

Step840may include, based on the final level of detail value for the sub-tree, selecting child nodes in an acceleration structure tree and trace the selected child nodes. In one example, this step may include performing sub-task E of the algorithm of step506ofFIG.6, such that the traversal engine may choose child nodes from the acceleration structure with an LOD value that is maximum of the computed LOD value (LODc) and the resident LOD value (LODr). The traversal engine may then trace child nodes of the bounding volume v down to the leaf nodes.FIG.6shows traversal of the child nodes for an example frame when a higher level of detail is selected. In contrast,FIG.7shows the traversal of the child nodes for an example frame when a lower level of detail is selected. AlthoughFIG.8describes the steps in a certain order, they need not be performed in this order.

FIG.9shows a flow chart900of a method implemented by a graphics processing system in accordance with one example. In one example, the steps described in this method may be performed by the graphics processing system200described earlier with respect toFIG.2. Step910may include, for each bounding volume associated with a set of rays for a frame, testing each of the set of rays against the bounding volume to determine an intersection. In one example, this step may include performing the testing of rays described with respect to task506ofFIG.5.

Step920may include performing several sub-steps for each ray that intersected with the bounding volume and the level of detail processing is required. As explained earlier, one way to determine whether the level of detail processing is required is to check whether the LOD test flag is set to a true value. The first sub-step for step920may include determining a computed level of detail value for a sub-tree indexed by the bounding volume. As explained earlier, this may include LOD processor250ofFIG.2performing a level of detail (LOD) evaluation function or look up a table. The evaluation function may map bounding volume size to LOD values. An example evaluation function may be LODc=maxLOD−log2(max(dx, dy, dz)). Alternatively, as part of step920, instead of performing the evaluation function, the LOD processor250ofFIG.2may look up a table that is configured to store the LOD values for various bounding volume sizes. The determined LOD value is referred to as the computed LOD (LODc).

The next sub-step of step920may include retrieving a resident level of detail value for the sub-tree indexed by the bounding volume. In one example, this sub-step may include performing task502described earlier with respect toFIG.5. As part of task502, the traversal engine (e.g., traversal engine244ofFIG.2) may fetch the residency map for the frame including the sub-trees for the bounding volume being processed. As explained earlier, each entry in the residency map may point to at least one location (e.g., via a pointer or via an index) of a level of detail for each existing sub-tree for a bounding volume in a geometry node pool created by the CPU. Each sub-tree may contain all of the nodes for the acceleration structure(s) corresponding to that sub-tree.

The next sub-step of step920may include determining a final level of detail value based on a comparison between the computed level of detail value for the sub-tree and the resident level of detail value for the sub-tree. In one example, this sub-step may include performing sub-task E of the algorithm of task506ofFIG.5. As explained earlier, in one example, the final LOD value (LODf) may be communicated to the traversal engine by the LOD processor after determining the maximum of the computed LOD value (LODc) and the resident LOD value (LODr). This way the final LOD value corresponds to a coarser representation.

The next sub-step of step920may include, based on the final level of detail value, selecting child nodes in an acceleration structure tree for the bounding volume and tracing the selected child nodes in the acceleration structure tree. In one example, this sub-step may include performing sub-task E of the algorithm of step506ofFIG.6, such that the traversal engine may choose child nodes from the acceleration structure with an LOD value that is maximum of the computed LOD value (LODc) and the resident LOD value (LODr). Traversal engine may then trace child nodes of the bounding volume v down to the leaf nodes.FIG.6shows traversal of the child nodes for an example frame when a higher level of detail is selected. In contrast,FIG.7shows the traversal of the child nodes for an example frame when a lower level of detail is selected. AlthoughFIG.9describes the steps in a certain order, they need not be performed in this order.

In conclusion, the present disclosure relates to a graphics processing system to retrieve a first level of detail value for a sub-tree from a level of detail residency map corresponding to a bounding volume hierarchy of objects. The graphics processing system is to determine a second level of detail value for the sub-tree. The graphics processing system is to select a final level of detail value for the sub-tree based on a comparison between the first level of detail value for the sub-tree and the second level of detail value for the sub-tree. The graphics processing system is to, based on the final level of detail value for the sub-tree, select child nodes in an acceleration structure tree and trace the selected child nodes.

The level of detail residency map may correspond to levels of detail for sub-trees, and the level of detail residency map may be maintained by a central processing unit (CPU) associated with the graphics processing system. The graphics processing system is further configured to determine the second level of detail value by performing a lookup operation or by performing an evaluation function. The final level of detail value for the sub-tree may be selected as a maximum of the first level of detail value for the sub-tree and the second level of detail value for the sub-tree, where a higher level of detail value corresponds to a coarser representation.

The graphics processing system is configured to update a level of detail recording map, where a higher level of detail value corresponds to a coarser representation, with an updated level of detail value for the sub-tree, and where the updated level of detail value for the sub-tree is selected as a minimum of the second level of detail value for the sub-tree and a third level of detail value for the sub-tree obtained from a current level of detail recording map.

The updated level of detail recording map may be provided to a central processing unit (CPU) associated with the graphics processing system. The CPU is configured to process the updated level of detail recording map to determine sub-trees to be added or discarded from a geometry node pool maintained by the CPU.

In another example, the present disclosure relates to a method implemented by a graphics processing system. The method includes for each bounding volume associated with a set of rays for a frame, testing each of the set of rays against the bounding volume to determine an intersection. The method further includes upon determining an intersection between a ray and the bounding volume and upon determining that a level of detail processing is required for the bounding volume: determining a computed level of detail value for a sub-tree indexed by the bounding volume, retrieving a resident level of detail value for the sub-tree indexed by the bounding volume, determining a final level of detail value based on a comparison between the computed level of detail value for the sub-tree and the resident level of detail value for the sub-tree, and based on the final level of detail value, selecting child nodes in an acceleration structure tree for the bounding volume and tracing the selected child nodes in the acceleration structure tree.

As part of the method, the retrieving the resident level of detail value for the sub-tree may comprise obtaining the resident level of detail value from a level of detail residency map, where the level of detail residency map corresponds to levels of detail for sub-trees, and where the level of detail residency map is maintained by a central processing unit (CPU) associated with the graphics processing system. The final level of detail value may be selected as a maximum of the computed level of detail value and the resident level of detail value, where a higher level of detail value corresponds to a coarser representation.

The method may further comprise updating a level of detail recording map, where a higher level of detail value corresponds to a coarser representation, with an updated level of detail value for the sub-tree, and where the updated level of detail value for the sub-tree is selected as a minimum of the computed level of detail value for the sub-tree and a resident level of detail value for the sub-tree obtained from a current level of detail recording map. The method may further include providing an updated level of detail recording map to a central processing unit (CPU) associated with the graphics processing system. The CPU is configured to process the updated level of detail recording map to determine sub-trees to be added or discarded from a geometry node pool maintained by the CPU.

In yet another example, the present disclosure relates to a graphics processing system to, for each bounding volume associated with a set of rays for a frame, test each of the set of rays against the bounding volume to determine an intersection. The graphics processing system is further configured to, upon determining the intersection and upon determining that a level of detail processing is required for the bounding volume: determine a computed level of detail value for a sub-tree indexed by the bounding volume, retrieve a resident level of detail value for the sub-tree indexed by the bounding volume, determine a final detail value based on a comparison between the computed level of detail value for the sub-tree and the resident level of detail value for the sub-tree, and based on the final detail value, selecting child nodes in an acceleration structure tree for the bounding volume and tracing the selected child nodes in the acceleration structure tree.

The resident level of detail value may be obtained from a level of detail residency map, where the level of detail residency map corresponds to levels of detail for sub-trees, and where the level of detail residency map is maintained by a central processing unit (CPU) associated with the graphics processing system. The final level of detail value may be selected as a maximum of the computed level of detail value and the resident level of detail value, where a higher level of detail value corresponds to a coarser representation.

The graphics processing system may further be configured to update a level of detail recording map, where a higher level of detail value corresponds to a coarser representation, with an updated level of detail value for the sub-tree, and where the updated level of detail value for the sub-tree is selected as a minimum of the computed level of detail value for the sub-tree and a resident level of detail value for the sub-tree obtained from a current level of detail recording map. The updated level of detail recording map may be provided to a central processing unit (CPU) associated with the graphics processing system. The CPU may be configured to process the updated level of detail recording map to determine sub-trees to be added or discarded from a geometry node pool maintained by the CPU.

It is to be understood that the methods, modules, and components depicted herein are merely exemplary. Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or inter-medial components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “coupled,” to each other to achieve the desired functionality. Merely because a component, which may be an apparatus, a structure, a system, or any other implementation of a functionality, is described herein as being coupled to another component does not mean that the components are necessarily separate components. As an example, a component A described as being coupled to another component B may be a sub-component of the component B, the component B may be a sub-component of the component A, or components A and B may be a combined sub-component of another component C.

The functionality associated with some examples described in this disclosure can also include instructions stored in a non-transitory media. The term “non-transitory media” as used herein refers to any media storing data and/or instructions that cause a machine to operate in a specific manner. Exemplary non-transitory media include non-volatile media and/or volatile media. Non-volatile media include, for example, a hard disk, a solid-state drive, a magnetic disk or tape, an optical disk or tape, a flash memory, an EPROM, NVRAM, PRAM, or other such media, or networked versions of such media. Volatile media include, for example, dynamic memory such as DRAM, SRAM, a cache, or other such media. Non-transitory media is distinct from, but can be used in conjunction with transmission media. Transmission media is used for transferring data and/or instruction to or from a machine. Exemplary transmission media include coaxial cables, fiber-optic cables, copper wires, and wireless media, such as radio waves.

Furthermore, those skilled in the art will recognize that boundaries between the functionality of the above described operations are merely illustrative. The functionality of multiple operations may be combined into a single operation, and/or the functionality of a single operation may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

Although the disclosure provides specific examples, various modifications and changes can be made without departing from the scope of the disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure. Any benefits, advantages, or solutions to problems that are described herein with regard to a specific example are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.

Furthermore, the terms “a” or “an,” as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles.

Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements.