Flexible lamp strip virtual debugging method and system based on digital twinning

Abstract

The invention provides a flexible lamp strip virtual debugging method and system based on digital twinning, and belongs to the technical field of digital twinning. The method comprises the steps of dynamically adjusting the resource occupancy rate of a computing unit and generating rendering configuration by judging if the fluctuation amplitude of a predicted frame rate sequence exceeds a preset threshold value, balancing the large-scale array debugging computing power demand and the debugging resource occupancy of a single lamp strip, and avoiding the waste of computing resources; by monitoring the ratio of the viewport resolution rendering data volume to the preset frame buffer area capacity, the overflow risk of the buffer area is avoided; by determining a rendering task priority execution sequence, multi-task parallel conflicts are coordinated. Therefore, dynamic allocation of virtual resources, multi-task ordered scheduling and accurate parameter management are realized, the resource utilization rate is remarkably improved, rendering delay is reduced, the debugging period is shortened, and the consistency and delivery quality of flexible lamp strip products are guaranteed.

Description

Technical Field

[0001] This application relates to the field of digital twin technology, specifically to a virtual debugging method and system for flexible LED strips based on digital twins. Background Technology

[0002] Currently, flexible LED strips are increasingly widely used in smart lighting, displays, and decoration. Their production and debugging processes directly impact product consistency and final product quality. Digital twin technology, by constructing a virtual mirror, allows LED strips to undergo comprehensive debugging before physical manufacturing, becoming a key approach to improving efficiency and reducing costs. However, existing virtual debugging methods often struggle to adapt to the frequently changing debugging needs in actual production, leading to uneven resource utilization and prolonged debugging cycles. When simultaneously debugging multiple LED strips or large-scale arrays, insufficient computing power or rendering delays can easily occur. Conversely, when handling fine-tuning of individual LED strip parameters, there may be excessive resource consumption with low utilization. This mismatched resource allocation makes it difficult to conduct multiple debugging tasks in parallel, easily causing task interference or excessively long waiting times.

[0003] The information provided in the background section of this application is only for enhancing the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] In view of this, this application provides a virtual debugging method and system for flexible LED strips based on digital twins, which can realize the dynamic allocation of computing resources.

[0005] In a first aspect, embodiments of this application provide a virtual debugging method for flexible LED strips based on digital twins. The method includes: acquiring multiple debugging tasks for the flexible LED strip in a digital twin platform, and determining the resource occupancy rate of each computing unit based on the debugging tasks; acquiring the load of each stage of the rendering pipeline of the computing unit, and determining a rendering demand feature vector based on the resource occupancy rate of each computing unit and the load of each stage of the rendering pipeline; determining a predicted frame rate sequence based on the rendering demand feature vector, and determining whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold; if it exceeds the preset fluctuation amplitude threshold, adjusting the resource occupancy rate of each computing unit and generating a rendering configuration; acquiring the viewport resolution rendering data volume and texture resource binding status in the rendering configuration, and determining whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds a preset ratio threshold; if it exceeds the preset ratio threshold, determining a rendering task priority execution sequence based on the texture resource binding status, and adjusting the rendering configuration based on the rendering task priority execution sequence.

[0006] Secondly, embodiments of this application provide a virtual debugging system for flexible LED strips based on digital twins, the system comprising: a first acquisition module, a second acquisition module, a first determination module, a third acquisition module, and a second determination module. The system comprises the following modules: a first acquisition module, used to acquire multiple debugging tasks of the flexible light strip in the digital twin platform and determine the resource utilization rate of each computing unit based on the debugging tasks; a second acquisition module, used to acquire the load of each stage of the rendering pipeline of the computing unit and determine the rendering requirement feature vector based on the resource utilization rate of each computing unit and the load of each stage of the rendering pipeline; a first determination module, used to determine the predicted frame rate sequence based on the rendering requirement feature vector and determine whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold. If it is determined that it exceeds the preset fluctuation amplitude threshold, the resource utilization rate of each computing unit is adjusted, and a rendering configuration is generated; a third acquisition module, used to acquire the viewport resolution rendering data volume and texture resource binding status in the rendering configuration and determine whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds a preset ratio threshold; and a second determination module, used to determine the rendering task priority execution sequence based on the texture resource binding status if it is determined that it exceeds the preset ratio threshold, and adjust the rendering configuration based on the rendering task priority execution sequence.

[0007] This application provides a virtual debugging method and system for flexible LED strips based on digital twins. By determining whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold, the resource utilization of each computing unit is dynamically adjusted and a rendering configuration is generated. This solves the problems of drastic frame rate fluctuations and mismatch between computing resources and task requirements in existing virtual debugging. It avoids simulation stuttering or incomplete rendering caused by insufficient computing power during large-scale array joint debugging, and reduces excessive resource consumption when fine-tuning the parameters of a single LED strip. By determining whether the ratio of the viewport resolution rendering data volume to the preset frame buffer capacity exceeds a preset ratio threshold, the risk of buffer overflow is avoided in advance, ensuring the stability of the rendering process. When the ratio exceeds the preset ratio threshold, the rendering task priority execution sequence is determined based on the texture resource binding status, and the rendering configuration is adjusted. This achieves orderly scheduling of rendering tasks, coordinates conflicts in the parallel execution of multiple rendering tasks, and solves the problem of chaotic rendering parameter configuration recording, calling, and version management when multiple engineers are collaborating on debugging. It facilitates rapid switching between different debugging versions of the same flexible LED strip and reduces redundant adjustments. In this way, by dynamically allocating virtual resources, coordinating the parallel execution of multiple tasks, and accurately managing the configuration of rendering parameters, the utilization rate of computing resources is significantly improved, rendering latency is effectively reduced, the virtual debugging cycle of flexible light strips is shortened, and the product consistency and factory quality of flexible light strips during production and debugging are guaranteed. This solves the technical problems of mismatch between resource allocation and task requirements, difficulty in parallel execution of multiple tasks, and complexity of parameter version management in existing technologies. Attached Figure Description

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

[0009] Figure 1 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins provided in an exemplary embodiment of this application. Figure 2 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in another exemplary embodiment of this application. Figure 3 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in another exemplary embodiment of this application. Figure 4 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in yet another exemplary embodiment of this application. Figure 5 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in yet another exemplary embodiment of this application. Figure 6 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in yet another exemplary embodiment of this application. Figure 7 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in yet another exemplary embodiment of this application. Figure 8 This is a flowchart illustrating a virtual debugging method for flexible LED strips based on digital twins, provided in another exemplary embodiment of this application. Detailed Implementation

[0010] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this application will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this application.

[0011] The terms “a,” “one,” and “the” are used to indicate the existence of one or more elements / components / etc.; the terms “including” and “having” are used to indicate an open-ended inclusion and that other elements / components / etc. may exist in addition to those listed. The terms “first” and “second” are used only as markers and are not a limitation on the number of objects.

[0012] Currently, flexible LED strips are increasingly widely used in smart lighting, displays, and decoration. Their production and debugging processes directly impact product consistency and final product quality. Digital twin technology, by constructing a virtual mirror, allows LED strips to undergo comprehensive debugging before physical manufacturing, becoming a key approach to improving efficiency and reducing costs. However, existing virtual debugging methods often struggle to adapt to the frequently changing debugging needs in actual production, leading to uneven resource utilization and prolonged debugging cycles. When simultaneously debugging multiple LED strips or large-scale arrays, insufficient computing power or rendering delays can easily occur. Conversely, when handling fine-tuning of individual LED strip parameters, there may be excessive resource consumption with low utilization. This mismatched resource allocation makes it difficult to conduct multiple debugging tasks in parallel, easily causing task interference or excessively long waiting times.

[0013] For example, in actual debugging, the priorities and complexities of different tasks vary greatly. Joint debugging of large-scale arrays requires a large number of simulation computing units and real-time rendering support, while detailed debugging of a single light strip relies more on precise parameter iteration and rapid feedback. If virtual resources cannot be dynamically adjusted according to task characteristics, high-priority tasks will be delayed, or low-complexity tasks will consume too many computing units, thus affecting the overall debugging progress. Furthermore, when multiple engineers simultaneously carry out debugging work at different stages, the recording, calling, and version management of rendering parameter configurations can easily become chaotic. Different debugging versions of the same light strip are difficult to switch quickly, and repeated adjustments frequently occur.

[0014] For example, during the debugging of a flexible LED strip array composed of thousands of LEDs, it is necessary to simultaneously simulate the overall brightness distribution and local color gradations. If the computing resources of the computing unit are not increased in time, simulation stuttering or incomplete rendering will occur. Switching to another LED strip that only requires optimization of a single segment's flickering effect, the system still maintains high resource consumption, preventing other waiting joint debugging tasks from starting in a timely manner. This mismatch between resource allocation and task requirements further increases the difficulty of multi-task parallel execution and data version management.

[0015] Therefore, how to dynamically allocate virtual resources based on the priority and complexity of debugging tasks on a digital twin platform, and how to coordinate the parallel execution of multiple tasks and accurately manage the optimized rendering parameter configuration, have become the technical problems that need to be solved in the research of flexible LED strip virtual debugging methods and systems based on digital twins.

[0016] This application provides a virtual debugging method for flexible LED strips based on digital twins, such as... Figure 1 The illustrated method is a virtual debugging method for flexible LED strips based on digital twins. This method may include the following steps: Step S110: Obtain multiple debugging tasks for the flexible light strip in the digital twin platform, and determine the resource utilization rate of each computing unit based on the debugging tasks; Step S120: Obtain the load of each stage of the rendering pipeline of the computing unit, and determine the rendering requirement feature vector based on the resource utilization of each computing unit and the load of each stage of the rendering pipeline. Step S130: Determine the predicted frame rate sequence based on the rendering requirement feature vector, and determine whether the fluctuation range of the predicted frame rate sequence exceeds the preset fluctuation range threshold. If it is determined that it exceeds the preset fluctuation range threshold, adjust the resource utilization rate of each computing unit and generate the rendering configuration. Step S140: Obtain the viewport resolution rendering data volume and texture resource binding status in the rendering configuration, and determine whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds the preset ratio threshold. Step S150: If it is determined that the preset ratio threshold is exceeded, the rendering task priority execution sequence is determined according to the texture resource binding status, and the rendering configuration is adjusted according to the rendering task priority execution sequence.

[0017] According to the virtual debugging method for flexible LED strips based on digital twins provided in this application, this method can dynamically adjust the resource utilization of each computing unit and generate rendering configuration by judging whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold. This solves the problems of drastic frame rate fluctuations and mismatch between computing resources and task requirements in existing virtual debugging. It avoids simulation stuttering or incomplete rendering caused by insufficient computing power during large-scale array joint debugging, and reduces excessive resource consumption when fine-tuning the parameters of a single LED strip. By judging whether the ratio of the rendering data volume of the viewport resolution to the preset frame buffer capacity exceeds a preset ratio threshold, the risk of buffer overflow is avoided in advance, ensuring the stability of the rendering process. When the ratio exceeds the preset ratio threshold, the priority execution sequence of rendering tasks is determined according to the texture resource binding status and the rendering configuration is adjusted, realizing the orderly scheduling of rendering tasks and coordinating the conflict of parallel execution of multiple rendering tasks. At the same time, through standardized rendering configuration management, the problem of chaotic recording, calling and version management of rendering parameter configurations when multiple engineers are debugging together is solved, which facilitates the rapid switching of different debugging versions of the same flexible LED strip and reduces the situation of repeated adjustments. In this way, by dynamically allocating virtual resources, coordinating the parallel execution of multiple tasks, and accurately managing the configuration of rendering parameters, the utilization rate of computing resources is significantly improved, rendering latency is effectively reduced, the virtual debugging cycle of flexible light strips is shortened, and the product consistency and factory quality of flexible light strips during production and debugging are guaranteed. This solves the technical problems of mismatch between resource allocation and task requirements, difficulty in parallel execution of multiple tasks, and complexity of parameter version management in existing technologies.

[0018] The following is a detailed description of each step of the virtual debugging method for flexible LED strips based on digital twins provided in the embodiments of this application: In one embodiment of this application, step S110 involves acquiring multiple debugging tasks for the flexible LED strip in the digital twin platform. Specifically, the digital twin platform currently collects three types of virtual debugging tasks for the flexible LED strip from the task management module. These include a large-scale array debugging task manually submitted by an engineer for a smart lighting project (Task ID: T001), a single LED strip fine parameter adjustment task submitted for a decorative display project (Task ID: T002), and a consistency verification task automatically generated by the platform based on batch production requirements (Task ID: T003). Task T001 targets a flexible LED strip of model F-2024, with 10,000 LEDs / 10 meters, and aims to achieve uniform overall brightness distribution and local red-to-blue color gradient. Task T002 targets a flexible LED strip of model F-Mini, with 500 LEDs / 1 meter, and aims to optimize the adjustable flicker effect from 1Hz to 5Hz and reduce power consumption. Task T003 involves debugging 100 flexible LED strips of model F-2024. The debugging objective is to verify the consistency of factory parameters (brightness deviation ≤ ±5%).

[0019] In one embodiment of this application, step S110, determining the resource utilization rate of each computing unit based on the debugging task, further includes the following steps: Figure 2 As shown, the specific content is as follows: Step S210: Obtain the evaluation metrics for each debugging task. The evaluation metrics include urgency, value, number of instructions, data volume, and rendering accuracy. Step S220: Determine the priority score of each debugging task based on urgency and value, and determine the complexity score of each debugging task based on the number of instructions, the amount of data, and the rendering accuracy. Step S230: Determine the load score for each debugging task based on the priority score and complexity score; Step S240: Sort the load scores in order from the maximum to the minimum, and based on the sorting results, use a linear programming algorithm to determine the resource utilization rate of the computing unit.

[0020] Specifically, by quantifying multi-dimensional evaluation indicators of tasks, comprehensively calculating the load requirements of tasks, and then using linear programming algorithms to achieve optimal allocation of computing unit resources, we can ensure that resource utilization is accurately matched with task priority and complexity, and avoid resource waste or insufficiency caused by subjective allocation. Among them, urgency refers to the urgency of completing the debugging task, with a value range of 1-10 (1 point = minimum urgency, 10 points = maximum urgency, such as "must be completed 2 hours before mass production" with a value of 10); value refers to the business value of the debugging task (such as whether it affects mass production or customer acceptance), with a value range of 1-5 (1 point = minimum value, 5 points = maximum value, such as "customer customized effect debugging" with a value of 5); number of instructions refers to the total number of calculation steps that the debugging task needs to execute, in "ten thousand" (reflecting the computational intensity of the task); data volume refers to the total amount of model data and simulation data that needs to be processed during the task debugging process, in "GB" (reflecting the storage and transmission pressure of the debugging task); rendering accuracy refers to the level of detail of the simulation of the debugging task, divided into three levels: high, medium, and low, corresponding to quantitative values ​​of 3, 2, and 1 (high = requires simulation of LED heat dissipation / color gradient details, medium = requires simulation of overall effect, low = only basic function verification is required).

[0021] The priority score is calculated as follows: Priority score = Urgency × 0.6 + Value score × 0.4; Complexity score = (Number of instructions / 100) × 0.5 + Data volume × 0.3 + Rendering accuracy × 0.2; Load score = Priority score × 0.4 + Complexity score × 0.6. All debugging tasks are sorted according to their load scores from highest to lowest to determine the priority order of resource allocation. Then, a linear programming algorithm is used to determine the resource utilization rate of the computing units.

[0022] For example, the digital twin platform has three flexible LED strip debugging tasks, with a total of 1000 computing units. Evaluation metrics for each debugging task are obtained. Task T001 has an urgency score of 10 (must be completed in 2 hours), a value score of 5 (critical for customer acceptance), 3 million instructions, 8GB of data, and a rendering accuracy score of 3 (high, requiring simulated heat dissipation and color gradient). Task T002 has an urgency score of 8 (must be completed in 4 hours), a value score of 3 (mass production support), 1.5 million instructions, and 3GB of data. GB, rendering accuracy is 2 points (medium, only overall effect simulation required), task T003 has an urgency of 6 points (must be completed in 8 hours), a value of 2 points (routine testing), 500,000 instructions, 1GB of data, and a rendering accuracy of 1 point (low, only verifying the blinking function); according to the above formula, the priority score and complexity score are calculated as follows: task T001 has a priority score of 10×0.6+5×0.4=8.0 points and a complexity score of (300 / 100)×0.5+8×0.3+3×0.2=4.5 points. Task T002 has a priority score of 8×0.6+3×0.4=6.0 points and a complexity score of (150 / 100)×0.5+3×0.3+2×0.2=2.05 points. Task T003 has a priority score of 6×0.6+2×0.4=4.4 points and a complexity score of (50 / 100)×0.5+1×0.3+1×0.2=0.75 points. Task T001 has a load score of 8.0×0.4+4.5×0.6=5.9 points, Task T002 has a load score of 6.0×0.4+2.05×0.6=3.63 points, and Task T003 has a load score of 4.4×0.4+0.75×0.6=2.21 points. The load scores are sorted from largest to smallest as T001→T002→T003. Then, a linear programming algorithm is used, with the objective of minimizing the total latency of all tasks and the constraint that the total number of computing units does not exceed 1000. It is found that task T001 is allocated 500 computing units, task T002 is allocated 350 computing units, and task T003 is allocated 150 computing units. Finally, the computing unit resource utilization rate of task T001 is calculated to be (500 / 1000)×100%=50%, task T002 is 35%, and task T003 is 15%.

[0023] It should be noted that the computing unit described in this application may be a GPU (Graphics Processing Unit) unit in a digital twin platform, used to process highly parallel tasks, such as rendering visual effects during the debugging of flexible light strips, manipulating video data during content creation, and calculating results in intensive AI workloads.

[0024] In the above method, by transforming the dispersed indicators such as urgency, value, and number of instructions of debugging tasks into quantifiable priority scores, complexity scores, and load scores, the imbalance caused by relying on subjective experience in resource allocation is avoided, ensuring the uniformity and objectivity of the evaluation criteria. Secondly, by reasonably setting the weight of each indicator, the load score can accurately reflect the actual demand of tasks for computing resources, ensuring the priority of high-urgency and high-value tasks while fully considering the decisive impact of task complexity on resource consumption. Furthermore, by using a linear programming algorithm for computing resource allocation, the global optimal goal of minimizing total latency is achieved under the constraint of limited total computing unit resources, effectively solving the contradiction of insufficient computing resources for large-scale array debugging and excessive resource occupation for single light strip debugging in existing technologies.

[0025] In one embodiment of this application, step S120, which involves obtaining the load of each stage of the rendering pipeline of the computing unit and determining the rendering requirement feature vector based on the resource utilization of each computing unit and the load of each stage of the rendering pipeline, further includes the following steps: Figure 3 As shown, the specific content is as follows: Step S310: Standardize the resource utilization of each computing unit and the load of each stage of the rendering pipeline to generate standardized resource utilization and standardized rendering pipeline load. Step S320: Based on the standardized resource utilization rate and the standardized rendering pipeline load, a convolutional neural network is used to determine the feature vector of rendering requirements.

[0026] Specifically, the rendering pipeline is used in the flexible LED strip virtual debugging process to convert 3D models into visualized images, and the load of each stage directly reflects the computing power consumption of the computing unit. The stages of the rendering pipeline can include the vertex shader stage, geometry shader stage, rasterization stage, pixel shader stage, and post-processing stage. The process involves several stages: the vertex shader stage processes vertex data (such as coordinates, normals, and texture coordinates) of the 3D model of the light strip, with a workload directly proportional to the model's mesh density (the denser the mesh, the more vertices, and the higher the workload); the geometry shader stage performs geometric transformations on the vertex data (such as simulating the bending and stretching of the flexible light strip), and is only collected when debugging tasks require simulating light strip deformation; the rasterization stage converts the processed vertex data into pixel fragments, with a workload directly proportional to the viewport resolution (the higher the resolution, the more pixels, and the higher the workload); the pixel shader stage calculates the color and brightness of each pixel (such as simulating color gradients and brightness uniformity of the light strip), with a workload directly proportional to the computational complexity of lighting and the texture sampling frequency; and the post-processing stage optimizes the rendered image (such as anti-aliasing, Bloom effects, and color correction), with a workload directly proportional to the number of post-processing effect layers (the more layers, the higher the workload). The workload of each stage of the rendering pipeline in the computing unit can be obtained in real time by using the GPU performance monitoring module integrated into the digital twin platform (such as based on NVIDIA NVML or AMD ADL interfaces). Next, by using CNN to deeply mine the correlation features between resource utilization and rendering pipeline load in the standardized data, the high-dimensional and scattered data is transformed into a low-dimensional and structured rendering requirement feature vector. This vector can reflect the core rendering requirements of the flexible light strip virtual debugging (such as 3D model mesh density and number of lighting calculation iterations).

[0027] For example, the digital twin platform has three computing units, each corresponding to one of the three debugging tasks for the flexible LED strip (Computing unit 1 corresponds to T001 large-scale array joint debugging, computing unit 2 corresponds to T002 fine parameter adjustment of a single LED strip, and computing unit 3 corresponds to T003 batch LED strip consistency verification). The rendering pipeline includes the vertex shader stage, pixel shader stage, and rasterization stage. The resource utilization of each computing unit and the load of each stage of the rendering pipeline are standardized, mapping both types of data to the 0.0-1.0 range. The original resource utilization of computing unit 1 is 50%, the vertex shader stage load is 0.72, the pixel shader stage load is 0.85, and the rasterization stage load is 0.61. The initial resource utilization of computing unit 2 is 35%, with a vertex shader stage load of 0.55, a pixel shader stage load of 0.48, and a rasterization stage load of 0.40. The initial resource utilization of computing unit 3 is 15%, with a vertex shader stage load of 0.30, a pixel shader stage load of 0.25, and a rasterization stage load of 0.20. Standardized values ​​are calculated for each index category, resulting in a standardized resource utilization of 1.0, a standardized vertex shader stage load of 1.0, a standardized pixel shader stage load of 1.0, and a standardized rasterization stage load of 1.0 for computing unit 1. The standardized resource utilization of computing unit 2 is 0.571, the standardized vertex shader stage load is 0.595, the standardized pixel shader stage load is 0.383, and the standardized rasterization stage load is 0.488 for computing unit 3. The standardized resource utilization of computing unit 3 is 0.0, the standardized vertex shader stage load is 0.0, the standardized pixel shader stage load is 0.0, and the standardized rasterization stage load is 0.0. Based on this standardized data, a 3×4×128 multi-channel input tensor (3 computational units × 4 standardized indices × 128 time sampling points) is constructed and normalized to the range of 0.0-1.0. This tensor is then input into the constructed convolutional neural network. The first layer uses 32 3×3 convolutional kernels to capture local load patterns. The second layer uses 64 5×5 convolutional kernels combined with 2×2 max pooling to reduce dimensionality and retain key features. The third layer uses 128 3×3 convolutional kernels to abstract spatiotemporal correlations. Global average pooling compresses the feature map into a 512-dimensional vector, which is then processed through two more layers... The fully connected layers (256 units in the first layer, Dropout rate 0.5, and 128 units in the second layer) process the data and finally output a 64-dimensional rendering requirement feature vector. The first 32 dimensions encode the 3D model mesh density requirement, with an average value of 0.8012, indicating that the large-scale array debugging task corresponding to computing unit 1 requires a high mesh density. The last 32 dimensions encode the lighting calculation iteration number requirement, with an average value of 0.6987, indicating that the debugging task requires 10-14 lighting calculation iterations. The rendering feature vector can predict the rendering requirement with an accuracy of over 94.5%.

[0028] In one embodiment of this application, step S130, determining the predicted frame rate sequence based on the rendering requirement feature vector, further includes the following steps: Figure 4 As shown, the specific content is as follows: Step S410: Obtain the mapping relationship record between the historical rendering requirement feature vector and the historical rendering delay value; Step S420: Using the nearest neighbor matching algorithm, calculate the cosine similarity between the current rendering requirement feature vector and the mapping relationship record, and use the mapping relationship record corresponding to the maximum value of the cosine similarity as the historical rendering delay value corresponding to the current rendering requirement feature vector; Step S430: Determine the predicted rendering latency value based on the historical rendering latency value and the current rendering requirement feature vector; Step S440: Based on the predicted rendering latency, a linear regression algorithm is used to determine the predicted frame rate sequence.

[0029] Specifically, frame rate and rendering latency are inversely proportional (frame rate = 1000ms / rendering latency), while rendering latency is directly related to the rendering demand feature vector (the rendering demand feature vector encodes load requirements such as mesh density and lighting iteration; higher load results in higher latency). A mapping relationship between the rendering demand feature vector and rendering latency values ​​is constructed using historical data, providing historical experience for current predictions. Next, a nearest neighbor matching algorithm is used to find the historical record most similar to the current rendering demand feature vector, thereby obtaining a reference historical rendering latency value and avoiding unfounded blind predictions. Historical latency values ​​are based on past task scenarios; subtle differences exist between the current task and historical tasks (such as different local dimensional values ​​of the feature vector), requiring adjustments to obtain a more accurate current rendering latency prediction. The predicted frame rate sequence is a continuous frame rate value over a future period (not a single frame rate), requiring a linear regression algorithm to fit the frame rate change trend to ensure the continuity and stability of the predicted frame rate sequence.

[0030] For example, retrieving 1000 valid historical rendering request feature vector and historical rendering latency value mapping records from the debug log database of the digital twin platform can include historical record H001: historical rendering request feature vector is [0.82,0.79,0.86,0.75,0.81,...,0.71,0.69,0.73,0.67,0.65], historical rendering latency value is 75.2ms. Historical record H002: historical rendering request feature vector is [0.52,0.50,0.55,0.48,0.53,...,0.41,0.39,0.43,0.37,0.35], historical rendering latency value corresponding to the current historical record is 42.8ms. Historical record H003: The historical rendering demand feature vector is [0.30, 0.28, 0.32, 0.25, 0.29, ..., 0.21, 0.19, 0.23, 0.17, 0.15], with a corresponding historical rendering latency of 28.5ms. The nearest neighbor matching algorithm is used to calculate the cosine similarity between the current rendering demand feature vector (corresponding to calculation unit 1) and the historical record. The similarity is 0.98 with H001, 0.62 with H002, and 0.35 with H003. The maximum value of 0.98 is higher than the preset similarity threshold of 0.85, corresponding to a historical rendering latency of 75.2ms. The current rendering requirement feature vector magnitude is 8.2, and the H001 vector magnitude is 8.3. The difference coefficient is |8.2-8.3| / 8.3≈0.012. Using the formula Rendering Delay Prediction = Historical Rendering Delay × (1 + Difference Coefficient), we get 75.2ms × 1.012≈76.1ms. The preset base frame rate is about 13.14 FPS. Then, based on the frame rate change trend of the historical H001 task, we train a linear regression model y = -0.01x + 13.25 (x is the frame number, y is the frame rate). Substituting the future 10 frame numbers into the linear regression model and smoothing it, we get the predicted frame rate sequence [13.23, 13.24, 13.22, 13.21, 13.20, 13.19, 13.18, 13.17, 13.16, 13.15].

[0031] In one embodiment of this application, step S130 involves determining whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold. If it is determined that the fluctuation amplitude exceeds the preset fluctuation amplitude threshold, the resource utilization rate of each computing unit is adjusted, and a rendering configuration is generated. The step also includes the following steps: Figure 5 As shown, the specific content is as follows: Step S510: Obtain the adjustment coefficient and determine the adjustment ratio of each current calculation unit based on the adjustment coefficient; Step S520: Determine the task weight coefficient of each debugging task based on the load score of each debugging task; Step S530: Adjust the resource utilization rate of each computing unit according to the adjustment ratio and task weight coefficient; Step S540: Generate rendering configuration based on the adjusted resource utilization of each computing unit.

[0032] Specifically, the ratio of the difference between the maximum and minimum values ​​in the predicted frame rate sequence to the average value can be used as a quantifiable measure of the frame rate instability, i.e., the fluctuation range of the predicted frame rate sequence. For example, if the predicted frame rate sequence of calculation unit 2 is [28.5, 22.3, ..., 22.8], and the fluctuation range of 31.2% exceeds the preset fluctuation range threshold of 15%, then resource utilization adjustment will be triggered.

[0033] For example, the digital twin platform has three computing units corresponding to three debugging tasks for flexible LED strips: computing unit 1 corresponds to T001 large-scale array joint debugging, computing unit 2 corresponds to T002 fine parameter adjustment of a single LED strip, and computing unit 3 corresponds to T003 batch LED strip consistency verification. First, the adjustment coefficient is set to 0.5, and the current load percentage of each computing unit is: computing unit 1 is 60%, computing unit 2 is 30%, and computing unit 3 is 10%, with an average load percentage of 33.33%. The adjustment ratio of a computing unit is calculated as: Adjustment coefficient × (Current load percentage of the computing unit / Average load percentage of all computing units). Therefore, the adjustment ratio for computing unit 1 is 0.5 × (60% / 33.33%) = 0.9, for computing unit 2 it is 0.45, and for computing unit 3 it is 0.15. Based on the load scores of each task (T001 is 5.9, T002 is 3.63, and T003 is 2.21) and the total load score of 11.74, the task weight coefficient is determined as: Single task load score / Sum of all task load scores. The task weight coefficients are then calculated as: T001 0.503, T002 0.310, and T003 0.188. The resource utilization rate of each computing unit is adjusted according to the formula: Resource utilization rate before adjustment × (1 + Computing unit adjustment ratio × Task weight coefficient). The initial resource utilization rates were 50%, 35%, and 15% before adjustment. The calculated post-adjustment rates were 65.09%, 39.88%, and 15.42%. Since the total exceeded 100%, a reduction factor of 0.831 was applied, resulting in final values ​​of 54.10%, 33.14%, and 12.82%. Based on these adjusted resource utilization rates, a standardized rendering configuration was generated, determining the resource allocation for each computing unit. An additional 2GB of video memory was allocated proportionally: 11.08GB for computing unit, 20.66GB for computing unit, and 30.26GB for computing unit. The number of parallel threads was configured to be 4, 3, and 2 respectively, and the number of post-processing layers to be 3, 2, and 1 respectively. This data was compiled into a JSON-formatted rendering configuration file, including the configuration version, effective date, and adjustment criteria (frame rate fluctuation range, adjustment factor, etc.), and written to the digital twin platform.

[0034] In the above method, the task weight coefficient is calculated based on the load score of the debugging task, so that the resource adjustment is tilted towards high-priority and high-complexity tasks. This solves the contradiction between resource allocation and task requirements in the existing technology and ensures the frame rate stability of key tasks such as large-scale array joint debugging. Furthermore, by adjusting the resource utilization rate of each computing unit, the resource allocation of each computing unit is ensured to be balanced, avoiding new bottlenecks caused by excessive resource consumption by a single unit, and improving the utilization rate of computing resources and the overall efficiency of flexible light strip virtual debugging.

[0035] In one embodiment of this application, step S140 involves obtaining the viewport resolution rendering data volume and texture resource binding status from the rendering configuration, and determining whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds a preset ratio threshold. Specifically, the viewport resolution rendering data volume refers to the total amount of data that needs to be processed for a single frame rendering under the viewport resolution of the current rendering configuration, measured in bytes (B) or gigabytes (GB), directly determined by the viewport resolution and pixel format. The viewport resolution (e.g., 1920x1080, 1280x720) can be parsed from the rendering configuration file, combined with a preset pixel format (e.g., RGBA8888, each pixel occupies 4 bytes). The texture resource binding status refers to the key information of the texture resources bound to the current rendering task, including the total number of bound texture units, the load level of each texture unit (high / medium / low), texture resolution, and memory bandwidth usage (e.g., 2.5GB / s). This information can be extracted by parsing the texture binding field in the rendering configuration and combining it with GPU real-time monitoring data to help determine the buffer pressure (the higher the texture resource load, the greater the read / write pressure on the buffer). The preset frame buffer capacity is the maximum storage capacity of the frame buffer allocated by the digital twin platform for rendering tasks. It is measured in GB and can be preset according to the GPU hardware performance and the type of debugging task (e.g., 4GB for large-scale array debugging and 2GB for single light strip debugging) to ensure that it can accommodate the maximum amount of data for a single frame rendering.

[0036] For example, compute unit 1 has a viewport resolution of 1920x1080, a pixel format of RGBA8888 (4 bytes per pixel), is bound to 8 texture units (4 high-load, occupying 2.5GB / s bandwidth), and a total texture size of 1.2GB. The preset frame buffer capacity is 4GB, and the preset ratio threshold is 80%. The pixel data size of compute unit 1 per frame = 1920 × 1080 × 4 bytes = 0.0077GB. After adding the texture data, the total data size is 1.2077GB. Therefore, the ratio between the viewport resolution rendering data size and the preset frame buffer capacity = 1.2077GB / 4GB × 100% = 30.19% < 80%, so there is no risk of buffer overflow, and the current configuration is maintained.

[0037] In one embodiment of this application, step S150, if it is determined that the preset ratio threshold is exceeded, then the rendering task priority execution sequence is determined according to the texture resource binding state, and further includes the following steps, such as... Figure 6 As shown, the specific content is as follows: Step S610: Determine the texture dependency strength and texture load level of each rendering task based on the texture resource binding status; Step S620: Obtain the weights corresponding to the texture dependency strength and the texture load level, respectively; Step S630: Based on the weight corresponding to the texture dependency strength and the weight corresponding to the texture load level, perform a weighted calculation on the texture dependency strength and the texture load level, and use the result of the weighted calculation as the execution priority score of each rendering task; Step S640: Sort the execution priority scores of each rendering task in order from the maximum value to the minimum value, and use the sorting result as the execution sequence of the rendering task priority.

[0038] Specifically, based on the binding relationship between rendering tasks and texture resource states, it can be categorized into three levels: strong dependency, medium dependency, and weak dependency. Strong dependency means that the specified texture resource must be loaded to start rendering. For example, the color gradient effect of a flexible light strip depends on texture sampling; without the texture, the rendering effect is completely lost. Medium dependency means that core rendering steps rely on textures, while non-core steps can be without them. For example, overall brightness simulation relies on textures, while local detail adjustments can temporarily lack textures. Weak dependency means that textures are only used to optimize rendering effects; the absence of textures does not affect task startup or core function verification. For example, secondary decorative textures only enhance visual effects. Based on the resource consumption of bound textures, texture load levels are categorized into three levels: high load, medium load, and low load. High load is defined as: ≥6 bound texture units, or containing 4K or higher high-resolution textures, or consuming ≥2GB / s of memory bandwidth; medium load is defined as: 3-5 bound texture units, or a texture resolution of 2K, or consuming 1-2GB / s of memory bandwidth; low load is defined as: ≤2 bound texture units, or a texture resolution ≤1080P, or consuming <1GB / s of memory bandwidth.

[0039] For example, if there is a risk of buffer overflow due to the ratio of the viewport resolution rendering data volume to the preset frame buffer capacity exceeding a preset threshold, the texture dependency strength and texture load level are determined based on the texture resource binding status of each rendering task. Rendering task T001 binds 8 texture units, including 2 4K textures, and occupies 2.5GB / s of memory bandwidth. Its color gradient effect requires texture sampling, and it is judged as having strong dependency and high load. Rendering task T002 binds 4 texture units, with a texture resolution of 2K, and occupies 1.5GB / s of memory bandwidth. The core brightness simulation stage relies on texture resources, while non-core stages can temporarily lack textures, and it is judged as having medium dependency and medium load. Rendering task T003 binds 2 texture units, with a texture resolution of 1080P, and occupies 0.8GB / s of memory bandwidth. The texture is only used to optimize visual effects, and the absence of textures does not affect core function verification, and it is judged as having weak dependency and low load. In texture dependency strength calculations, strong dependency corresponds to a weight of 0.4, medium dependency to 0.3, and weak dependency to 0.2. Similarly, in texture load level calculations, high load corresponds to a weight of 0.6, medium load to 0.4, and low load to 0.2. Weighting these data, the execution priority score for rendering task T001 is 0.4×100+0.6×100=100 points, for T002 it's 0.3×100+0.4×100=70 points, and for T003 it's 0.2×100+0.2×100=40 points. Sort the execution priority scores of each rendering task from maximum to minimum to obtain the sorted result T001→T002→T003. This sorted result is the final rendering task priority execution sequence, ensuring that high-dependency, high-load rendering tasks receive texture resources and computing units first, thus avoiding the risk of buffer overflow.

[0040] In the above method, the priority score is obtained by quantifying the degree of dependence of the rendering task on texture resources and the load pressure of the texture itself, and then the execution sequence is generated according to the score. This ensures that the rendering tasks with high dependence and high load get priority to obtain texture resources and computing units, avoids the risk of buffer overflow caused by resource competition, and improves the overall debugging efficiency. It is suitable for multi-task parallel scenarios of virtual debugging of digital twin flexible light strips.

[0041] In one embodiment of this application, step S150, adjusting the rendering configuration according to the rendering task priority execution sequence, further includes the following steps: Figure 7 As shown, the specific content is as follows: Step S710: Based on the execution sequence of rendering tasks by priority, use the K-means clustering algorithm to determine the execution groups of rendering tasks at different resource allocation levels; Step S720: Optimize the resource utilization of each computing unit according to the rendering task grouping; Step S730: Adjust the rendering configuration according to the optimized resource utilization of each computing unit.

[0042] Specifically, for example, the rendering priority execution sequence is: T001 (100 points) → T004 (85 points) → T002 (70 points) → T003 (40 points), and there is a risk of buffer overflow. Based on the rendering task priority execution sequence, the rendering task execution priority score, texture load level quantization value (high=3, medium=2, low=1), and viewport resolution rendering data volume (unit: GB) are selected as clustering features. K=3 is set (corresponding to high, medium, and low resource allocation levels). After 50 iterations, the cluster centers are stable, and finally, a high resource allocation group (T001, T004, total texture load 6, total data volume 2.2609GB), a medium resource allocation group (T002, texture load 2, data volume 0.8034GB), and a low resource allocation group (T003, texture load 1, data volume 0.3029GB) are formed. Next, resource allocation weights are set for the groups: 0.5 for the high resource allocation group, 0.3 for the medium resource allocation group, and 0.2 for the low resource allocation group. The resource utilization rate of the current resource allocation group is calculated using the formula: (Total resource demand of this group / Total resource demand of all groups) × Group resource allocation weight × 100%. Considering the constraints of a single group's utilization rate cap of ≤70% and a total utilization rate of 100%, the optimized resource utilization rates are: 60% for the high resource allocation group, 33.14% for the medium resource allocation group, and 6.86% for the low resource allocation group. The rendering configuration was adjusted based on the optimized resource utilization rate, and a total of 8GB of video memory was allocated proportionally (4.8GB for high-end groups, 2.65GB for mid-end groups, and 0.55GB for low-end groups). The number of parallel threads was configured (6 threads for high-end groups, 4 threads for mid-end groups, and 2 threads for low-end groups) and the number of post-processing layers were configured (3 layers for high-end groups, 2 layers for mid-end groups, and 1 layer for low-end groups). The configuration was organized into a standardized rendering configuration file in JSON format, which includes group identifiers, resource allocation details, and an adaptation task list. This was written to the digital twin platform, which can avoid the risk of buffer overflow and improve resource utilization.

[0043] In one embodiment of this application, after adjusting the rendering configuration in step S150, the following steps are also included: Figure 8 As shown, the specific content is as follows: Step S810: Based on the rendering task priority, execute the sequence to load the virtual debug task configuration in the digital twin platform to generate debug task runtime data; Step S820: Determine performance index data based on the debugging task execution data; Step S830: Based on the performance index data, use the random forest algorithm to determine the performance index data groupings for different performance levels. The performance index data groupings include high-efficiency performance index data groupings, qualified performance index data groupings, and inefficient performance index data groupings. Step S840: Based on the inefficient performance index data grouping, use a genetic algorithm to optimize the resource utilization rate of each computing unit.

[0044] Specifically, the standardized rendering configuration adjusted in step S730 (including computing unit resource utilization, memory allocation, thread configuration, etc.) can be loaded from the configuration management module of the digital twin platform, and the corresponding virtual debugging tasks can be started according to the rendering task priority execution sequence. Next, the platform's integrated performance monitoring tool collects runtime data for each task at a sampling frequency of 128 times / second, including task execution time, real-time GPU computing unit utilization, memory usage, rendering latency, frame rate changes, and texture resource loading time. Key performance indicators are extracted from the debugging task runtime data to quantify the performance of the virtual debugging tasks. Performance indicators can include computing unit resource utilization, average rendering latency, frame rate stability, and task completion efficiency. Machine learning algorithms are used to automatically classify the performance indicator data, accurately identifying the indicator data corresponding to inefficiently running tasks. For example, the performance indicator dataset can be input into a trained random forest model, and the model automatically matches performance level labels based on indicator values, outputting three groups of performance indicator data: efficient, acceptable, and inefficient, with each group associated with a corresponding virtual debugging task. For debugging tasks involving inefficient performance metrics data grouping and association, a genetic algorithm is used to precisely adjust the resource utilization rate of the corresponding computing units, solving the inefficiency problem caused by insufficient or redundant resource allocation and improving overall performance.

[0045] For example, the rendering task priority execution sequence is T001→T004→T002→T003. Based on this priority execution sequence, the adjusted standardized rendering configuration is loaded, and each virtual debug task is started. The platform's integrated performance monitoring tool collects running data at a sampling frequency of 128 times / second, including task execution time, real-time GPU computing unit utilization, video memory usage, single-frame rendering latency, and frame rate. After smoothing using a moving average method (window size 3) and removing outliers, a structured debug task running dataset is generated. Four core performance indicators—computing unit resource utilization, average rendering latency, frame rate fluctuation, and task completion efficiency—are extracted from the running data and their values ​​are calculated. The results show that T001 has a resource utilization of 96.67%, an average rendering latency of 42ms, a frame rate fluctuation of 7.5%, and a task completion efficiency of 92%; T004 has a resource utilization of 92.00%, an average rendering latency of 38ms, a frame rate fluctuation of 6.8%, and a task completion efficiency of 88%. T002 has a resource utilization rate of 90.00%, an average rendering latency of 55ms, a frame rate fluctuation of 16.3%, and a task completion efficiency of 68%. T003 has a resource utilization rate of 80.00%, an average rendering latency of 62ms, a frame rate fluctuation of 18.5%, and a task completion efficiency of 65%. These performance metrics are input into a constructed random forest classification model (100 decision trees, maximum tree depth 8). The model is automatically classified according to preset performance thresholds. T001 and T004 are grouped into the high-performance metric data group, while T002 and T003 are grouped into the low-performance metric data group due to their substandard frame rate fluctuation and task completion efficiency. With the dual objectives of maximizing computing unit resource utilization and minimizing average rendering latency, a fitness function is constructed, and a genetic algorithm is used to optimize the resource occupancy rate of the inefficient group. 20 schemes are initialized, and after 50 iterations of roulette wheel selection, crossover operation with a crossover probability of 0.8, and mutation operation with a mutation probability of 0.1, the optimal scheme is obtained, and the computing unit resource occupancy rate of T002 is adjusted to 14% and that of T003 is adjusted to 7%.

[0046] In the above method, the resource utilization, operating efficiency, and stability of virtual debugging tasks are quantified by extracting multi-dimensional performance indicators; the random forest algorithm is used to automatically classify performance indicators, accurately identify inefficient tasks, and avoid subjective bias in manual classification; for inefficient groups, a genetic algorithm is used to optimize the resource occupancy rate of computing units, and the optimal resource allocation scheme is found through multi-objective fitness functions and iterative evolution, which effectively improves the resource utilization and operating efficiency of inefficient tasks, and further enhances the overall reliability and resource utilization efficiency of flexible light strip virtual debugging in the digital twin platform.

[0047] This application also provides a virtual debugging system for flexible LED strips based on digital twins. The system may include a first acquisition module, a second acquisition module, a first determination module, a third acquisition module, and a second determination module. The system comprises the following modules: a first acquisition module, used to acquire multiple debugging tasks of the flexible light strip in the digital twin platform and determine the resource utilization rate of each computing unit based on the debugging tasks; a second acquisition module, used to acquire the load of each stage of the rendering pipeline of the computing unit and determine the rendering requirement feature vector based on the resource utilization rate of each computing unit and the load of each stage of the rendering pipeline; a first determination module, used to determine the predicted frame rate sequence based on the rendering requirement feature vector and determine whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold. If it is determined that it exceeds the preset fluctuation amplitude threshold, the resource utilization rate of each computing unit is adjusted, and a rendering configuration is generated; a third acquisition module, used to acquire the viewport resolution rendering data volume and texture resource binding status in the rendering configuration and determine whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds a preset ratio threshold; and a second determination module, used to determine the rendering task priority execution sequence based on the texture resource binding status if it is determined that it exceeds the preset ratio threshold, and adjust the rendering configuration based on the rendering task priority execution sequence.

[0048] It should be noted that the embodiments of the flexible LED strip virtual debugging system based on digital twin provided in this application can be used to execute the processing flow of the embodiments of the flexible LED strip virtual debugging method based on digital twin in the above embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the above method embodiments.

[0049] This application also provides an electronic device, which includes one or more processors and memory resources represented by memory for storing instructions executable by the processor, such as application programs. The application programs stored in the memory may include one or more modules, each corresponding to a set of instructions. Furthermore, the processor is configured to execute instructions to perform the aforementioned virtual debugging method for flexible LED strips based on digital twins.

[0050] The electronic device may also include a power supply component configured to perform power management of the electronic device, a wired or wireless network interface configured to connect the electronic device to a network, and an input / output (I / O) interface. The electronic device can be operated based on operating devices stored in memory, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0051] In one embodiment, a computer device, which may be a server, is also provided. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes non-volatile storage media and internal memory. The non-volatile storage media stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device stores data. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a virtual debugging method for flexible LED strips based on digital twins.

[0052] In one embodiment, a computer device is provided, which may be a terminal. The computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a virtual debugging method for flexible LED strips based on digital twins. The display unit of the computer device is used to form a visually visible image and may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0053] This application also provides a non-transitory computer-readable storage medium, which, when the instructions in the storage medium are executed by the processor of the aforementioned electronic device, enables the aforementioned electronic device to execute a virtual debugging method for flexible LED strips based on digital twins.

[0054] This application may take the form of a computer program product implemented on one or more storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing program code. Computer-readable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information may be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to: phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0055] It should be noted that although the steps of the flexible LED strip virtual debugging method based on digital twins in this application are described in a specific order in the accompanying drawings, this does not require or imply that these steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps, such as omitting certain steps, combining multiple steps into one step, and / or decomposing one step into multiple steps, should all be considered part of this application.

[0056] It should be understood that this application is not limited to the detailed structure and arrangement of the modules of the flexible LED strip virtual debugging system based on digital twins proposed in this specification. This application can have other implementations and can be implemented and executed in various ways. The foregoing variations and modifications fall within the scope of this application. It should be understood that the application and its definition in this specification extend to all alternative combinations of two or more individual features mentioned or apparent in the text and / or drawings. All these different combinations constitute multiple alternative aspects of this application. The embodiments described in this specification illustrate the best known mode for implementing this application and will enable those skilled in the art to utilize this application.

Claims

1. A virtual debugging method for flexible LED strips based on digital twins, characterized in that, include: Obtain multiple debugging tasks for the flexible light strip in the digital twin platform, and determine the resource utilization rate of each computing unit based on the debugging tasks; The load of each stage of the rendering pipeline of the computing unit is obtained, and the rendering requirement feature vector is determined based on the resource utilization of each computing unit and the load of each stage of the rendering pipeline. The predicted frame rate sequence is determined based on the rendering requirement feature vector, and it is determined whether the fluctuation amplitude of the predicted frame rate sequence exceeds the preset fluctuation amplitude threshold. If it is determined that it exceeds the preset fluctuation amplitude threshold, the resource utilization rate of each computing unit is adjusted, and a rendering configuration is generated. Obtain the viewport resolution rendering data volume and texture resource binding status in the rendering configuration, and determine whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds a preset ratio threshold. If the preset ratio threshold is exceeded, the rendering task priority execution sequence is determined according to the texture resource binding status, and the rendering configuration is adjusted according to the rendering task priority execution sequence.

2. The virtual debugging method for flexible LED strips based on digital twins according to claim 1, characterized in that, The step of determining the resource utilization rate of the computing unit based on each of the debugging tasks includes: Obtain the evaluation metrics for each of the debugging tasks, including urgency, value, number of instructions, data volume, and rendering accuracy; The priority score of each debugging task is determined based on the urgency and the value, and the complexity score of each debugging task is determined based on the number of instructions, the amount of data, and the rendering accuracy. The load score for each debugging task is determined based on the priority score and the complexity score. The load scores are sorted sequentially from the maximum to the minimum, and based on the sorting results, a linear programming algorithm is used to determine the resource utilization rate of the computing unit.

3. The virtual debugging method for flexible LED strips based on digital twins according to claim 1, characterized in that, The step of determining the rendering requirement feature vector based on the resource utilization of each computing unit and the load of each stage of the rendering pipeline includes: The resource utilization of each computing unit and the load of each stage of the rendering pipeline are standardized to generate standardized resource utilization and standardized rendering pipeline load. Based on the standardized resource utilization rate and the standardized rendering pipeline load, a convolutional neural network is used to determine the rendering requirement feature vector.

4. The virtual debugging method for flexible LED strips based on digital twins according to claim 1, characterized in that, Determining the predicted frame rate sequence based on the rendering requirement feature vector includes: Obtain a record of the mapping relationship between historical rendering requirement feature vectors and historical rendering delay values; The nearest neighbor matching algorithm is used to calculate the cosine similarity between the current rendering requirement feature vector and the mapping relationship record, and the mapping relationship record corresponding to the maximum value of the cosine similarity is used as the historical rendering delay value corresponding to the current rendering requirement feature vector. The predicted rendering latency value is determined based on the historical rendering latency value and the current rendering requirement feature vector. Based on the predicted rendering latency, a linear regression algorithm is used to determine the predicted frame rate sequence.

5. The virtual debugging method for flexible LED strips based on digital twins according to claim 2, characterized in that, The adjustment of resource utilization of each computing unit and the generation of rendering configuration include: Obtain the adjustment coefficients, and determine the adjustment ratio of each current calculation unit based on the adjustment coefficients; The task weight coefficient of each debugging task is determined based on the load score of each debugging task; The resource utilization rate of each computing unit is adjusted according to the adjustment ratio and the task weight coefficient. The rendering configuration is generated based on the adjusted resource utilization of each computing unit.

6. The virtual debugging method for flexible LED strips based on digital twins according to claim 1, characterized in that, The step of determining the rendering task priority execution sequence based on the texture resource binding state includes: The texture dependency strength and texture load level of each rendering task are determined based on the texture resource binding status. Obtain the weights corresponding to the texture dependency strength and the texture load levels, respectively. Based on the weight corresponding to the texture dependency strength and the weight corresponding to the texture load level, a weighted operation is performed on the texture dependency strength and the texture load level, and the result of the weighted operation is used as the execution priority score for each rendering task; The execution priority scores of each rendering task are sorted from the maximum value to the minimum value, and the sorting result is used as the execution sequence of the rendering task priority.

7. The virtual debugging method for flexible LED strips based on digital twins according to claim 1, characterized in that, The step of adjusting the rendering configuration according to the rendering task priority execution sequence includes: Based on the execution sequence of the rendering tasks according to their priority, the K-means clustering algorithm is used to determine the execution groups of rendering tasks at different resource allocation levels. Based on the rendering task, the resource utilization of each computing unit is optimized in groups; The rendering configuration is adjusted based on the optimized resource utilization of each computing unit.

8. The virtual debugging method for flexible LED strips based on digital twins according to claim 1, characterized in that, After adjusting the rendering configuration, the following is also included: Based on the rendering task priority, the execution sequence is loaded to load the virtual debugging task configuration in the digital twin platform to generate debugging task running data; Determine performance metrics based on the debugging task execution data; Based on the performance index data, the random forest algorithm is used to determine the performance index data groupings of different performance levels. The performance index data groupings include high-efficiency performance index data groupings, qualified performance index data groupings, and inefficient performance index data groupings. Based on the grouping of the inefficient performance index data, a genetic algorithm is used to optimize the resource utilization rate of each computing unit.

9. A virtual debugging system for flexible LED strip lights based on digital twins, characterized in that, include: The first acquisition module is used to acquire multiple debugging tasks of the flexible light strip in the digital twin platform, and determine the resource occupancy rate of each computing unit based on the debugging tasks. The second acquisition module is used to acquire the load of each stage of the rendering pipeline of the computing unit, and to determine the rendering requirement feature vector based on the resource utilization rate of each computing unit and the load of each stage of the rendering pipeline. The first determining module is used to determine the predicted frame rate sequence based on the rendering requirement feature vector, and to determine whether the fluctuation amplitude of the predicted frame rate sequence exceeds a preset fluctuation amplitude threshold. If it is determined that the fluctuation amplitude exceeds the preset fluctuation amplitude threshold, the resource utilization rate of each computing unit is adjusted, and a rendering configuration is generated. The third acquisition module is used to acquire the viewport resolution rendering data volume and texture resource binding status in the rendering configuration, and to determine whether the ratio between the viewport resolution rendering data volume and the preset frame buffer capacity exceeds a preset ratio threshold. The second determining module is used to determine the rendering task priority execution sequence based on the texture resource binding status if the determination exceeds the preset ratio threshold, and to adjust the rendering configuration based on the rendering task priority execution sequence.

Images