Graphics processor, graphics processor binning method, device and medium

Abstract

The application discloses a graphics processor, a graphics processor partitioning method, equipment and a medium, and relates to the technical field of graphics processors. The graphics processor partitioning method comprises the following steps: a TBU receives ray requests sent by at least two RTUs corresponding to the TBU; according to path information in each ray request, each ray request with the same execution path is determined; each ray request with the same execution path is written into the same shader binding table slot; in the case that the shader binding table slot meets a preset condition, the shader binding table slot is assembled in a single instruction multiple data stream thread bundle, and the single instruction multiple data stream thread bundle is sent to a shader execution unit. By corresponding one TBU to multiple RTUs, the number of ray requests with the same execution path obtained can be increased, and the TBU can obtain more ray requests with the same execution path in a short time, so that the efficiency of writing the ray requests with the same execution path into the shader binding table slot is improved.

Description

Technical Field

[0001] This application belongs to the field of graphics processor technology, and particularly relates to a graphics processor, a method for partitioning a graphics processor, an apparatus, and a medium. Background Technology

[0002] In a ray tracing system, the Graphics Processing Unit (GPU) is used to perform ray traversal and intersection calculations, multipath partitioning and beamforming, and parallel shading operations to complete ray tracing rendering, lighting and shadow simulation, and pixel image generation for 3D scenes. Specifically, the shader execution unit in the GPU sends ray generation requests to the RayTraversal Unit (RTU). The RTU generates ray requests and sends them to the ThreadBinning Unit (TBU). The TBU first writes ray requests with the same execution path into the ShaderBinding Table slot (SBT slot). When certain conditions are met, the shader binding table slots are assembled into a Single Instruction Multiple Data Warp (SIMD Warp). The TBU then distributes the ray requests in the SIMD Warp to the shader execution units to obtain the execution results.

[0003] The current TBU is inefficient at writing ray requests with the same execution path into shader binding table slots, resulting in low efficiency in obtaining execution results. Summary of the Invention

[0004] This application provides a graphics processor, a method for partitioning graphics processors, an apparatus, and a medium to address the problem of low efficiency in TBU writing ray requests with the same execution path into shader binding table slots.

[0005] A first aspect of this application provides a graphics processor, the graphics processor including a ray traversal unit (RTU), a thread partitioning unit (TBU), and a shader execution unit, wherein at least two RTUs correspond to one TBU, wherein: The RTU is used to send a ray request to the corresponding TBU; The TBU is used to receive ray requests sent by at least two RTUs corresponding to the TBU; determine the ray requests with the same execution path according to the path information in each ray request; write the ray requests with the same execution path into the same shader binding table slot; and, if the shader binding table slot meets the preset conditions, assemble the shader binding table slot into a single instruction multiple data stream (SIMDS) thread bundle and send the SIMDS thread bundle to the shader execution unit.

[0006] A second aspect of this application provides a method for partitioning a graphics processor, the graphics processor including an RTU, a TBU, and a shader execution unit, wherein at least two RTUs correspond to one TBU, the method is applied to the TBU, and the method includes: Receive ray requests sent by at least two RTUs corresponding to the TBU; Based on the path information in each of the ray requests, determine the ray requests with the same execution path; Write all ray requests with the same execution path to the same shader binding table slot; If the shader binding table slot meets the preset conditions, the shader binding table slot is assembled into a single instruction multiple data stream thread bundle; The single instruction multiple data stream (SMILE) thread bundle is sent to the shader execution unit.

[0007] A third aspect of this application provides an electronic device, the electronic device including a graphics processor as described in the first aspect of this application.

[0008] A fourth aspect of this application provides a computer-readable storage medium, which is a non-volatile or non-transient storage medium, having a computer program thereon, wherein the computer program, when executed by a processor, performs the steps of the graphics processor segmentation method described in the second aspect of this application.

[0009] In the graphics processor, graphics processor partitioning method, device, and medium provided in this application, the TBU can only assemble the shader binding table slot into the SIMD Warp when the number of rays for which the TBU writes ray requests with the same execution path to the shader binding table slots reaches the required number. This application, by assigning multiple RTUs to one TBU, can increase the number of ray requests obtained by the TBU, thereby increasing the number of ray requests with the same execution path. Thus, the TBU can acquire more ray requests with the same execution path in a shorter time, thereby improving the efficiency of writing ray requests with the same execution path to the shader binding table slots and improving the efficiency of obtaining execution results. Furthermore, by assigning multiple RTUs to one TBU, the number of TBUs used can be reduced, thereby reducing hardware costs and improving economic efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the structure of a graphics processor provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a graphics processor segmentation method provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device 10 provided in an embodiment of this application. Detailed Implementation

[0012] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0013] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0014] It should be noted that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0015] In current mainstream GPU architectures, one RTU typically corresponds to one TBU. However, the limited number of ray requests for the same execution path within an RTU affects the efficiency of the TBU in filling shader binding table slots, which in turn affects the efficiency of the TBU in sending SIMD warps to the shader execution unit. Furthermore, if filling a shader binding table slot times out, the TBU can automatically assemble shader binding table slots that do not meet preset conditions into a SIMD warp and launch it to the shader execution unit, which leads to a decrease in SIMD wavefront efficiency. For example, the preset condition could be that the number of ray requests filling the shader binding table slots reaches a preset number. The preset number can be set as needed; for example, the preset number could be set to 32.

[0016] This application addresses the aforementioned problems of decreased SIMD wavefront efficiency and reduced efficiency of the TBU writing ray requests with the same execution path into shader binding table slots. It proposes a solution for a graphics processor, a graphics processor partitioning method, a device, and a medium. By mapping multiple RTUs to one TBU, the number of ray requests received by the TBU can be increased, thereby increasing the number of ray requests with the same execution path. This allows the TBU to acquire more ray requests with the same execution path in a shorter time, improving the efficiency of writing these ray requests into the shader binding table slots and ultimately increasing the efficiency of obtaining execution results. Furthermore, mapping multiple RTUs to one TBU reduces the number of TBUs used, thereby reducing hardware costs and improving economic efficiency.

[0017] This application provides a graphics processor including an RTU, a TBU, and a shader execution unit, wherein at least two RTUs correspond to one TBU.

[0018] Figure 1 This is a schematic diagram of the structure of a graphics processor provided in an embodiment of this application, such as... Figure 1 As shown, a graphics processor may include multiple RTUs and TBUs. Specifically, an RTU may include RTU0, RTU1, RTU2 (not shown), etc., and one TBU may correspond to at least two RTUs. Figure 1 Taking one TBU corresponding to two RTUs as an example, the TBU may include a conflict resolution module and a shader binding table. The shader binding table stores the entry address of the shader program, so that the shader execution unit can execute the shader program according to the sent Single Instruction Multiple Data Stream (SIM) thread bundle. The function of the conflict resolution module will be described in detail later.

[0019] It is understood that a GPU may include multiple TBUs, each TBU corresponding to at least two RTUs. Specifically, at least two RTUs can establish hardware connections with the TBU. The input of the TBU can be configured as a multi-channel ray queue or a two-channel ray queue to receive ray requests sent by the at least two RTUs corresponding to that TBU. In the embodiments of this application, the TBU mentioned can be any TBU in the GPU, and the RTU mentioned is the RTU that has established a hardware connection with that TBU.

[0020] RTU is used to send ray requests to the corresponding TBU.

[0021] The TBU is used to receive ray requests sent by at least two RTUs corresponding to the TBU; based on the path information in each ray request, it determines the ray requests with the same execution path; writes the ray requests with the same execution path into the same shader binding table slot; if the shader binding table slot meets the preset conditions, it assembles the shader binding table slot into a single instruction multiple data stream thread bundle and sends the single instruction multiple data stream thread bundle to the shader execution unit.

[0022] When a TBU interacts with its corresponding RTUs to request rays, at least two RTUs corresponding to that TBU send ray requests to the TBU. The TBU can receive ray requests sent by at least two RTUs corresponding to the TBU. A ray request may include geometry intersection status markers, path information, intersection parameters, ray properties, instance ID, and primitive ID. For example, intersection status markers may include states such as geometry hit, missed, and shadow occlusion. Path information can be used to specify the specific shader to which the ray request points. Path information may include shader type, intersection parameters may include intersection distance and normal, and ray properties may include ray type and level. For each ray request, the TBU can determine the path identifier for that ray request based on information such as the instance ID and primitive ID in the ray request. The path identifier may include the Shader Binding Table ID (SBT ID).

[0023] It should be noted that the embodiments of this application do not limit the timing at which the RTU corresponding to the TBU sends the ray request to the TBU; they can send it simultaneously or at different times. A high degree of overlap in the execution paths of ray requests between at least two RTUs corresponding to a TBU is beneficial for improving the efficiency of the TBU in writing ray requests with the same execution path into the shader binding table slots.

[0024] In some embodiments, the overlap of execution paths of ray requests between at least two RTUs can be determined by statistically analyzing the number of overlapping execution paths of ray requests sent by each RTU and the total number of ray requests sent by each RTU when one TBU corresponds to one RTU.

[0025] For example, the degree of overlap can be calculated using the following formula: When the overlap is greater than the preset threshold, RTU0~RTUn can be set as a corresponding TBU. The preset threshold can be set as needed, for example, it can be set to 0.6.

[0026] When the TBU determines which ray requests have the same execution path based on the path information in each ray request, since ray requests with the same execution path need to be written to the same shader binding table slot, and the path information in the ray request can characterize the execution path corresponding to that ray request, the TBU can determine whether the execution paths of the ray requests of each RTU are the same by using the path information in each received ray request. If they are the same, the TBU executes the step of writing the ray requests with the same execution path to the same shader binding table slot. If they are not the same, the TBU can execute the step of writing each ray request to its corresponding shader binding table slot in parallel.

[0027] When the TBU writes ray requests with the same execution path to the same shader binding table slot, each shader binding table slot can hold a preset number of ray requests. Therefore, when it is determined that the ray requests have the same execution path, and the number of rays in the shader binding table slot corresponding to that execution path has not reached the preset number, ray requests with the same execution path can be written to the corresponding shader binding table slot. If the number of rays in the shader binding table slot corresponding to that execution path reaches the preset number, it indicates that the shader binding table slot meets the preset condition, and the TBU can assemble the shader binding table slot into a single instruction multiple data stream (SMD) thread bundle.

[0028] When the TBU sends a Single Instruction Multiple Data Stream (SMD) thread bundle to the shader execution unit, it can be understood that one SMD thread bundle corresponds to one shader binding table slot, and one shader binding table slot can include multiple ray requests. By sending the SMD thread bundle to the shader execution unit, the TBU enables the shader execution unit to execute the same task simultaneously without needing to switch paths while executing tasks, thus saving control logic and time cycles, and improving the utilization rate of the shader execution unit.

[0029] In this embodiment, no additional global scheduling unit is required. By mapping multiple RTUs to one TBU, the number of ray requests received by the TBU can be increased, thereby increasing the number of ray requests with the same execution path. The TBU can then acquire more ray requests with the same execution path in a shorter time, reducing idle periods and improving the efficiency of writing ray requests with the same execution path to shader binding table slots, thus improving the efficiency of obtaining execution results. This can also be understood as reducing wavefront divergence and improving SIMD parallelism by merging similar types of rays from two RTUs. Furthermore, by mapping multiple RTUs to one TBU, the number of TBUs used can be reduced, thereby reducing hardware costs and improving economic efficiency. This solves the problem of decreased SIMD wavefront efficiency caused by multiple independent TBUs being unable to share thread grouping opportunities in scenarios with severe divergence.

[0030] Before the TBU determines the ray requests with the same execution path based on the path information in each ray request, in order to clarify the execution path of each ray request so that the ray request can be written to the corresponding shader binding table slot later, in some embodiments, the TBU can be used to determine the shader type corresponding to each ray request based on the path information in each ray request; group the ray requests with the same shader type into the same group; and for each group, determine the ray requests with the same execution path based on a preset index table and the path differentiation identifier of each ray request in the group.

[0031] The foregoing description indicates that the path information includes the shader type. Therefore, the shader type can be directly determined from the path information to initially group each ray request based on the shader type. After grouping, all ray requests in each group have the same shader type. For each group, operations can be performed to determine which ray requests have the same execution path based on a preset index table and the path differentiation identifier of each ray request within that group.

[0032] For example, the preset index table can be an SBT lookup table, which stores the correspondence between path identifiers and shader binding table slots. Therefore, for each ray request within a group, the corresponding shader binding table slot can be determined by looking up the SBT lookup table for the path identifier of that ray request. Then, by comparing whether the shader binding table slots of each ray request are the same, it can be determined that the execution paths of each ray request pair are the same.

[0033] For example, if two ray requests have the same shader binding table slot, then the two ray requests will have the same execution path.

[0034] In this embodiment, since different shaders execute different content, the initial grouping of each ray request by shader type can reduce the computational resources required for fine matching by path differentiation identifier, thereby improving the binning efficiency and hardware resource utilization of TBU.

[0035] In some embodiments, after initial grouping, ray requests of the same shader type can be merged into a block queue of the same type so that the TBU can subsequently write the ray requests from the block queue into the corresponding shader binding table slot.

[0036] In some embodiments, ray requests with the same execution path can also be determined directly based on the path distinguishing identifier of each ray request. For example, if any two or more ray requests within a group have the same path distinguishing identifier, it indicates that the two or more ray requests have the same execution path.

[0037] When the TBU determines the ray requests with the same execution path based on the path information in each ray request, it should be noted that at the same time, the TBU can simultaneously write ray requests with different execution paths into the corresponding shader binding table slots. However, for multiple ray requests with the same execution path at the same time, the TBU can only write one ray request into the shader binding table slot of that same execution path.

[0038] Since a TBU can correspond to at least two RTUs, and two or more RTUs can send ray requests to the TBU at the same time, if the execution paths of the ray requests are the same, the TBU will face the conflict problem of needing to write multiple ray requests into the same shader binding table slot at the same time.

[0039] To resolve write conflicts, a conflict resolution module can be set up in the graphics processor. This module can schedule multiple conflicting ray requests so that the TBU can write a ray request to the corresponding shader binding table slot at the same time.

[0040] In some embodiments, the conflict assessment module is used to determine the target ray request among the ray requests with the same execution path according to a preset priority judgment mechanism when all ray requests are sent to the TBU at the same time and at least two ray requests have the same execution path. The TBU is used to write the target ray request into the shader binding table slot; and to store all ray requests with the same execution path other than the target ray request in the wait queue included in the TBU. The conflict resolution module is used to redetermine the target ray request based on the waiting queue and the preset priority judgment mechanism, until all ray requests with the same execution path are written into the same shader binding table slot.

[0041] For example, the priority determination mechanism can be to set the priority of each ray request corresponding to the RTU to the highest priority in a round-robin manner, and then determine the target ray request from the ray requests sent by each RTU according to the priority of each RTU.

[0042] For example, taking a TBU corresponding to two RTUs, namely RTU0 and RTU1, first set the priority of RTU0 to the highest priority and use RTU0's ray request as the target ray request. If a request conflict occurs again later, the priority of RTU1 can be set to the highest priority and RTU1's ray request can be used as the target ray request.

[0043] Once the target ray request is identified, it indicates that the target ray request can be written into the corresponding shader binding table slot by the TBU at the current moment. Therefore, at this time, the TBU can write the target ray request into the shader binding table slot.

[0044] Since TBU can only write one ray request to the shader binding table slot at a time, other ray requests can be stored in the wait queue included in TBU so that the ray requests in the wait queue can be written to in the next time step or period.

[0045] Since a ray request with the same execution path as the ray request in the waiting queue may appear in the next time period or cycle, the conflict judgment module can also re-determine the target ray request according to the waiting queue and the preset priority judgment mechanism, until all ray requests with the same execution path are written into the same shader binding table slot.

[0046] In this embodiment, a priority judgment mechanism is used to clearly define the target ray request, ensuring that the TBU writes only one ray request at a time, thus resolving write conflicts and single-path overload or latency accumulation issues. Other ray requests are stored in a waiting queue to retain them and prevent ray request loss, so that all ray requests can be written to the corresponding colorimeter binding table slots later.

[0047] In some embodiments, the priority determination mechanism may also set the priority of RTU0 to a fixed highest priority. However, setting the priority of RTU0 to a fixed highest priority will cause the ray requests of other RTUs to always be stored in the waiting queue, making it difficult to write them into the shader binding table slot, thus affecting the execution of subsequent tasks.

[0048] To balance the number of ray requests written by each RTU, the priority determination mechanism can also set other RTUs to the highest priority when a preset switching condition is met, and then set the priority of the RTUs back to the fixed highest priority. The aforementioned mechanism of temporarily setting other RTUs to the highest priority can also be called a dynamic compensation mechanism.

[0049] In some embodiments, when determining the target ray request among ray requests with the same execution path according to a preset priority judgment mechanism, the conflict judgment module may, if it is determined that there is no compensating RTU among the RTUs corresponding to the ray requests with the same execution path, determine the RTU marked as the target static priority identifier as the highest priority among the RTUs corresponding to the ray requests with the same execution path; if it is determined that there is a compensating RTU among the RTUs corresponding to the ray requests with the same execution path, determine the priority of the compensating RTU as the highest priority. The conflict assessment module is used to identify the ray request of the highest priority RTU among ray requests with the same execution path as the target ray request.

[0050] In some embodiments, when the priority determination mechanism sets the priority of RTU0 to a fixed highest priority, a specific priority identifier can be assigned to RTU0 to indicate that the priority of RTU0 is a fixed highest priority. For example, the identifier of RTU0 can be set to a target static priority identifier.

[0051] For dynamic compensation mechanisms, in order to distinguish whether the priority of the RTU is a temporary highest priority or a fixed highest priority, the identifier of the RTU to be compensated can be set as a compensation identifier.

[0052] The target static priority identifier and compensation identifier can be set as needed, and there can be a difference between the two. For example, the target static priority identifier and compensation identifier can be set to x1 and x2 respectively.

[0053] In some embodiments, due to the existence of a dynamic compensation mechanism, the highest priority may not be the default RTU0. It can be determined first whether there is a compensated RTU in the RTU corresponding to each ray request in order to determine the target ray.

[0054] Specifically, if the identifier of the RTU corresponding to each ray request with the same execution path is not a compensation identifier, it indicates that there is no compensation RTU among the RTUs corresponding to each ray request with the same execution path. In this case, the highest priority RTU is the RTU identified as the target static priority identifier. Therefore, the ray request corresponding to the RTU identified as the target static priority identifier is determined as the target ray request.

[0055] If the RTUs corresponding to each ray request with the same execution path have a compensation identifier, it indicates that there is a compensation RTU among the RTUs corresponding to each ray request with the same execution path, and the RTU with the compensation identifier has the highest priority. Therefore, the ray request corresponding to the RTU with the compensation identifier is determined as the target ray request.

[0056] It should be noted that RTU0 typically handles ray requests for Primary Rays and Closest-Hit related main path rays. By setting the priority of the RTU sending the main path ray request to a fixed highest priority, the latency of the main path ray request can be ensured to be low and the throughput efficiency high in various scenarios. In addition, by setting a dynamic compensation mechanism, the number of ray requests from other RTUs can be balanced, ensuring the scheduling fairness of each RTU and the overall write efficiency.

[0057] In some embodiments, when setting the identifiers of each RTU, only the identifier of the highest priority RTU may be set as the target static priority identifier, without setting a compensation identifier. When determining the priority of each RTU, the priority of the RTU with the identifier of the target static priority identifier is directly determined as the highest priority, and the ray request of that RTU is taken as the target ray request.

[0058] In some embodiments, as described above, even if other ray requests are stored in the waiting queue, a ray request with the same execution path as the ray request in the waiting queue may appear in the next time period or cycle. In order to identify the next target ray request, the conflict judgment module can be used to re-execute the step of determining the target ray request among the ray requests with the same execution path in the ray requests of the next time period received by the TBU, according to the preset priority judgment mechanism. If, among the ray requests received by the TBU in the next time period, there is no ray request with the same execution path as the ray request in the waiting queue, the ray request in the waiting queue is identified as the target ray request.

[0059] After a target ray request is identified, it is written to the colorimeter binding table slot. The TBU can then obtain ray requests from each RTU in the next time period and re-perform conflict resolution. The objects involved in this conflict resolution include all ray requests in the waiting queue and the obtained ray requests from each RTU in the next time period. For ray requests in the waiting queue whose execution paths differ from those of the obtained ray requests from each RTU in the next time period, the TBU can directly perform the write operation. However, for ray requests in the waiting queue whose execution paths are the same as those of the obtained ray requests from each RTU in the next time period, the target ray request needs to be re-identified.

[0060] It should be noted that since one TBU can correspond to at least two RTUs, when at least two ray requests have the same execution path, after initially determining the target ray request for the current moment, the number of ray requests stored in the waiting queue is at least one. If the number of ray requests stored in the waiting queue is greater than one, even if none of the ray requests received by the TBU in the next time period have the same execution path as the ray requests in the waiting queue, the step of determining the target ray request among the ray requests with the same execution path according to the preset priority judgment mechanism must be re-executed. For the sake of brevity, this content has not been repeated above.

[0061] In this embodiment, since the TBU can write a target ray request into the colorimeter binding table slot at any given time, even if the ray request is written to the waiting queue, it cannot be directly written into the colorimeter binding table slot at the next time step. The problem of write operation conflicts for the TBU can be resolved by repeatedly performing conflict checks.

[0062] In some embodiments, in order to ensure the normal operation of the dynamic compensation mechanism, after the ray request of the highest priority RTU is determined as the target ray request, the conflict judgment module is used to count the number of times the RTU with the target static priority identifier is determined as the highest priority RTU; if the number is greater than the preset number, the compensation RTU is determined from the RTUs corresponding to each ray request in the waiting queue.

[0063] Understandably, the preset switching conditions can be set as needed. For example, the preset switching condition can be set to the number of times the RTU with the target static priority identifier is determined as the highest priority RTU is greater than a preset number. Therefore, to determine whether the preset switching conditions are currently met, the number of times the RTU with the target static priority identifier is determined as the highest priority RTU can be counted, and it can be determined whether this number is greater than the preset number. If so, the preset switching conditions are currently met, and the compensation RTU can be determined. If not, the preset switching conditions are not currently met, and the fixed highest priority priority judgment mechanism will still be used. The preset number can be set as needed, specifically through dynamic hardware configuration or as a fixed parameter; for example, it can be set to 4 times.

[0064] In some embodiments, a polling method is used to sequentially identify each RTU as a compensation RTU when determining the compensation RTU. For example, the waiting queue stores ray requests for RTU1 and RTU2. Neither RTU1 nor RTU2 is a fixed highest-level RTU. RTU1 can be used as the compensation RTU initially, and RTU2 can be used as the compensation RTU the next time a conflict occurs.

[0065] In some embodiments, the waiting time for each ray request in the waiting queue can also be determined, and the RTU corresponding to the ray request with the longest waiting time can be used as the compensation RTU.

[0066] In some embodiments, the total number of ray requests stored in the waiting queue for each RTU can be counted, and the RTU with the largest total number of ray requests is determined as the compensation RTU. The total number of ray requests stored in the waiting queue is the sum of the number of ray requests currently in the waiting queue and the number of ray requests stored in the waiting queue before the current time but subsequently retrieved.

[0067] It should be noted that the dynamic compensation mechanism will only take effect in the next conflict if the currently determined compensation RTU is identified. In other words, the currently determined compensation RTU can be used to identify the ray request of the compensation RTU as the target ray request in the next conflict.

[0068] In this embodiment, a dynamic compensation mechanism is used to temporarily set the RTU to the highest priority, ensuring that each RTU can complete at least one write operation and preventing any RTU from remaining idle for extended periods. Furthermore, this dynamic compensation mechanism guarantees that the RTU with the fixed highest priority has priority processing rights for most of the time period, ensuring the write efficiency of the main path ray requests, improving load balancing, and maintaining low latency in launch decisions.

[0069] In some embodiments, to facilitate the TBU in determining whether a compensating RTU exists during the next conflict assessment, a compensation identifier can be assigned to the compensating RTU when it is currently identified. Therefore, the conflict assessment module is used to assign a compensation identifier to the compensating RTU. If the identifier of the RTU corresponding to each ray request with the same execution path includes the compensation identifier, it is determined that there is a compensation RTU among the RTUs corresponding to each ray request with the same execution path; If the identifier of the RTU corresponding to each ray request with the same execution path does not include the compensation identifier, then it is determined that there is no compensation RTU among the RTUs corresponding to each ray request with the same execution path. If a compensation RTU exists among the RTUs corresponding to each ray request with the same execution path, the compensation RTU is set to the highest priority, and then the compensation identifier of the compensation RTU is cleared.

[0070] Furthermore, the number of times an RTU is used as a compensation RTU can be controlled. For example, if the number of compensation RTUs is set to twice, then if a compensation RTU exists among the RTUs corresponding to each ray request with the same execution path, the priority of the compensation RTU is set to the highest priority, and the compensation identifier of the compensation RTU is retained. In the next conflict, if a compensation RTU is found among the RTUs corresponding to each ray request with the same execution path, the priority of the compensation RTU is set to the highest priority again, and the compensation identifier of the compensation RTU is cleared.

[0071] If the number of compensation RTUs is one, then if a compensation RTU exists among the RTUs corresponding to the ray requests with the same execution path, the priority of the compensation RTU is set to the highest priority, and then the compensation identifier of the compensation RTU is cleared.

[0072] For example, if the preset number of RTU compensations is n, after repeatedly executing n-1 times to determine the priority of the compensation RTU as the highest priority, the step of retaining the compensation identifier of the compensation RTU is executed. After the nth execution to determine the priority of the compensation RTU as the highest priority, the step of clearing the compensation identifier of the compensation RTU is executed.

[0073] In this embodiment, configuring a compensation identifier for the compensation RTU facilitates subsequent determination based on the compensation identifier whether any RTUs corresponding to the same ray requests along the same execution path exist as compensation RTUs, which is quite convenient. The number of compensation attempts can be controlled by clearing the compensation identifier, and by dynamically adjusting the number of compensation attempts, the problem of severe congestion during ray request writing for compensation RTUs can be resolved.

[0074] In some embodiments, after conflict resolution, the TBU can write the ray requests of at least two RTUs into the corresponding shader binding table slots in parallel, enabling at least two RTUs to participate in block filling in a unified manner. Each shader binding table slot includes ray requests for one execution path, resulting in high task purity and no mixed heterogeneous tasks. Consequently, there is no branching during SIMD execution, reducing idle mask waste and ensuring high wavefront execution purity. In other words, dual-path block filling or multi-path block filling can form a denser and more consistent wavefront, thereby improving the SIMD efficiency of subsequent shader scheduling.

[0075] As business operations change or other external factors influence the process, the ray submission rate of each RTU may also vary. For example, the ray submission rate of RTU0 may drop significantly, indicating that the importance of RTU0's ray requests may be decreasing. As the ray submission rate changes, the corresponding RTU priorities should also be adjusted accordingly to ensure that more important ray requests are written to the shader binding table slots in a timely manner.

[0076] In some embodiments, in order to adapt to such changes in a timely manner and reduce the impact on write ray requests, the TBU is used to count the number of ray requests sent by each RTU corresponding to the TBU to the TBU within a unit time period according to a preset time period; and adjust the priority of each RTU according to the number of each ray.

[0077] For example, the ray submission rate refers to the number of rays requested by each RTU corresponding to the TBU to the TBU per unit time. Based on statistics collected over a preset time period, the RTU corresponding to the highest fixed level can be switched according to the statistical results within that period.

[0078] In some embodiments, priority can be adjusted by changing the identifier of each RTU.

[0079] For example, after determining the ray submission rate of each RTU in the current time period, the ray submission rates of each RTU can be compared, and the identifier of the RTU with the highest ray submission rate can be determined as the target static priority identifier, so that the priority of the RTU with the highest ray submission rate is set as the fixed highest priority.

[0080] In this embodiment, by adjusting the priority of each RTU through the ray submission rate, the dual-channel or multi-channel input ratio of the TBU can be adjusted, which can ensure the ray request write efficiency of the RTU with higher importance and achieve adaptive allocation.

[0081] Continue Figure 1 For example, taking one TBU corresponding to two RTUs as an example, the process of interaction between various hardware modules in the graphics processor is explained.

[0082] Specifically, RTU0 and RTU1 simultaneously generate ray requests, carrying fields such as Shader type. TBU receives the requests and categorizes them according to the Shader type. The SBT ID is determined using information such as the instance ID in the ray request. The SBT ID is then used to determine if the execution paths of the two ray requests are the same. If the two ray requests point to the same SBT slot, the conflict resolution module makes the decision. The priority target ray request is immediately written to its corresponding SBT slot, while the other ray request is temporarily stored in a waiting queue, to be filled when the slot is released in the next cycle. After the chunking is completed, if the shader binding table slots meet preset conditions, the shader binding table slots are assembled into a Single Instruction Multiple Data Stream (SMD) thread bundle, and the SMD thread bundle is sent to the shader execution unit for execution.

[0083] In this embodiment, by using three mechanisms—parallel input, conflict determination, and dynamic balancing—the block efficiency and wavefront utilization of the TBU are improved without increasing hardware complexity.

[0084] It should be noted that although the above embodiments of this application describe the specific graphics processor's block division method from the perspective of method implementation logic, the methods of the above embodiments can be implemented in hardware, for example, through the hardware implementation of the graphics processor.

[0085] Specifically, embodiments of this application provide a graphics processor, a method for partitioning a graphics processor, an apparatus, a medium, and a product. The execution entity of the graphics processor partitioning method in this application embodiment can be a graphics processor. The graphics processor includes an RTU, a TBU, and a shader execution unit; at least two RTUs correspond to one TBU, and specifically, the TBU can be used as the execution entity.

[0086] Figure 2A flowchart illustrating a graphics processor segmentation method according to an embodiment of this application is shown. Figure 2 As shown, the method includes steps S201 to S205.

[0087] S201, Receive ray requests sent by at least two RTUs corresponding to the TBU.

[0088] S202, based on the path information in each ray request, determine which ray requests have the same execution path.

[0089] S203, write all ray requests with the same execution path to the same shader binding table slot.

[0090] S204, if the shader binding table slot meets the preset conditions, assemble the shader binding table slot into a single instruction multiple data stream thread bundle.

[0091] S205 sends the Single Instruction Multiple Data Stream (SMD) thread bundle to the shader execution unit.

[0092] In this embodiment, no additional global scheduling unit is required. By mapping multiple RTUs to one TBU, the number of ray requests received by the TBU can be increased, thereby increasing the number of ray requests with the same execution path. The TBU can then acquire more ray requests with the same execution path in a shorter time, reducing idle periods and improving the efficiency of writing ray requests with the same execution path into shader binding table slots, thus improving the efficiency of obtaining execution results. This can also be understood as reducing wavefront divergence and improving SIMD parallelism by merging similar types of rays from two RTUs. Furthermore, by mapping multiple RTUs to one TBU, the number of TBUs used can be reduced, thereby reducing hardware costs and improving economic efficiency. This solves the problem that in scenarios with severe divergence, multiple independent TBUs cannot share thread grouping opportunities, leading to a decrease in SIMD wavefront efficiency.

[0093] In some embodiments, determining ray requests with the same execution path based on path information in each ray request includes: If all ray requests are sent to the TBU at the same time and at least two ray requests have the same execution path, the target ray request is determined among the ray requests with the same execution path according to the preset priority judgment mechanism. Write the target ray request to the shader binding table slot; store all ray requests with the same execution path other than the target ray request in the wait queue included in the TBU; Based on the waiting queue and the preset priority judgment mechanism, the target ray request is re-determined until all ray requests with the same execution path are written into the same shader binding table slot.

[0094] In some embodiments, a target ray request is determined among ray requests with the same execution path according to a preset priority determination mechanism, including: If there is no compensating RTU among the RTUs corresponding to the same ray requests, the RTU marked with the target static priority identifier will be determined as the highest priority RTU among the RTUs corresponding to the same ray requests. If a compensation RTU exists among the RTUs corresponding to the same ray requests, the priority of the compensation RTU is set to the highest priority. Among the ray requests with the same execution path, the ray request of the highest priority RTU is determined as the target ray request.

[0095] In some embodiments, the target ray request is re-determined based on the waiting queue and a preset priority determination mechanism until all ray requests with the same execution path are written into the same shader binding table slot. The method further includes: The number of times the RTU with the target static priority identifier is determined as the highest priority RTU is counted; if the number exceeds the preset number, the compensation RTU is determined from the RTUs corresponding to each ray request in the waiting queue.

[0096] In some embodiments, the method further includes: Assign a compensation identifier to the compensation RTU; It was determined that among the RTUs corresponding to the ray requests with the same execution path, there are compensated RTUs, including: If the identifier of the RTU corresponding to each ray request with the same execution path includes the compensation identifier, it is determined that there is a compensation RTU among the RTUs corresponding to each ray request with the same execution path; It was determined that none of the RTUs corresponding to the ray requests with the same execution path contained a compensation RTU, including: If the identifier of the RTU corresponding to each ray request with the same execution path does not include the compensation identifier, then it is determined that there is no compensation RTU among the RTUs corresponding to each ray request with the same execution path. If, after determining that there is a compensating RTU among the RTUs corresponding to the same ray requests, the priority of the compensating RTU is set to the highest priority, the method further includes: Clear the compensation flag of the compensation RTU.

[0097] In some embodiments, after sending the single instruction multiple data stream (SMILE) thread bundle to the shader execution unit, the method further includes: According to the preset time period, count the number of rays sent by each RTU corresponding to the TBU to the TBU within a unit time period; adjust the priority of each RTU according to the number of rays.

[0098] In some embodiments, the target ray request is re-determined based on the waiting queue and a preset priority determination mechanism until all ray requests with the same execution path are written into the same shader binding table slot, including: If, among the ray requests received by the TBU in the next time period, there is a ray request with the same execution path as the ray request in the waiting queue, the step of determining the target ray request among the ray requests with the same execution path is re-executed according to the preset priority judgment mechanism. If, among the ray requests received by the TBU in the next time period, there is no ray request with the same execution path as the ray request in the waiting queue, the ray request in the waiting queue is identified as the target ray request.

[0099] In some embodiments, before determining ray requests with the same execution path based on path information in each ray request, the method further includes: Based on the path information in each ray request, determine the shader type corresponding to each ray request; group ray requests of the same shader type into the same group; for each group, determine the ray requests with the same execution path based on the preset index table and the path differentiation identifier of each ray request in the group.

[0100] Figure 3 This is a schematic diagram of the structure of an electronic device 10 provided for an embodiment of this application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0101] like Figure 3As shown, the electronic device 10 includes at least one graphics processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one graphics processor 11. The memory stores computer programs executable by the at least one graphics processor. The graphics processor 11 can perform various appropriate actions and processes based on the computer programs stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The graphics processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0102] Multiple components in electronic device 10 are connected to input / output (I / O) interface 15, including: input unit 16, such as a keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as a disk, optical disk, etc.; and communication unit 19, such as a network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0103] The graphics processor 11 can be any dedicated graphics processing component with processing and computing capabilities. The graphics processor 11 performs the various methods and processes described above, such as the graphics processor's tile-based method.

[0104] In some embodiments, the graphics processor's chunking method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by graphics processor 11, one or more steps of the graphics processor's chunking method described above may be performed. Alternatively, in other embodiments, graphics processor 11 may be configured to perform the graphics processor's chunking method by any other suitable means (e.g., by means of firmware).

[0105] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: implementation in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable graphics processor, which may be an application-specific programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0106] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to the graphics processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the graphics processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0108] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0109] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include: Local Area Networks (LANs), Wide Area Networks (WANs), blockchain networks, and the Internet.

[0110] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0111] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0112] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A graphics processor, characterized in that, The graphics processor includes a ray traversal unit (RTU), a thread partitioning unit (TBU), a conflict resolution module, and a shader execution unit, wherein at least two RTUs correspond to one TBU, and: The RTU is used to send a ray request to the corresponding TBU; The TBU is used to receive ray requests sent by at least two RTUs corresponding to the TBU; determine the ray requests with the same execution path according to the path information in each ray request; write the ray requests with the same execution path into the same shader binding table slot; when the shader binding table slot meets the preset conditions, assemble the shader binding table slot into a single instruction multiple data stream thread bundle, and send the single instruction multiple data stream thread bundle to the shader execution unit; The conflict assessment module is used to determine the target ray request among the ray requests with the same execution path when all the ray requests are sent to the TBU at the same time and at least two of the ray requests have the same execution path, according to a preset priority judgment mechanism. The TBU is used to write the target ray request into the shader binding table slot; The conflict assessment module is used to re-evaluate the priority at the next moment or period, and the TBU continues to execute the ray request write operation.

2. The graphics processor as described in claim 1, characterized in that, The TBU is used to write the target ray request into the shader binding table slot; and to store all ray requests with the same execution path other than the target ray request in the waiting queue included in the TBU. The conflict assessment module is used to re-determine the target ray request based on the waiting queue and the preset priority judgment mechanism, until all the ray requests with the same execution path are written into the same shader binding table slot.

3. The graphics processor as described in claim 2, characterized in that, The conflict assessment module is used to determine the RTU marked with the target static priority identifier as the highest priority RTU among the RTUs corresponding to the ray requests with the same execution path, when there is no compensation RTU among the RTUs corresponding to the ray requests with the same execution path. If a compensation RTU exists among the RTUs corresponding to the ray requests with the same execution path, the priority of the compensation RTU is determined to be the highest priority; The conflict assessment module is used to determine the ray request of the highest priority RTU as the target ray request among the ray requests with the same execution path. The conflict assessment module is used to count the number of times the RTU with the target static priority identifier is determined as the highest priority RTU; If the number of requests exceeds a preset number, a compensation RTU is determined from the RTUs corresponding to each ray request in the waiting queue.

4. The graphics processor as described in claim 3, characterized in that, The conflict assessment module is used to assign a compensation identifier to the compensation RTU; If the identifier of the RTU corresponding to each ray request with the same execution path includes a compensation identifier, it is determined that there is a compensation RTU among the RTUs corresponding to each ray request with the same execution path; If the identifier of the RTU corresponding to each ray request with the same execution path does not include the compensation identifier, it is determined that there is no compensation RTU among the RTUs corresponding to each ray request with the same execution path; If a compensation RTU exists among the RTUs corresponding to the ray requests with the same execution path, the compensation RTU is set to the highest priority, and then the compensation identifier of the compensation RTU is cleared.

5. The graphics processor as described in claim 3, characterized in that, The TBU is used to count the number of ray requests sent by each RTU corresponding to the TBU to the TBU within a unit time period according to a preset time period; and to adjust the priority of each RTU according to the number of rays.

6. The graphics processor as described in claim 2, characterized in that, The conflict assessment module is used to re-execute the step of determining the target ray request among the ray requests with the same execution path as the ray request in the waiting queue in each of the ray requests in the next time period received by the TBU, according to a preset priority judgment mechanism. If, among the ray requests received by the TBU in the next time period, there is no ray request with the same execution path as the ray request in the waiting queue, the ray request in the waiting queue is identified as the target ray request.

7. The graphics processor as claimed in claim 1, characterized in that, The TBU is used to determine the shader type corresponding to each ray request based on the path information in each ray request; The ray requests of the same shader type are grouped together; for each group, the ray requests with the same execution path are determined according to the preset index table and the path identification identifier of each ray request in the group.

8. A method for partitioning a graphics processor, characterized in that, The graphics processor includes a ray traversal unit (RTU), a thread partitioning unit (TBU), a conflict resolution module, and a shader execution unit. At least two RTUs correspond to one TBU. The method is applied to the TBU, and the method includes: Receive ray requests sent by at least two RTUs corresponding to the TBU; Based on the path information in each of the ray requests, determine the ray requests with the same execution path; Write all ray requests with the same execution path to the same shader binding table slot; If the shader binding table slot meets the preset conditions, the shader binding table slot is assembled into a single instruction multiple data stream thread bundle; The single instruction multiple data stream thread bundle is sent to the shader execution unit; Write all ray requests with the same execution path to the same shader binding table slot, including: If all the ray requests are sent to the TBU at the same time, and at least two of the ray requests have the same execution path, the target ray request is determined among the ray requests with the same execution path according to the preset priority judgment mechanism; the target ray request is written into the shader binding table slot; the priority judgment is performed again at the next time or period, and the ray request writing operation is continued.

9. An electronic device, characterized in that, The electronic device includes: a graphics processor as described in any one of claims 1 to 7.

10. A computer-readable storage medium, wherein the computer-readable storage medium is a non-volatile storage medium or a non-transient storage medium, having a computer program thereon, characterized in that, The computer program is executed by the processor to perform the steps of the graphics processor segmentation method of claim 8.

Images