Directed acyclic graph node compiling method and device, equipment and storage medium

Abstract

The invention discloses a directed acyclic graph node compiling method, device and equipment and a storage medium, and the method comprises the steps: monitoring the execution time of each directed acyclic graph node through an application programming interface, and recognizing the dependency relationship among the directed acyclic graph nodes through a topological sorting algorithm to obtain a time-consuming key node; aiming at the grid data in the time-consuming key node, performing data alignment and block storage processing, and matching a preset kernel template library in combination with the type of the time-consuming key node to generate a kernel code; executing data transmission between the CPU and the GPU by adopting an asynchronous transmission and batch processing strategy according to a data format and a parameter interface required by a kernel code, and constructing a mapping table; calling a compiler to compile the kernel code in real time, and generating a dynamic link library matched with the parameter interface of the mapping table; and registering the dynamic link library as a plug-in through the plug-in interface. According to the method, the processing efficiency of the Maya node is remarkably improved, and the optimization and maintenance cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of animation production technology, and in particular to a method, apparatus, device, and storage medium for compiling nodes of a directed acyclic graph. Background Technology

[0002] In the field of computer graphics processing and 3D animation production, Autodesk Maya, as a mainstream professional software, is widely used in core tasks such as creating complex 3D scenes, designing character animations, and rendering high-quality content. It is a key tool for content creation in industries such as film and television and games. As the industry's requirements for creative efficiency and content quality continue to increase, Maya's performance bottlenecks are becoming increasingly prominent when handling complex projects such as large-scale models, complex material node networks, and high-precision animations, severely restricting the smoothness of the production workflow.

[0003] From a technical perspective, all objects and data processing units in a Maya scene are organized around Directed Acyclic Graph (DAG) nodes, which are interconnected to form a complex hierarchical structure and dependency network. Traditionally, Maya's rendering and animation simulation of DAG node networks rely primarily on the CPU's serial computing mode. However, CPU hardware design prioritizes complex logic control and efficient sequential processing with a limited number of cores, making it difficult to adapt to the massive parallel computing demands of graphics processing. This results in insufficient utilization of hardware resources and slow processing speeds. For example, when rendering cinematic 3D scenes containing massive amounts of polygons and complex material nodes, traditional CPU serial processing often takes hours or even days to complete a single frame, significantly extending project production cycles.

[0004] To overcome this performance bottleneck, GPUs (Graphics Processing Units), with their massive number of computing cores and parallel computing capabilities, have become a key hardware support for improving graphics processing efficiency. CUDA (Compute Unified Device Architecture), a parallel computing platform and programming model launched by NVIDIA, allows developers to fully utilize the parallel computing capabilities of NVIDIA GPUs, offloading tasks such as matrix operations and parallel data processing to the GPU for execution, significantly improving computational efficiency. This technology has been widely used in fields such as deep learning, becoming a standard acceleration solution for large-scale neural network training. However, in the DAG node processing scenarios of Maya software, the efficient integration of CUDA technology faces multiple technical challenges: First, Maya's software architecture is complex, with its DAG node network operating mechanism deeply coupled with various software modules and data structures. The data transfer method and dependency management mode between DAG nodes are fundamentally different from the data parallel processing mode required by CUDA, resulting in low data transfer efficiency between the CPU and GPU, and difficulty in reasonably allocating node computing tasks to GPU cores. How to achieve effective integration of the underlying architecture of the two while ensuring the stability of Maya's original functions has become the primary technical challenge.

[0005] Secondly, Maya's DAG nodes are diverse, including geometry nodes, deformer nodes, and material nodes, with significant differences in functionality and computational logic among different types. To achieve efficient acceleration based on CUDA, customized optimization strategies need to be designed for the characteristics of each type of node. For example, the mesh data of geometry nodes needs to be adapted to the GPU memory layout and optimized CUDA kernels need to be generated; the lighting models and texture mapping calculations of material nodes need to be accelerated in parallel while ensuring rendering accuracy. Currently, there is a lack of a unified and universal CUDA optimization solution.

[0006] Third, traditional optimization methods rely on manually written operator libraries, which are difficult to adapt to complex and ever-changing application environments. With the continuous updates of NVIDIA GPU architecture and CUDA versions, as well as the iteration of Maya software versions and the widespread use of user-defined plugins, operator library developers need to continuously update GPU operators manually to adapt to new features. This not only consumes a lot of manpower and time, but also makes it difficult to guarantee universality and efficiency in different hardware and software environments, resulting in high adaptation difficulty and optimization costs.

[0007] In related technical research, some solutions improve performance by improving Maya's internal algorithms or optimizing existing plugins. However, these methods are often limited to specific functional modules or application scenarios and lack systematic optimization of DAG node networks, thus failing to fully unleash the parallel computing potential of CUDA. Other CUDA optimization solutions for general graphics computing are difficult to directly migrate to the Maya environment and achieve the desired results because they do not fully consider the unique architecture of Maya software and the characteristics of DAG nodes. Summary of the Invention

[0008] The purpose of this invention is to provide a method, apparatus, device, and storage medium for compiling nodes of a directed acyclic graph, aiming to solve the problems of low data transmission efficiency in existing CPUs and GPUs.

[0009] In a first aspect, embodiments of the present invention provide a method for compiling nodes of a directed acyclic graph, including: Obtain the directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node within the DAG node network data through the application programming interface, and identify the dependency relationships between each DAG node within the DAG node network data through the topology sorting algorithm to obtain the time-consuming key nodes. For the grid data in the time-consuming critical nodes, data alignment and block storage processing are performed, and kernel code is generated by matching the type of the time-consuming critical nodes with a preset kernel template library. For the time-consuming critical nodes, based on the data format and parameter interface required by the kernel code, an asynchronous transmission and batch processing strategy is adopted to execute data transmission between the CPU and GPU, and a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters is constructed. The compiler is invoked to compile the kernel code in real time, generating a dynamic link library that matches the parameter interface of the mapping table; Register the dynamic link library as a plugin through the plugin interface.

[0010] Secondly, embodiments of the present invention provide a directed acyclic graph node compilation apparatus, comprising: The acquisition unit is used to acquire directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node in the DAG node network data through the application programming interface, and identify the dependency relationship between each DAG node in the DAG node network data through the topology sorting algorithm to obtain the time-consuming key nodes. The alignment unit is used to perform data alignment and block storage processing on the grid data in the time-consuming critical node, and to generate kernel code by matching the type of the time-consuming critical node with a preset kernel template library. The construction unit is used to perform data transmission between the CPU and GPU using asynchronous transmission and batch processing strategies, based on the data format and parameter interface required by the kernel code, for the time-consuming critical nodes, and to construct a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters. The compilation unit is used to call the compiler to compile the kernel code in real time and generate a dynamic link library that matches the parameter interface of the mapping table; The registration unit is used to register the dynamic link library as a plugin through the plugin interface.

[0011] Thirdly, embodiments of the present invention provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the directed acyclic graph node compilation method described in the first aspect.

[0012] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the directed acyclic graph node compilation method described in the first aspect.

[0013] This invention discloses a method, apparatus, device, and storage medium for compiling directed acyclic graph (DAG) nodes. The method includes: acquiring DAG node network data; monitoring the execution time of each DAG node within the network data via an application programming interface (API); identifying the dependencies between DAG nodes using a topology sorting algorithm to obtain time-consuming critical nodes; performing data alignment and block storage processing on the grid data in the time-consuming critical nodes; matching a preset kernel template library with the type of the time-consuming critical nodes to generate kernel code; for the time-consuming critical nodes, executing data transmission between the CPU and GPU using an asynchronous transmission and batch processing strategy based on the data format and parameter interface required by the kernel code; constructing a mapping table between the node attributes of the DAG nodes and kernel parameters; calling a compiler to compile the kernel code in real time to generate a dynamic link library that matches the parameter interface of the mapping table; and registering the dynamic link library as a plugin through a plugin interface. This invention accurately identifies time-consuming critical nodes and their dependencies by monitoring and analyzing directed acyclic graph (DAG) node network data. Subsequently, it automatically matches template libraries based on node type and aligns and segments the mesh data according to the GPU memory architecture to generate kernel code. Through asynchronous transmission and attribute mapping table technology, it achieves efficient data exchange between the CPU and GPU. By automatically compiling and registering plugins, it seamlessly replaces the original CPU nodes with GPU acceleration logic. This achieves unified and precise acceleration for different node types, eliminating reliance on manual operator libraries and adapting to changes in the hardware and software environment, thereby improving the system performance of complex DAG node network data. This invention also provides a DAG node compilation device, a computer-readable storage medium, and a computer device, all with the aforementioned beneficial effects, which will not be elaborated further here. Attached Figure Description

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

[0015] Figure 1 A flowchart illustrating the compilation method for nodes in a directed acyclic graph; Figure 2This is a schematic diagram of the sub-processes of the method for compiling nodes in a directed acyclic graph. Figure 3 This is a schematic diagram of the sub-processes of the method for compiling nodes in a directed acyclic graph. Figure 4 This is a schematic diagram of the aligned video memory layout; Figure 5 A schematic block diagram of a node compilation device for a directed acyclic graph; Figure 6 This is a schematic diagram of the structure of a node compilation device for a directed acyclic graph. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more of its features, integrals, steps, operations, elements, components and / or collections thereof.

[0018] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0019] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the relevant listed items and all possible combinations, and includes such combinations.

[0020] Please see Figures 1-3 This embodiment provides a method for compiling nodes of a directed acyclic graph, including: S101: Obtain the directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node in the DAG node network data through the application programming interface, and identify the dependency relationship between each DAG node in the DAG node network data through the topology sorting algorithm to obtain the time-consuming key nodes. In this embodiment, directed acyclic graph (DAG) node network data is acquired. The execution time of each DAG node within the DAG node network data is monitored via an application programming interface (API). Furthermore, a topology sorting algorithm is used to identify the dependencies between DAG nodes within the DAG node network data, resulting in the following time-consuming key nodes: Acquire directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node within the DAG node network data through the application programming interface (API), and generate a time series record table and statistical distribution characteristics. The topology sorting algorithm is applied to process the network data of directed acyclic graph nodes, parse the connection relationships of each node in the directed acyclic graph, and generate a node dependency topology sequence. The cumulative influence weight of each node in the directed acyclic graph is calculated by combining the time-series record table and the node-dependent topology sequence. The time threshold is determined based on the statistical distribution characteristics of all nodes in the directed acyclic graph; By comparing the cumulative influence weights of each node in the directed acyclic graph with the time threshold, nodes in the directed acyclic graph whose cumulative influence weights exceed the time threshold are selected to form a set of candidate key nodes. By analyzing the dependency transitive relationships between nodes in the directed acyclic graph of the candidate key node set, the time-consuming key nodes are obtained.

[0021] This embodiment combines real-time API monitoring with topology sorting to not only obtain the original execution time of nodes but also capture their positional characteristics within the entire dependency network, forming a multi-dimensional performance profile. The calculation of cumulative impact weights comprehensively considers the node's own execution time and its cascading impact on downstream nodes, avoiding a one-sided judgment based solely on execution time. Dynamic thresholds are determined based on overall statistical distribution characteristics, adapting to DAG networks of varying sizes and complexities, avoiding over-optimization or under-optimization issues caused by fixed thresholds. The candidate node set is further refined after dependency transitivity analysis, effectively eliminating redundant nodes and ensuring that optimization resources are concentrated on the key nodes that truly impact overall performance. This hierarchical screening mechanism significantly improves identification accuracy, providing precise targets for subsequent targeted optimization while avoiding unnecessary waste of computational resources.

[0022] Specifically, the DAG node network data in the scene is obtained through application programming interfaces (APIs) provided by Maya (such as MCallbackId and MGraph Iterator). The execution time of each node is monitored, specifically by registering callback functions before and after node execution, recording timestamps, and calculating execution duration. A time-series record table is generated, containing node ID, start time, end time, and execution duration; at the same time, the execution time distribution characteristics of all nodes are statistically analyzed, such as mean, standard deviation, and peak value.

[0023] Next, a topology sorting algorithm (such as Kahn's algorithm) is applied to process the DAG node network data. Based on the input-output connections between nodes, the algorithm constructs an in-degree table and iteratively processes nodes to generate a dependency topology sequence. This sequence clearly defines the execution order and hierarchical relationships of the nodes, ensuring acyclic dependencies. The output is a node dependency topology sequence, including the hierarchical information and dependency chains of each node.

[0024] By combining the time-series record table and the node dependency topology sequence, the cumulative impact weight of each node is calculated. The weight calculation considers the node's execution time and its position in the dependency chain, assigning higher-level nodes higher weights. The formula is: Cumulative Impact Weight = Node Execution Time × Hierarchy Coefficient. The hierarchy coefficient is dynamically adjusted based on the dependency depth to ensure that nodes on the critical path receive priority attention.

[0025] Subsequently, a time threshold is dynamically determined based on the statistical distribution characteristics of all DAG nodes (such as whether the execution time follows a normal or skewed distribution). The threshold is set as a multiple of the average execution time (e.g., 3 times), while also adjusting for outliers. The threshold is used to standardize the screening criteria.

[0026] Next, the cumulative impact weight of each node is compared with a time threshold. Nodes whose cumulative impact weight exceeds the threshold are selected to form a set of candidate key nodes. The set includes the node ID, weight value, and dependencies for subsequent analysis.

[0027] Next, the dependency transitive relationships between nodes in the candidate critical node set are analyzed, and indirect dependencies and critical paths are identified by traversing the dependency topology sequence. For example, a node with low weight but dependent on by multiple high-weight nodes is included as a time-consuming critical node. The final output is a list of time-consuming critical nodes, including node IDs and execution optimization suggestions.

[0028] This embodiment achieves accurate identification of time-consuming critical nodes in a DAG node network through the above steps. The method has the characteristics of being systematic, quantitative, and adaptive, providing a reliable foundation for performance optimization.

[0029] In some embodiments, the topology sorting algorithm is applied to process the directed acyclic graph (DAG) node network data, parses the connection relationships of each DAG node, and generates a node-dependent topology sequence, including: Count the number of in-degrees of each node in the directed acyclic graph (DAG) node network data, and generate an in-degree count mapping table. Filter the directed acyclic graph nodes with an in-degree value of zero from the in-degree count mapping table, and construct an initial queue of zero-in-degree nodes; Iteratively update the in-degree values ​​of the child nodes associated with each directed acyclic graph node in the initial zero-in-degree node queue, and add the child nodes whose in-degree becomes zero to the initial zero-in-degree node queue to generate a node dependency topology sequence.

[0030] This embodiment constructs a mapping table by counting the number of in-degree nodes, enabling the system to quickly identify independent starting nodes and provide a clear starting point for topology sorting. The strategy of selecting nodes with zero in-degree to construct the initial queue ensures that the processing order strictly follows dependencies, avoiding computational deadlocks caused by circular dependencies. The iterative update mechanism dynamically adjusts the in-degree values ​​of related child nodes when processing each node. This incremental processing method significantly reduces algorithm complexity, keeping the time complexity at a linear level, and can efficiently handle large networks containing tens of thousands of nodes. The generated node dependency topology sequence not only accurately reflects the execution order between nodes but also implicitly contains the hierarchical position information of nodes in the dependency chain, providing a structured foundation for subsequent key node identification. The algorithm inherently possesses loop detection capabilities; when the number of nodes in the final sequence is less than the total number of original nodes, it can automatically identify loops in the graph, enhancing the system's robustness. The entire process requires only two graph traversals, has a small memory footprint, is suitable for running in real-time graphics software environments such as Maya, does not affect the user experience, and provides a precise dependency data foundation for subsequent GPU acceleration optimization.

[0031] Specifically, suppose a simplified Maya DAG node network contains five nodes with the following connections: node A has no parent node; node B depends on node A; node C depends on node A; node D depends on nodes B and C; and node E depends on node C.

[0032] First, the system traverses the network, counts the in-degree of each node, and generates an in-degree count mapping table. The mapping table contains: node A: 0, node B: 1, node C: 1, node D: 2, node E: 1.

[0033] Next, the system filters nodes with an in-degree value of zero from the in-degree count mapping table. At this point, only node A has an in-degree of 0, so the initial zero-in-degree node queue contains only node A.

[0034] Then, the system begins iterative processing. Node A is removed from the initial queue and added to the output node dependency topology sequence. Subsequently, the in-degree values ​​of all associated child nodes of node A are updated: the in-degrees of nodes B and C are both decremented by 1, becoming 0. The system then adds nodes B and C, whose in-degrees have become zero, to the zero-in-degree node queue.

[0035] Proceed to the next iteration: Remove node B from the current queue and add it to the topology sequence. Update the in-degree of node B's child node D, decreasing it from 2 to 1. Since node D's in-degree is not yet 0, no new node is added to the queue in this round. Next, remove node C from the queue and add it to the topology sequence. Update the in-degrees of node C's children nodes D and E: decrease node D's in-degree from 1 to 0, and decrease node E's in-degree from 1 to 0. The system then adds nodes D and E to the queue.

[0036] Continue iterating: Retrieve node D and node E from the queue in sequence and add them to the topology sequence. Neither has any children, so there's no need to update their in-degree. Finally, the queue is empty, and the iteration ends. The generated node dependency topology sequence is: A, B, C, D, E. This sequence clearly defines the execution order for acyclic nodes.

[0037] In some embodiments, the specific process for implementing DAG node network diagnostics in the Autodesk Maya software environment is as follows: Data acquisition of the DAG node network was performed using the Maya API. The MGraph Iterator interface was used to traverse the node network in the scene, recording the unique identifier, parent node list, and child node list for each node. Simultaneously, callback functions before and after node execution were registered using MCharbackId, capturing the node execution start timestamp t_start and end timestamp t_end, and calculating the actual execution duration t_exec = t_end - t_start. The acquired data was stored in two core data structures: a dictionary {node_id:{parent_ids:[],child_ids:[]}} recording node dependencies, and a dictionary {node_id:t_exec} recording execution times.

[0038] Next, the Kahn algorithm is used for topological sorting analysis. First, a node in-degree table {node_id:in_degree} is constructed to identify the starting node with an in-degree of 0. The processing queue and level record dictionary are initialized, and the starting node is added to the queue and marked as the first level. The nodes in the queue are processed iteratively, with the current node added to the topological sequence `topo_order`, its child nodes traversed, and their in-degree values ​​decreased. When the in-degree of a child node becomes 0, it is added to the queue, and its level is marked as the current node's level plus 1. Finally, the topological sequence and the node level dictionary {node_id:level} are output, forming a complete dependency graph.

[0039] Based on the collected execution time data, the average execution time of all nodes, avg_t, is calculated as sum(t_exec.values()) / len(t_exec). A time threshold of 3 × avg_t is set to initially filter out candidate critical nodes whose execution time exceeds the threshold. Combining the dependency relationships obtained from topological sorting, upstream and downstream dependency node information is added to each candidate critical node to form a complete list of time-consuming critical nodes. The list includes key information such as node ID, execution time, dependency level, and upstream / downstream node relationships, as shown in Table 1.

[0040] Table 1 Subsequently, duplicate nodes were deduplicated during implementation, and invalid nodes with an execution time of 0 were excluded. A dynamic threshold adjustment mechanism was employed for high-level nodes, appropriately reducing the threshold to 2.5×avg_t for nodes at the end of the dependency chain. A dependency graph was generated using Maya's built-in drawing tools or Graphviz visualization tools to visually display the location distribution of key nodes in the network.

[0041] This embodiment achieves precise location of time-consuming critical nodes in a DAG node network through systematic data acquisition, topology analysis, and intelligent filtering, providing clear target nodes for subsequent GPU acceleration optimization. This method solves the problem of blind optimization and significantly improves the targeting and efficiency of subsequent optimization steps.

[0042] S102: For the grid data in the time-consuming critical node, perform data alignment and block storage processing, and generate kernel code by matching the type of the time-consuming critical node with the preset kernel template library; In this embodiment, for the grid data in the time-consuming critical nodes, data alignment and block storage processing are performed, and the kernel code is generated by matching the type of the time-consuming critical nodes with a preset kernel template library. Extract the geometric features and topological structure of the grid data in the time-consuming key nodes to generate data layout description information; The data layout description information is parsed to determine the memory offsets of vertex coordinates, normal vectors, and texture coordinates. The memory layout of the mesh data is reconstructed according to the byte boundary alignment rules, and the aligned mesh data is output. Analyze the dimensional characteristics and access patterns of the aligned grid data, determine the block size parameters, and divide the aligned grid data into multiple regular data blocks according to the block size parameters to generate a block index mapping table; Identify the type identifiers and functional attributes of time-consuming critical nodes, and retrieve the matching basic kernel templates in the kernel template library based on the type identifiers; Extract the block dimension parameters and thread configuration parameters from the block index mapping table, and inject the block dimension parameters and thread configuration parameters into the placeholder positions of the basic kernel template to replace the memory access mode with optimized access instructions; Integrate functional attributes and optimized access instructions to generate kernel code.

[0043] This embodiment extracts the geometric features and topology of the grid data, enabling the system to optimize for specific data types rather than employing a general processing strategy. Memory alignment follows specific byte boundary rules, significantly reducing cache misses in GPU memory access. The block storage strategy dynamically determines the block size based on data dimensional features and access patterns. This adaptive block mechanism maximizes data locality and reduces data contention between threads. The kernel template library design achieves a balance between code reuse and customization, avoiding redundant development costs. Simultaneously, a parameter injection mechanism ensures that the generated kernel code is highly optimized for specific data structures. The process of replacing memory access patterns with optimized access instructions eliminates unaligned access and scattered reads in the original code, significantly improving memory bandwidth utilization.

[0044] Specifically, the mesh data in the time-consuming key nodes is extracted, and the geometric features and topology of the data are collected. The geometric features include the number of vertices, the number of faces, the range of vertex coordinates, the distribution range of normal vectors, and the range of texture coordinate values. The topology includes the relationship between vertices and faces, and the mapping relationship between texture coordinates and vertices. The above information is integrated to generate data layout description information.

[0045] Next, the data layout description information is parsed to determine the offsets of vertex coordinates, normal vectors, and texture coordinates in memory. Vertex coordinates are set to an offset of 32 bytes, normal vectors to an offset of 64 bytes, and texture coordinates to an offset of 96 bytes. The memory storage order of the mesh data is reconstructed according to the 256-byte boundary alignment rule, and invalid padding data is added to meet the byte alignment requirements. The aligned mesh data is then output.

[0046] Then, the dimensional characteristics and access patterns of the aligned mesh data are analyzed. The dimensional characteristics include that the vertex dimension is three-dimensional and the texture coordinate dimension is two-dimensional. The access pattern is to access vertex data in face index order. Based on the above characteristics, the block size parameter is determined to be 128×128. The aligned mesh data is divided into multiple regular data blocks according to this block size parameter. The starting memory address, data dimension, and associated vertex range of each data block are recorded to generate a block index mapping table.

[0047] Next, read the metadata of the time-consuming key nodes, identify the type identifier and function attribute. The type identifier is GEOMETRY_MESH, and the function attribute is grid smoothing calculation. Based on the type identifier, search in the kernel template library and match the corresponding grid smoothing processing basic kernel template.

[0048] Then, the block dimension parameter 128×128 and the thread configuration parameter are extracted from the block index mapping table. The thread configuration parameter is set to the thread block size of 256 and the number of data blocks corresponding to the thread grid size. The above parameters are injected into the parameter placeholder position of the basic kernel template. At the same time, the original default memory access instructions in the template are replaced with optimized access instructions, which include continuous memory access instructions and shared memory cache instructions.

[0049] Then, the functional attributes of the time-consuming critical node, including the number of iterations for mesh smoothing and the smoothing weight coefficient, are integrated with the above-mentioned optimized access instructions and added to the functional logic area of ​​the basic kernel template, ultimately generating kernel code adapted to the time-consuming critical node.

[0050] In some embodiments, a polygonal mesh geometry node with 10,000 vertices in Maya software is used as an example to illustrate the GPU adaptation, kernel code generation, and compilation process of its mesh data.

[0051] Assume the current environment and basic data are as shown in Table 2: Table 2 First, please refer to Figure 4 The system acquires the raw mesh data for time-consuming critical nodes. This data includes vertex coordinates, normal vectors, and texture coordinates. The system first processes the vertex coordinate data. The GPU memory bus width alignment requirement is set to 256 bytes, and each vertex coordinate data is of type float3, occupying 12 bytes. It is calculated that each 256-byte alignment block can hold 21 vertex coordinates (21 × 12 = 252 bytes), and 4 bytes of invalid data are added to the end of each data block to achieve alignment. The system obtains the raw vertex array through the Maya API, copies it in groups of 21 vertices, and adds 4 bytes of padding after each group to generate aligned vertex coordinate data. For texture coordinate data, which is of type float2 and occupies 8 bytes, the 256-byte alignment block can hold exactly 32 texture coordinates (32 × 8 = 256 bytes), requiring no padding. The system generates aligned texture coordinate data according to this rule.

[0052] Next, the system divides the aligned vertex coordinate data into blocks. The CUDA thread block size is set to 128, and the data dimension is 3 (corresponding to the x, y, z components of the vertex coordinates). The block division strategy processes 128 vertices per thread block. With a total of 10,000 vertices, it is calculated that 79 thread blocks are needed (the first 78 blocks each process 128 vertices, and the 79th block processes the remaining 16 vertices). The system generates a block index mapping table (as shown in Table 3) to record the starting index and number of vertices processed by each thread block.

[0053] Table 3 The system then identifies the node's type identifier as `mesh_geometry`. Based on this identifier, it retrieves the corresponding base kernel template from the kernel template library. This template defines the basic structure of the kernel functions and includes alignment parameters, block size parameters, data dimension parameters, data read / write logic placeholders, computation logic placeholders, and placeholders for mapping parameters from Maya node attributes.

[0054] The system performs parameter injection and logic generation. Data layout parameters (alignment 256 bytes, block size 128, dimension 3) are filled into the template. Based on the block partitioning strategy, data read / write logic is automatically generated, specifically calculating vertex indices using thread global IDs and reading or writing three consecutive float values ​​from the aligned video memory array. The world transformation matrix is ​​extracted from Maya node attributes and used as the `transform_matrix` parameter. The core calculation logic for vertex transformation (e.g., multiplying vertex coordinates using the transformation matrix) is filled into the calculation logic placeholders. Finally, a complete CUDA kernel source code is generated, with functionality identical to the `vertex Transform Kernel` function in the example.

[0055] Next, the system invokes the NVIDIA CUDA compiler, configures compilation parameters matching the target GPU architecture, and compiles the generated kernel source code to produce object code files. These object code files are then linked and packaged into Maya plugin dynamic library files.

[0056] Finally, the system registers this dynamic library as a new plugin node through the Maya plugin interface, replacing the execution logic of the original geometry node while retaining all its attributes and connections. When the Maya scene needs to perform calculations for this node, the plugin will be called, and the generated kernel code will be executed in parallel by the GPU to complete the batch transformation of vertex coordinates.

[0057] The summary information on the segmentation and alignment of different grid data is shown in Table 4: Table 4 S103: For the time-consuming critical nodes, according to the data format and parameter interface required by the kernel code, the asynchronous transmission and batch processing strategy is adopted to execute the data transmission between the CPU and the GPU, and a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters is constructed. In this embodiment, for time-consuming critical nodes, based on the data format and parameter interface required by the kernel code, an asynchronous transmission and batch processing strategy is adopted to execute data transmission between the CPU and GPU, and a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters is constructed, including: Extract the data format definitions and parameter interface specifications from the kernel code; Based on the data format definition, the original grid data to be processed at time-consuming key nodes is reorganized and filled to generate optimized grid data blocks; Based on the source attribute identifier in the parameter interface specification, the connectable attributes of the directed acyclic graph nodes are traversed, and the source attribute identifier is matched with the actual attribute name in the directed acyclic graph nodes to generate parameter source matching relationship. Based on the parameter source matching relationship and optimized grid data blocks, multiple asynchronous transport streams are created, and asynchronous batch processing transport tasks are assigned to each asynchronous transport stream; When scheduling asynchronous batch transfer tasks, the parameter values ​​of node attributes that match the optimized grid data blocks are transferred from CPU memory to GPU memory. Based on the parameter values ​​successfully transferred to the GPU memory and their position order in the parameter interface specification, a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters is constructed.

[0058] This embodiment extracts the data format definition from the kernel code, enabling targeted reorganization of the original mesh data, eliminating memory access conflicts, and improving GPU read efficiency. The automatic parameter interface matching mechanism eliminates manual configuration, ensuring precise correspondence between Maya node attributes and GPU kernel parameters, avoiding common mapping errors. The multi-stream asynchronous transmission architecture fully utilizes PCIe bandwidth, and the batch processing strategy merges scattered small data packets for transmission, significantly reducing synchronization overhead. Data transmission and computation processes overlap, effectively hiding I / O latency. The dynamic mapping table construction mechanism automatically generates parameter mapping relationships after transmission, ensuring accurate parameter positions during kernel execution. The entire process achieves seamless integration from data preparation to parameter mapping, allowing the GPU acceleration module to be directly integrated into Maya's existing workflow without modifying the original scene structure, significantly improving the processing performance of complex 3D scenes while ensuring accurate and consistent calculation results.

[0059] Specifically, the data format and parameter interface specifications defined in the kernel code are extracted. The data format specification requires that the input vertex data be aligned to 256 bytes, with each vertex being of type float3. The parameter interface specification includes one parameter named deform_strength, of type float, whose source attribute identifier is the strength value of the Maya node attribute.

[0060] Next, based on the data format definition, the original mesh vertex data to be processed at the time-consuming critical nodes is reorganized and padded. Assuming the original number of vertices is 8500, and calculating based on 21 vertices per alignment block, 405 alignment data blocks are generated after processing. Necessary padding bytes are added to the end of each block to finally generate optimized mesh data blocks.

[0061] Then, based on the source attribute identifier in the parameter interface specification, all connectable attributes of the directed acyclic graph (DAG) node are traversed. The identifier strength value is compared and matched with the actual attribute name (e.g., strength or intensity) in the node attribute list to confirm that the strength attribute of the DAG node is the required parameter source, thereby generating a parameter source matching relationship and clarifying that the kernel parameter deform_strength should obtain its value from this strength attribute.

[0062] Next, based on the parameter source matching relationship and the optimized grid data block, two independent asynchronous transport streams are created. The optimized grid data block is divided into two parts and assigned to the two streams as asynchronous batch transport tasks. At the same time, the current value of the matched node's strength attribute (e.g., 0.75) is also appended to one of the streams as a small data transport task.

[0063] When these asynchronous batch transfer tasks are scheduled for execution, the system initiates the transfer. The first stream transfers a subset of its allocated optimized grid data blocks from CPU memory to a designated address A in GPU memory. The second stream simultaneously transfers another portion of the grid data blocks, along with the floating-point value 0.75, to designated addresses B and C in GPU memory.

[0064] Finally, based on the parameter values ​​successfully transferred to GPU memory and their declaration order in the kernel parameter interface specification, the system constructs a mapping table. This table records that the node attribute `strength` maps to the kernel parameter `deform_strength`, and that this parameter value is located at GPU memory address C. Simultaneously, the starting addresses A and B of the optimized grid data blocks are also recorded as data input sources for the kernel. This mapping table will be passed to the kernel execution unit to ensure accurate acquisition of data and parameters during computation.

[0065] In some embodiments, page-locked memory optimization is implemented to address the high-frequency, low-data transfer problem of the character skeletal system. Analysis shows that under the ordinary memory scheme, the 64-byte transformation matrix, updated 24 times per frame, requires 1000 GPU accesses. Each access triggers a 64-byte CPU-to-GPU copy, resulting in a cumulative latency of 4.8 milliseconds per frame, becoming a performance bottleneck. The page-locked memory scheme, by forcing memory to not be paged, allows the GPU to directly access CPU memory via DMA, eliminating the overhead of repeated copying.

[0066] The implementation process first verifies that the data meets the page-locking conditions: the world transformation matrix data size is 64 bytes, which is less than the 64KB threshold; the access frequency of 1000 times per frame is considered high-frequency; and the update frequency is only once per frame, meeting the low-frequency update condition. During the plugin initialization phase, the CUDA runtime interface cuda Host Alloc is called to allocate page-locked memory, specifying a size of 64 bytes in a float4x4 structure. The cuda Host Alloc Default flag ensures direct GPU access capability. After allocation, a status check is performed; if it fails, it falls back to the normal memory allocation scheme.

[0067] Next, during the data binding phase, the world matrix properties of the animation nodes are obtained through Maya's dependency node functions. The MMatrix type is converted to a CUDA-compatible float4x4 format and directly written to the page-locked memory region. This operation is performed only when the animation frame changes, avoiding frequent updates. In the vertex transformation kernel design, the parameter list includes a page-locked memory pointer instead of a traditional device pointer. The GPU thread directly reads the transformation matrix data through this pointer, without needing to copy it to video memory beforehand. The kernel calculation adopts the standard vertex transformation process, but eliminates the data transfer step before each call.

[0068] During each frame rendering, the kernel is launched after configuring a thread block of 128 threads and 8 mesh blocks, directly passing the page-locked memory address. After the kernel execution is complete, device synchronization is performed as needed. When the plugin is unloaded, CUDA Free Host is called to release the page-locked memory to prevent resource leaks. The optimized implementation includes four key details: memory allocation is only performed at the beginning and end of the plugin's lifecycle to avoid frequent allocation overhead; data updates are strictly limited to being triggered when parameters change; the cudaHost Alloc Portable flag is used in multi-GPU systems to ensure compatibility; and an exception rollback mechanism is implemented to ensure system stability.

[0069] The effects of regular memory and page-locked memory are shown in Table 5: Table 5 As can be seen from the above, this embodiment effectively solves the performance bottleneck problem of high-frequency, small-data transmission through a systematic page-locking memory management strategy, providing reliable technical support for real-time graphics processing applications. This method significantly improves system operating efficiency while maintaining data transmission accuracy.

[0070] S104: Call the compiler to compile the kernel code in real time and generate a dynamic link library that matches the parameter interface of the mapping table; In this embodiment, the compiler is invoked to perform real-time compilation of the kernel code, generating a dynamic link library that matches the parameter interface of the mapping table, including: Parse the parameter types, memory alignment boundaries, and data dimension constraints defined in the mapping table to generate interface specification description data; Based on the interface specification, a set of compilation configuration parameters is constructed to describe the signature template of the data extraction function and the memory access mode. The current GPU's computing power version is detected, and the target architecture identifier and register allocation strategy are determined by combining the compilation configuration parameter set, and architecture-adaptive compilation instructions are generated. The kernel code and architecture adaptation compilation instructions are integrated into a compilation task description, and the asynchronous compilation queue priority is set to generate compilation task objects; The compiler processes the compilation task object to generate the initial compilation result. Verify the compatibility between the exported symbols of the initial compilation result and the parameter interfaces in the mapping table, identify type mismatches and memory boundary conflicts, and generate interface correction instructions; The application interface correction instructions rewrite the kernel function parameter declarations in the kernel code, generating the corrected kernel code; The runtime library and math library are obtained, and the modified kernel code is linked with the runtime library and math library by the compiler to generate a dynamic link library.

[0071] This embodiment dynamically generates interface specifications by parsing the mapping table, accurately capturing parameter types, memory alignment requirements, and dimensional constraints, eliminating manual configuration errors. Automatic generation of compilation configuration parameter sets ensures that function signatures and memory access patterns strictly match hardware characteristics, improving execution efficiency. The GPU architecture automatic detection mechanism optimizes register allocation strategies for different computing power versions (such as sm_86 or sm_90), maximizing hardware utilization. The asynchronous compilation queue design, through a priority scheduling mechanism, prioritizes the compilation of critical kernels while other tasks are processed in the background, significantly improving system responsiveness. Interface compatibility verification steps identify type mismatches and memory boundary conflicts in advance, preventing runtime crashes. An automatic correction mechanism dynamically rewrites kernel function parameter declarations, reducing development and debugging cycles. The final linking stage intelligently selects runtime and math libraries, ensuring that the generated dynamic link library maintains a minimum size while possessing full functionality. This provides seamless hardware acceleration capabilities for the DAG node network while significantly reducing maintenance costs.

[0072] Specifically, the process reads the constructed mapping table between node attributes and kernel parameters of the directed acyclic graph. This table defines the parameter types of the vertex transformation kernel (e.g., vertex data parameters are of type float*, total number of vertices is of type size_t, transformation matrix is ​​of type float4x4), the memory alignment boundary is 256 bytes, and the data dimension of vertex data is three-dimensional. A parsing tool iterates through the key-value pairs of the mapping table, extracting the name, data type, memory alignment requirements, data dimension, and position order of each parameter in the parameter interface. This information is then integrated into structured interface specification description data, which directly provides clear constraints for subsequent compilation configuration.

[0073] Then, the kernel function signature template is extracted from the interface specification description data. This template contains the kernel function's return type, function name, and parameter list. Specifically, it is a function with no return value modified by `__global__`, named `vertexTransform Kernel`, with parameters of type `float*` vertex data, type `size_t` total number of vertices, and type `float4x4` transformation matrix. The extracted data also shows contiguous memory access and adheres to a 256-byte alignment rule. Based on this information, a set of compilation configuration parameters is constructed, including function signature parameter constraints, memory access optimization parameters, parameters with a compilation optimization level of O3, and parameters to disable redundant code compilation.

[0074] Next, the device attribute query interface in the CUDA Runtime API is called to obtain the current GPU device information, which detects that its computing version is 8.0 (corresponding to sm_80). This version information is combined with the compilation configuration parameter set to determine the target architecture identifier as -arch=sm_80, the register allocation strategy as -maxrregcount=256 (256 registers allocated per thread), and the -use_fast_math parameter is added to enable fast mathematical computation optimization. These parameters are integrated into architecture-adaptive compilation instructions, which include multiple compilation options such as target architecture, register allocation, and mathematical optimization.

[0075] The text content of the vertex transformation kernel code is then integrated with the architecture adaptation compilation instructions to form a compilation task description that includes the code path, compilation options, and output path. Based on the priority of the Maya node corresponding to this kernel code, the priority of the asynchronous compilation queue is set to high priority, ensuring that this compilation task is scheduled for execution first. Based on the compilation task description and priority settings, a compilation task object that can be recognized by the compiler is generated.

[0076] Next, the NVCC compiler interface is called, and the compilation task object is passed to the compiler's processing flow. The compiler performs lexical analysis, syntax analysis and code generation on the kernel code according to the configuration in the instructions, and finally generates an object file with the .o suffix, which is the initial compilation result.

[0077] Next, a symbol resolution tool was used to read the exported symbols from the initial compilation result, extracting the actual signatures and parameter constraint information of the kernel functions, and comparing them one by one with the parameter interface specifications in the mapping table. During the comparison, it was found that the vertex data parameters of the kernel functions were defined as type float3, which did not match the requirement of float type in the mapping table, and the memory alignment constraint was 128 bytes, which conflicted with the requirement of 256 bytes. To address these issues, interface correction instructions were generated, which changed the parameter declaration of type float3 to float type and added the constraint logic of 256-byte memory alignment to the code.

[0078] Next, based on the interface correction instructions, the function parameter declaration section in the kernel code was located, and the vertex data parameter type was changed from float3 to float. Logical code for reading data aligned to 256 bytes was added to the memory access area of ​​the code. After completing the modifications, the corrected vertex transformation kernel code was saved and generated.

[0079] Then, through the system's library file retrieval interface, the paths and linking parameters of the CUDA runtime library (cudart) and the CUDA math library (cublas) are obtained. The NVCC compiler is then invoked to link the corrected kernel code with the two library files. The compiler handles library dependencies according to the linking parameters, ultimately generating a dynamic link library adapted for Maya software. This is a .mll file on Windows and a .so file on Linux. The parameter interfaces of this dynamic link library perfectly match the mapping table definition and can be directly called by Maya plugins.

[0080] S105: Register the dynamic link library as a plugin through the plugin interface.

[0081] In this embodiment, registering a dynamic link library as a plugin through the plugin interface includes: Obtain the dynamic link library, GPU kernel call instructions, and the node identifier of the original CPU node to be replaced; Based on the node identifier, the original CPU node's attribute interface list and topology connection relationship are extracted through the application programming interface to generate the original node topology configuration data. Call the node registration function in the plugin interface, taking the node identifier in the dynamic link library and the original node topology configuration data as input, register the dynamic link library as a new plugin node, and generate a plugin registration handle; Based on the plugin registration handle and the attribute interface list in the original node topology configuration data, each attribute definition of the original CPU node is mapped and bound to the corresponding attribute interface of the new plugin node, generating an attribute binding mapping table. Based on the attribute binding mapping table and the topological connection relationship in the original node topology configuration data, the new plug-in node is connected to the directed acyclic graph node network data, and the GPU kernel call instructions are replaced with the CPU execution logic of the new plug-in node.

[0082] This embodiment accurately captures all node dependency information by extracting the original CPU node's attribute interface list and topology connections, avoiding the risk of data loss caused by manually rebuilding connections. The plugin registration mechanism utilizes the application's native interface, ensuring that new nodes receive system-level approval rather than intrusive modifications, significantly improving system stability. The attribute-by-attribute mapping and binding strategy guarantees the precise correspondence of each parameter and input / output connection, eliminating the need for artists to reconfigure material parameters or reconnect node networks. Seamlessly embedding GPU kernel call instructions into the node execution logic achieves a leap in computational performance without altering the user's workflow.

[0083] Specifically, the compiled dynamic link library polySmooth_gpu.so is obtained, which contains optimized vertex smoothing kernel code. The GPU kernel call instruction launch Smooth Kernel is extracted, and the original CPU node identifier to be replaced is identified as polySmooth1, which processes a high-precision character model containing 52,000 vertices.

[0084] Then, by accessing node polySmooth1 through the Maya API MFnDependency Node, its attribute interface list is queried to obtain 14 input and output attributes such as divisions, smoothness, and input poly mesh. The node connection relationship is traversed to obtain 83 topology connections, including the out mesh connection of the predecessor node polygon base and the in mesh connection of the successor node skinCluster1, generating complete raw node topology configuration data, which includes 14 attribute metadata and 83 connection relationships.

[0085] Next, the Maya plugin registration interface MFnPlugin:register Node is called, passing the dynamic link library path and the node identifier polySmooth1 as parameters. The system loads the library file and verifies the exported symbols, creates a GPU-accelerated node instance, and returns the plugin registration handle node Handle_7890. This handle contains the memory address and function pointer table of the new node. Verification shows that loading was successful, and the new node has been added to the Maya node registry.

[0086] Then, using the plugin registration handle node Handle_7890, the 14 attribute definitions in the original node topology configuration data are traversed and mapped one by one to the new plugin node. The original node's divisions attribute (integer, range 1-10) is bound to the corresponding attribute interface param_divisions in the new node, the smoothness attribute (floating-point, range 0.0-1.0) is mapped to param_smoothness_factor, and the inputPolymesh attribute (polygon mesh data) is mapped to gpu_input_geometry. Each attribute mapping records the data type, default value, and access permissions, generating an attribute binding mapping table containing 14 entries, and verifying that all mapping items match the data type successfully.

[0087] Next, based on the attribute binding mapping table and 83 topology connections, the system calls the `MFnDag Node:reconnect Nodes` function to connect the new plugin node to the DAG network, disconnects all connections of the original `polySmooth1` node, redirects the output of the predecessor node `polygonBase` to the input of the new node, and updates the input source of the successor node `skinCluster1` to the output of the new node. Simultaneously, the GPU kernel call instruction `launch Smooth Kernel` is injected into the `compute` function pointer of the new node, replacing the original CPU execution logic.

[0088] In some embodiments, while maintaining the original technical framework and core processes, a smooth transition from a dedicated computing platform to a cross-platform computing architecture is achieved by systematically replacing the underlying hardware interaction modules.

[0089] In terms of the overall architecture, the entire proven workflow from node analysis to parallel execution in the original solution is fully retained. This includes performance monitoring of the DAG node network through the Maya application programming interface, using a topology sorting algorithm to identify dependencies between nodes, and filtering out time-consuming critical nodes. Meanwhile, the data preprocessing workflow remains unchanged, continuing to use 256-byte alignment and block storage strategies to optimize data layout. The automatic plugin registration mechanism and Maya workflow compatibility are also fully preserved, ensuring that user operating habits are not affected.

[0090] During the replacement of the underlying hardware interaction module, the first step was to convert the computation kernel template library. The original CUDA kernel template files were converted to OpenCL kernel template files, maintaining the core computational logic while adjusting key character meanings. Specifically, the thread identification method was changed from the CUDA-specific blockIdx.x and threadIdx.x to the OpenCL standard get_global_id(0) function call. For missing mathematical utility functions in the OpenCL standard library, such as 4x4 matrix multiplication, targeted implementations were needed based on the characteristics of Maya node types.

[0091] Adapting the memory management mechanism is another crucial step. While maintaining the data alignment strategy and block storage scheme, the memory allocation interface was converted from CUDA-specific functions to the OpenCL standard interface. Device memory allocation is implemented through the `cl Create Buffer` function, while the fixed mapping of high-frequency, small data is accomplished using the `CL_MEM_ALLOC_HOST_PTR` flag combined with the `cl Enqueue Map Buffer` function. This conversion ensures that the device can directly access host memory, avoiding unnecessary data duplication while maintaining the original memory type mapping relationships.

[0092] The device interaction interface update involves hardware selection and execution model adaptation. The OpenCL platform's enumeration mechanism automatically identifies available computing devices in the system, including GPUs and CPUs from different vendors, and prioritizes GPUs as the computing unit. CUDA's grid and thread block dimension configurations are converted to OpenCL's global and workgroup size settings to maintain consistency in parallel computing granularity. The kernel startup method has been changed from the CUDA Launch function to the clEnqueueNDRangeKernel function, while ensuring the continuity of parameter binding logic.

[0093] The adjustments to the compilation and deployment process reflect a shift from offline compilation to runtime compilation. The original NVCC offline compilation solution has been abandoned in favor of the Open CL runtime compilation mechanism. Program objects are created using the `clCreateProgramWithSource` function, and then real-time compilation is performed using the `clBuildProgram` function. This change allows for the reuse of plugin generation logic; only the linked runtime library needs to be replaced from the CUDA series to the Open CL standard library.

[0094] The core advantages of this solution are reflected in three aspects. Cross-hardware compatibility is achieved through OpenCL's platform abstraction layer, automatically adapting to various hardware environments and eliminating dependence on specific vendors' hardware. Performance is guaranteed through appropriate compilation parameter configuration, such as using the `fast-relaxed-math` flag to enable fast mathematical operations, ensuring computational efficiency comparable to the original solution. Migration costs are effectively controlled; since only the underlying interface is replaced while the upper-level architecture remains unchanged, existing node analysis algorithms and data processing flows do not require modification, significantly reducing code refactoring workload.

[0095] When implementing this solution, special attention needs to be paid to handling platform differences. A corresponding compatibility layer needs to be established to address potential feature differences between OpenCL implementations from different vendors. Simultaneously, the device selection strategy should be optimized to ensure that the optimal computing device is selected under various hardware configurations. For complex data types and computational tasks, it may be necessary to develop specific optimized kernels to fully leverage the parallel computing capabilities of different hardware.

[0096] By implementing the above technical solutions, a smooth transition from dedicated computing platforms to open computing standards can be achieved while maintaining the original technological advantages. This not only expands the applicability of the solution, making it adaptable to diverse hardware environments, but also lays a more open foundation for subsequent technology upgrades and functional expansions. The entire solution demonstrates the advantages of modular design, achieving significant functional improvements through limited interface changes, and providing a more flexible solution for performance optimization in the field of 3D graphics processing.

[0097] In some embodiments, to address the need for accelerating nodes in directed acyclic graphs (DAGs) in Maya software, a simplified compilation process is adopted, using a pre-compiled CUDA operator library with dynamic invocation. The core logic is to build a pre-compiled CUDA operator library covering commonly used DAG nodes offline, and directly invoke the corresponding operator at runtime through node type matching. This completely eliminates the steps of dynamically generating code, real-time NVCC compilation, and dynamically registering plugins, retaining only the lightweight process of node analysis, operator matching, and parallel execution. This simplifies the architecture and improves system response speed. The overall process is divided into two stages: offline operator library construction and runtime core execution. Each stage is closely connected and remains compatible with the core optimization logic of the original solution.

[0098] The first step is to build a pre-compiled CUDA operator library offline. This is the core preliminary step of the entire solution, and all operations are completed offline in one go, requiring no compilation during subsequent runtime. The first step is to screen commonly used DAG node types, identifying the core node types frequently used in Maya to ensure that the operator library covers more than 80% of practical application scenarios. Specifically, this includes geometry nodes such as mesh, NURBS, and polyplane, which primarily handle the calculation of vertex, normal, and texture coordinates; material nodes such as Phong, Lambert, and Blinn, which primarily handle lighting and texture sampling; deformer nodes such as blend Shape, skinCluster, and nonlinear deformation, which primarily handle vertex displacement and shape interpolation; and general computational nodes such as multiply Divide and add Double Linear, which primarily handle parameter calculations. By screening, the coverage of the operator library is clearly defined, setting boundaries for subsequent operator development.

[0099] The second step involves developing pre-compiled operators. Independent CUDA operators are developed for each selected node type, reusing core optimization logic from the original scheme, such as 256-byte data alignment, 128×N block partitioning, and CPU-GPU data transfer optimization. Only the dynamically generated code step is removed. Taking the vertex transformation operator for mesh nodes as an example, the CUDA kernel code is written first, defining the input parameters as aligned vertex data, total number of vertices, transformation matrix, and block size. The block size is fixed at 128, consistent with the original scheme. The kernel uses parallel mapping logic where one thread processes one vertex, first calculating the vertex ID and... Boundary checks are performed, then vertex data is read to perform the core calculation of transformation matrix multiplication, and finally the result is written back. Subsequently, a C-style call interface for the operator library is developed to expose the outside world. The interface reuses the memory management and data transfer logic of the original solution. First, GPU memory is allocated through cudaMalloc, and then the host vertex data is transferred to the GPU through cudaMemcpy. Next, the dimensions of thread blocks and thread grids are configured, the above CUDA kernel is started, and after execution, the result is sent back to the host and the memory is released. The development of operators for other node types follows this logic, and is customized and optimized according to the computational characteristics of the node type.

[0100] The third step is to compile offline to generate the operator library. All the developed CUDA operator files are compiled using the NVCC compiler. During compilation, the architecture is specified as sm_80, fast mathematical calculation is enabled, and the number of registers allocated is set to 256. First, the object files are compiled and generated. Then, the object files are packaged into static or dynamic libraries under the Windows system and static or shared libraries under the Linux system to form a pre-compiled CUDA operator library that can be directly called.

[0101] The fourth step is to construct a node type-operator mapping table. A configuration file is created to record the mapping relationship between each Maya node type and the corresponding operator in the operator library. Specifically, it includes the Maya node type identifier, operator name, exposed calling interface, input parameter list, and data layout requirements. The data layout requirements specify the 256-byte alignment and block size. This mapping table serves as a key index for runtime operator matching, ensuring the accurate correspondence between node types and operators.

[0102] After completing the offline operator library construction, the core process of the runtime phase is executed. This phase consists of three steps: node analysis, operator matching, and parallel execution, completely skipping the real-time compilation stage. The first step is node analysis. This step reuses the logic of the original solution without any modification. Callback functions before and after node execution are registered using the MCallbackId of the Maya API. The execution time of each node in the DAG node network is monitored. The dependency relationship between nodes is resolved using the MGraphIterator interface. A topological sorting algorithm is used to identify dependency chains. Then, based on the average execution time, nodes whose execution time exceeds three times the average time are selected as time-consuming critical nodes. Subsequently, the mesh data and texture coordinate data of the critical nodes are preprocessed. The data is aligned to 256 bytes and divided into 128×N blocks according to the data layout requirements of the mapping table to ensure that the output data format is consistent with the input format of the pre-compiled operators.

[0103] The second step is operator matching, a newly added core step that replaces the original real-time compilation. First, the type string of the current key node is obtained through the Maya API's MObject:apiTypeStr(). Then, the offline-built node type-operator mapping table is loaded. This mapping table is loaded only once at program startup and cached in memory to avoid repeatedly reading the configuration file. Next, the mapping table is traversed, and the corresponding operator information is matched according to the node type string, including the operator call interface, input parameter requirements, and data layout. Then, the input parameters required by the operator are extracted from the Maya node attributes, such as the world Matrix attribute of the mesh node and the diffuse color attribute of the phong node, and converted into a format that the operator can recognize, such as converting the Maya MMatrix type to the CUDA float4x4 type. Finally, operator call permission verification is performed. If the corresponding operator is matched, the parallel execution phase begins. If no user-defined node or uncommon node is matched, the process automatically falls back to CPU serial execution to ensure system compatibility.

[0104] The third step involves parallel execution. This step reuses the logic of the original solution, only replacing the operator calling method. First, according to the data layout requirements in the mapping table, the preprocessed aligned data and adapted input parameters are transferred to the GPU memory via CUDA API. During the transfer, the original solution's optimization strategies, such as asynchronous batch processing and fixed mapping of high-frequency small data, are reused to reduce data transfer time. Then, the operator calling interface found in the mapping table is used to directly call the CUDA kernel in the pre-compiled operator library without any compilation operation. After the GPU completes the execution, the result is sent back to the CPU memory to replace the calculation result of the original node. Finally, according to the topologically ordered dependency relationship, the matching operators of all key nodes are executed in sequence to ensure that downstream nodes can obtain the optimized results of upstream nodes, thus completing the execution of the entire dependency chain.

[0105] Throughout the implementation process, key adaptation details ensured the feasibility of the solution. Firstly, there was strong data format compatibility: the input data format of precompiled operators, including alignment and block size, was strictly constrained with the output format of runtime data preprocessing through a mapping table, preventing calculation errors caused by data mismatches. Secondly, there was operator library version management: when Maya versions were updated or GPU architectures were upgraded, only offline compilation of the operator library and replacement of the old library files were required, without modifying the runtime logic. Thirdly, there was an exception rollback mechanism: nodes that did not match precompiled operators automatically switched to CPU serial execution logic, without affecting Maya's normal workflow. Finally, there was parameter mapping caching: the mapping table loaded at runtime was cached in memory, improving the efficiency of operator matching. The advantages of this solution are fully demonstrated in practical application scenarios. First, it has a fast response speed. By eliminating the real-time compilation stage, the latency from analysis to execution of key nodes is reduced from seconds to milliseconds. Second, the architecture is simpler. There is no need to integrate the NVCC compiler and dynamic code generation module, reducing development and maintenance costs by 50%. Finally, it has higher stability. The pre-compiled operators have been verified through offline testing, avoiding syntax errors and compatibility issues that may occur with real-time compilation. It is especially suitable for standardized production processes based on commonly used Maya nodes, such as batch rendering of film and animation, game scene production, and scenarios with high requirements for system response speed and fixed hardware environments.

[0106] In some embodiments, for mesh_geometry and simple_transform type nodes in the directed acyclic graph of Maya software, a CPU-GPU collaborative scheme with the addition of a hybrid scheduling module is adopted. A task priority judgment step is inserted into the original node analysis to execution process. By quantifying the node computational characteristics and real-time hardware load, dynamic load allocation between CPU and GPU is achieved. The overall process retains the core logic of the original scheme, and only selects the execution path through branching. This avoids unnecessary hardware switching overhead and maximizes the utilization of CPU and GPU computing resources.

[0107] Specifically, the original node analysis process was executed without modification. Node execution callback functions were registered via the Maya API. Frame-by-frame execution time monitoring was performed on the mesh_geometry and simple_transform nodes, recording the start and end timestamps of each node's execution and calculating the actual execution time. Simultaneously, a topological sorting algorithm was used to parse the upstream and downstream dependencies between nodes, identifying the input and output data association objects of each node. Combining the scale of the mesh data processed by the node, the types of computational operators included, and other attributes, a node analysis list containing node execution time data, dependencies, and computational characteristics was generated. The logic and operations of the entire node analysis process were completely reused from the original solution without any modifications.

[0108] After completing the node analysis, the task priority determination stage begins, as shown in Table 6.

[0109] Table 6 This evaluation is based on three core quantitative indicators and preset thresholds: In terms of computational complexity, regarding data scale, `mesh_deform` has 15,000 vertices (≥10,000) and 2e6 ≥1e6 operations, meeting the high-scale condition; `keyframe_control` has 800 <1,000 vertices and 5e3 <1e4 operations, belonging to the small-scale category; `mesh_smooth` has 5,000 vertices, falling between 1,000 and 10,000, belonging to the medium-scale category. Regarding computational intensity, `mesh_deform` involves complex real-time lighting calculations, with a single-element operation of 40 FLOPs (≥30), `keyframe_control` only involves simple matrix multiplication, with a single-element operation of 5 FLOPs, and `mesh_smooth` involves vertex interpolation calculations, with a single-element operation of 20 FLOPs. In terms of dependency characteristics, `keyframe_control` has 6 ≥ 5 upstream and downstream dependent nodes, belonging to high serial dependency, while the other two types of nodes each have 3 dependent nodes, belonging to low dependency. Based on real-time hardware status, allocation is performed according to a three-level priority decision rule, as shown in Table 7: Table 7 Mesh_deform meets the high-priority criteria, namely, the data size and computational load meet the requirements, the computational intensity is sufficient, and the GPU is idle, so it is assigned to the GPU for execution; keyframe_control meets the low-priority criteria, namely, the data size is small and the serial dependency is high, so it is directly assigned to the CPU for execution; mesh_smooth is of medium size and the hardware load is balanced, so it enters the dynamic branch to wait for further allocation.

[0110] The process then enters the branch execution phase. Each branch logic reuses the existing solution, only making fork selection: For the `mesh_deform` node allocated to the GPU, the original execution flow is completely reused. First, its mesh data undergoes 256-byte boundary alignment. Vertex coordinates are padded with 4 bytes of invalid data in blocks of 21, and texture coordinates are directly arranged in blocks of 32. Then, according to the rule of thread block size 128 and data dimension 3, the aligned data is divided into regular data blocks, generating a block index mapping table. Subsequently, the pre-compiled mesh deformation CUDA operator is called, and the corresponding GPU kernel is started to complete parallel computation. After the result is returned, the node data is updated. For the keyframe_control node allocated to the CPU, the GPU adaptation and data transmission process is skipped. The native CPU serial computing interface of Maya is called, and the transformation logic of the keyframe is completed through the matrix operation method provided by the MMatrix class, avoiding the additional overhead caused by hardware switching. For the mesh_smooth node in the dynamic branch, the hardware load data is read in real time. If the current GPU utilization is lower than that of the CPU, it is allocated to the GPU for execution. If the GPU utilization is subsequently monitored to rise to above 70%, it can be dynamically switched to the CPU for execution.

[0111] Throughout the execution process, three key details ensure the feasibility of the solution: First, collaborative processing is relied upon. If the upstream node of the mesh_smooth node is assigned to GPU execution, the downstream node mesh_deform will also prioritize GPU execution, reducing the overhead of cross-hardware data transfer. Second, threshold calibration is implemented. If the current hardware is a low-end GPU, the data size threshold for computational complexity can be adjusted from 10,000 to 8,000 to adapt to the actual processing capabilities of the hardware. Third, exception rollback is handled. If the mesh_deform node encounters a memory shortage exception during GPU execution, the system will automatically terminate the GPU execution process and switch to CPU to call Maya's native interface to complete the calculation, ensuring that the entire node execution process is not interrupted and guaranteeing the stability of the Maya workflow.

[0112] This embodiment solves the problems of low data transfer efficiency between CPU and GPU and difficulty in parallel allocation of node tasks by implementing low-level adaptation between Maya DAG nodes and CUDA architecture. The parallel computing power of GPU can be fully utilized, which can significantly shorten the execution time of large-scale DAG node networks. For example, in tasks such as complex scene rendering and animation simulation, the processing efficiency can be improved by several times or even tens of times, greatly reducing the project production cycle. Simultaneously, the system automatically adapts and accelerates computational performance for different types of DAG nodes. This ensures accurate results for tasks such as mesh data processing for geometry nodes and lighting calculations for material nodes, without requiring the development of separate optimization schemes for each type of node. This feature allows the system to cover the vast majority of commonly used node types in Maya, expanding the applicability of the technical solution. Then, through an automatic operator generation and compilation mechanism, the system eliminates the reliance on manually written operator libraries. When Maya versions are updated, NVIDIA GPUs introduce new architectures, or users use custom plugins, the system can automatically adapt to the new environment without the need for manual redevelopment or code modification. This not only reduces maintenance costs but also enables rapid response to hardware and software upgrade needs, ensuring high efficiency in long-term use. Unlike optimization schemes that only target a single module, the fully automated system constructed in this invention covers the entire process from node analysis and parallel acceleration to compilation and deployment. This enables the DAG node network to achieve efficient collaboration in all stages, including data transmission, task allocation, and computation execution, fully unleashing the parallel computing potential of CUDA and providing strong support for the stable and efficient operation of Maya software in large-scale projects.

[0113] Please see Figure 5 This embodiment provides a directed acyclic graph node compilation device 200, including: The acquisition unit 201 is used to acquire directed acyclic graph node network data, monitor the execution time of each directed acyclic graph node in the directed acyclic graph node network data through the application programming interface, and identify the dependency relationship between each directed acyclic graph node in the directed acyclic graph node network data through the topology sorting algorithm to obtain the time-consuming key nodes. Alignment unit 202 is used to perform data alignment and block storage processing on the grid data in the time-consuming critical node, and to generate kernel code by matching the type of the time-consuming critical node with a preset kernel template library. The construction unit 203 is used to perform data transmission between the CPU and GPU using an asynchronous transmission and batch processing strategy, based on the data format and parameter interface required by the kernel code, for the time-consuming critical nodes, and to construct a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters. The compilation unit 204 is used to call the compiler to compile the kernel code in real time and generate a dynamic link library that matches the parameter interface of the mapping table. Registration unit 205 is used to register the dynamic link library as a plugin through the plugin interface.

[0114] Furthermore, the acquisition unit 201 includes: The monitoring subunit is used to acquire directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node in the DAG node network data through the application programming interface, and generate a time series record table and statistical distribution characteristics. The parsing subunit is used to process the directed acyclic graph node network data by applying the topology sorting algorithm, parsing the connection relationship of each directed acyclic graph node, and generating a node-dependent topology sequence. The calculation subunit is used to calculate the cumulative influence weight of each node in the directed acyclic graph by combining the time-series record table and the node-dependent topology sequence; Determine the sub-units to determine the time threshold based on the statistical distribution characteristics of all nodes in the directed acyclic graph; A filtering subunit is used to compare the cumulative influence weight of each directed acyclic graph node with the time threshold, and filter out directed acyclic graph nodes whose cumulative influence weight exceeds the time threshold to form a set of candidate key nodes. The analysis subunit is used to analyze the dependency transitive relationships between each directed acyclic graph node in the candidate key node set to obtain the time-consuming key nodes.

[0115] Furthermore, the parsing subunit includes: The statistics subunit is used to count the number of in-degrees of each node in the directed acyclic graph (DAG) node network data and generate an in-degree count mapping table. The queue construction subunit is used to filter the directed acyclic graph nodes with an in-degree value of zero in the in-degree count mapping table and construct an initial queue of zero-in-degree nodes. The iterative sub-unit is used to iteratively update the in-degree values ​​of the child nodes associated with each directed acyclic graph node in the initial zero-in-degree node queue, and add the child nodes whose in-degree becomes zero to the initial zero-in-degree node queue to generate a node dependency topology sequence.

[0116] Furthermore, the alignment unit 202 includes: The feature extraction subunit is used to extract the geometric features and topological structure of the grid data in the time-consuming key nodes and generate data layout description information. The reconstruction subunit is used to parse the data layout description information to determine the memory offsets of vertex coordinates, normal vectors and texture coordinates, and reconstruct the memory layout of the mesh data according to the byte boundary alignment rules, and output the aligned mesh data; The slicing unit is used to analyze the dimensional characteristics and access patterns of the aligned grid data, determine the block size parameters, and divide the aligned grid data into multiple regular data blocks according to the block size parameters to generate a block index mapping table. The retrieval subunit is used to identify the type identifier and functional attributes of the time-consuming critical node, and retrieve a matching basic kernel template in the kernel template library according to the type identifier; An injection subunit is used to extract the block dimension parameters and thread configuration parameters from the block index mapping table, and inject the block dimension parameters and thread configuration parameters into the placeholder position of the basic kernel template to replace the memory access mode with optimized access instructions. An integration subunit is used to integrate the functional attributes and the optimized access instructions to generate kernel code.

[0117] Furthermore, the building unit 203 includes: Define an extraction subunit for extracting the data format definition and parameter interface specification of the kernel code; The data reorganization subunit is used to reorganize and fill the original grid data to be processed by the time-consuming key nodes according to the data format definition, and generate optimized grid data blocks. The matching subunit is used to traverse the connectable attributes of the directed acyclic graph nodes based on the source attribute identifier in the parameter interface specification, match the source attribute identifier with the actual attribute name in the directed acyclic graph nodes, and generate parameter source matching relationship. The batch processing subunit is used to create multiple asynchronous transport streams based on the parameter source matching relationship and the optimized grid data block, and to assign asynchronous batch processing transport tasks to each of the asynchronous transport streams; The transmission subunit is used to transmit the parameter values ​​of the node attributes that match the optimized grid data block, and the optimized grid data block from the CPU memory to the GPU memory when the asynchronous batch transmission task is scheduled to be executed. The mapping table construction subunit is used to construct a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters based on the parameter values ​​successfully transferred to the GPU memory and the position order of the parameter values ​​in the parameter interface specification.

[0118] Furthermore, the compilation unit 204 includes: The type parsing subunit is used to parse the parameter types, memory alignment boundaries, and data dimension constraints defined in the mapping table and generate interface specification description data. The parameter set construction subunit is used to construct a compilation configuration parameter set based on the data extraction function signature template and memory access mode described in the interface specification. The instruction generation subunit is used to detect the current GPU's computing power version, determine the compilation target architecture identifier and register allocation strategy in combination with the compilation configuration parameter set, and generate architecture-adaptive compilation instructions. The priority setting subunit is used to integrate the kernel code and architecture adaptation compilation instructions into a compilation task description, set the asynchronous compilation queue priority, and generate a compilation task object; An object processing subunit is used to process the compilation task object through the compiler and generate an initial compilation result; The verification subunit is used to verify the compatibility between the exported symbols of the initial compilation result and the parameter interfaces in the mapping table, identify type mismatches and memory boundary conflicts, and generate interface correction instructions. The application subunit is used to rewrite the kernel function parameter declarations of the kernel code using the interface correction instructions, and generate the corrected kernel code. The linking subunit is used to obtain the runtime library and the math library, and to link the modified kernel code with the runtime library and the math library through the compiler to generate a dynamic link library.

[0119] Furthermore, the registration unit 205 includes: The identifier acquisition subunit is used to acquire the dynamic link library, GPU kernel call instructions, and node identifier of the original CPU node to be replaced. The relationship extraction subunit is used to extract the list of attribute interfaces and topological connection relationships defined by the original CPU node based on the node identifier through the application programming interface, and generate the original node topology configuration data. The node registration subunit is used to call the node registration function in the plugin interface, taking the dynamic link library and the node identifier in the original node topology configuration data as input, registering the dynamic link library as a new plugin node, and generating a plugin registration handle. The mapping subunit is used to map and bind each attribute definition of the original CPU node to the corresponding attribute interface of the new plugin node based on the plugin registration handle and the attribute interface list in the original node topology configuration data, and generate an attribute binding mapping table. The access subunit is used to connect the new plug-in node to the directed acyclic graph node network data based on the attribute binding mapping table and the topological connection relationship in the original node topology configuration data, and to replace the GPU kernel call instruction with the CPU execution logic of the new plug-in node.

[0120] Please see Figure 6 MAYA network node: This is the starting point of the entire process input, representing the DAG node network to be accelerated in Maya software.

[0121] Node Analysis Module: Receives input from "MAYA Network Node 1" and analyzes the node's execution time, dependencies, etc., divided into three branch processes: Branch 1: Flow to CUDA parallel acceleration module 3; Branch 2: Flow to API monitoring module 4; Branch 3: Flow Optimization Data Transmission Module 7.

[0122] CUDA Parallel Acceleration: Based on the analysis results of Node Analysis Module 2, the nodes are adapted for GPU parallelization, including grid data memory layout optimization, automatic CUDA kernel generation, etc. The processed data flows to the Data Transmission and Mapping Module 5.

[0123] API monitoring: The node execution process is monitored through MayaAPI to obtain information such as node execution time and data dependencies. The monitoring results flow to the data preprocessing module 6.

[0124] Data transmission and mapping: responsible for data format conversion and parameter mapping between CPU and GPU. The processed data flows to the link analysis module 11 on one hand and to the data preprocessing module 6 on the other.

[0125] Data preprocessing module: Receives input from API monitoring module 4 and data transmission and mapping module 5, performs preprocessing on node data such as standardization and outlier filtering, and the processed data flows to automatic compilation module 9.

[0126] Optimize data transmission: Based on the analysis of node analysis module 2, plan the data transmission strategy between CPU and GPU. The processed data flows to the automatic compilation module 9 on one hand and to the data verification module 8 on the other.

[0127] Data verification module: Receives input from optimized data transmission module 7 and automatic compilation module 9, verifies the accuracy of the data after GPU acceleration, and ensures that the calculation results are consistent with the original CPU execution results.

[0128] The automatic compilation module receives input from the data preprocessing module 6 and the optimized data transmission module 7, and completes the compilation of the CUDA kernel and Maya plugin code. It consists of two branching processes: Branch 1: Flow to generate plugin code module 10; Branch 2: The data flows to the data verification module 8, and its compilation results also flow to the link analysis module 11.

[0129] Generate plugin code: Receives input from the automatic compilation module 9, dynamically generates acceleration plugin code that can be registered in Maya, and finally flows to the link analysis module 11.

[0130] Link Analysis Module: Receives input from Data Transmission and Mapping 5, Automatic Compilation Module 9, and Plugin Code Generation 10, optimizes the parallel links of GPU tasks by combining node dependency graphs, and the processed data flows to Data Interaction Module 12.

[0131] Data interaction: This is the endpoint of the process, completing the full-process optimization of data interaction between the CPU and GPU, and enabling GPU-accelerated execution of DAG nodes. The overall process presents a closed loop of analysis-acceleration-compilation-optimization. Each module drives each other through data links and control logic, achieving a fully automated conversion from Maya's original nodes to GPU-accelerated plugins, ultimately achieving the goal of improving Maya's graphics processing performance.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0133] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, can implement the methods provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0134] The present invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the methods provided in the above embodiments. Of course, the computer device may also include various network interfaces, power supplies, and other components.

[0135] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

[0136] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only 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-exclusivity.

[0137] The term "comprises" implies that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for compiling nodes of a directed acyclic graph, characterized in that, include: Obtain the directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node within the DAG node network data through the application programming interface, and identify the dependency relationships between each DAG node within the DAG node network data through the topology sorting algorithm to obtain the time-consuming key nodes. For the grid data in the time-consuming critical nodes, data alignment and block storage processing are performed, and kernel code is generated by matching the type of the time-consuming critical nodes with a preset kernel template library. For the time-consuming critical nodes, based on the data format and parameter interface required by the kernel code, an asynchronous transmission and batch processing strategy is adopted to execute data transmission between the CPU and GPU, and a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters is constructed. The compiler is invoked to compile the kernel code in real time, generating a dynamic link library that matches the parameter interface of the mapping table; Register the dynamic link library as a plugin through the plugin interface.

2. The method for compiling nodes of a directed acyclic graph according to claim 1, characterized in that, The process involves acquiring directed acyclic graph (DAG) node network data, monitoring the execution time of each DAG node within the data via an application programming interface (API), and identifying the dependencies between DAG nodes using a topology sorting algorithm. The resulting time-consuming key nodes include: Acquire directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node within the DAG node network data through the application programming interface, and generate a time series record table and statistical distribution characteristics; The topology sorting algorithm is applied to process the directed acyclic graph node network data, parse the connection relationships of each directed acyclic graph node, and generate a node dependency topology sequence. The cumulative influence weight of each node in the directed acyclic graph is calculated by combining the time-series record table with the node-dependent topology sequence. The time threshold is determined based on the statistical distribution characteristics of all nodes in the directed acyclic graph; By comparing the cumulative influence weight of each node in the directed acyclic graph with the time threshold, nodes in the directed acyclic graph whose cumulative influence weight exceeds the time threshold are selected to form a set of candidate key nodes. By analyzing the dependency transitive relationships between the nodes in the directed acyclic graph of the candidate key node set, the time-consuming key nodes are obtained.

3. The method for compiling nodes of a directed acyclic graph according to claim 2, characterized in that, The application of the topology sorting algorithm processes the directed acyclic graph (DAG) node network data, parses the connection relationships of each DAG node, and generates a node-dependent topology sequence including: The number of in-degrees of each node in the directed acyclic graph (DAG) node network data is counted, and an in-degree count mapping table is generated. Filter the directed acyclic graph nodes with an in-degree value of zero from the in-degree count mapping table, and construct an initial queue of zero-in-degree nodes; Iteratively update the in-degree values ​​of the child nodes associated with each directed acyclic graph node in the initial zero-in-degree node queue, and add the child nodes whose in-degree becomes zero to the initial zero-in-degree node queue to generate a node dependency topology sequence.

4. The method for compiling nodes of a directed acyclic graph according to claim 1, characterized in that, The process of aligning and storing the grid data in the time-consuming critical nodes, and generating kernel code by matching the type of the time-consuming critical nodes with a preset kernel template library, includes: Extract the geometric features and topological structure of the grid data in the time-consuming key nodes to generate data layout description information; The data layout description information is parsed to determine the memory offsets of vertex coordinates, normal vectors, and texture coordinates. The memory layout of the mesh data is reconstructed according to the byte boundary alignment rules, and the aligned mesh data is output. Analyze the dimensional characteristics and access patterns of the aligned grid data, determine the block size parameters, and divide the aligned grid data into multiple regular data blocks according to the block size parameters to generate a block index mapping table; Identify the type identifier and functional attributes of the time-consuming critical nodes, and retrieve the matching basic kernel template in the kernel template library based on the type identifier; Extract the block dimension parameters and thread configuration parameters from the block index mapping table, and inject the block dimension parameters and thread configuration parameters into the placeholder positions of the basic kernel template to replace the memory access mode with optimized access instructions; The aforementioned functional attributes and optimized access instructions are integrated to generate kernel code.

5. The method for compiling nodes of a directed acyclic graph according to claim 1, characterized in that, For the time-consuming critical nodes, based on the data format and parameter interface required by the kernel code, an asynchronous transmission and batch processing strategy is used to execute data transmission between the CPU and GPU, and a mapping table between the node attributes of the directed acyclic graph nodes and kernel parameters is constructed, including: Extract the data format definition and parameter interface specification from the kernel code; Based on the data format definition, the original grid data to be processed at the time-consuming key nodes is reorganized and filled to generate optimized grid data blocks; Based on the source attribute identifier in the parameter interface specification, the connectable attributes of the directed acyclic graph node are traversed, and the source attribute identifier is matched with the actual attribute name in the directed acyclic graph node to generate a parameter source matching relationship. Based on the parameter source matching relationship and the optimized grid data block, multiple asynchronous transport streams are created, and asynchronous batch processing transport tasks are assigned to each of the asynchronous transport streams; When the asynchronous batch transfer task is scheduled to be executed, the parameter values ​​of the node attributes that match the optimized grid data block, and the optimized grid data block are transferred from CPU memory to GPU memory. Based on the parameter values ​​successfully transmitted to the GPU memory and the order of these parameter values ​​in the parameter interface specification, a mapping table is constructed between the node attributes of the directed acyclic graph nodes and the kernel parameters.

6. The method for compiling nodes of a directed acyclic graph according to claim 1, characterized in that, The step of calling the compiler to perform real-time compilation of the kernel code and generate a dynamic link library that matches the parameter interface of the mapping table includes: Parse the parameter types, memory alignment boundaries, and data dimension constraints defined in the mapping table to generate interface specification description data; Based on the interface specification, a set of compilation configuration parameters is constructed to describe the signature template of the data extraction function and the memory access mode. The current GPU's computing power version is detected, and the target architecture identifier and register allocation strategy are determined in combination with the compilation configuration parameter set to generate architecture-adaptive compilation instructions; The kernel code and architecture-adaptive compilation instructions are integrated into a compilation task description, and the asynchronous compilation queue priority is set to generate a compilation task object; The compiler processes the compilation task object to generate initial compilation results. Verify the compatibility between the exported symbols of the initial compilation result and the parameter interfaces in the mapping table, identify type mismatches and memory boundary conflicts, and generate interface correction instructions; The kernel function parameter declarations of the kernel code are rewritten using the interface correction instructions to generate the corrected kernel code; The runtime library and the math library are obtained, and the modified kernel code is linked with the runtime library and the math library by the compiler to generate a dynamic link library.

7. The method for compiling nodes of a directed acyclic graph according to claim 1, characterized in that, Registering the dynamic link library as a plugin via the plugin interface includes: Obtain the dynamic link library, GPU kernel call instructions, and node identifier of the original CPU node to be replaced; Based on the node identifier, the list of attribute interfaces and topology connection relationships defined by the original CPU node are extracted through the application programming interface to generate the original node topology configuration data. Call the node registration function in the plugin interface, taking the node identifier in the dynamic link library and the original node topology configuration data as input, register the dynamic link library as a new plugin node, and generate a plugin registration handle; Based on the plugin registration handle and the attribute interface list in the original node topology configuration data, each attribute definition of the original CPU node is mapped and bound to the corresponding attribute interface of the new plugin node, generating an attribute binding mapping table. Based on the attribute binding mapping table and the topological connection relationship in the original node topology configuration data, the new plug-in node is connected to the directed acyclic graph node network data, and the GPU kernel call instruction is replaced with the CPU execution logic of the new plug-in node.

8. A node compilation apparatus for a directed acyclic graph, characterized in that, include: The acquisition unit is used to acquire directed acyclic graph (DAG) node network data, monitor the execution time of each DAG node in the DAG node network data through the application programming interface, and identify the dependency relationship between each DAG node in the DAG node network data through the topology sorting algorithm to obtain the time-consuming key nodes. The alignment unit is used to perform data alignment and block storage processing on the grid data in the time-consuming critical node, and to generate kernel code by matching the type of the time-consuming critical node with a preset kernel template library. The construction unit is used to perform data transmission between the CPU and GPU using asynchronous transmission and batch processing strategies, based on the data format and parameter interface required by the kernel code, for the time-consuming critical nodes, and to construct a mapping table between the node attributes of the directed acyclic graph nodes and the kernel parameters. The compilation unit is used to call the compiler to compile the kernel code in real time and generate a dynamic link library that matches the parameter interface of the mapping table; The registration unit is used to register the dynamic link library as a plugin through the plugin interface.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for compiling nodes of a directed acyclic graph as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the directed acyclic graph node compilation method as described in any one of claims 1 to 7.

Images