Processing apparatus, methods, graphics processors, and computer equipment for intersection testing

Abstract

This application provides a processing apparatus, method, graphics processor, and computer device for intersection testing. The processing apparatus for intersection testing is applied in a graphics processor, which includes a hierarchical bounding volume traversal module, a program execution module, and an intersection testing module. The program execution module is configured to send ray tracing execution instructions to the hierarchical bounding volume traversal module and execute the intersection testing process corresponding to the ray tracing execution instructions to obtain the corresponding software intersection result. The hierarchical bounding volume traversal module is configured to, in response to the ray tracing execution instructions, obtain a hardware intersection result through the intersection testing module and send the hardware intersection result to the program execution module. The program execution module is further configured to determine a processing unit in the program execution module and the intersection testing module based on the hardware intersection result and the software intersection result, and to perform subsequent intersection tests based on the determined processing unit to obtain the ray tracing result.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computer technology, and in particular to a processing apparatus, method, graphics processor, and computer device for intersection testing. Background Technology

[0002] In the field of ray tracing, Bounding Volume Hierarchy (BVH) trees are widely used because they can efficiently reduce the computational cost of finding intersections between rays and models.

[0003] In related technologies, the traversal process of ray tracing is highly dependent on the actual intersection of rays with the BVH (Browser Volume Hierarchy). However, because the intersection test execution process in ray tracing systems is usually opaque to the program execution module, developers find it difficult to perform real-time interaction and debugging during the traversal process. If an error occurs in the intersection result, it is difficult to detect it in a timely manner. Therefore, a new method is urgently needed to improve the above-mentioned problems. Summary of the Invention

[0004] In view of this, embodiments of this application provide at least one processing apparatus, method, graphics processor, and computer device for intersection testing.

[0005] The technical solution of this application embodiment is implemented as follows.

[0006] On one hand, embodiments of this application provide a processing apparatus for intersection testing. This apparatus is applied in a graphics processor, which includes a hierarchical bounding volume traversal module, a program execution module, and an intersection testing module. The program execution module is configured to send a ray tracing execution instruction to the hierarchical bounding volume traversal module and execute the intersection testing process corresponding to the ray tracing execution instruction to obtain the corresponding software intersection result. The hierarchical bounding volume traversal module is configured to, in response to the ray tracing execution instruction, obtain a hardware intersection result through the intersection testing module and send the hardware intersection result to the program execution module. The program execution module is further configured to determine a processing unit in the program execution module and the intersection testing module based on the hardware intersection result and the software intersection result, and to perform subsequent intersection tests based on the determined processing unit to obtain the ray tracing result.

[0007] On the other hand, embodiments of this application provide a method for processing intersection tests. This method is applied in a graphics processor and includes: in response to a received ray tracing execution instruction, obtaining software intersection results and hardware intersection results of the intersection test process, wherein the software intersection results are obtained based on the program execution module of the graphics processor, and the hardware intersection results are obtained based on the intersection test module in the graphics processor; determining a processing unit in the program execution module and the intersection test module based on the hardware intersection results and the software intersection results, and performing subsequent intersection tests based on the determined processing unit to obtain ray tracing results.

[0008] In another aspect, embodiments of this application provide a graphics processor that includes the aforementioned intersection test processing apparatus.

[0009] In another aspect, embodiments of this application provide a computer device including the aforementioned graphics processor.

[0010] Based on the embodiments provided in this application, the program execution module generates software intersection results at the software level, and the ray tracing execution instructions instruct the intersection test module to generate hardware intersection results at the hardware level, which are then fed back to the program execution module. This strengthens the interaction between the hardware (i.e., the intersection test module) and the software (i.e., the program execution module). Subsequently, based on the specific circumstances of the hardware and software intersection results, any intersection anomalies can be detected promptly, and a more suitable processing unit for performing the intersection test can be identified. This processing unit can then be used to perform subsequent intersection tests to obtain the final ray tracing result. This improves the accuracy of the intersection test.

[0011] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0013] Figure 1 A schematic diagram of the structure of a processing device for intersection testing provided in an embodiment of this application. Figure 1 ; Figure 2 A schematic diagram of the structure of a processing device for intersection testing provided in an embodiment of this application. Figure 2 ; Figure 3 A flowchart illustrating an intersection test processing method provided in this application embodiment. Figure 1 ; Figure 4A flowchart illustrating an intersection test processing method provided in this application embodiment. Figure 2 ; Figure 5 This is a schematic diagram of the hardware entity of an electronic device according to an embodiment of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to be limiting of this application.

[0017] To facilitate understanding of this solution, the application background of the embodiments in this application will be explained below.

[0018] In the fields of computer graphics and geometric computation, BVH, as an efficient spatial partitioning structure, is widely used in scenarios such as ray tracing, 3D rendering, and collision detection. By organizing geometric objects into a tree-like hierarchical structure, it effectively reduces the number of calculations required to find the intersection between rays and objects in the scene, thereby significantly improving the overall efficiency of ray traversal and intersection testing.

[0019] During the intersection testing of rays and BVH trees, the intersection testing module in the graphics processor (GPU) interacts minimally with the program execution module after execution. In most cases, the intersection testing module simply returns the intersection test results—such as hit points, geometric information, or distance parameters—after completing all tests. This provides high execution efficiency in most scenarios. However, when faced with complex traversal tasks, if anomalies occur during the intersection process, the hierarchical nesting nature of the BVH structure makes it difficult to capture and locate the anomalies in a timely manner. Furthermore, such anomalies generally do not affect the normal execution of the program but are passed on to subsequent calculation stages as erroneous intermediate results. This continuous accumulation of errors not only gradually reduces the accuracy of rendering or simulation results but also significantly increases the difficulty of debugging and troubleshooting.

[0020] To address the aforementioned issues, this application provides an intersection testing processing apparatus applied in a graphics processing unit (GPU). The GPU includes a hierarchical bounding volume traversal module, a program execution module, and an intersection testing module. The program execution module generates software intersection results at the software level, while ray tracing execution instructions instruct the intersection testing module to generate hardware intersection results at the hardware level, which are then fed back to the program execution module. This strengthens the interaction between the hardware (i.e., the intersection testing module) and the software (i.e., the program execution module). Based on the specific circumstances of the hardware and software intersection results, any intersection anomalies can be detected promptly, and a more suitable processing unit for performing the intersection test can be identified. This unit is then used to execute subsequent tests to obtain the final ray tracing result. This improves the accuracy of the intersection test.

[0021] Figure 1 This is a schematic diagram of the structure of a processing device for intersection testing provided in an embodiment of this application, as shown below. Figure 1 As shown, the intersection testing processing device 10 provided in this application embodiment is applied in a graphics processor, which includes a hierarchical bounding volume traversal module 110, a program execution module 120, and an intersection testing module 130.

[0022] The program execution module 120 is configured to send ray tracing execution instructions to the hierarchical bounding volume traversal module 110, and execute the intersection test process corresponding to the ray tracing execution instructions to obtain the corresponding software intersection results.

[0023] The hierarchical bounding volume traversal module 110 is configured to respond to ray tracing execution instructions, obtain hardware intersection results through the intersection test module 130, and send the hardware intersection results to the program execution module 120.

[0024] The program execution module 120 is also configured to determine a processing unit in the program execution module 120 and the intersection test module 130 based on the hardware intersection result and the software intersection result, so as to perform subsequent intersection tests based on the determined processing unit and obtain ray tracing results.

[0025] Here, a graphics processing unit (GPU) is a dedicated graphics processing device used for the processing and display of computer graphics.

[0026] The ray tracing execution command is used to trigger the hierarchical bounding volume traversal module 110 to perform the intersection test process between the ray and the BVH tree. Here, BVH is a tree structure on a set of geometric objects. The BVH tree structure is constructed from hierarchical bounding box nodes, with the root node at the top level, various box nodes (also called intermediate box nodes) in the middle levels, and leaf nodes (also called leaf primitive nodes) at the bottom level corresponding to the actual model surface. The ray traversal process starts from the root node, sequentially finding intersections with each level of box nodes, gradually filtering out child nodes that may intersect with the ray, and finally traversing to the leaf nodes to complete the accurate intersection judgment between the ray and the model.

[0027] In some embodiments, the process of testing the intersection of light rays with the BVH tree may include: before rendering begins, the scene is pre-organized into a BVH tree. This BVH tree can wrap all objects in the scene within their respective axial bounding boxes, and by dividing the scene layer by layer to construct a tree-like hierarchical structure, light rays can quickly eliminate a large number of irrelevant objects through hierarchical traversal.

[0028] At the start of rendering, rays are emitted from the camera position, passing through each pixel on the image plane, into the 3D scene. For each ray, a fast traversal is performed using a pre-constructed BVH tree. This fast traversal starts from the root node and then checks if the ray intersects the bounding box of the current node. If they do not intersect, the entire branch under that node is skipped; if they intersect, its child nodes are recursively checked until a leaf node is reached. At the leaf node, intersection calculations are performed on the actual contained geometric primitives, and the information of the intersection point closest along the ray direction is recorded. If no geometry is hit, the pixel corresponding to that ray directly uses the background color.

[0029] After determining the nearest hit point, lighting calculations are performed based on the material properties of the object corresponding to that hit point and the contribution of the light source. The material properties not only determine how the object's surface responds to light (e.g., transmission, specular reflection, refraction), but also determine whether new secondary rays need to be generated to continue tracking the physical process. If the surface of the object corresponding to the hit point has specular reflection properties, a reflected ray is generated according to the law of reflection; if the surface of the object corresponding to the hit point has transparent properties, a refracted ray is generated according to Snell's law. Each newly generated secondary ray becomes the current ray, and the ray intersection phase starting from the BVH root node and the subsequent shading and recursion phases are repeatedly executed until the preset maximum recursion depth is reached.

[0030] When performing lighting calculations, the contribution of a light source depends on its visibility to the point of impact. To determine the contribution, shadow rays are emitted from the point of impact to each light source, and intersection tests are performed again using a BVH tree. If a shadow ray intersects with another object before reaching the light source, it indicates that the light source is occluded and makes no lighting contribution to the point of impact. If a shadow ray does not intersect with another object before reaching the light source, the contribution of that light source will be included in the final lighting result.

[0031] Finally, all the lighting information on the entire path tree formed by the light rays after multiple reflections and refractions (including the direct lighting at each hit point, the indirect lighting transmitted through secondary rays, and the shadow judgment results of each light source) will be summarized and calculated to obtain the final color value of the corresponding pixel on the image plane.

[0032] In some embodiments, when the program execution module 120 triggers the hardware module 110 to perform a hardware-level intersection test via a ray tracing execution instruction, the program execution module 120 also executes the intersection test process corresponding to the ray tracing execution instruction, thereby generating a software-level intersection result. The software intersection result can then be used as a standard to further determine whether the hardware intersection result has any intersection anomalies. Here, the software intersection result may include the software traversal stack, the nodes in the software traversal stack, and the intersection test result of each node.

[0033] When the hierarchical bounding volume traversal module 110 receives the ray tracing execution command, it can respond to the ray tracing execution command by obtaining the hardware intersection result through the intersection test module 130 and sending the hardware intersection result to the program execution module 120.

[0034] After receiving the hardware intersection result, the program execution module 120 can determine the processing unit to perform the subsequent intersection test based on the hardware intersection result and its own output software intersection result. That is, it determines whether to change the processing unit to perform the intersection test based on the specific circumstances of the current hardware and software intersection results. Then, the determined processing unit is used to perform subsequent intersection tests to improve the accuracy of the obtained ray tracing results.

[0035] For example, if the processing unit that performs the intersection test in the current frame (or the previous N frames) is the intersection test module 130, it can be determined, based on the hardware intersection result and the software intersection result output by the intersection test module 130, that the processing unit that performs the intersection test in the next frame (or the next M frames) is still the intersection test module 130. Here, M and N are positive integers.

[0036] For example, the processing unit that performs the intersection test in the current frame (or the previous N frames) is the intersection test module 130. Based on the hardware intersection result and the software intersection result output by the intersection test module 130, the processing unit that performs the intersection test in the next frame (or the next M frames) is determined to be the program execution module 120.

[0037] In some embodiments, the hardware intersection result sent by the hierarchical bounding volume traversal module 110 to the program execution module 120 may include the intersection test results of all nodes traversed during the intersection test. Alternatively, the hardware intersection result may include the intersection test result of the last node during the intersection test.

[0038] In some embodiments, the software intersection result obtained by the program execution module 120 may include the intersection test results of all nodes along the path in the intersection test process. Alternatively, the software intersection result may include the intersection test result of the last node in the intersection test process.

[0039] In this embodiment, the program execution module 120 generates software intersection results at the software level, and the ray tracing execution instruction instructs the intersection test module 130 to generate hardware intersection results at the hardware level, which are then fed back to the program execution module 120. This strengthens the interaction between the hardware (i.e., the intersection test module 130) and the software (i.e., the program execution module 120). Subsequently, based on the specific circumstances of the hardware and software intersection results, any intersection anomalies can be detected in a timely manner, and a processing unit more suitable for performing the intersection test can be identified, thereby improving the accuracy of the intersection test.

[0040] In some embodiments, the intersection test includes a box intersection test and a primitive intersection test; the program execution module 120 is configured to perform the primitive intersection test at the software layer; the intersection test module 130 is configured to perform the box intersection test at the hardware layer; or, the intersection test module 130 is configured to perform both the box intersection test and the primitive intersection test at the hardware layer.

[0041] Here, the hardware layer refers to the use of fixed, dedicated physical chips to perform calculations. These physical chips are fixed in the chip design stage and do not require instruction acquisition, decoding, or scheduling. They have extremely high execution speed, throughput, and extremely low latency.

[0042] The software layer refers to program code consisting of instruction sequences that runs on general-purpose processors (such as CPU cores, GPU stream processors, or programmable shaders). This code can be modified, optimized, or have new primitive intersection algorithms (such as those for handling triangles and tori) added at any time. Compared to the hardware layer, software layer computations typically consume more instruction bandwidth and execute relatively slower.

[0043] Box intersection testing is used to determine whether a ray intersects the bounding box (such as an AABB, or axis-aligned bounding box) of an object in the scene. Because the bounding box structure is simple, the test can be completed with only a few addition, subtraction, and comparison operations, resulting in low computational cost. Box intersection testing allows for the quick skipping of areas that are definitely not hit by the ray, rapidly narrowing the search to nodes that may contain intersection points. The core of box intersection testing lies in "culling," which utilizes hierarchical structures to significantly reduce unnecessary precise calculations.

[0044] Primitive intersection testing occurs at the leaf nodes of the BVH tree. Primitive intersection testing is used to perform mathematical operations on rays and the actual geometric primitives (such as triangles, spheres, etc.) stored within the node to determine whether an intersection point exists, and to calculate specific information such as the coordinates of the intersection point, the normal direction, and distance parameters.

[0045] Because primitive intersection testing involves solving complex geometric equations, its computational cost is far greater than that of box intersection testing. Therefore, performing primitive testing only within candidate regions that pass the box intersection test allows computational resources to be focused on the geometry that is actually likely to produce intersections, improving resource utilization.

[0046] In some embodiments, such as Figure 2As shown, the intersection testing module 130 includes a box intersection testing unit 1302 and a primitive intersection testing unit 1301. The primitive intersection testing unit 1301 can also be called a leaf intersection testing unit. The box intersection testing unit 1302 is used to perform intersection testing between rays and box nodes, while the primitive intersection testing unit 1301 is used to perform intersection testing between rays and primitives in leaf nodes. Here, the primitive intersection testing unit 1301 may also include an opaque primitive processing unit and a transparent / procedural primitive processing unit.

[0047] In the BVH-based intersection testing process, box intersection testing (i.e., every time a ray enters a node, it needs to be determined whether it intersects with the bounding box) is the most frequently traversed operation. If box intersection testing relies on software calculations, each test involves multiple floating-point comparisons and branch judgments, which will quickly become a testing bottleneck.

[0048] The intersection test module 130 processes these calculations in parallel using dedicated circuitry, enabling it to quickly determine the intersection of rays and bounding boxes with extremely low latency and high throughput. Since most nodes are quickly eliminated during BVH traversal, the intersection test module 130 can be used to perform box intersection tests, thus preserving the speed advantage of eliminating invalid paths, ensuring that the ray tracing system can run in real time, and accelerating the entire intersection test process.

[0049] In some embodiments, the program execution module 120 may also be configured to perform box intersection tests at the software layer.

[0050] In some embodiments, the program execution module 120 is further configured to perform box intersection tests and primitive intersection tests at the software layer.

[0051] For example, when the intersection test module 130 malfunctions, in order to ensure the accuracy of the box intersection test and the primitive intersection test, the program execution module 120 can be used as a processing unit to perform the box intersection test and the primitive intersection test.

[0052] In some embodiments, since the hardware (i.e., the intersection test module 130) has an acceleration effect, when the intersection test module 130 is not abnormal, the intersection test module 130 is preferentially selected to perform box intersection test and primitive intersection test.

[0053] In this embodiment of the application, by controlling different modules to perform corresponding intersection tests (such as program execution module 120 performing primitive intersection tests and intersection test module 130 performing box intersection tests), different types of test processes can be arranged more reasonably, thereby improving the efficiency of intersection tests while ensuring accuracy.

[0054] In some embodiments, the program execution module 120 is further configured to compare the hardware intersection result and the software intersection result to obtain a comparison result; and to determine the processing unit for the intersection test based on the comparison result.

[0055] The program execution module 120 is further configured to determine the intersection test processing unit as the intersection test module 130 when the comparison results are the same for both hardware and software intersection; and to determine the intersection test processing unit as the program execution module 120 when the comparison results are different for both hardware and software intersection.

[0056] Based on the foregoing, once the hardware intersection result is obtained, the software intersection result can be used as a standard to compare the hardware and software intersection results. If the hardware and software intersection results are the same, it indicates that the intersection test module 130 did not encounter any intersection exceptions during the intersection test, and therefore, the intersection test module 130 can continue to be used as the processing unit for intersection testing. If the hardware and software intersection results are different, it indicates that the intersection test module 130 encountered any intersection exceptions during the intersection test, and therefore, the program execution module 120 can be used as the processing unit for intersection testing.

[0057] In some embodiments, the program execution module 120 is further configured to determine the processing unit as the intersection test module 130 when the hardware intersection result and the software intersection result are the same, and to perform subsequent box intersection tests and primitive intersection tests based on the intersection test module 130; and to determine the processing unit as the program execution module 120 when the primitive intersection result in the hardware intersection result and the primitive intersection result in the software intersection result are different, and to perform subsequent primitive intersection tests based on the program execution module 120.

[0058] In some embodiments, the program execution module 120 is further configured to determine the processing unit as the intersection test module 130 if the primitive intersection results in the hardware intersection results and the primitive intersection results in the software intersection results are the same, and to perform subsequent primitive intersection tests based on the intersection test module 130.

[0059] In other words, when the primitive intersection result is normal, the intersection test module 130 is prioritized as the processing unit for subsequent intersection tests, fully leveraging the hardware's parallel processing capabilities and significantly improving the overall efficiency of the intersection test. Only when the primitive intersection result is abnormal is the program execution module 120 used as the processing unit for subsequent intersection tests, utilizing the precision of the software to improve the accuracy of the intersection test. Through this hardware-first, software-backup processing mechanism, high throughput performance accelerated by hardware is achieved in normal scenarios (i.e., no primitive intersection anomalies), while rendering distortion caused by hardware errors is avoided in abnormal scenarios (i.e., abnormal primitive intersections). Thus, the overall accuracy and efficiency of the intersection test are both ensured.

[0060] In some embodiments, the program execution module 120 is further configured to determine the processing unit for the box intersection test as the program execution module 120 when the box intersection results in the hardware intersection results and the box intersection results in the software intersection results are different. In this way, when there is a problem with the intersection result of a certain type of node (such as a box node), the program execution module can continue to execute, avoiding the error from happening again.

[0061] In some embodiments, the program execution module 120 is further configured to determine the intersection test processing unit as the intersection test module 130 when the box intersection results in the hardware intersection results and the box intersection results in the software intersection results are different. That is, even when the box intersection results in the hardware intersection results and the box intersection results in the software intersection results are different, the box intersection test is still performed through the intersection test module 130.

[0062] It should be noted that the box intersection test is only used to accelerate the traversal and culling of structures, and its purpose is to quickly skip node regions that cannot intersect with rays. Even if the hardware makes a few judgment errors during this process (such as judging boxes that should intersect as non-intersecting, or non-intersecting boxes as intersecting), it will not affect the accuracy of the final image. Specifically, when the hardware makes a few judgment errors, the intersection test module 130 can be instructed to skip the erroneous nodes or modify its intersection results through ray tracing execution instructions to continue executing subsequent box intersection tests. Please refer to the relevant explanations later for details.

[0063] Conversely, if switching to software intersection calculation via program execution module 120 due to inconsistent box intersection results would negate the advantages of hardware acceleration, severely impacting real-time performance. Therefore, continuing to use intersection testing module 130 even when box intersection results are inconsistent maximizes the preservation of hardware acceleration culling capabilities without sacrificing final test accuracy. For primitive intersection tests that directly affect the final pixel color, the aforementioned processing mode (i.e., hardware priority, software fallback) continues to be executed to ensure the correctness of the rendering results. This differentiated processing ensures the accuracy of the final image while maintaining the overall execution efficiency of the ray tracing system.

[0064] In this embodiment, by comparing the hardware intersection results and the software intersection results, a more suitable processing unit can be selected when the intersection results are abnormal, thereby ensuring the accuracy of subsequent intersection tests.

[0065] In some embodiments, the program execution module 120 is further configured to close the interface in the intersection test module 130 used for performing primitive intersection tests if the primitive intersection results in the hardware intersection results and the primitive intersection results in the software intersection results are different.

[0066] For example, when the primitive intersection results in the hardware intersection result and the software intersection result are different, the program execution module 120 can send a primitive test interface closure instruction to the hierarchical bounding volume traversal module 110. This primitive test interface closure instruction is used to instruct the interface in the intersection test module 130 used to perform primitive intersection tests to be closed. After receiving the primitive test interface closure instruction, the hierarchical bounding volume traversal module 110 controls the intersection test module 130 to close the interface of the primitive intersection test unit 1301.

[0067] In some embodiments, the program execution module 120 is further configured to close the interface in the intersection test module 130 used to perform box intersection tests if the box intersection results in the hardware intersection results and the box intersection results in the software intersection results are different.

[0068] For example, when the box intersection results in the hardware intersection result and the software intersection result are different, the program execution module 120 can send a box test interface close instruction to the hierarchical bounding volume traversal module 110. This box test interface close instruction is used to instruct the interface in the intersection test module 130 used to perform box intersection tests to be closed. After receiving the box test interface close instruction, the hierarchical bounding volume traversal module 110 controls the intersection test module 130 to close the interface of the box intersection test unit 1302.

[0069] In other embodiments, if the box intersection results in the hardware intersection result are different from those in the software intersection result, the interface in the intersection test module 130 used to perform the box intersection test is not closed, and the box intersection test unit 1302 in the intersection test module 130 continues to be called to perform the box intersection test.

[0070] In this embodiment of the application, by disabling the interface for performing primitive intersection testing in the hardware unit (such as the intersection test module 130), it is possible to directly avoid potential calculation deviations or compatibility issues in the hardware when the primitive intersection results in the hardware intersection results are inconsistent with those in the software intersection results; at the same time, it avoids abnormal hardware output from interfering with subsequent processes and ensures the reliability of system operation.

[0071] In some embodiments, such as Figure 2 As shown, the graphics processor also includes a configuration register control module 140.

[0072] The hierarchical bounding volume traversal module 110 is also configured to determine the state of the interactive debugging operation mode based on the debugging flag bit of the configuration register control module 140 during the intersection test in response to the ray tracing execution instruction; if the interactive debugging operation mode is enabled, then the hardware traversal information and hardware intersection results are read.

[0073] Here, the default state of the interactive debugging mode is off. Of course, the default state of the interactive debugging mode can also be on, and this application does not restrict this.

[0074] Hardware traversal information is used to characterize the traversal path during the intersection test process; this information can also be referred to as debugging information. The hardware traversal information details the nodes traversed by the intersection test module 130 during the intersection test, and can also be used to more quickly identify abnormal intersection nodes.

[0075] In some embodiments, the configuration register control module 140 is configured to enable the interactive debug run mode during the intersection test.

[0076] In some embodiments, the interactive debugging mode can be activated during the intersection test of the ray and the BVH tree; or, if there is a problem with the intersection test result of the current frame (or the previous N frames), the interactive debugging mode can be activated in the next frame (or the next M frames). This application does not limit the timing of activating the interactive debugging mode.

[0077] In some embodiments, such as Figure 2As shown, the hierarchical bounding volume traversal module 110 includes a run control unit 1101. The run control unit 1101 is configured to determine the state of the interactive debugging run mode according to the debug flag bit of the configuration register control module 140 during the intersection test; if the interactive debugging run mode is enabled, it reads the hardware traversal information and the hardware intersection result.

[0078] Here, the debug flag is used to indicate whether the interactive debug mode is enabled. For example, the debug flag can be indicated by 0 or 1. If the debug flag is 0, the interactive debug mode is disabled; if the debug flag is 1, the interactive debug mode is enabled. As another example, if the debug flag is 0, the interactive debug mode is enabled; if the debug flag is 1, the interactive debug mode is disabled. It is understood that whether the interactive debug mode is enabled can be indicated by the debug flag or by debug commands; this application does not impose any restrictions on this, as long as it conforms to actual use.

[0079] After the control unit 1101 reads the debug flag, it can determine the status of the interactive debug mode based on the debug flag. When the interactive debug mode is enabled, the corresponding hardware traversal information and the final hardware intersection result can be read during the intersection test. When the interactive debug mode is disabled, the system is in normal operation mode and only needs to return the hardware intersection result after the intersection test is completed.

[0080] In this embodiment, the reading permissions of hardware traversal information and hardware intersection results are controlled by the interactive debugging operation mode, so as to achieve precise limitation of the timing of data acquisition. Data is only read when the interactive debugging operation mode is turned on, and is not actively acquired in other cases. This reduces the reading and transmission of invalid data in non-debugging scenarios, reduces data redundancy and bandwidth occupation, and reduces unnecessary data parsing and storage overhead, thereby improving system operating efficiency.

[0081] In some embodiments, the ray tracing execution instruction is used to trigger the execution of an intersection test and cause the hierarchical bounding volume traversal module 110 to return interaction information at a preset check position. Here, the interaction information includes hardware intersection results and hardware traversal information.

[0082] It should be noted that the preset check position can be configured after the interactive debugging mode is turned on, or when the interactive debugging mode is turned off. This application does not limit the timing of the preset check position configuration.

[0083] The configuration parameters corresponding to the preset inspection position can be stored in the command domain, and the configuration parameters in the command domain can be flexibly adjusted according to the actual debugging or analysis requirements, thereby achieving precise debugging of the ray tracing process.

[0084] For example, the program execution module can send a ray tracing execution command to the hierarchical bounding volume traversal module 110. The hierarchical bounding volume traversal module 110 can respond to this command by performing an intersection test between the ray and the BVH tree, returning interactive information at preset checkpoints. In this way, the program execution module 120 can monitor the intermediate states and phased results of the intersection test in real time, grasping the test progress without waiting for the entire process to end. If an intersection anomaly occurs, the problem can be quickly located to a specific node based on the interactive information fed back from each checkpoint. Furthermore, the progress and results of the intersection test remain transparent to the program execution module 120, supporting dynamic tracking of the execution status during the test, rather than only being able to backtrack after the entire process is completed. This allows any intersection anomaly to be quickly traced back to the specific node where the problem occurred through the interactive information recorded at the checkpoints, accelerating the identification of the problem point.

[0085] In some embodiments, the interactive information may be obtained by the hierarchical bounding volume traversal module 110 during the intersection test performed by the box intersection test unit 1302 and / or the primitive intersection test unit 1301.

[0086] In some embodiments, the interactive information may also be obtained by the operation control unit 1101 in the hierarchical bounding volume traversal module 110 during the intersection test performed by the box intersection test unit 1302 and / or the primitive intersection test unit 1301.

[0087] Here, the preset check position is related to at least one of the following test data generated by the hierarchical bounding volume traversal module during the intersection test: The number of times the intersection test is performed; The currently traversed node during the intersection test; The currently traversed primitive during the intersection test.

[0088] Here, the preset check position can also be called the breakpoint position.

[0089] For example, the preset check position can be determined based on the number of times the intersection test is performed. For instance, the ray tracing execution instruction control hierarchy bounding volume traversal module 110 returns interactive information after performing 100 intersection tests.

[0090] For example, the preset check position can be determined based on the current traversal node during the intersection test. For instance, when the ray tracing execution instruction control hierarchy bounding volume traversal module 110 executes the intersection test of node A, it returns interactive information.

[0091] For example, the preset check position can be determined based on the currently traversed primitives during the intersection test. For instance, when the ray tracing execution instruction control layer bounding volume traversal module 110 executes the intersection test of primitive B, it returns interactive information.

[0092] It is understandable that the preset inspection location may also be related to other content, and this application does not limit this.

[0093] In this embodiment, by periodically returning interactive information at preset checkpoints, the program execution module 120 can promptly obtain the execution progress and result data of the intersection test process, eliminating the need for backtracking and troubleshooting after the entire test process is completed. When an intersection anomaly occurs, the specific node where the anomaly occurred can also be quickly located based on the interactive information of each checkpoint, shortening the scope of anomaly troubleshooting.

[0094] In some embodiments, the program execution module 120 is further configured to receive hardware intersection results and hardware traversal information, and, when the hardware intersection results and software intersection results are different, locate the first node with an anomaly in the intersection test based on the hardware traversal information.

[0095] As described above, the hierarchical bounding volume traversal module 110 can respond to ray tracing execution commands and return hardware intersection results and hardware traversal information to the program execution module 120 at preset check positions. Since the hardware traversal information can represent the traversal path during the intersection test, when the hardware intersection results and software intersection results differ, the program execution module 120 can locate the first node with the anomaly based on the specific content in the hardware traversal information.

[0096] In this embodiment, when there is a difference between the hardware intersection result and the software intersection result, the nodes where the hardware and software results are inconsistent are determined based on the hardware traversal information, avoiding indiscriminate full-scale investigation, greatly shortening the anomaly location cycle and improving location efficiency.

[0097] In some embodiments, the hardware traversal information includes at least a first traversal stack and the nodes within the first traversal stack; the software traversal information includes at least a second traversal stack and the nodes within the second traversal stack.

[0098] The program execution module 120 is also configured to compare the nodes in the first traversal stack with the nodes in the second traversal stack, and determine the nodes that are different in the first traversal stack and the second traversal stack as the first node.

[0099] In some embodiments, the hardware traversal information also includes the level of the currently traversed node in the BVH tree, and the nodes in the first traversal stack can be box nodes or leaf nodes. The nodes in the second traversal stack can also be box nodes or leaf nodes.

[0100] Here, the traversal stack is a data structure used to manage node access paths, which can be implemented as a stack. Because BVH trees have multiple levels of branches, when a ray traverses downwards along a branch, a stack is needed to record other branch nodes that have been passed but not yet processed. This allows the stored node information to be popped from the stack after the current subtree has been traversed, thus accurately determining where to continue traversing next. Here, the traversal stack can be a first traversal stack, or it could be a second traversal stack.

[0101] Nodes in the traversal stack can be stored as node indices or pointers. Each node corresponds to a bounding box in the BVH tree and its child nodes or a list of primitives. Nodes in the traversal stack refer to those that have been pushed onto the stack and are awaiting further processing. Each node in the stack includes its index or pointer, and may also include auxiliary data such as the intersection distance, used to quickly restore the traversal context during backtracking. Here, nodes in the traversal stack can be nodes from the first traversal stack, or they can be nodes from the second traversal stack.

[0102] Understandably, the program execution module 120 can obtain hardware traversal information, and then compare the first traversal stack and the nodes in the first traversal stack in the hardware traversal information with the second traversal stack and the nodes in the second traversal stack in the software traversal information to identify which node the intersection test module encountered an anomaly during the intersection test, thereby locating the first node of the anomaly.

[0103] In this embodiment, by comparing the nodes in the first traversal stack and the nodes in the second traversal stack, the node that differs from the node can be accurately located and identified as the first node. In this way, the core position of inconsistent node states in the traversal process can be directly locked, without having to check the traversal process node by node, quickly locating abnormal traversal nodes and improving the accuracy and efficiency of the location.

[0104] In some embodiments, the program execution module 120 is further configured to generate updated ray tracing execution instructions to control the processing unit to skip the intersection test of the branch corresponding to the first node and execute the intersection test of the next node during the execution of subsequent intersection tests.

[0105] Here, the updated ray tracing execution instructions include first modification information, which indicates that the intersection state of the first node is a first state, which is different from the intersection state of the first node in the hardware intersection result.

[0106] Based on the above, it can be seen that by comparing the hardware traversal information and the software traversal information, the first abnormal node can be identified. For example, the intersection result of the first node output by the intersection test module 130 is "miss", while the intersection result of the first node output by the program execution module 120 is "hit".

[0107] To further determine whether there are other abnormal nodes besides the first node, the program execution module 120 can continue to issue updated ray tracing execution instructions to the hierarchical bounding volume traversal module 110. The updated ray tracing execution instructions modify the intersection result of the first node. For example, if the intersection test module 130 outputs an intersection result of "missing," while the program execution module 120 outputs an intersection result of "hit," then the first modification information in the updated ray tracing execution instructions indicates that the intersection result of the first node is "hit."

[0108] For example, if the intersection result of the first node output by the intersection test module 130 is "hit", while the intersection result of the first node output by the program execution module 120 is "miss", then the first modification information in the updated ray tracing execution instruction indicates that the intersection result of the first node is "miss".

[0109] Thus, when the updated ray tracing execution command is sent to the hierarchical bounding volume traversal module 110, the hierarchical bounding volume traversal module 110 can choose to skip the processing of the first node according to the intersection result of the first node indicated by the first modification information, and perform correctness verification on the subsequent traversal process (i.e., the Traverse process) to confirm whether the execution of the traversal process conforms to the expected logic.

[0110] Understandably, because the intersection test module 130 hardware unit has an acceleration effect, after identifying the first abnormal node, the intersection result of the first node can be directly modified through the updated ray tracing execution instructions. Then, based on the correct intersection result of the first node, the intersection test module 130 (i.e., the hardware unit) continues to execute the intersection test of the next node, thereby achieving complete control over the subsequent intersection test process of the ray and the BVH tree, and thus achieving faster problem localization.

[0111] In some embodiments, the updated ray tracing execution instructions may further include third modification information, which includes all data that may be used during the subsequent intersection test of the ray and the BVH tree. For example, the third modification information may include node information, identification information, and temporary information used by the intersection test module 130 during traversal, etc. Here, the node information may be the node information of the box node or the node information of the leaf node. Using the temporary information used by the intersection test module 130 during traversal, specific configurations or data within the hardware unit can be dynamically adjusted, thereby dynamically changing the execution state of the hardware according to the intent of the program execution module 120. For example, the access path of the ray in the BVH tree can be changed by modifying the stack pointer or stack content related to the traversal order in the intersection test module 130; the precision threshold or comparison logic of the ray and bounding box intersection test can also be adjusted to adapt to the rendering requirements of the current scene; in addition, the intersection detection of specific branches can be dynamically enabled or disabled in subsequent traversals by updating the node culling mask or overriding flag, ultimately achieving fine-grained control over the intersection test process. Of course, the third modification information can also be other information, which will not be shown here one by one.

[0112] In this embodiment, the updated ray tracing execution instructions can pre-configure the intersection results of specified nodes during subsequent intersection tests. This allows for human intervention in the entire intersection test process and, based on known abnormal nodes, further identification of the traversal status and intersection results of other branches of the BVH tree, gradually identifying abnormal paths. This enables precise and rapid location of software and hardware issues, simplifies the debugging process, and improves the overall debugging efficiency of the system.

[0113] In some embodiments, the program execution module 120 is further configured to generate updated ray tracing execution instructions to control the processing unit to update the default attribute value of the first node read from the cache to a first value, and to perform the intersection test of the first node according to the first value.

[0114] Here, the updated ray tracing execution instructions include second modification information, which indicates that the attribute value of the first node is the first value.

[0115] For example, the first node is a leaf node, and the attribute value of the primitives included in the first node is a first numerical value, which indicates that the primitive is transparent. This first numerical value is an attribute value configured by the program execution module 120. However, the default attribute value of the primitive stored in the node cache 150 is opaque. That is, the default attribute value of the primitives in the first node stored in the cache is different from the attribute value of the primitives in the first node configured by the program execution module 120.

[0116] When performing an intersection test, referring to the temporary information stored during the traversal process, the program execution module 120 can update the attribute value of the primitive in the first node from the default "opaque" to "transparent". Then, the intersection test can be performed according to the new attribute value (transparent) and the test result corresponding to the transparency attribute can be obtained (for example, the light passes through the primitive and continues to find a closer intersection point).

[0117] It is understandable that, in addition to updating the attribute values ​​of primitives, other parameters of nodes and / or primitives can also be updated, such as updating the traversal priority of the node level, the bounding box range, or the geometric parameters of primitives (such as vertex coordinates, normal vectors), material parameters (such as reflectivity, refractive index), etc., which will not be elaborated here.

[0118] In this embodiment of the application, by updating the parameters of primitives or other nodes and performing intersection tests based on the updated parameters, the impact of a single parameter on the intersection test results can be accurately determined, and problems caused by inconsistent data or incorrect parameter configuration can be quickly located, effectively narrowing the debugging scope and improving the efficiency and accuracy of locating system hardware and software problems.

[0119] Figure 2 This is a schematic diagram of the structure of a graphics processor provided in an embodiment of this application, such as... Figure 2 As shown, the graphics processor provided in this embodiment may further include a node cache 150 and an acceleration data structure 160.

[0120] The node cache 150 is further configured to allocate caches for different nodes in response to a request from the hierarchical bounding volume traversal module 110. The acceleration data structure 160 is used to store node information for each node in the BVH tree, including information for box nodes and leaf nodes. Exemplarily, the acceleration data structure 160 is stored in video memory.

[0121] Additionally, the program execution module 120 is configured to input light rays into the hierarchical bounding volume traversal module 110 and execute a software-defined program. The hierarchical bounding volume traversal module 110 is also used to control the traversal order and path of light rays in the BVH tree structure during the intersection test between light rays and each node.

[0122] For example, the software-defined program executed by the program execution module 120 can be a shader. The hierarchy bounding volume traversal module 110 can return the intersection test results of different nodes to the program execution module 120. When the intersection test result indicates that the ray hits an opaque primitive, the program execution module 120 can call the hit shader, which calculates the final color value and optical properties of the hit point based on the material parameters, texture sampling, and lighting model at the hit point. If the intersection test result shows that the ray hits a semi-transparent or hollow geometry, the hit shader determines at the program level whether to perform fragment blending, discard the current intersection point, or continue to trace the ray to simulate complex optical behaviors such as refraction and transmission, based on parameters such as transparency threshold, blending mode, or texture alpha channel. Conversely, if the intersection test result indicates that the ray does not hit any geometry, the miss shader will be triggered. The miss shader uses the environment map as the background and assigns a background color or radiosity value to the corresponding pixel.

[0123] In some embodiments, the process by which the hierarchical bounding volume traversal module 110 controls the traversal order and path of light rays in the BVH tree structure may include: when a light ray enters the scene, the hierarchical bounding volume traversal module 110 executes a depth-first or stack-based breadth-first traversal algorithm to perform a bounding box intersection test between the current node and the light ray; if the test passes, the pointers of the child nodes of the current node are pushed onto the stack for subsequent processing; if the test fails, the branch is skipped to reduce invalid calculations.

[0124] In the above process, the layer bounding volume traversal module 110 needs to dynamically trim the traversal range based on the nearest intersection point returned by the opaque primitives to achieve pruning optimization. For transparent or procedural primitives, since it is not possible to terminate immediately after the first hit, it is necessary to continue traversing to collect all potential intersection points, and sort or derive new light paths according to the material's transmission properties to complete the spatial interaction between light and scene primitives.

[0125] Here, transparent primitives can be geometries that allow incident light to pass through in terms of optical properties. When a transparent primitive intersects with a ray, some light will refract through the medium, in addition to surface reflection. Opaque primitives can be geometries that completely block light transmission in terms of optical properties. When an opaque primitive intersects with a ray, the incident light is only reflected or absorbed, causing the ray path to terminate there. Procedural primitives can be geometries that are generated algorithmically rather than statically stored in terms of geometric definition. When a procedural primitive intersects with a ray, a dedicated procedural intersection shader is called, rather than relying on a fixed hardware traversal unit, thus enabling the expression of infinitely fine or infinitely extended geometric details with a very small memory footprint.

[0126] In some embodiments, the hierarchical bounding volume traversal module 110 is further configured to receive light rays from the program execution module 120, determine the currently traversed node as the first node, generate the address of the first node in the accelerated data structure 160, and send the address of the first node in the accelerated data structure 160 to the node cache 150.

[0127] The node cache 150 is also used to access the address of the first node in the accelerated data structure 160 based on the address of the first node in the accelerated data structure 160 issued by the hierarchical enclosing volume traversal module 110; and to receive the node information of the first node returned from the accelerated data structure 160 and send the node information of the first node to the intersection test module 130.

[0128] The accelerated data structure 160 is also used to return the node information of the first node to the node cache 150.

[0129] The intersection test module 130 is also used to receive node information from the first node from the node cache 150, and perform an intersection test according to the type of the first node to obtain the intersection test result corresponding to the first node.

[0130] For example, if the first node is a box node, the box intersection test unit 1302 in the intersection test module 130 is used to receive the node data of the first node and perform an intersection test according to the node data of the first node to obtain the intersection test result corresponding to the first node.

[0131] If the first node is a leaf node, the leaf intersection test unit in the intersection test module 130 is used to receive the node data of the first node and perform an intersection test based on the node data of the first node to obtain the intersection test result corresponding to the first node.

[0132] In some embodiments, the hierarchical bounding volume traversal module 110 is further configured to receive the intersection test result corresponding to the first node, and determine whether to continue traversing the branch corresponding to the first node based on the intersection test result corresponding to the first node.

[0133] In some embodiments, the program execution module 120 is a software unit, and the hierarchical bounding volume traversal module 110, the operation control unit 1101, the intersection test module 130, the primitive intersection test unit 1301, the box intersection test unit 1302, the configuration register control module 140, the node cache 150, and the acceleration data structure 160 are hardware units.

[0134] Based on the above-described intersection test processing apparatus, a method for processing intersection tests is provided. For example... Figure 3 As shown, the processing method for this intersection test includes the following:

[0135] S11, Light generation.

[0136] At the start of rendering, rays are emitted from the camera position through each pixel on the image plane into the 3D scene, and the program execution module sends them to the layer bounding volume traversal module for processing.

[0137] S12. Use BVH traversal to find the nearest intersection point.

[0138] Before performing the intersection test between the ray and the BVH tree, it is first determined whether the interactive debug mode is enabled. If enabled, data return and debug information writing enable are executed (i.e., returning hardware traversal information, hardware intersection results, and enabling debug information writing control). If the interactive debug mode is disabled, the hardware intersection results are returned according to the normal operation mode. Then, nodes that need to be processed later are preloaded through node prefetching control, and the acquired nodes are stored in the node cache. Next, for each ray, the pre-built BVH tree is used for accelerated traversal. During the traversal, the hierarchical bounding volume traversal module can determine the current node that needs to be processed (e.g., the first node) and obtain the node information of the current node through the node cache. After obtaining the node information of the current node, the corresponding intersection test is performed. Generally, the traversal of the box nodes is executed first according to the hierarchical structure of the BVH tree, and then the input is recursively performed until the leaf node is reached, finally determining the geometric primitive hit by the ray. Here, the hit geometric primitive can be a procedural primitive or a transparent primitive. Finally, if the hit geometric primitive is a procedural primitive or a transparent primitive, the hit point information is returned to the program execution module for further processing. If the hit point primitive is not a procedural primitive or a transparent primitive, the next intersection test continues until the entire BVH tree is traversed, and the final traversal result (i.e., the most recent hit point information or the miss identifier) ​​is returned.

[0139] For example, such as Figure 3 As shown, S12, which uses BVH traversal to find the nearest intersection point, includes at least S121 checking if the interactive debugging mode is enabled, S122 node prefetching control, S123 box node traversal, S124 leaf node traversal, S125 continuing to execute the next intersection test, and S126 whether the BVH tree has been traversed completely. The content of S121-S126 is similar to the aforementioned "process of performing intersection tests between rays and the hierarchical bounding volume structure BVH tree," and will not be repeated here.

[0140] Based on the foregoing embodiments, this application provides a method for intersection testing. This method can be applied to a graphics processing unit (GPU), which includes a hierarchical bounding volume traversal module, a program execution module, and an intersection testing module. Figure 4 As shown, the method may include the following steps S101-S102.

[0141] Step S101: In response to the received ray tracing execution command, obtain the software intersection result and hardware intersection result of the intersection test process.

[0142] The software intersection result is obtained based on the program execution module of the graphics processor, while the hardware intersection result is obtained based on the intersection test module in the graphics processor.

[0143] Step S102: Based on the hardware intersection result and the software intersection result, a processing unit is determined in the program execution module and the intersection test module. Subsequent intersection tests are then performed based on the determined processing unit to obtain the ray tracing result.

[0144] In this embodiment, ray tracing execution instructions are used to generate software intersection results at the software level using a program execution module, and hardware intersection results are generated at the hardware level using an intersection testing module. Then, based on the specific circumstances of the hardware and software intersection results, any intersection anomalies can be detected in a timely manner, and a processing unit more suitable for performing subsequent intersection tests can be identified. This processing unit is then used to perform subsequent intersection tests to obtain the final ray tracing result. This improves the accuracy of the intersection test.

[0145] In some embodiments, the intersection test includes a box intersection test and a primitive intersection test. The method further includes steps S103 and S104.

[0146] Step S103: Perform box intersection test through hardware acceleration unit; Step S104: Perform primitive intersection test through hardware acceleration unit or software unit.

[0147] In some embodiments, step S102 can be implemented by steps S1021 and S1022.

[0148] Step S1021: If the hardware intersection result and the software intersection result are the same, the processing unit is determined to be the intersection test module.

[0149] Step S1022: If the primitive intersection results in the hardware intersection results are different from those in the software intersection results, the processing unit is determined to be the program execution module.

[0150] In some embodiments, step S1022 may further include step S10221.

[0151] Step S10221: If the primitive intersection results in the hardware intersection results are different from those in the software intersection results, close the interface in the intersection test module used to perform primitive intersection tests.

[0152] In some embodiments, the method further includes the step S201.

[0153] Step S201: During the intersection test, the status of the interactive debugging mode is determined according to the debugging flag bit of the configuration register control module; if the interactive debugging mode is enabled, the hardware traversal information and hardware intersection result are read.

[0154] The graphics processor also includes a register control module, and the interactive debug mode is disabled by default; hardware traversal information is used to characterize the traversal path during the intersection test.

[0155] In some embodiments, the ray tracing execution instruction is used to trigger the execution of an intersection test and cause the hierarchical bounding volume traversal module to return interactive information at a preset check position; wherein, the interactive information includes hardware intersection results and hardware traversal information.

[0156] In some embodiments, the preset check position is related to at least one of the following: the number of times the intersection test is performed; the currently traversed node during the intersection test; and the currently traversed primitive during the intersection test.

[0157] In some embodiments, the method further includes steps S301 and S302.

[0158] Step S301: Receive the hardware intersection result and hardware traversal information; Step S302: When the hardware intersection result and the software intersection result are different, locate the first node with an anomaly in the intersection test process based on the hardware traversal information.

[0159] In some embodiments, the hardware traversal information includes at least a first traversal stack and the nodes within the first traversal stack; the software traversal information includes at least a second traversal stack and the nodes within the second traversal stack.

[0160] In step S302, based on the hardware traversal information, the location of the first node with an anomaly during the intersection test can be achieved through the following step S3021.

[0161] Step S3021: Compare the nodes in the first traversal stack with the nodes in the second traversal stack, and determine the nodes that are different in the first traversal stack and the second traversal stack as the first node.

[0162] In some embodiments, the method further includes the step S401.

[0163] Step S401: Generate updated ray tracing execution instructions to control the processing unit to skip the intersection test of the branch corresponding to the first node and execute the intersection test of the next node during the intersection test.

[0164] The updated ray tracing execution instructions include first modification information, which indicates that the intersection state of the first node is a first state, which is different from the intersection state of the first node in the hardware intersection result.

[0165] In some embodiments, the method further includes the step S501.

[0166] Step S501: Generate updated ray tracing execution instructions to control the processing unit to update the default attribute value of the first node read from the cache to the first value, and perform the intersection test of the first node according to the first value; The updated ray tracing execution instructions include second modification information, which indicates that the attribute value of the first node is a first value.

[0167] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0168] In the embodiments of this application, specific implementation methods can be referred to the description of any of the foregoing intersection test processing apparatuses. The descriptions of the above method embodiments are similar to the descriptions of the apparatus embodiments and have similar beneficial effects. For technical details not disclosed in the method embodiments of this application, please refer to the description of the apparatus embodiments of this application for understanding.

[0169] The following describes the application of the intersection test processing method provided in the embodiments of this application in a real-world scenario.

[0170] Ray tracing is a graphics rendering technique that differs from traditional rasterization rendering. Ray tracing simulates the propagation, intersection, reflection, refraction, and occlusion of light rays in a scene to ultimately determine the color of each pixel. This allows for the simulation of the physical properties of lighting in the real world, resulting in more realistic visual effects.

[0171] The ray tracing process includes: first, ray rays are emitted from the camera position into the scene; then, it is determined whether the ray intersects with geometric primitives in the scene; second, the closest primitive hit point to the camera is found, and then the color of the hit point is calculated; finally, the above steps are recursively performed as needed until all the traced ray information is summarized to calculate the final color of the pixel. During the process of finding primitive hit points, it is also necessary to determine whether other types of secondary rays are generated based on the results, such as: shadow rays (specifically, rays that travel from the intersection point to the light source, and whether the ray is blocked is determined to be in a shadow), reflected rays (specifically, if the surface is smooth (such as a mirror), reflected rays will be generated to continue tracing, even to outside the scene), and refracted rays (specifically, if the object is transparent (such as glass or liquid), refracted rays will be generated to pass through the object).

[0172] In practice, primitives are organized into spatial data structures to accelerate intersection calculation efficiency. The BVH tree is a commonly used spatial data structure. It contains different types of nodes, such as box nodes and leaf nodes. BVH traversal is a depth-first tree traversal, performed by testing whether rays intersect with box nodes and leaf nodes. The traversal process depends on the actual intersection of rays with the BVH, and for complex traversal scenarios, interactive debugging is particularly important. However, in related technologies, during the ray traversal process, the intersection testing module rarely interacts with the program execution module. When intersection exceptions occur, it is difficult to identify the problem, resulting in low debugging efficiency throughout the process.

[0173] To address the aforementioned problems, a processing apparatus for intersection testing is provided. This intersection testing processing apparatus is applied in a graphics processor, such as... Figure 2 As shown, the graphics processor mainly includes a program execution module, a hierarchical bounding volume traversal module, a node cache, an acceleration data structure, a configuration register control module, and an intersection testing module. The hierarchical bounding volume traversal module includes a runtime control unit (also known as an interactive debug runtime control unit or a single-step runtime control unit). The intersection testing module includes a primitive intersection testing unit, which in turn includes an opaque primitive processing unit and a transparent or procedural primitive processing unit.

[0174] The program execution module sends light to the hierarchical bounding volume traversal module to execute the software-defined program. The hierarchical bounding volume traversal module is used for traversal control. The operation control unit in the hierarchical bounding volume traversal module determines the status of the interactive debugging operation mode based on the debugging flag bit of the configuration register control module. If the interactive debugging operation mode is enabled, it reads the hardware traversal information. This hardware traversal information includes, but is not limited to, the traversal stack, box node and leaf node addresses, and the level of the currently traversed node. The node cache receives node retrieval requests from the hierarchical bounding volume traversal module, stores the retrieved nodes, and sends node information to the intersection test module. The acceleration data structure stores hierarchical bounding volume data, including but not limited to box nodes and leaf nodes. The configuration register control module configures whether the interactive debugging operation mode is enabled (the interactive debugging operation mode is disabled by default). The intersection test module performs box intersection tests and primitive intersection tests; specifically, the box intersection test unit performs box intersection tests, and the primitive intersection test unit performs primitive intersection tests. When the primitive is transparent, the primitive intersection test is performed through the transparent or procedural primitive processing unit; when the primitive is opaque, the primitive intersection test is performed through the opaque primitive processing unit.

[0175] Based on the aforementioned graphics processor, the intersection test process between rays and the BVH tree is as follows: The program execution module sends the ray to the hierarchical bounding volume traversal module. The hierarchical bounding volume traversal module generates an address for accessing the accelerated data structure, accesses the accelerated data structure through the node cache, and returns the node data to the node cache. The node cache sends the node data to the intersection test module, and the intersection test module returns the box or primitive intersection test result to the hierarchical bounding volume traversal module. The hierarchical bounding volume traversal module determines whether to continue traversing based on the result, or returns the data to the program execution module if all traversals have been completed.

[0176] Additionally, the runtime control unit in the hierarchical bounding volume traversal module controls whether the traversal process enters interactive debug mode based on the debug flag in the configuration register control module. By default, this interactive debug mode is off, and the system will perform the traversal normally and return the intersection result to the program execution module. If the interactive debug mode is enabled, the system will enable the transmission of additional hardware traversal information, which will be returned to the program execution module along with the hardware intersection result.

[0177] After receiving the hardware traversal information and hardware intersection results, the program execution module can verify whether the hardware and software intersection results meet expectations. If an error is found in the hardware intersection result, the interface of the primitive intersection test unit can be closed, and the program execution module can then perform the primitive intersection, thereby reducing the chance of the chip being unable to support hardware ray tracing due to hardware errors. Moreover, the ray tracing execution instructions sent downstream by the program execution module (i.e., the hierarchical bounding volume traversal module, intersection test module, node cache, acceleration data structure, and configuration register control module) have the function of controlling the preset check position, which can determine how many steps to execute before stopping and interacting with the program execution module in the interactive debug running mode.

[0178] In other words, when an error occurs in the hardware intersection result and debugging is required, the interactive debugging mode can be opened to check whether the execution result of each step meets expectations. During the process, the preset check position and the hardware traversal information can be written to the hardware through the ray tracing execution instructions of the program execution module.

[0179] Furthermore, the updated ray tracing execution instructions can rewrite the hardware state of the intersection test module or assign new values ​​to nodes or primitives, thereby gaining complete control over traversal and intersection calculations, enabling faster identification of hardware and software issues. For example, the ray tracing execution instructions can carry modification information (such as first modification information, second modification information, etc.). This modification information includes all data that might be used during the intersection test between the ray and the BVH tree. For instance, this modification information may include node information, identification information, temporary information used by the intersection test module (i.e., the hardware unit) during traversal, etc. In this way, by modifying the contents of the hardware, the execution state of the hardware can be dynamically changed according to the intent of the program execution module.

[0180] For example, if a problem is known to exist in node A, and you want to skip the problem in node A to check for problems in the subsequent traversal process, you can carry modification information when executing node A. This modification information indicates that "the intersection state of node A is miss / hit". Then, the hardware can use this modification information to skip the problem in node A and continue checking for problems in the subsequent traversal process.

[0181] For example, during the intersection test between a ray and primitive A, the program execution module can modify the attribute information of primitive A to be transparent by modifying the information, while the attribute information temporarily stored in the cache is also transparent. Afterwards, the hardware can skip the attribute information stored in the cache and directly use the attribute information in the modified information to perform the intersection test. Of course, the modification information can also modify the index of primitive A and other attributes that need to be configured; this application does not limit this.

[0182] As can be seen from the above embodiments, the key point of this application is that during the intersection test, the operating mode can be configured to either a normal operating mode or an interactive debugging operating mode. Then, preset check positions are controlled via ray tracing execution instructions, or interactive information is written to the hardware via ray tracing execution instructions, thereby finding error points more quickly and improving the overall debugging efficiency of the system. Furthermore, when a problem occurs in the primitive intersection test, the program execution module can be used to execute the primitive intersection test, ensuring that the box intersection test is still performed through the intersection test module, thereby reducing the possibility of hardware function shutdown.

[0183] The intersection testing method provided in this application can improve debugging efficiency. After reading the hardware traversal information, the program execution module can also write the hardware traversal information into the intersection testing module. If the primitive intersection result is found to be incorrect, the primitive intersection test can be performed through the program execution module, so that the box intersection test is still performed by the intersection testing module, thereby obtaining some hardware acceleration functions and reducing the possibility of hardware function shutdown.

[0184] Based on the foregoing embodiments, this application provides a processing device for intersection testing. The device includes various units and modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a CPU, a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0185] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. For technical details not disclosed in the apparatus embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0186] It should be noted that, in the embodiments of this application, if the above-mentioned intersection test processing method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0187] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0188] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0189] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device performs some or all of the steps in the above-described method.

[0190] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0191] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0192] Figure 5 This application provides a hardware entity diagram of a computer device as an embodiment of the present application, such as... Figure 5 As shown, the hardware entity of the computer device 500 includes a processor 501 and a memory 502, wherein the memory 502 stores a computer program that can run on the processor 501, and the processor 501 executes the program to implement the steps in the method of any of the above embodiments.

[0193] The memory 502 stores computer programs that can run on the processor. The memory 502 is configured to store instructions and applications that can be executed by the processor 501. It can also cache data to be processed or already processed by the processor 501 and various modules in the computer device 500 (e.g., image data, audio data, voice communication data and video communication data). It can be implemented by flash memory or random access memory (RAM).

[0194] When processor 501 executes a program, it implements the steps of the processing method for any of the above intersection tests. Processor 501 typically controls the overall operation of computer device 500.

[0195] This application provides a computer storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the intersection test processing method as described in any of the above embodiments.

[0196] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0197] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0198] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0199] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0200] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0201] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0202] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0203] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0204] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0205] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A processing apparatus for intersection testing, characterized in that, Applied in a graphics processing unit, the graphics processing unit includes a hierarchical bounding volume traversal module, a program execution module, and an intersection testing module; The program execution module is configured to send a ray tracing execution instruction to the hierarchical bounding volume traversal module, and execute the intersection test process corresponding to the ray tracing execution instruction to obtain the corresponding software intersection result; The hierarchical bounding volume traversal module is configured to, in response to the ray tracing execution command, obtain the hardware intersection result through the intersection test module and send the hardware intersection result to the program execution module; The program execution module is further configured to determine a processing unit in the program execution module and the intersection test module based on the hardware intersection result and the software intersection result, so as to perform subsequent intersection tests based on the determined processing unit to obtain ray tracing results.

2. The apparatus according to claim 1, characterized in that, The intersection test includes box intersection test and primitive intersection test; The program execution module is configured to perform the primitive intersection test at the software layer; the intersection test module is configured to perform the box intersection test at the hardware layer; or, The intersection test module is configured to perform the box intersection test and the primitive intersection test at the hardware layer.

3. The apparatus according to claim 2, characterized in that, The program execution module is further configured to, when the hardware intersection result and the software intersection result are the same, determine the processing unit as the intersection test module, and perform subsequent box intersection tests and primitive intersection tests based on the intersection test module; If the primitive intersection results in the hardware intersection results are different from those in the software intersection results, the processing unit is determined to be the program execution module, and subsequent primitive intersection tests are performed based on the program execution module.

4. The apparatus according to claim 3, characterized in that, The program execution module is further configured to disable the interface in the intersection test module used to perform the primitive intersection test if the primitive intersection results in the hardware intersection result and the primitive intersection result in the software intersection result are different.

5. The apparatus according to any one of claims 1-4, characterized in that, The graphics processor also includes a configuration register control module; The hierarchical bounding volume traversal module is also configured to determine the state of the interactive debugging operation mode based on the debugging flag bit of the configuration register control module during the intersection test performed in response to the ray tracing execution instruction. If the interactive debugging mode is enabled, then read the hardware traversal information and the hardware intersection result; The default state of the interactive debugging operation mode is off; The hardware traversal information is used to characterize the traversal path during the intersection test.

6. The apparatus according to any one of claims 1-5, characterized in that, The ray tracing execution command is used to trigger the execution of the intersection test and cause the hierarchical bounding volume traversal module to return interactive information at the preset check position; The interactive information includes the hardware intersection result and the hardware traversal information.

7. The apparatus according to claim 6, characterized in that, The preset check position is related to at least one of the following test data generated by the hierarchical bounding volume traversal module during the intersection test: The number of times the intersection test is performed; The current traversed node in the intersection test process; The currently traversed primitives during the intersection test process.

8. The apparatus according to claim 6 or 7, characterized in that, The program execution module is also configured to receive the hardware intersection result and hardware traversal information, and when the hardware intersection result and the software intersection result are different, locate the first node with an anomaly in the intersection test process based on the hardware traversal information.

9. The apparatus according to claim 8, characterized in that, The hardware traversal information includes at least a first traversal stack and the nodes within the first traversal stack; the software traversal information includes at least a second traversal stack and the nodes within the second traversal stack. The program execution module is further configured to compare the nodes in the first traversal stack with the nodes in the second traversal stack, and determine the nodes that are different in the first traversal stack and the second traversal stack as the first node.

10. The apparatus according to claim 8 or 9, characterized in that, The program execution module is also configured to generate updated ray tracing execution instructions, so as to use the updated ray tracing execution instructions to control the processing unit to skip the intersection test of the branch corresponding to the first node and execute the intersection test of the next node during the execution of subsequent intersection tests; The updated ray tracing execution instruction includes first modification information, which indicates that the intersection state of the first node is a first state, and the first state is different from the intersection state of the first node in the hardware intersection result.

11. The apparatus according to claim 8 or 9, characterized in that, The program execution module is also configured to generate updated ray tracing execution instructions, so as to use the updated ray tracing execution instructions to control the processing unit to update the default attribute value of the first node read from the cache to a first value, and to perform the intersection test of the first node according to the first value; The updated ray tracing execution instruction includes second modification information, which indicates that the attribute value of the first node is the first value.

12. A method for processing intersection tests, characterized in that, When applied to a graphics processor, the method includes: In response to a received ray tracing execution command, the software intersection result and the hardware intersection result of the intersection test process are obtained, wherein the software intersection result is obtained based on the program execution module of the graphics processor, and the hardware intersection result is obtained based on the intersection test module in the graphics processor; Based on the hardware intersection result and the software intersection result, a processing unit is determined in the program execution module and the intersection test module, and subsequent intersection tests are performed based on the determined processing unit to obtain the ray tracing result.

13. A graphics processor, characterized in that, The graphics processor includes the processing means for intersection testing as described in any one of claims 1 to 11.

14. A computer device, characterized in that, Includes the graphics processor as described in claim 13.

Images