Three-dimensional rendering task scheduling and resource allocation method and platform based on cloud collaboration

Abstract

This invention discloses a cloud-based collaborative method and platform for scheduling and allocating resources for 3D rendering tasks, belonging to the field of data processing technology. The method includes the following steps: performing a structured analysis of the 3D rendering job to be executed, breaking it down into parallel subtasks to form asset task groups, and initially mapping them to corresponding cloud computing node sets; conducting a multi-dimensional quantitative assessment of resource impact for each asset task group during the preparation phase before entering rendering computation, obtaining a set of load risk description parameters; generating a corresponding set of resource allocation control parameters for each asset task group, and implementing concurrent access control and node preheating scheduling to form a set of warmed nodes; and performing affinity parallel scheduling processing to complete the 3D rendering task. This solves the technical problems in existing technologies where the shared channel carrying capacity during the preparation phase is not considered, leading to long GPU waiting times, delayed rendering startup, and unstable loading responses.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a cloud-based collaborative method and platform for scheduling and allocating 3D rendering tasks and resources. Background Technology

[0002] In cloud-based collaborative 3D rendering platforms, the platform not only needs to handle photorealistic rapid rendering and batch rendering tasks, but also needs to support high-concurrency interactive scenarios such as multi-user online review and cross-device real-time viewing. Users typically initiate rendering requests in a concentrated and repeated manner within a short time window. For example, during scheme review, marketing rendering, or version comparison, it is often necessary to quickly generate rendering results with multiple angles, multiple scene templates, and multiple quality levels based on the same 3D model version. To meet the user experience requirements of fast loading, concurrent rendering, and stable response, existing cloud rendering platforms typically adopt a multi-node collaborative cluster computing approach, breaking down a single rendering job into multiple sub-tasks and distributing them to different cloud computing nodes for parallel execution.

[0003] Because the same batch of rendering subtasks are highly consistent in terms of model structure, texture resources, material libraries, and renderer configurations, each subtask generally needs to perform preparatory operations such as asset retrieval, cache preheating, shader compilation, and texture uploading before entering the formal rendering computation. These preparatory operations rely on the platform's shared storage system and shared network channel, and their resource consumption exhibits significant concentration and suddenness. In high-concurrency rendering request scenarios, a large number of subtasks simultaneously entering the preparation stage within a short period can easily cause a sudden impact on the shared channel, shifting the overall platform performance bottleneck from computing power to the shared channel's capacity during the asset preparation stage. This leads to rendering startup delays, increased GPU waiting time, and fluctuations in output latency, ultimately affecting the user experience of online collaborative review and cross-terminal viewing.

[0004] Existing cloud rendering solutions achieve parallel rendering by dividing the rendering task into image regions, while others achieve 3D rendering by building a cloud rendering node cluster and allocating tasks based on the node load status.

[0005] For example, Chinese invention patent CN106502794B discloses an efficient rendering method for 3D rendering based on cloud rendering, which includes: S1, the floor plan design module designs the floor plan and sends the rendering task image data to the data exchange management module, and the data exchange management module sends the rendering task data to the rendering task scheduler; S2, the rendering task scheduler receives the rendering task image data and divides the image to be rendered in the rendering task image data into n image regions according to the image allocation strategy, and assigns a corresponding rendering task to each image region, forming n rendering tasks.

[0006] For example, Chinese invention patent CN120821548B discloses a Windows 3D cloud rendering system, method, and device, including: a model data acquisition unit that determines whether a corresponding historical rendering model is stored in the cloud server; acquiring the 3D model data to be rendered and the rendering parameters corresponding to the 3D model data based on the determination result; a load balancing unit that dynamically allocates rendering tasks to multiple rendering nodes based on the node status of the service nodes; a task scheduling unit that constructs a cloud rendering node cluster based on all rendering nodes; deploying rendering tools based on the cloud rendering node cluster and calling local resources; and a rendering unit that uses the rendering tools and local resources to perform rendering according to the rendering parameters.

[0007] The above-mentioned technology has at least the following technical problems:

[0008] However, the aforementioned existing technologies, when collaboratively dispatching rendering subtasks across multiple nodes, typically prioritize the allocation of computing power during the rendering computation phase, failing to incorporate the capacity of shared storage and network channels during the pre-rendering asset retrieval and warm-up phases into a unified resource allocation constraint. When multiple subtasks of the same model version or the same set of materials are triggered simultaneously within a short period, model and texture retrieval, shader compilation, and texture uploading operations tend to occur in the preparation phase. This leads to a large number of subtasks being blocked in the preparation phase, causing prolonged GPU waiting times and low utilization. Consequently, this results in fluctuating rendering time, significant delays in the tail tasks of the job, difficulty in consistently meeting the batch rendering delivery schedule, and, in high-concurrency scenarios, impacts the loading response speed during online viewing and review processes. Summary of the Invention

[0009] To address the slow loading response speed problem in existing technologies, this invention provides a cloud-based collaborative method and platform for 3D rendering task scheduling and resource allocation. The technical solution is as follows:

[0010] On the one hand, a cloud-based collaborative method for scheduling and allocating resources for 3D rendering tasks is provided. This method includes: after receiving a rendering job trigger signal, the 3D rendering platform performs task structured analysis on the 3D rendering job to be executed, breaks it down into parallel sub-tasks, identifies asset associations for the parallel sub-tasks to form asset task groups, and performs initial mapping to the corresponding set of cloud computing nodes; for each asset task group in the preparation stage before entering rendering computation, a multi-dimensional quantitative assessment of resource impact is performed to obtain a load risk description parameter set to characterize the comprehensive impact of the asset task group on the stability of shared resources and computing power utilization; based on the load risk description parameter set, the 3D rendering platform generates a corresponding resource allocation control parameter set for each asset task group, and implements concurrent access control and node preheating scheduling for each asset task group in the preparation stage according to the resource allocation control parameter set to form a set of warmed nodes; the 3D rendering platform performs affinity parallel scheduling processing on each parallel sub-task based on the set of warmed nodes, thereby completing the 3D rendering task.

[0011] On the other hand, a cloud-based collaborative 3D rendering task scheduling and resource allocation platform is provided. This platform includes: a rendering task allocation module, a multi-dimensional risk quantification assessment module, a node preheating module, and an affinity parallel scheduling module. The rendering task allocation module, upon receiving a rendering job trigger signal, performs task structure parsing on the 3D rendering job to be executed, breaking it down into parallel sub-tasks, identifying asset associations for the parallel sub-tasks, forming asset task groups, and initially mapping them to the corresponding cloud computing node sets. The multi-dimensional risk quantification assessment module is used to assess the risk of each asset task group before it enters rendering computation. In the preparation phase, a multi-dimensional quantitative assessment of resource impact is conducted to obtain a load risk description parameter set that characterizes the comprehensive impact of asset task groups on the stability of shared resources and computing power utilization. The node preheating module is used by the 3D rendering platform to generate corresponding resource allocation control parameter sets for each asset task group based on the load risk description parameter set, and to implement concurrent access control and node preheating scheduling for each asset task group in the preparation phase according to the resource allocation control parameter set, forming a set of warmed nodes. The affinity parallel scheduling module is used by the 3D rendering platform to perform affinity parallel scheduling processing on each parallel subtask based on the set of warmed nodes, thereby completing the 3D rendering task.

[0012] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0013] 1. The cloud-based collaborative 3D rendering task scheduling and resource allocation method provided by this invention performs shared channel load intensity assessment, cloud platform shared storage and network channel congestion risk assessment, and computing power waiting and low utilization risk assessment on asset task groups during the preparation phase. Based on the assessment results, a resource allocation control parameter set is generated, thereby implementing concurrent access control and node preheating scheduling during the preparation phase. This achieves pre-constraint and orderly release of high-impact operations such as asset retrieval, cache preheating, and shader compilation, effectively solving the technical problems of long GPU waiting time, delayed rendering startup, and unstable loading response caused by the failure to consider the shared channel carrying capacity during the preparation phase in the prior art.

[0014] 2. This invention introduces a burst load intensity value into the asset task group during the preparation phase, and generates a corresponding concurrency limit and injection rate by combining the shared channel congestion risk value. This limits the repeated asset retrieval and repeated preheating of the same asset task group in a short period of time, thereby achieving smooth adjustment of shared storage bandwidth and network channel load, and improving the stability of the shared channel and the predictability of overall scheduling of the cloud platform in high-concurrency rendering scenarios.

[0015] 3. This invention assesses the computing power waiting and underutilization risks of asset task groups, and generates upper limits for the number of anchor nodes and scalable collaborative nodes based on the computing power waiting and underutilization risk values ​​and the shared channel congestion risk value. This guides asset preheating to be prioritized on anchor nodes and formed a reusable state, thereby avoiding long-term idle or excessive pre-occupation of computing power resources during the preparation phase, improving the actual utilization rate of GPU resources during the rendering phase and reducing the risk of tail task delays.

[0016] 4. This invention introduces a cache affinity weight set based on historical asset hit statistics and prioritizes scheduling parallel subtasks to the set of hot nodes in affinity parallel scheduling, thereby reducing repeated asset fetching and repeated cache construction operations. This enables efficient aggregation and execution of parallel subtasks within the same asset task group on hot nodes, improving cache reuse rate and overall rendering throughput efficiency in multi-node collaborative rendering scenarios. Attached Figure Description

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

[0018] Figure 1 A macro-level flowchart of the cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in the embodiments of this application;

[0019] Figure 2 A flowchart illustrating the overall process of a cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in this application embodiment;

[0020] Figure 3 A scatter plot of risk profiles for asset task groups in the cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in this application embodiment;

[0021] Figure 4 A comparative diagram of queuing time during the preparation phase of the cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in the embodiments of this application;

[0022] Figure 5 This is a schematic diagram of the structure of a cloud-based collaborative 3D rendering task scheduling and resource allocation platform provided in an embodiment of this application. Detailed Implementation

[0023] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0024] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0025] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0026] like Figure 1 As shown, Figure 1This is a macro-flowchart of a cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in an embodiment of this application. The method includes the following steps: After receiving a rendering job trigger signal, the 3D rendering platform performs task structure parsing on the 3D rendering job to be executed, breaking it down into parallel subtasks. Specifically, the 3D rendering job identifies various rendering tasks (such as model loading, texture mapping, and lighting calculation) by parsing the input rendering request. These tasks are then divided into multiple subtasks based on their functions. Each subtask represents an independent operation in the rendering process. The system then evaluates the computational resource requirements of each subtask, including computing power, memory, and bandwidth. Based on the dependencies between subtasks, they are allocated to different cloud computing nodes, ensuring that related subtasks are executed in parallel as much as possible on physical nodes. Asset association identification is performed on the parallel subtasks to form asset task groups. For example, if a rendering job needs to use the same texture map... The platform renders multiple scenes, each generating a parallel subtask that relies on the same texture map. Recognizing this shared texture resource, the platform aggregates these subtasks into an asset task group. The platform can then specify resource management strategies for this asset task group, such as preheating the cache or using shared storage, and perform initial mapping to the corresponding set of cloud computing nodes. The mapping method involves: assessing the resource requirements of each parallel subtask, including parameters such as CPU, GPU, memory, and storage bandwidth, to determine the required resource specifications for each subtask; and obtaining the resource capabilities of each cloud computing node, including its processing power, idle resources, network bandwidth, and storage capacity. This information can be obtained through the cloud platform's resource management module. Based on these resource requirements and node capabilities, a matching algorithm (such as shortest task priority scheduling) maps each subtask to a cloud computing node with sufficient resources. For example, if a subtask requires a significant amount of GPU resources, nodes with relatively idle GPU resources will be prioritized for mapping. This mapping can be statically allocated (e.g., static mapping based on task priority and node idle resources). For each asset task group during the preparation phase before rendering computation, a multi-dimensional quantitative assessment of resource impact is performed to obtain a load risk description parameter set characterizing the combined impact of the asset task group on the stability of shared resources and computing power utilization. This load risk description parameter set includes the burst load intensity value of the asset task group, the shared channel congestion risk value of the cloud platform, and the computing power waiting and low utilization risk value of the asset task group. Based on the load risk description parameter set, the 3D rendering platform generates a corresponding resource allocation control parameter set for each asset task group and implements concurrent access control and node preheating scheduling for each asset task group during the preparation phase, forming a set of warmed nodes. Based on the set of warmed nodes, the 3D rendering platform performs affinity parallel scheduling on each parallel subtask, thereby completing the 3D rendering task.

[0027] In this embodiment, as Figure 2 As shown, Figure 2 This is a flowchart illustrating the overall process of a cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in this application. Upon receiving a 3D rendering task, the system parses the task and divides it into corresponding asset task groups based on the task content. It further identifies the parallel subtasks within each asset task group. The platform acquires the rendering asset cache hit statistics generated during historical rendering processes and calculates a cache affinity weight set accordingly. Based on this set, the platform determines the set of hot nodes for the corresponding asset task group and performs affinity parallel scheduling processing on each parallel subtask during the scheduling phase. When the number of hot nodes meets the concurrent scheduling requirements of the parallel subtasks, the rendering subtasks are executed in parallel directly within the set of hot nodes. When the set of hot nodes cannot meet the concurrent scheduling requirements, the shared channel congestion risk value of the cloud platform is assessed. If the shared channel congestion risk value is lower than a preset shared channel congestion risk threshold and the number of collaborative nodes does not exceed the maximum scalable number of collaborative nodes, collaborative nodes are introduced to synchronously execute the 3D rendering task. Otherwise, the current node execution strategy is maintained, ultimately completing the 3D rendering and outputting the rendering result.

[0028] like Figure 3 As shown, Figure 3 This is a scatter plot illustrating the risk profile of asset task groups in the cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in this application embodiment. Each scatter point represents an asset task group. The horizontal axis represents the burst load intensity value (normalized), and the vertical axis represents the shared channel congestion risk value (normalized). The horizontal reference line in the figure represents the shared channel congestion risk threshold. Scatter points higher than this shared channel congestion risk threshold indicate that congestion during the preparation phase is more likely to occur under the current channel carrying capacity. The stronger the impact during the preparation phase of the asset task group, the higher the channel congestion risk.

[0029] Furthermore, a multi-dimensional quantitative assessment of resource impact is conducted. Specifically, based on the shared channel load intensity assessment, cloud platform shared storage and network channel congestion risk assessment, and computing power waiting and low utilization risk assessment performed on each asset task group, the burst load intensity value, cloud platform shared channel congestion risk value, and asset task group computing power waiting and low utilization risk value are obtained respectively, and these are combined as a load risk description parameter set.

[0030] In this embodiment, in the cloud-based collaborative 3D rendering scenario, the preparation phase of the rendering job before entering formal computation involves numerous asset retrieval and compilation operations, and relies on the shared storage, shared network channels, and computing node power status of the cloud platform. Its resource consumption exhibits characteristics of multi-source superposition, temporal interleaving, and instantaneous concentration. A single-dimensional resource assessment is insufficient to accurately reflect the true impact of the preparation phase on the subsystem. Therefore, a comprehensive analysis combining load intensity, channel capacity, and computing power utilization status is necessary to achieve a multi-dimensional quantitative assessment of resource impact. Specifically, the shared channel load intensity assessment can characterize the instantaneous impact on shared channels and node resources when asset task groups trigger concentrated asset retrieval, cache preheating, and compilation operations during the preparation phase. The congestion risk assessment of the cloud platform's shared storage and network channels reflects the capacity and congestion risk of shared channels for multiple asset task groups concurrently entering the preparation phase under the current overall platform operating status. The computing power waiting and low utilization risk assessment identifies GPU waiting, computing power idleness, and rendering startup delays caused by channel resource constraints during the preparation phase.

[0031] Furthermore, the shared channel load intensity assessment method is as follows: Obtain the load intensity parameters of each parallel subtask under the asset task group. These parameters include asset concurrent fetch intensity, cache preheating concurrency coefficient, shader compilation overlap rate, and peak memory usage for texture upload. Obtain a preset load intensity parameter reference set and normalize the load intensity parameters to obtain normalized values. Specifically, the normalization process involves dividing each load intensity parameter by its corresponding reference set. Then, a preset load intensity weighting factor set is introduced to weight and sum these normalized values ​​to obtain the final value. The burst load intensity value represents the instantaneous impact of the rendering task on shared channels and node resources during the preparation phase. The weighted summation is specifically achieved by multiplying each load intensity normalized value by its corresponding load intensity weighting factor set, obtaining the product result, and then summing the product results to obtain the burst load intensity value. The load intensity parameter reference set includes asset concurrent fetch intensity reference value, cache preheating concurrent coefficient reference value, shader compilation overlap rate reference value, and texture upload memory usage peak reference value. The load intensity weighting factor set includes asset concurrent fetch intensity weighting factor, cache preheating concurrent coefficient weighting factor, shader compilation overlap rate weighting factor, and texture upload memory usage peak weighting factor.

[0032] In this embodiment, the asset concurrent fetch intensity is the ratio of the number of subtasks concurrently fetching assets within a preset statistical time window to the total number of subtasks in the asset task group, which can be obtained through concurrent reading statistics of asset access logs recorded by the scheduling system. The cache preheating concurrency coefficient is the ratio of the number of parallel subtasks in the cache preheating state within a preset time window to the number of subtasks in the asset task group that have entered the preparation stage, which can be obtained through statistics of cache loading event timestamps and task identifiers recorded by the cache management module on the rendering node. The shader compilation overlap rate is the ratio of the sum of the compilation times of overlapping shaders within the statistical time window to the sum of the total compilation times of all subtask shaders, which can be obtained through analysis of the compilation logs and timestamps output by the rendering engine. The peak texture upload memory usage is the maximum value of texture upload-related memory usage monitored within the preparation stage time window, which can be obtained in real time through the GPU driver interface.

[0033] During the preparation phase, the asset concurrent fetch intensity, cache preheating concurrency coefficient, shader compilation overlap rate, and peak memory usage for texture upload are not independent of each other, but rather exhibit a clear chain-like and cumulative effect: a higher asset concurrent fetch intensity directly increases the cache preheating concurrency coefficient, causing multiple subtasks to load model and texture resources simultaneously within a similar timeframe; after the cache preheating operation is completed, compilation of the same or similar shader configurations is often triggered, thereby increasing the shader compilation overlap rate; after the shader compilation is completed, the texture upload phase begins, making the texture upload operation highly concentrated in time, further pushing up the peak memory usage for texture upload.

[0034] In multiple historical 3D rendering job cycles, actual monitoring data were collected on asset concurrent fetch intensity, cache preheating concurrency coefficient, shader compilation overlap rate, and peak texture upload memory usage during the preparation phase. Simultaneously, performance degradation indicators for the preparation phase within the corresponding job cycle were collected. These indicators included the increase in preparation phase time and the increase in GPU idle waiting time. The increase in preparation phase time refers to the increment of the actual preparation phase time for the same type of 3D rendering job in the current job cycle relative to the average preparation phase time for that type of job in the historical baseline cycle. This can be calculated by recording the start and end times of each asset task group entering the preparation phase within each job cycle using the scheduling system, calculating the current actual preparation phase time, and subtracting the baseline preparation phase time for the corresponding job type under stable operating conditions from the historical database. The increase in GPU idle waiting time refers to the increment of the cumulative waiting time during the preparation phase when the GPU is idle but has pending rendering tasks, relative to the historical baseline idle waiting time. This can be calculated by statistically analyzing the waiting time of GPUs idle during the preparation phase and the number of pending rendering tasks. The column contains the cumulative duration of tasks awaiting execution, which serves as the GPU idle waiting time for the current period. This idle waiting time is then compared to the baseline value of the corresponding job type's GPU idle waiting time in historical stable periods to calculate the increase in GPU idle waiting time. Using the value sequences of asset concurrent pull intensity, cache preheating concurrency coefficient, shader compilation overlap rate, and peak texture upload memory usage in each job period, along with their corresponding performance degradation index sequences, the Pearson correlation coefficient is used to calculate the linear correlation between each parameter and the performance degradation index, thus obtaining the asset concurrent pull... The correlation coefficients for intensity, cache preheating concurrency, shader compilation overlap rate, and peak texture upload memory usage were calculated. The absolute values ​​of each correlation coefficient were taken to eliminate the influence of positive and negative directions, and the obtained absolute value correlation coefficients were normalized so that the sum of the normalized results was 1. The normalized results were used as weighting factors for asset concurrent pull intensity, cache preheating concurrency, shader compilation overlap rate, and peak texture upload memory usage, respectively, to characterize the relative influence of each parameter on performance degradation during the preparation phase.

[0035] By quantitatively assessing the load intensity of shared channels, the risk of concentrated load on asset task groups in both time and resource dimensions can be identified before the rendering task enters the preparation phase. This avoids misjudgments caused by scheduling based solely on GPU computing power or node idle status. The selected parameters, such as concurrent asset fetching, cache preheating, shader compilation, and texture uploading, cover the key aspects of the preparation phase that have the greatest impact on shared storage, network channels, and GPU resources, ensuring that the assessment results accurately reflect the instantaneous impact characteristics of the preparation phase. Based on this burst load intensity value, the platform can further implement refined concurrent access control and node preheating strategies, thereby reducing asset fetch congestion, minimizing GPU idle time, smoothing rendering startup latency, and improving the overall stability and delivery consistency of cloud-based collaborative 3D rendering in high-concurrency scenarios.

[0036] Furthermore, the congestion risk assessment of shared storage and network channels on the cloud platform is conducted using the following method: First, obtain the current shared channel operating status parameters of the cloud platform, including the shared storage bandwidth limit, shared network channel throughput, and current utilization rate. Second, obtain a pre-set shared channel operating status reference set from the database, and after normalizing the shared channel operating status parameters, perform a weighted summation process to obtain the shared channel congestion risk value of the cloud platform. The shared channel operating status reference set includes the shared storage bandwidth limit reference value, the shared network channel throughput reference value, and the current utilization rate reference value. The shared channel congestion risk value is used to reflect the risk level when the same batch of rendering subtasks enters the preparation stage under existing resource conditions.

[0037] In this embodiment, the shared storage bandwidth limit refers to the maximum data transmission capacity that the cloud storage system can provide to all tasks within a unit of time. This can be obtained by querying the preset bandwidth limit parameter through the storage system management interface. The shared network channel throughput refers to the maximum amount of data that the network channel between cloud nodes can actually transmit within a unit of time, reflecting the capacity and efficiency of the network channel. This can be obtained by collecting network transmission rates using network monitoring tools and combining this with node topology statistics. The current utilization rate refers to the real-time occupancy ratio of the shared network channel at the current point in time, reflecting the immediate status of the resources. This can be obtained through the real-time monitoring API by obtaining the current transmission rate and calculating it against the bandwidth limit: Current utilization rate = Current rate ÷ Maximum bandwidth / Channel capacity.

[0038] The upper limit of shared storage bandwidth constrains the actual channel utilization and network throughput. When the bandwidth limit is low, even if the network is idle, the data transmission rate cannot be increased. The throughput of the shared network channel directly affects the speed of operations such as asset retrieval and texture upload. It is also constrained by the current utilization rate, which is affected by the bandwidth limit and network throughput, as well as by task concurrency and historical load patterns. High utilization rate means that resources are close to saturation, which may lead to increased queuing and latency. Therefore, the bandwidth limit and network throughput determine the resource limit, and the current utilization rate reflects the real-time state. They influence each other and jointly determine the availability and congestion risk of the shared channel.

[0039] The shared channel congestion risk value of the cloud platform is obtained as follows: A pre-defined set of weighted factors for the shared channel's operating status is retrieved from the database. This set includes weighted factors for the shared storage bandwidth limit, shared network channel throughput, and current utilization. The shared storage bandwidth limit is divided by the shared storage bandwidth limit, the shared network channel throughput is divided by the shared network channel throughput, and the current utilization is divided by the current utilization reference value. This normalization process yields the normalized values ​​for each shared channel operating status parameter. These normalized values ​​are then multiplied by their corresponding weighted factors and summed to obtain the shared channel congestion risk value of the cloud platform.

[0040] The weighting factor set for the shared channel's operational status can be obtained from a database. For example, it can collect shared channel usage data for historical rendering tasks on different cloud nodes, specifically including historical shared storage bandwidth usage, historical shared network channel throughput, and historical channel utilization time series. Simultaneously, it can collect latency indicators related to the preparation phase of the shared channel within the corresponding job cycle, including queuing time, asset retrieval waiting time, cache preheating waiting time, and texture upload waiting time. The values ​​of actual shared storage bandwidth usage, actual shared network channel throughput, and channel utilization within each job cycle are used as independent variables, and the total latency indicators within the corresponding cycle are used as the weighting factor. With waiting time as the dependent variable, a multiple linear regression method is used to calculate the contribution ratio of the three types of channel operating status parameters to the total waiting time variation during the preparation phase. This ratio reflects the degree of influence of the parameter on the performance degradation during the preparation phase, and this degree of influence is used as the corresponding weighting factor. The contribution ratios of the above three types of parameters are normalized so that the sum of the weighting factor of the shared storage bandwidth limit, the weighting factor of the shared network channel throughput, and the weighting factor of the current channel utilization rate is 1, thereby obtaining a reproducible set of weighting factors for the shared channel operating status. This set is used to weight and superimpose the normalized shared channel operating status parameters to calculate the final cloud platform shared channel congestion risk value.

[0041] The purpose of conducting a shared channel congestion risk assessment is to quantify potential bottlenecks during the asset preparation phase in advance during rendering task scheduling and resource allocation. The assessment can predict the probability of concurrent subtasks becoming blocked or queued when executing 3D rendering tasks, helping the platform to rationally set concurrency limits, injection rates, and the number of anchor nodes. This avoids GPU waiting and underutilization, improving the overall stability and efficiency of the rendering job. Simultaneously, it enables the platform to balance the load on shared resources under high concurrency conditions, ensuring the response speed for online viewing and review, and guaranteeing the timeliness of batch rendering and delivery.

[0042] Furthermore, the assessment of computing power waiting and underutilization risk is conducted using the following method: Obtaining the task status statistics of the asset task group during the preparation phase and the computing power status statistics of the cloud computing nodes; the task status statistics include queuing time during the preparation phase, asset retrieval waiting time, compilation waiting time, upload waiting time, and the preparation phase completion rate; the computing power status statistics include the number of rendering instances pre-occupied on the corresponding cloud computing nodes, the percentage of GPU queue idle time, and the number of tasks allocated but not yet entered for rendering computation; based on the correlation analysis of the task status statistics and computing power status statistics, the computing power waiting and underutilization risk value of the asset task group is obtained; the computing power waiting and underutilization risk value is used to characterize the degree of risk of long GPU waiting times, delayed rendering startup, and delayed tail tasks due to the limited capacity of the shared channel during the preparation phase.

[0043] In this embodiment, the preparation phase queuing time represents the time each parallel subtask spends waiting to enter the preparation phase queue, which can be obtained by recording the time difference between task enqueueing and dequeueing by the task scheduler. The asset retrieval waiting time represents the time spent by a task waiting to retrieve assets such as models and textures from shared storage or the network, which can be obtained by recording the time difference between starting and completing retrieval in the log. The compilation waiting time represents the time required for a task to wait for the shader to be compiled, which can be obtained by recording the compilation task scheduler. The upload waiting time represents the time required for a task to wait to upload textures or other data to the node, which can be obtained by recording the upload task log. The preparation phase completion rate represents the proportion of tasks that have completed preparation operations such as asset retrieval, cache preheating, shader compilation, and texture upload, which can be obtained by dividing the number of completed tasks by the total number of tasks.

[0044] The number of pre-allocated rendering instances represents the number of rendering instances that have been allocated on the node but have not yet been started. This can be queried through the node management system. The percentage of idle time in the GPU queue represents the proportion of the cumulative time that the GPU spends in an idle waiting state during the preparation phase to the total preparation phase time. This is calculated by collecting GPU idle time from the node monitoring and dividing it by the total time. The number of tasks that have been allocated but not yet entered into rendering computation represents the number of tasks that have been allocated on the node but have not yet been started. This can be obtained through the task scheduler and node status interface.

[0045] The statistical parameters of each task status are closely related to the statistical parameters of computing power status: longer queuing time and asset retrieval waiting time in the preparation phase will lead to a decrease in GPU utilization and an increase in GPU queue idle time, thereby increasing the number of tasks that have been allocated but have not yet entered rendering computation; increased compilation waiting time and upload waiting time will also occupy the rendering instance resources of the node, prolong the GPU queue waiting time, and increase queuing and waiting time; a low completion rate in the preparation phase indicates that node resources are not fully utilized and the proportion of queue idle time is increased; a decrease in GPU utilization will further lead to a prolongation of task queuing and waiting time, forming a negative feedback effect; an excessive number of pre-occupied rendering instances will increase the queuing time and waiting time of tasks in the preparation phase, thereby reducing the completion rate of the preparation phase.

[0046] Correlation analysis is performed based on task status statistics and computing power status statistics to obtain the computing power waiting and low utilization risk values ​​of asset task groups. The specific method is as follows: obtain the preset task status statistics comparison set and computing power statistics comparison set in the database. The task status statistics comparison set includes comparison values ​​of queuing time in the preparation stage, asset retrieval waiting time, compilation waiting time, upload waiting time, and preparation stage completion rate. The computing power statistics comparison set includes comparison values ​​of the number of pre-occupied rendering instances, the percentage of idle time in the GPU queue, and the number of tasks that have been allocated but have not yet entered rendering computation. By dividing the queuing time during the preparation phase, the asset retrieval waiting time, the compilation waiting time, the upload waiting time, the number of pre-occupied rendering instances, the percentage of idle time in the GPU queue, and the number of tasks allocated but not yet entered rendering computation by their respective reference values, we obtain the normalized values ​​for each computing power waiting and low utilization risk. Dividing the reference value for the preparation phase completion rate by the preparation phase completion rate yields the normalized value for the preparation phase completion rate. Multiplying each normalized value for computing power waiting and low utilization risk and the normalized value for the preparation phase completion rate by the set of weighting factors for computing power waiting and low utilization risk assessment, and then summing them, we obtain the computing power waiting and low utilization risk value for the asset task group. The set of weighting factors for computing power waiting and low utilization risk assessment includes weighting factors for queuing time during the preparation phase, asset retrieval waiting time, compilation waiting time, upload waiting time, preparation phase completion rate, number of pre-occupied rendering instances, percentage of idle time in the GPU queue, and the number of tasks allocated but not yet entered rendering computation.

[0047] The set of weighting factors for assessing computing power wait time and low utilization risk can be obtained from a database. Taking the queuing time weighting factor in the preparation phase as an example, we collect queuing time data of several rendering tasks in the preparation phase on various cloud nodes, including the time series of each subtask from entering the preparation phase to starting to occupy the GPU. We perform variance analysis on the historical task queuing time and the corresponding total latency in the preparation phase (such as average waiting time), calculate the variance contribution ratio of queuing time to total latency, that is, the influence ratio of this parameter on overall performance degradation, and normalize the contribution ratio of all task status and computing power status parameters so that the sum of all weighting factors is 1. Thus, we obtain the queuing time weighting factor in the preparation phase. The other weighting factors in the set of weighting factors for assessing computing power wait time and low utilization risk are obtained in the same way as the queuing time weighting factor in the preparation phase.

[0048] Conducting a risk assessment of computing power waiting and underutilization can identify which tasks or nodes have problems such as resource waiting, queuing, and underutilization, thus providing a basis for generating resource allocation control parameters. This allows for the early detection of potential bottlenecks, avoids GPU idleness or overload, improves rendering efficiency, ensures that rendering jobs are completed on time, and maintains stable rendering performance and online collaborative experience under high concurrency conditions, thereby optimizing the overall scheduling strategy of the cloud-based 3D rendering platform.

[0049] Furthermore, a corresponding set of resource allocation control parameters is generated for each asset task group. Specifically, based on the shared channel congestion risk value and the burst load intensity value, a concurrency limit and an injection rate per unit time are generated for asset task groups to be allowed to simultaneously enter the preparation phase. The concurrency limit and injection rate are used to limit the scale of repeated asset fetching and repeated preheating triggered by the same asset task group within a short period. Based on the shared channel congestion risk value and the computing power waiting and low utilization risk values, an upper limit is generated for the number of anchor nodes and the number of scalable collaborative nodes for the asset task group. Anchor nodes are used to prioritize completing asset preheating and forming a reusable state, while collaborative nodes are used to expand rendering throughput when the scaling conditions are met. Asset hit statistics for historically identical rendering tasks are obtained, and a cache affinity weight set is obtained through analysis. The concurrency limit, injection rate, number of anchor nodes, upper limit for the number of scalable collaborative nodes, and cache affinity weight set are uniformly encapsulated to form a resource allocation control parameter set.

[0050] In this embodiment, based on the shared channel congestion risk value and the burst load intensity value, the concurrency limit value and the injection rate per unit time for asset task groups to simultaneously enter the preparation phase are generated. Specifically, the method involves retrieving data on the scale of subtasks entering the preparation phase of historical rendering tasks and the corresponding shared channel usage, including the number of tasks entering simultaneously, the request rate for pulling assets per unit time, and any queuing or blocking events. Then, based on the currently calculated shared channel congestion risk value and burst load intensity value, the actual concurrency and injection rate distribution of similar risk value ranges in historical tasks are searched in the database. The maximum concurrency value in historical data that did not cause significant queuing or blocking is obtained as the concurrency limit value for this task group, and the injection rate per unit time is calculated based on the historical average entry rate.

[0051] Based on the shared channel congestion risk value and the computing power waiting and low utilization risk value, the number of anchor nodes and the upper limit of the number of scalable collaborative nodes for asset task groups are generated. Specifically, the execution records of historical rendering tasks on each cloud node are retrieved, including the number of nodes assigned to the task, the node warm-up time, GPU utilization, and task tail latency. Then, based on the current task's shared channel congestion risk value and computing power waiting and low utilization risk value, tasks with similar risk ranges are matched in the historical records, and the number of nodes with balanced node load and minimum tail latency at that risk level is calculated. The number of anchor nodes is taken as the historically optimal number of nodes, enabling assets to complete warm-up and reuse preferentially. The upper limit of the number of collaborative nodes is taken as the historically allowed maximum number of scalable nodes, ensuring increased throughput while keeping risks under control.

[0052] To obtain the asset hit statistics of the same historical rendering tasks, analyze them to obtain the cache affinity weight set. The specific method is as follows: obtain the asset hit statistics of the same historical rendering tasks and compare them with the preset data range of each historical asset hit statistics in the database. If the asset hit statistics of the same historical rendering tasks are within a certain historical asset hit statistics data range, then the cache affinity weight set corresponding to that range is taken as the cache affinity weight set.

[0053] By analyzing the asset hit statistics of the same historical rendering tasks, the cache hit rate of each rendering asset on different cloud computing nodes is calculated. The rendering asset is the rendering resource unit repeatedly referenced by multiple parallel subtasks within the asset task group. Based on the cache hit rate of each rendering asset on each node, the corresponding hit ratio is calculated and used as the cache affinity weight value of the rendering asset on the corresponding node. The cache affinity weight values ​​of each rendering asset on each node within the asset task group are summarized to form a cache affinity weight set used to characterize the differences in the cache reuse capabilities of different nodes for the asset task group. The hit ratio is calculated as follows: Within a preset historical statistical period, for the same rendering asset, the number of cache hits and the corresponding total number of accesses are counted on each cloud computing node. The number of cache hits is the number of times that parallel subtasks directly reuse the existing cache or preheating products of the node during the execution preparation or rendering phase, and the total number of accesses is the total number of times the rendering asset is scheduled to participate in processing on the node. The ratio of the number of cache hits to the total number of accesses is taken as the cache hit rate of the rendering asset on the corresponding node. Furthermore, the cache hit rate of the same rendering asset on different nodes is normalized. That is, the sum of the cache hit rates of the rendering asset on all nodes is used as the normalization benchmark. The cache hit rate of each node is divided by the normalization benchmark to obtain the hit ratio of the rendering asset on each node. The hit ratio is used to characterize the degree of cache reuse advantage of the node relative to other nodes for the rendering asset. The cache affinity weight set includes several weight values. Each weight value represents the degree to which the corresponding asset has completed cache loading, warm-up, or reusable preparation in historical rendering tasks on a given hot node. A higher weight indicates a higher cache affinity for that asset on that node. This weight set ultimately applies to the set of hot nodes to differentiate the priority of different hot nodes when undertaking sub-tasks within the same asset task group.

[0054] When performing affinity parallel scheduling on each parallel subtask, nodes in the set of already warmed nodes are prioritized for scheduling. The scheduling logic uses the cache affinity weight set as a reference. The higher the weight of a node, the more likely the corresponding asset on that node has been preheated or the cache is reusable. When a subtask is scheduled to these nodes, repeated fetching and preheating can be avoided. This reduces redundant data preparation operations (such as asset fetching, cache preheating, and texture uploading), reduces the pressure on shared channels and computing power, improves node utilization and rendering throughput, stabilizes the execution time of rendering tasks, and minimizes redundant data operations and maximizes resource utilization.

[0055] By controlling the scale of tasks entering per unit time through concurrency caps and injection rates, instantaneous load impacts are reduced; by limiting the number of anchor nodes and scalable collaborative nodes, node allocation is ensured to guarantee efficient reuse of preheated assets and balance computing power; and by prioritizing task scheduling on already warmed nodes through cached affinity weight sets, node utilization and rendering throughput are improved.

[0056] Furthermore, the concurrent admission control is implemented as follows: A preparation phase admission queue is established for each asset task group. Specifically, each asset task group is used as the smallest scheduling unit, and an independent preparation phase task queue structure is created for each group. This queue structure uses a first-in, first-out (FIFO) queue format, sorted by arrival time. Each queue node corresponds to a parallel subtask awaiting entry into the preparation phase, and records the subtask's task identifier, asset type, estimated resource consumption, and arrival timestamp. When the scheduling system receives a new parallel subtask, it first maps it to the tail of the corresponding preparation phase admission queue based on its asset task group. Within each scheduling cycle, the scheduling control module reads the head subtask of the admission queue corresponding to that asset task group and combines this with the current number of admitted parallel subtasks, the concurrency limit, and the unit time. The system uses a combination of the number of injected tasks and the injection rate threshold to determine whether a task is allowed to proceed. If the determination passes, the first subtask in the queue is removed from the admission queue and marked as "admitted," allowing it to enter the preparation phase for data preparation. If the determination fails, the subtask remains at the head of the queue and is marked as "waiting for admission," continuing to participate in admission determination in subsequent scheduling cycles until all parallel subtasks in the asset task group's admission queue have completed admission and data preparation. Based on the concurrency limit and injection rate, the system performs admission determination on parallel subtasks entering the preparation phase. Parallel subtasks that meet the admission criteria are allowed to enter the preparation phase for data preparation. Parallel subtasks that do not meet the admission criteria are guided into the waiting queue and continue to undergo admission determination in subsequent scheduling cycles until all data preparation is completed.

[0057] In this embodiment, it should be noted that the admission criteria refer to the fact that the number of parallel subtasks in the preparation stage of the current asset task group does not exceed the concurrency limit of the asset task group, and the number of new subtasks entering the preparation stage within the current time window does not exceed the number of subtasks corresponding to the injection rate per unit time.

[0058] It should also be noted that data preparation includes asset retrieval, cache preheating, shader compilation, and texture upload processing. Data preparation is part of the preparation phase, which may include processes such as scheduling and waiting, and resource placement.

[0059] like Figure 4 As shown, Figure 4 This diagram illustrates a comparison of queuing times during the preparation phase of a cloud-based collaborative 3D rendering task scheduling and resource allocation method provided in this application embodiment. The horizontal axis represents time in minutes, and the vertical axis represents the queuing time during the preparation phase. The solution in the diagram combines concurrent access control with an affinity strategy in subsequent scheduling. Both the existing baseline solution and this solution describe a comparative trend of queuing times during the preparation phase under the same load process. The curve of the baseline solution shows higher peaks and greater fluctuations during burst periods, indicating that when sub-tasks of the same asset enter the preparation phase in a concentrated manner, the shared channel congestion leads to a significant increase in waiting time. In contrast, the curve of this solution is lower and smoother overall, indicating that after suppressing concurrent conflicts during the preparation phase through access control, the waiting time is suppressed and becomes more stable.

[0060] Furthermore, the node preheating scheduling method is as follows: For each parallel subtask that has passed the concurrency admission control, it is scheduled to the anchor node set of the corresponding asset task group to perform the preparation phase processing. Specifically, after the parallel subtask passes the concurrency admission control, the scheduling system selects the target node from the anchor node set that has been allocated to the asset task group based on the number of anchor nodes and their corresponding cloud computing node identifiers determined in the resource allocation control parameter set, and assigns the parallel subtask to the target node to perform preparation phase operations such as asset retrieval, cache loading, shader compilation and texture uploading. During the specific scheduling process, anchor nodes that are currently idle or under low load are prioritized to ensure that the preparation phase processing can be executed continuously without interruption. When the number of anchor nodes is greater than 1, parallel subtasks can be allocated to each anchor node according to the principle of minimum waiting time, thereby forming a controlled parallel preheating execution process within the anchor node range, avoiding repeated fetching and preheating of assets on different nodes. After the anchor node completes the data preparation processing, the preheating completion status, cache availability status, and reusable status of the preheating products of the corresponding asset fingerprint on that anchor node are recorded. The anchor nodes that have completed preheating are registered as the warmed nodes of the corresponding asset task group, and the set of warmed nodes is updated.

[0061] In this embodiment, asset fingerprint refers to feature identification information used to uniquely identify the state of a set of rendering assets, including at least one of the following: model version identifier, texture set hash value, material configuration parameter summary, and renderer configuration summary.

[0062] The preheating completion status indicates whether the corresponding asset fingerprint has completed all the preheating processes required in the preparation phase on the anchor node. This includes: whether the asset file has been completely fetched to local storage, whether the required dependencies have been resolved, whether the shaders have been compiled, and whether the textures have been uploaded and mapped to video memory. When all the above preparation phase operations are completed, the preheating completion status of the asset fingerprint on the anchor node is recorded as complete. The cache availability status indicates whether the data corresponding to the asset fingerprint in the anchor node's local cache is in a directly reusable and available state. This includes: whether the cache data has been hit, whether the cache data has not been evicted, whether the cache validity period is still valid, and whether the cache consistency check has passed. This status is used to determine whether subsequent parallel subtasks can directly use the existing cache without triggering asset fetching or preheating processes again. The preheating artifact reusable status indicates whether the preheating results formed on the anchor node can be shared and used by other parallel subtasks in the same asset task group. This includes: whether the preheating artifact supports concurrent access from multiple instances, whether there are no private dependency conflicts, and whether the version consistency requirements of subsequent rendering tasks are met.

[0063] Furthermore, affinity parallel scheduling is performed on each parallel subtask. Specifically, based on the cached affinity weight set, each parallel subtask to be scheduled is preferentially scheduled to cloud computing nodes in the set of hot nodes. This ensures that each parallel subtask in the same asset task group is executed in parallel within the set of hot nodes, provided that the number of hot nodes meets its concurrent scheduling requirements. When the shared channel congestion risk value is lower than the preset shared channel congestion risk threshold, and the number of currently introduced collaborative nodes is less than the upper limit of the number of scalable collaborative nodes, collaborative nodes are introduced to synchronously execute the 3D rendering task; otherwise, collaborative nodes are not introduced to synchronously execute the 3D rendering task.

[0064] In this embodiment, a collaborative node refers to an additional cloud computing node introduced by the cloud platform as needed, in addition to the anchor nodes and already-warmed nodes in the asset task group, based on the current shared channel operating status and computing power utilization. This node is used to extend the parallel execution capability of the 3D rendering stage without disrupting the existing asset preheating and cache reuse structure. The collaborative node does not undertake the core preheating tasks of the preparation stage. Instead, it is introduced to participate in 3D rendering calculations after the anchor nodes and already-warmed nodes have formed a stable cache and reusable state, improving the overall rendering throughput by executing rendering subtasks in parallel. Its main function is to supplement computing resources, rather than repeatedly performing high shared channel consumption operations such as asset fetching, cache preheating, or shader compilation.

[0065] Under the premise of controllable shared channel pressure, increasing the number of available computing nodes improves the parallelism of the 3D rendering stage, thereby shortening the overall rendering job completion time and alleviating the tail task delay problem caused by excessive load on a single node. Cooperative nodes are only introduced when the shared channel congestion risk value is below a preset threshold. This is to avoid further amplifying the channel congestion risk by adding nodes triggering additional asset access or synchronization operations when the shared storage or network channel is already under high load. Simultaneously, limiting the number of currently introduced cooperative nodes to no more than the maximum number of scalable cooperative nodes prevents excessive computing power expansion and avoids problems such as GPU resource idleness, decreased node utilization, or scheduling jitter. Not introducing cooperative nodes when the above conditions are not met helps maintain the stability and predictability of the scheduling system under resource-constrained conditions.

[0066] like Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of a cloud-based collaborative 3D rendering task scheduling and resource allocation platform provided in this application embodiment. The cloud-based collaborative 3D rendering task scheduling and resource allocation platform provided in this application embodiment includes: a rendering task allocation module, a multi-dimensional risk quantification assessment module, a node preheating module, and an affinity parallel scheduling module. The rendering task allocation module is used by the 3D rendering platform to perform task structure parsing on the 3D rendering job to be executed after receiving a rendering job trigger signal, breaking it down into parallel sub-tasks, identifying asset associations for the parallel sub-tasks, forming asset task groups, and initially mapping them to the corresponding cloud computing node sets. The multi-dimensional risk quantification assessment module… The system is used to perform multi-dimensional quantitative assessment of resource impact for each asset task group during the preparation phase before entering rendering computation, and obtain a load risk description parameter set to characterize the comprehensive impact of the asset task group on the stability of shared resources and computing power utilization; the node preheating module is used by the 3D rendering platform to generate corresponding resource allocation control parameter sets for each asset task group based on the load risk description parameter set, and to implement concurrent access control and node preheating scheduling for each asset task group during the preparation phase according to the resource allocation control parameter set, forming a set of warmed nodes; the affinity parallel scheduling module is used by the 3D rendering platform to perform affinity parallel scheduling processing on each parallel subtask based on the set of warmed nodes, thereby completing the 3D rendering task.

[0067] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0068] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0069] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0070] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0071] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0072] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A cloud-based collaborative three-dimensional rendering task scheduling and resource allocation method, characterized in that, Includes the following steps: After receiving the rendering job trigger signal, the 3D rendering platform performs task structure parsing on the 3D rendering job to be executed, breaks it down into parallel subtasks, identifies the asset associations of the parallel subtasks, forms asset task groups, and performs initial mapping to the corresponding set of cloud computing nodes. For each asset task group in the preparation stage before entering the rendering calculation, a multi-dimensional quantitative assessment of resource impact is carried out to obtain a set of load risk description parameters to characterize the comprehensive impact of the asset task group on the stability of shared resources and computing power utilization. The multi-dimensional quantitative assessment of resource impact is specifically as follows: based on the shared channel load intensity assessment, cloud platform shared storage and network channel congestion risk assessment, and computing power waiting and low utilization risk assessment performed by each asset task group, the burst load intensity value, cloud platform shared channel congestion risk value, and asset task group computing power waiting and low utilization risk value are obtained respectively, and they are combined as a load risk description parameter set. The 3D rendering platform generates a corresponding resource allocation control parameter set for each asset task group based on the load risk description parameter set, and implements concurrent access control and node preheating scheduling for each asset task group in the preparation stage according to the resource allocation control parameter set, forming a set of hot nodes. The specific method for generating corresponding resource allocation control parameter sets for each asset task group is as follows: Based on the shared channel congestion risk value and the burst load intensity value, the concurrent upper limit and injection rate per unit time for generating asset task groups to enter the preparation phase are determined. The concurrency limit and injection rate are used to limit the scale of repeated asset fetching and repeated preheating triggered by the same asset task group in a short period of time. Based on the shared channel congestion risk value and the computing power waiting and low utilization risk value, the number of anchor nodes and the upper limit of the number of scalable collaborative nodes for the asset task group are generated. The anchor nodes are used to complete the asset preheating first and form a reusable state, and the collaborative nodes are used to expand the rendering throughput when the scaling conditions are met. Obtain asset hit statistics for the same historical rendering tasks and analyze them to obtain a cache affinity weight set; The concurrency limit, injection rate, number of anchor nodes, maximum number of scalable collaborative nodes, and cache affinity weight set are uniformly encapsulated to form a resource allocation control parameter set. The 3D rendering platform performs affinity parallel scheduling on each parallel subtask based on the set of hot nodes, thereby completing the 3D rendering task.

2. The cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in claim 1, characterized in that: The specific method for assessing the load intensity of the shared channel is as follows: Obtain the load intensity parameters of each parallel subtask under the asset task group. The load intensity parameters include asset concurrent pull intensity, cache preheating concurrency coefficient, shader compilation overlap rate, and peak memory usage for texture upload. Obtain a preset load intensity parameter reference set, and normalize the load intensity parameters to obtain the normalized values ​​of each load intensity. Introduce a preset load intensity weighting factor set to weight and superimpose the normalized values ​​of each load intensity to obtain the burst load intensity value used to characterize the instantaneous impact capability of the rendering task on the shared channel and node resources during the preparation phase. The load intensity parameter comparison set includes asset concurrent fetch intensity comparison value, cache preheating concurrent coefficient comparison value, shader compilation overlap rate comparison value, and texture upload memory usage peak comparison value. The load intensity weighting factor set includes asset concurrent pull intensity weighting factor, cache preheating concurrency coefficient weighting factor, shader compilation overlap rate weighting factor, and texture upload memory usage peak weighting factor.

3. The cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in claim 1, characterized in that: The specific method for assessing the congestion risk of the shared storage and network channels on the cloud platform is as follows: Obtain the current shared channel operating status parameters of the cloud platform, including the shared storage bandwidth limit, shared network channel throughput, and current utilization rate; Obtain a preset set of shared channel operation status comparisons from the database, and after normalizing the shared channel operation status parameters, perform weighted summation to obtain the shared channel congestion risk value of the cloud platform. The shared channel operation status comparison set includes the shared storage bandwidth upper limit comparison value, the shared network channel throughput comparison value, and the current utilization rate comparison value; The shared channel congestion risk value is used to reflect the risk level when the same batch of rendering subtasks enter the preparation stage under existing resource conditions.

4. The cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in claim 1, characterized in that: The specific method for assessing the risk of computing power waiting and underutilization is as follows: Obtain the task status statistics parameters of the asset task group during the preparation phase and the computing power status statistics parameters of the cloud computing nodes; The task status statistics parameters include the queuing time during the preparation phase, the waiting time for asset retrieval, the waiting time for compilation, the waiting time for uploading, and the completion rate of the preparation phase. The computing power status statistics parameters include the number of rendering instances pre-occupied for the corresponding cloud computing node, the percentage of idle time in the GPU queue, and the number of tasks that have been allocated but not yet entered into rendering computation. Based on the correlation analysis of task status statistical parameters and computing power status statistical parameters, the computing power waiting and low utilization risk values ​​of asset task groups are obtained. The computing power wait and low utilization risk values ​​are used to characterize the risk of long GPU wait times, delayed rendering startup, and delayed tail tasks due to the limited capacity of the shared channel during the preparation phase.

5. The cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in claim 1, characterized in that: The specific method for the concurrent admission control is as follows: Establish a preparation phase access queue for each asset task group; Based on the concurrency limit and injection rate, the parallel subtasks entering the preparation phase are subject to admission judgment. Each parallel subtask that meets the admission conditions is allowed to enter the preparation phase to perform data preparation processing. Parallel subtasks that do not meet the admission criteria are guided into the waiting queue, and the admission criteria are re-executed in subsequent scheduling cycles until all data preparation and processing are completed.

6. The cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in claim 1, characterized in that: The specific method for node preheating and scheduling is as follows: For each parallel subtask that passes concurrent access control, it is scheduled to the anchor node set of the corresponding asset task group to perform the preparation phase processing; After the anchor node completes the data preparation and processing, record the preheating completion status, cache availability status, and reusable status of the corresponding asset fingerprint on that anchor node. Register the anchored nodes that have completed the preheating process as the warmed-up nodes of the corresponding asset task group, and update the set of warmed-up nodes.

7. The cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in claim 1, characterized in that: The specific method for performing affinity parallel scheduling on each parallel subtask is as follows: Based on the cache affinity weight set, each parallel subtask to be scheduled is preferentially scheduled to cloud computing nodes in the set of hot nodes, so that each parallel subtask in the same asset task group can be executed in parallel within the set of hot nodes, provided that the number of hot nodes meets its concurrent scheduling requirements. When the shared channel congestion risk value is lower than the preset shared channel congestion risk threshold, and the number of currently introduced collaborative nodes is less than the upper limit of the number of scalable collaborative nodes, collaborative nodes are introduced to synchronously execute 3D rendering tasks; otherwise, collaborative nodes are not introduced to synchronously execute 3D rendering tasks.

8. A platform applying the cloud-based collaborative 3D rendering task scheduling and resource allocation method as described in any one of claims 1-7, characterized in that, include: The module includes a rendering task allocation module, a multi-dimensional risk quantification assessment module, a node preheating module, and an affinity parallel scheduling module. The rendering task allocation module is used by the 3D rendering platform to perform task structure parsing on the 3D rendering job to be executed after receiving the rendering job trigger signal, splitting it into parallel sub-tasks, identifying asset associations for the parallel sub-tasks, forming asset task groups, and initially mapping them to the corresponding cloud computing node set. The multidimensional risk quantification assessment module is used to conduct a multidimensional quantitative assessment of resource impact for each asset task group in the preparation stage before entering the rendering calculation, and obtain a set of load risk description parameters to characterize the comprehensive impact of the asset task group on the stability of shared resources and computing power utilization. The node preheating module is used by the 3D rendering platform to generate a corresponding resource allocation control parameter set for each asset task group based on the load risk description parameter set, and to implement concurrent access control and node preheating scheduling for each asset task group in the preparation stage according to the resource allocation control parameter set, forming a set of preheated nodes. The affinity parallel scheduling module is used by the 3D rendering platform to perform affinity parallel scheduling processing on each parallel subtask based on the set of hot nodes, thereby completing the 3D rendering task.

Images