A method and apparatus for asynchronous rendering across GPUs

Abstract

The application provides a cross-GPU asynchronous rendering method and device, and relates to the technical field of graphic rendering. The method comprises the following steps: generating task descriptors of a plurality of processing tasks based on scene description data; determining a dependency relationship between the processing tasks based on the task descriptors of the plurality of processing tasks; constructing a directed acyclic graph based on the dependency relationship between the processing tasks; obtaining hardware parameters of a plurality of GPUs; and distributing the plurality of processing tasks to a plurality of target GPUs based on the directed acyclic graph and the hardware parameters of the plurality of GPUs, so that the target GPUs asynchronously execute the distributed processing tasks to obtain a rendered image. The application can reduce the idle rate of the GPUs.

Description

Technical Field

[0001] This application relates to the field of graphics rendering technology, and in particular to an asynchronous rendering method and apparatus across GPUs. Background Technology

[0002] As computer graphics are increasingly applied in fields such as games, film and television rendering, and virtual simulation, the complexity of scenes and the demand for image quality continue to increase. The computing power of a single GPU (Graphics Processing Unit) is no longer sufficient to meet the performance requirements of real-time rendering. Cross-GPU collaborative rendering has become a key technology direction for breaking through performance bottlenecks.

[0003] The existing task management solution uses a blocking queue. The CPU needs to organize rendering commands in a strict order. The task submission and execution processes are coupled. New tasks can only be submitted after the tasks in the queue have been completed. The GPU executes stages such as geometry rasterization in a pipeline manner, which causes the GPU to be frequently idle due to task dependency chain blocking. Summary of the Invention

[0004] This application is made in view of at least one of the above-mentioned technical problems existing in the prior art, and the application is able to reduce the idle rate of GPU.

[0005] In a first aspect, embodiments of this application provide an asynchronous rendering method across GPUs, comprising: Based on the scene description data, generate task descriptors for multiple processing tasks; Based on the task descriptors of the multiple processing tasks, the dependencies between the processing tasks are determined; Based on the dependencies between the processing tasks, a directed acyclic graph is constructed; Obtain hardware parameters for multiple GPUs; Based on the directed acyclic graph and the hardware parameters of the multiple GPUs, the multiple processing tasks are assigned to multiple target GPUs, so that the multiple target GPUs execute the assigned processing tasks asynchronously to obtain a rendered image; wherein, different target GPUs transfer data based on the dependency relationship.

[0006] Secondly, embodiments of this application provide an asynchronous rendering apparatus across GPUs, comprising: The generation module is configured to generate task descriptors for multiple processing tasks based on scene description data; The construction module is configured to determine the dependencies between the processing tasks based on the task descriptors of the multiple processing tasks; and to construct a directed acyclic graph based on the dependencies between the processing tasks. The allocation module is configured to acquire the hardware parameters of multiple GPUs; based on the directed acyclic graph and the hardware parameters of the multiple GPUs, allocate the multiple processing tasks to multiple target GPUs, so that the multiple target GPUs asynchronously execute the allocated processing tasks to obtain a rendered image; wherein, different target GPUs transfer data based on the dependency relationship.

[0007] This application provides a cross-GPU asynchronous rendering method and apparatus that decouples the rendering task into multiple processing tasks through task descriptors and directed acyclic graphs, enabling concurrent execution of stages that traditionally must be performed sequentially, such as texture processing, geometry rasterization, pixel calculation, and physics calculation. By allocating processing tasks, each GPU undertakes a processing task matched to its hardware characteristics, avoiding the problem of strong GPUs being idle and weak GPUs being overloaded caused by load sharing in traditional solutions. Simultaneously, the asynchronous execution mechanism allows GPUs to start only when local dependencies are met, without waiting for the overall task queue, significantly reducing GPU idle rates. Attached Figure Description

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

[0009] Figure 1 This is a flowchart illustrating an asynchronous rendering method across GPUs, provided in one embodiment of this application. Figure 2 This is a flowchart of an asynchronous rendering method across GPUs provided in another embodiment of this application; Figure 3 This is a flowchart of an asynchronous rendering method across GPUs provided in another embodiment of this application; Figure 4 This is a schematic diagram of an asynchronous rendering apparatus across GPUs provided in one embodiment of this application. Detailed Implementation

[0010] To enable those skilled in the art to better understand the technical solutions of the embodiments of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] like Figure 1As shown in the figure, this application embodiment provides an asynchronous rendering method across GPUs, including: Step 101: Generate task descriptors for multiple processing tasks based on the scene description data.

[0012] Scene description data includes scene geometry information (such as triangle meshes and vertex coordinates), texture resources (such as image files and material properties), lighting parameters (such as light source position and intensity), physical rules (such as gravity and collision threshold), and other information required for rendering.

[0013] A task descriptor is structured data that encapsulates a task. It may contain fields such as task ID, task type, priority, required GPU resource handle, and execution function pointer. (Task types include texture processing, geometric rasterization, pixel calculation, and physics calculation.) This step breaks down rendering tasks into functional modules of the rendering process to ensure that each processing task has the integrity to be executed independently. The specific breakdown logic can be determined based on actual needs.

[0014] Step 102: Determine the dependencies between processing tasks based on the task descriptors of multiple processing tasks.

[0015] Dependencies can include: data dependencies, such as task B needing to use the texture data output by task A; and logical dependencies, such as pixel calculations needing to be performed after geometric rasterization.

[0016] Dependencies can be determined by resolving task descriptors. For example, if the output resource handle of task 1 is the same as the input resource handle of task 2, then there is a dependency between them.

[0017] Step 103: Construct a directed acyclic graph based on the dependencies between processing tasks.

[0018] Treat the processing tasks as nodes and the dependencies as directed edges.

[0019] Step 104: Obtain hardware parameters for multiple GPUs.

[0020] Hardware parameters can include: computing power parameters (such as FP32 and FP16 computing capabilities), functional parameters (such as the number of ray tracing cores and the proportion of computing units), and resource parameters (such as memory bandwidth, L2 cache size, and memory capacity). Hardware parameters can be collected through the GPU driver query interface.

[0021] Step 105: Based on the directed acyclic graph and the hardware parameters of multiple GPUs, multiple processing tasks are assigned to multiple target GPUs so that the multiple target GPUs execute the assigned processing tasks asynchronously to obtain the rendered image; wherein, different target GPUs transfer data based on dependencies.

[0022] Task allocation employs a capability matching and load balancing strategy. For example, ray tracing tasks are assigned to GPUs with sufficient ray tracing cores, computationally intensive tasks are assigned to GPUs with high computing power, and a directed acyclic graph ensures that processing tasks with dependencies are assigned to GPUs that can collaborate.

[0023] The target GPU does not need to wait for other GPUs to complete all tasks; it only needs to wait for the prerequisites of the task it is executing to complete before it can start execution, and it does not block the tasks of other GPUs during the execution process.

[0024] This application's embodiments decouple the rendering task into multiple processing tasks using task descriptors and directed acyclic graphs, enabling concurrent execution of stages that traditionally must be performed sequentially, such as texture processing, geometric rasterization, pixel calculation, and physics calculation. By allocating processing tasks, each GPU undertakes a processing task matching its hardware characteristics, avoiding the problem of strong GPUs being idle and weak GPUs being overloaded caused by load sharing in traditional solutions. Simultaneously, the asynchronous execution mechanism allows GPUs to start only when local dependencies are met, without waiting for the overall task queue, significantly reducing GPU idle rates.

[0025] In one embodiment of this application, task descriptors for multiple processing tasks are generated based on scene description data, including: Based on scene description data, task descriptors for multiple processing tasks are generated in parallel; these multiple processing tasks include multiple tasks such as texture processing, geometric rasterization, pixel calculation, and physical calculation.

[0026] This application breaks away from the traditional method of serially decomposing scene data and serially generating task descriptors. Instead, it adopts a parallel approach to complete the conversion from scene description data to standardized task descriptors, thereby improving rendering efficiency.

[0027] Scene description data is split into functional modules, such as texture data for texture processing and geometric data for geometric rasterization, and allocated to different CPU threads. Each thread independently completes the parsing of the corresponding data and the generation of task descriptors. For example, thread 1 generates texture tasks based on texture data, and there is no mutual blocking between threads.

[0028] Texture processing can include subtasks such as texture data loading, mipmap generation, LOD (Level of Detail), and texture mapping parameter configuration, providing texture resources for rendering.

[0029] Geometric rasterization can include subtasks such as triangle mesh subdivision and simplification, vertex and index buffer construction, and is the geometric foundation of rendering.

[0030] Pixel computing can include subtasks such as lighting calculation, ray tracing, material shading, and pixel color blending, which determine the final visual effect of the image.

[0031] Physics calculations can include subtasks such as rigid body collision detection, fluid simulation, object position update, and physical state synchronization, supporting real-time rendering of dynamic scenes.

[0032] The rendering task can be flexibly broken down according to the complexity of the scene. It can include all four types, such as a complex game scene, or it can be 2-3 types, such as a simple static visualization scene, which may not require physical calculations.

[0033] This application embodiment improves the efficiency of task descriptor generation by distributing the originally serial parsing work through parallel generation.

[0034] In one embodiment of this application, task descriptors for multiple processing tasks are generated in parallel based on scene description data, including: Based on the viewport distance and angle in the scene description data, determine the detail level of the texture; Based on the detail level of the texture, a task descriptor for texture processing is generated; the task descriptor for texture processing is used to instruct the GPU to load the texture data corresponding to the detail level and process it.

[0035] The viewport distance and angle in the scene description data determine the human eye's perception requirements for texture details. Textures with a closer viewport distance and a more frontal angle are assigned a higher level of detail to retain more texture details; textures with a farther viewport distance and a more off-center angle are assigned a lower level of detail to simplify texture details and avoid wasting resources by loading high-resolution textures from distant locations and off-center angles.

[0036] The task descriptor for texture processing will clearly indicate the level of detail, the texture data address at the corresponding resolution, and the texture processing operation instructions, such as texture decompression, mipmap completion, and texture coordinate mapping.

[0037] In traditional rendering schemes, texture processing often uses a full-resolution loading method, loading the highest resolution texture data regardless of the texture's distance from the viewport or the viewing angle. This results in a large amount of high-resolution data from distant, off-view textures becoming invalid resources. This not only consumes GPU memory but also increases the computational load of GPU texture processing and data transfer overhead. The embodiments of this application dynamically determine the Level of Detail (LOD) based on viewport distance and viewing angle, generating only texture processing tasks for the corresponding layer. This allows the GPU to load and process only the texture data required for the current rendering, eliminating invalid loading and computation at the source and significantly reducing resource waste in the texture processing stage.

[0038] In one embodiment of this application, task descriptors for multiple processing tasks are generated in parallel based on scene description data, including: Based on the geometric model information in the scene description data and the current view frustum parameters, potential visible objects located within the view frustum are filtered out. Determine the geometric detail level of potential visible objects; Based on the dynamic transformation data output from the previous frame's physical calculations and the geometric detail level of potentially visible objects, a geometric rasterization task descriptor is generated. The geometric rasterization task descriptor is used to instruct the GPU to perform any one or more of the following operations on the geometric model information: vertex transformation, surface tessellation, viewport clipping, and rasterization.

[0039] Geometric model information can include basic geometric data such as vertex coordinates and surface parameters of objects in the scene. Current view frustum parameters can include the camera's near clipping plane, far clipping plane, left, right, top, and bottom clipping planes, field of view angle, and camera position, which determine the camera's visible range and viewing angle.

[0040] Based on the current view frustum parameters, determine whether the bounding box of the geometric object intersects with the view frustum. Only retain potential visible objects within the intersection range, including objects that are completely or partially within the view frustum, and directly discard objects that are completely outside the view frustum.

[0041] Different LOD levels correspond to different levels of detail in the geometric model. Higher LOD levels preserve more vertex, triangle, and surface details, such as the detailed geometry of the face and limbs in a close-up human model. Lower LOD levels simplify the number of vertices and faces, such as the simplified geometry of a distant building. The geometric detail level is determined based on parameters such as the distance between potentially visible objects and the camera, their projected size in the viewport, and the viewing angle. Objects closer to the camera, with larger projected sizes, and facing the camera directly are assigned higher geometric LOD levels, and vice versa.

[0042] Dynamic transformation data can include dynamic parameters such as the object's displacement, rotation, scaling, and shape changes after a collision, supporting the geometric rendering of dynamic scenes, such as moving vehicles and colliding objects.

[0043] The task descriptor for geometric rasterization can include: task ID, task type, identifier of the corresponding potential visible object, geometric LOD, physical dynamic transformation parameters, GPU execution operation instructions (one or more of vertex transformation, tessellation, and viewport clipping), input geometric data address, and output result storage address.

[0044] In traditional rendering schemes, geometric rasterization requires calculations for all objects in the scene, regardless of whether they are within the camera's field of view. This results in a large amount of geometric calculations for objects invisible outside the view frustum becoming unnecessary overhead, consuming significant GPU computing resources. This application's embodiment uses view frustum filtering to retain only potentially visible objects, simplifying geometric precision by LOD (Level of Detail) and reducing unnecessary geometric calculations.

[0045] In one embodiment of this application, task descriptors for multiple processing tasks are generated in parallel based on scene description data, including: Based on the lighting configuration, post-processing effects, and rendering target definition in the scene description data, determine the rendering channel and rendering target; Based on the rendering pipeline, rendering target, texture resource identifiers pre-allocated for texture processing, and geometric resource identifiers allocated for geometric rasterization, a task descriptor for pixel computation is generated. The task descriptor for pixel computation explicitly declares the texture and geometric resources required for pixel computation and is used to instruct the GPU to perform one or more operations in fragment shading, ray tracing, or post-processing computation.

[0046] Lighting configuration can include: light source type, position, intensity, shadow attributes, and lighting model in the scene, such as global illumination and local point light sources. Post-processing effects can include: anti-aliasing, tone mapping, depth of field, and other image quality optimization requirements. Rendering target definition can include: output image resolution, color format, and render buffer type, such as screen display buffer and offline rendering texture buffer.

[0047] Defining the rendering pipeline involves splitting the pipeline into independent execution pipelines based on visual effect requirements, such as the lighting pipeline, shadow pipeline, post-processing pipeline, and ray tracing pipeline. Different rendering pipelines correspond to different pixel calculation logic. Defining the rendering target means clarifying the output carrier for each rendering pipeline. For example, the lighting pipeline outputs lighting textures, and the post-processing pipeline outputs the final display image, ensuring that the pixel calculation results have a clear storage location.

[0048] Texture resource identifiers are unique identifiers for texture processing tasks, associated with the texture data of the corresponding Level of Detail (LOD). Geometric resource identifiers are unique identifiers for geometric rasterization tasks, associated with the geometric data of potentially visible objects.

[0049] The task descriptor for pixel computation can include task ID, task type, rendering channel identifier, rendering target address, list of required texture resource identifiers, list of required geometry resource identifiers, GPU execution operation instructions (one or more of fragment shading, ray tracing post-processing computations), resource access permissions, etc.

[0050] Fragment shading calculates the final pixel color based on texture and geometry resources and lighting configuration; ray tracing performs intersection detection and reflection / refraction calculations between rays and scene objects to meet the ray tracing requirements in the rendering pipeline; post-processing calculations perform optimization operations such as anti-aliasing and tone mapping on pixel data.

[0051] This application embodiment defines the rendering channel and target, binds dedicated resources and operation instructions, so that pixel calculations only perform the required operations on the target channel and only access the associated texture and geometric resources, thereby eliminating invalid pixel calculations from the source and significantly reducing the load on GPU pixel processing.

[0052] In one embodiment of this application, task descriptors for multiple processing tasks are generated in parallel based on scene description data, including: Based on the physical world state in the scene description data, determine the sub-task division of the physics simulation; Based on the subtask partitioning results of the physics simulation, a task descriptor for physics computation is generated. The task descriptor for physics computation is used to instruct the GPU to perform any one or more of the following calculations: collision detection, motion integration, and constraint solving. The results of the physics computation are used to update the object's transformation state.

[0053] The physical world state can include: the physical properties of objects, such as mass, coefficient of friction, and elasticity coefficient; the physical rules of the scene, such as gravity, wind force, and collision threshold; and the initial motion state of objects, such as velocity and angular velocity.

[0054] Based on the functional modules of the physics simulation, the core tasks are divided into three main categories: collision detection, which determines whether a collision occurs between objects and the location of the collision; motion integration, which calculates and updates the position and velocity of objects based on the forces acting on them; and constraint solving, which handles the constraint relationships between objects, such as joint constraints and momentum conservation after a collision. In addition, specialized sub-tasks such as fluid simulation and cloth simulation can be further broken down according to the complexity of the scene.

[0055] The subtasks are not tightly coupled and can be executed independently (e.g., collision detection and motion integration can be performed in parallel); the computational load of the subtasks is roughly balanced, which is suitable for load balancing distribution across multiple GPUs.

[0056] The task descriptor for physics computation can include: task ID, task type, subtask type identifier (collision detection, motion integral, constraint solving), required physics parameters (object physical properties, scene physics rules), input data address (object initial state data), output result storage address, GPU execution operation instructions, etc.

[0057] Collision detection determines collision relationships based on the geometric boundaries of objects (associated with the aforementioned geometric resources) and outputs collision information; motion integration calculates and updates the motion state of objects using a numerical integration algorithm; constraint solving processes constraints, corrects the motion state of objects, and ensures consistency of physical rules.

[0058] This application embodiment improves physics computation efficiency by splitting physics simulation into multiple parallel subtasks and distributing them to multiple GPUs for asynchronous execution.

[0059] In one embodiment of this application, such as Figure 2 As shown, based on a directed acyclic graph and the hardware parameters of multiple GPUs, multiple processing tasks are assigned to multiple target GPUs, including: Step 201: Traverse the directed acyclic graph to identify multiple target processing tasks whose input dependencies have been satisfied.

[0060] Step 202: Based on the hardware parameters of each GPU, determine the matching degree between each target processing task and each GPU.

[0061] Step 203: Assign each target processing task to the target GPU with the highest compatibility.

[0062] Specifically, a topological sorting traversal algorithm is used to check the dependency links of nodes in the DAG one by one. If all the predecessor dependent nodes of a task node, that is, all the predecessor tasks in the DAG that point to the node, have been executed, then the input dependency is determined to be satisfied.

[0063] The target processing task has the conditions to be executed independently, without waiting for other unfinished tasks, and can be directly assigned to the GPU for execution.

[0064] The matching degree can be calculated by setting weights for each requirement dimension of the task. For example, for a ray tracing task, the weight of the ray tracing core is 60%, the weight of computing power is 30%, and the weight of memory bandwidth is 10%. After normalizing the corresponding hardware parameters of the GPU, multiply them by the weights and sum them to obtain the matching degree score between the task and the GPU. The higher the score, the stronger the adaptability.

[0065] The specific allocation priority can be as follows: First priority: the highest matching score; Second priority: GPU real-time load. If multiple GPUs have the same matching score, the GPU with the lower load is selected. The load is determined by parameters such as GPU utilization and video memory usage.

[0066] The allocation process can be implemented by generating task allocation instructions. These instructions explicitly specify the task ID, target GPU identifier, and task execution queue, and are directly sent to the target GPU through a cross-GPU scheduling interface without CPU intervention. After allocation, the target GPU reads the task from its own task queue and executes it asynchronously.

[0067] This application embodiment accurately identifies tasks that satisfy dependencies, allocates only ready tasks, eliminates dependency conflicts at the source, ensures the correctness of task execution, and avoids invalid task allocation and rollback overhead.

[0068] In one embodiment of this application, such as Figure 3 As shown, based on a directed acyclic graph and the hardware parameters of multiple GPUs, multiple processing tasks are assigned to multiple target GPUs, including: Step 301: Based on the directed acyclic graph and the hardware parameters of multiple GPUs, write the task descriptor of the processing task to the first buffer, which is currently used as the write buffer.

[0069] Step 302: When the preset conditions are met, the roles of the first buffer and the second buffer, which is used as a read buffer, are swapped through an atomic pointer swap operation.

[0070] Step 303: Read the task descriptor of the processing task from the first buffer of the swapped role read buffer to assign the processing task to the corresponding target GPU.

[0071] Initialize two equal buffers. Only one buffer is used as a write buffer at any given time for writing to the task descriptor, and the other is used as a read buffer for each GPU to read the task descriptor. The two buffers are mutually exclusive and read and write operations are completely separated.

[0072] The conditions that trigger buffer role switching are the completion of batch writing or the write buffer reaching a preset threshold, ensuring that there are enough tasks for the GPU to read in batches at each switch, and avoiding the overhead caused by frequent switching. Multiple GPUs, based on their own hardware identifiers, simultaneously scan and read the task descriptors bound to them from the read buffer without blocking each other. Each task descriptor clearly identifies the target GPU, and the GPU only reads the task corresponding to its own identifier, without needing to traverse the entire data, thus improving read efficiency; the GPU reads all the task descriptors bound to it in the buffer at once, forming a local task queue.

[0073] After the GPU completes reading all tasks in the current read buffer, the buffer becomes "idle" and can be reused as a write buffer after the next atomic pointer swap, realizing the circular reuse of the double buffer without wasting memory.

[0074] This application embodiment eliminates the lock mechanism by using dual-buffer read-write separation and atomic pointer swapping. Writes and GPU reads are executed in parallel without interference. Atomic operations ensure lock-free buffer switching, eliminating read-write conflicts and lock contention at the source and reducing the blocking rate in the task allocation process.

[0075] In one embodiment of this application, different target GPUs transfer data through shared virtual memory.

[0076] This application embodiment enables direct data access between GPUs by sharing virtual memory, eliminating the CPU relay link and the overhead of two copy operations, thereby improving data transfer efficiency.

[0077] like Figure 4 As shown, this application embodiment provides an asynchronous rendering apparatus across GPUs, including: The generation module 401 is configured to generate task descriptors for multiple processing tasks based on scene description data. Module 402 is configured to determine the dependencies between processing tasks based on task descriptors of multiple processing tasks; and to construct a directed acyclic graph based on the dependencies between processing tasks. The allocation module 403 is configured to obtain the hardware parameters of multiple GPUs; based on the directed acyclic graph and the hardware parameters of multiple GPUs, it allocates multiple processing tasks to multiple target GPUs so that the multiple target GPUs execute the allocated processing tasks asynchronously to obtain the rendered image; wherein, different target GPUs pass data based on dependency relationships.

[0078] In one embodiment of this application, the generation module 401 is configured to generate task descriptors for multiple processing tasks in parallel based on scene description data; wherein the multiple processing tasks include multiple of the following: texture processing, geometric rasterization, pixel calculation and physical calculation.

[0079] In one embodiment of this application, the generation module 401 is configured to determine the detail level of the texture based on the viewport distance and viewing angle in the scene description data; and generate a task descriptor for texture processing based on the detail level of the texture; wherein the task descriptor for texture processing is used to instruct the GPU to load the texture data corresponding to the detail level and process it.

[0080] In one embodiment of this application, the generation module 401 is configured to filter out potential visible objects located within the view frustum based on the geometric model information in the scene description data and the current view frustum parameters; determine the geometric detail level of the potential visible objects; and generate a geometric rasterization task descriptor based on the dynamic transformation data output by the physical calculation of the previous frame and the geometric detail level of the potential visible objects; wherein the geometric rasterization task descriptor is used to instruct the GPU to perform any one or more of the following operations on the geometric model information: vertex transformation, surface tessellation, viewport clipping, and rasterization.

[0081] In one embodiment of this application, the generation module 401 is configured to determine the rendering channel and the rendering target based on the lighting configuration, post-processing effect and rendering target definition in the scene description data; and generate a task descriptor for pixel computation based on the rendering channel, the rendering target, the texture resource identifier pre-allocated for texture processing and the geometric resource identifier allocated for geometric rasterization; wherein the task descriptor for pixel computation explicitly declares the texture resources and geometric resources required for pixel computation and is used to instruct the GPU to perform one or more operations in fragment shading, ray tracing or post-processing computation.

[0082] In one embodiment of this application, the generation module 401 is configured to determine the sub-task division of the physical simulation based on the physical world state in the scene description data; and generate a task descriptor for physical calculation based on the sub-task division result of the physical simulation; wherein the task descriptor for physical calculation is used to instruct the GPU to perform any one or more of collision detection, motion integration and constraint solving calculations, and the result of physical calculation is used to update the object transformation state.

[0083] In one embodiment of this application, the allocation module 403 is configured to traverse the directed acyclic graph, identify multiple target processing tasks whose input dependencies have been satisfied, determine the matching degree between each target processing task and each GPU based on the hardware parameters of each GPU, and allocate each target processing task to the target GPU with the highest matching degree.

[0084] In one embodiment of this application, the allocation module 403 is configured to write the task descriptor of the processing task into the first buffer, which is currently used as a write buffer, based on the directed acyclic graph and the hardware parameters of multiple GPUs; when a preset condition is met, the first buffer and the second buffer, which is used as a read buffer, are swapped through an atomic pointer swap operation; the task descriptor of the processing task is read from the first buffer, which has become a read buffer after the swap, so as to allocate the processing task to the corresponding target GPU.

[0085] This application provides an electronic device, including a memory and a processor. The memory stores an executable program, and the processor executes the executable program to perform the steps of the methods described in any of the above embodiments.

[0086] This application provides a computer program product that, when executed by a processor, implements the methods of any of the above embodiments.

[0087] It should be understood that in the embodiments of this application, the processor may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0088] It should also be understood that the memory mentioned in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile 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), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0089] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor.

[0090] It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.

[0091] In addition to the data bus, this bus may also include a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled "bus" in the diagram.

[0092] It should also be understood that the first, second, third, fourth and various numerical designations used herein are merely for descriptive convenience and are not intended to limit the scope of this application.

[0093] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0094] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0095] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each 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.

[0096] Those skilled in the art will recognize that the various illustrative logical blocks (ILBs) and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

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

[0098] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0100] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0101] The above description is merely a specific embodiment 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. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cross-GPU asynchronous rendering method, comprising: Based on the scene description data, generate task descriptors for multiple processing tasks; Based on the task descriptors of the multiple processing tasks, the dependencies between the processing tasks are determined; Based on the dependencies between the processing tasks, a directed acyclic graph is constructed; Obtain hardware parameters for multiple GPUs; Based on the directed acyclic graph and the hardware parameters of the multiple GPUs, the multiple processing tasks are assigned to multiple target GPUs, so that the multiple target GPUs execute the assigned processing tasks asynchronously to obtain a rendered image; wherein, different target GPUs transfer data based on the dependency relationship.

2. The method as described in claim 1, Based on the scene description data, task descriptors for multiple processing tasks are generated, including: Based on the scene description data, task descriptors for multiple processing tasks are generated in parallel; wherein, the multiple processing tasks include multiple of the following: texture processing, geometric rasterization, pixel calculation, and physical calculation.

3. The method as described in claim 2, Based on the scene description data, task descriptors for multiple processing tasks are generated in parallel, including: Based on the viewport distance and viewing angle in the scene description data, the detail level of the texture is determined; Based on the detail level of the texture, a task descriptor for texture processing is generated; wherein, the task descriptor for texture processing is used to instruct the GPU to load and process the texture data corresponding to the detail level.

4. The method as described in claim 2, Based on the scene description data, task descriptors for multiple processing tasks are generated in parallel, including: Based on the geometric model information and current view frustum parameters in the scene description data, potential visible objects located within the view frustum are filtered out. Determine the geometric detail level of the potential visible object; Based on the dynamic transformation data output from the previous frame's physical calculations and the geometric detail level of the potential visible object, a task descriptor for geometric rasterization is generated; wherein, the task descriptor for geometric rasterization is used to instruct the GPU to perform any one or more of the following operations on the geometric model information: vertex transformation, surface tessellation, viewport clipping, and rasterization.

5. The method as described in claim 2, Based on the scene description data, task descriptors for multiple processing tasks are generated in parallel, including: Based on the lighting configuration, post-processing effects, and rendering target definition in the scene description data, the rendering channel and rendering target are determined. Based on the rendering channel, the rendering target, the texture resource identifier pre-allocated for the texture processing, and the geometric resource identifier allocated for the geometric rasterization, a task descriptor for the pixel computation is generated; wherein, the task descriptor for the pixel computation explicitly declares the texture and geometric resources required for the pixel computation and is used to instruct the GPU to perform one or more of the following operations: fragment shading, ray tracing, or post-processing computation.

6. The method as described in claim 2, Based on the scene description data, task descriptors for multiple processing tasks are generated in parallel, including: Based on the physical world state in the scene description data, the sub-tasks of the physical simulation are determined. Based on the subtask partitioning results of the physical simulation, a task descriptor for the physical calculation is generated; wherein, the task descriptor for the physical calculation is used to instruct the GPU to perform any one or more of collision detection, motion integration and constraint solving calculations, and the result of the physical calculation is used to update the object transformation state.

7. The method as described in claim 1, Based on the directed acyclic graph and the hardware parameters of the multiple GPUs, the multiple processing tasks are assigned to multiple target GPUs, including: Traverse the directed acyclic graph to identify multiple target processing tasks whose input dependencies have been satisfied; Based on the hardware parameters of each GPU, the matching degree between each target processing task and each GPU is determined; Each of the target processing tasks is assigned to the target GPU with the highest compatibility.

8. The method as described in claim 1, Based on the directed acyclic graph and the hardware parameters of the multiple GPUs, the multiple processing tasks are assigned to multiple target GPUs, including: Based on the directed acyclic graph and the hardware parameters of the multiple GPUs, the task descriptor of the processing task is written into the first buffer, which is currently used as a write buffer. When the preset conditions are met, the roles of the first buffer and the second buffer, which serves as the read buffer, are swapped through an atomic pointer swap operation. The task descriptor of the processing task is read from the first buffer after the role is swapped and the processing task is assigned to the corresponding target GPU.

9. The method as described in claim 1, in, Different target GPUs transfer data by sharing virtual memory.

10. An asynchronous rendering apparatus across GPUs, comprising: The generation module is configured to generate task descriptors for multiple processing tasks based on scene description data; The module is configured to determine the dependencies between the processing tasks based on the task descriptors of the multiple processing tasks. Based on the dependencies between the processing tasks, a directed acyclic graph is constructed; The allocation module is configured to acquire the hardware parameters of multiple GPUs; based on the directed acyclic graph and the hardware parameters of the multiple GPUs, allocate the multiple processing tasks to multiple target GPUs, so that the multiple target GPUs asynchronously execute the allocated processing tasks to obtain a rendered image; wherein, different target GPUs transfer data based on the dependency relationship.

Images