Rendering test method and system based on supercomputing and computer equipment
By creating data centers and configuration files on the supercomputing platform, generating test cases and performing exception information analysis, the problems of low testing efficiency and low resource utilization of supercomputing rendering system are solved, and an efficient and accurate rendering and testing process is achieved, and the testing capabilities of domestic supercomputing platforms are improved.
Patent Information
- Application Number
- CN202510565894.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-30
- Publication Date
- 2025-08-15
AI Technical Summary
In the prior art, the testing methods of supercomputing rendering systems have problems such as low testing efficiency, low resource utilization and large test errors, especially on domestic supercomputing platforms, the traditional testing methods are cumbersome and prone to errors, and cannot effectively predict model integrity and node availability.
By creating data centers and configuration files, generating test cases and creating use case execution lists, dynamically compute node requirements, and generating supercomputing commands with static parameters of configuration files, performing exception information analysis and node inspection, realizing automated instruction generation and multi-dimensional result verification, ensuring standardization and efficient execution of the test process.
It significantly improves the rendering and testing efficiency in supercomputing environment, reduces manual operation errors, improves resource utilization and task execution success rate, ensures the accuracy and reliability of test results, and provides an efficient automated testing solution.
Smart Images
Figure CN120492334A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of software testing, and more particularly to a rendering testing method, system and computer equipment based on supercomputing. Background Art
[0002] With the widespread application of supercomputers in complex computing fields, their multi-architecture and multi-operating system characteristics have put forward higher requirements for software porting and optimization. As a typical high-performance computing scenario, three-dimensional rendering requires the conversion of 3D models into 2D images. After being ported to domestic supercomputing platforms, its performance needs to be verified through a large number of iterative tests. However, the testing methods for supercomputing rendering systems in the existing technology have significant defects: traditional testing requires manual splicing of supercomputing commands, manual counting of model frames and allocation of node resources. The operation is cumbersome and error-prone, resulting in low testing efficiency and large testing errors. Moreover, because the existing testing methods do not predict the integrity of the model or the availability of nodes, the use cases often fail due to file anomalies, bad nodes or insufficient resources, which takes up computing resources and requires extra time to troubleshoot the problem. In addition, due to the architectural differences of domestic supercomputing platforms, traditional automated testing frameworks are difficult to adapt, further exacerbating the problems of low testing efficiency and resource utilization.
[0003] Therefore, it is an urgent problem to provide a supercomputing-based rendering test method, system and computer equipment that can achieve dynamic resource matching, automatic instruction generation and multi-dimensional result verification. Summary of the Invention
[0004] The present invention provides a supercomputer-based rendering test method, system and computer equipment to at least solve the problems of low test efficiency, poor resource utilization and large test errors in existing testing methods for supercomputer rendering systems.
[0005] To achieve the above-mentioned object, the present invention provides a supercomputing-based rendering test method, comprising:
[0006] Steps for creating a data center: Create a data center to store model files;
[0007] Creating a configuration file step: creating a configuration file, the configuration file including path parameters and command parameters;
[0008] Use case generation step: generating corresponding test cases based on each model file of the data center and creating a use case execution list;
[0009] Based on the number of nodes required for each test case and the static parameters in the configuration file, generate a corresponding supercomputing command and executable script file for each test case;
[0010] Resource analysis step: performing abnormal information analysis on each of the model files, and marking the abnormal information analysis results in the use case execution list;
[0011] Perform supercomputing node checks to determine whether the required number of nodes for each test case meets the execution conditions based on preset rules, and mark the number in the test case execution list;
[0012] Use case execution steps: obtain a list of executable use cases based on the use case execution list, execute the corresponding executable script file, generate a supercomputing task, update the execution status of each test case in the use case execution list, and store the log file and rendering image results in the corresponding directory.
[0013] Furthermore, the method further includes executing the result detection step:
[0014] Regularly check the execution status and obtain executed test cases;
[0015] The log file and the rendered image corresponding to the executed test case are obtained, and a test case execution result is determined based on the log file and the rendered image.
[0016] Furthermore, the use case generation step includes:
[0017] The total number of frames of each model is obtained based on the model file of the data center. The number of required nodes of the corresponding test case is calculated based on the total number of frames of each model and recorded in the test case execution list. The expression is as follows:
[0018] N = min (number of blocks, number of frames) * total number of frames
[0019] Where N is the number of required nodes for each test case.
[0020] Furthermore, the use case execution list includes the following fields: test case name, model file name, total number of frames, resource satisfaction, analysis passed, execution conditions met, whether to execute and execution results.
[0021] Furthermore, the resource analysis step includes:
[0022] Obtaining a model file from the data center and checking whether the model file contains abnormal information;
[0023] If included, the "Analysis Passed" field and the "Satisfied Execution Condition" field corresponding to the test case corresponding to the model file in the use case execution list are marked as N;
[0024] If not included, the analysis pass field corresponding to the test case corresponding to the model file in the use case execution list is marked as Y.
[0025] Furthermore, the resource analysis step further includes:
[0026] Obtain a supercomputing resource queue, perform node inspection on the supercomputing resource queue and remove abnormal nodes, obtain the number of available nodes, and traverse the test cases to obtain the required number of nodes for each test case;
[0027] If the number of available nodes is greater than the required number of nodes, the resource satisfaction field and the execution condition satisfaction field corresponding to the test case in the use case execution list are marked as Y;
[0028] If the number of available nodes is less than the required number of nodes, the resource satisfaction field and the execution condition satisfaction field corresponding to the test case in the use case execution list are marked as N.
[0029] The present invention provides a supercomputer-based rendering test system, which is applied to the above-mentioned supercomputer-based rendering test method, including:
[0030] Create data center module: create a data center to store model files;
[0031] Create configuration file module: create a configuration file, the configuration file includes path parameters and command parameters;
[0032] Use case generation module: generates corresponding test cases based on each model file of the data center and creates a use case execution list;
[0033] Based on the number of nodes required for each test case and the static parameters in the configuration file, generate a corresponding supercomputing command and executable script file for each test case;
[0034] Resource analysis module: performs abnormal information analysis on each model file and marks the abnormal information analysis results in the use case execution list;
[0035] Perform supercomputing node checks to determine whether the required number of nodes for each test case meets the execution conditions based on preset rules, and mark the number in the test case execution list;
[0036] Use case execution module: obtains a list of executable use cases based on the use case execution list, executes the corresponding executable script file, generates a supercomputing task, updates the execution status of each test case in the use case execution list, and stores the log file and rendered image results in the corresponding directory.
[0037] Furthermore, it also includes an execution result detection module:
[0038] Regularly check the execution status and obtain executed test cases;
[0039] The log file and the rendered image corresponding to the executed test case are obtained, and a test case execution result is determined based on the log file and the rendered image.
[0040] The present invention provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned supercomputing-based rendering test method when executing the computer program.
[0041] The present invention provides a computer-readable storage medium having a computer program stored thereon, characterized in that when the program is executed by a processor, the above-mentioned supercomputing-based rendering test method is implemented.
[0042] Compared with the prior art, the advantages and positive effects of the present invention are:
[0043] This invention significantly improves rendering testing efficiency in supercomputing environments through dynamic resource matching and automated command generation. It automatically analyzes the total frame count of the model and dynamically calculates node requirements. It then generates independent executable scripts based on static configuration file parameters, avoiding errors associated with manually splicing commands. This standardizes and isolates use case generation and execution, significantly reducing the fragmentation and time costs of the testing process.
[0044] The resource pre-judgment module performs dual screening of model integrity and supercomputing node availability, effectively avoiding invalid task execution caused by file anomalies, bad nodes, or insufficient resources. Combined with the use case execution list, real-time annotation and filtering of abnormal use cases reduces invalid resource usage and time-consuming failure analysis, thereby improving the overall utilization of supercomputing resources and the success rate of task execution.
[0045] A multi-dimensional result verification strategy is introduced. Through automatic recognition of log keywords, comparison of output image quantity and periodic task status detection, multiple judgment conditions are constructed to overcome the limitations of traditional single-mark judgment and ensure the high accuracy and reliability of test result judgment.
[0046] This invention realizes closed-loop management of the entire process from use case generation to result analysis, providing an efficient and accurate automated testing solution for the complex rendering system of domestic supercomputing platforms. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] Figure 1 Schematic diagram of the process of a rendering test method based on supercomputing in an embodiment of the present invention;
[0048] Figure 2 A schematic diagram of a flow chart of steps for generating a use case in an embodiment of the present invention;
[0049] Figure 3A schematic diagram of the resource analysis process in an embodiment of the present invention;
[0050] Figure 4 Schematic diagram of the resource analysis model file analysis process in an embodiment of the present invention;
[0051] Figure 5 This is a schematic diagram of the resource analysis supercomputing node inspection process in an embodiment of the present invention;
[0052] Figure 6 Schematic diagram of the execution result detection process in an embodiment of the present invention;
[0053] Figure 7 Schematic diagram of the structure of a rendering test system based on supercomputing in an embodiment of the present invention;
[0054] Figure 8 A schematic diagram of a computer device provided in an embodiment of the present invention.
[0055] In the above picture:
[0056] 40. Bus; 41. Processor; 42. Memory; 43. Communication interface; 100. Data center creation module; 200. Configuration file creation module; 300. Use case generation module; 400. Resource analysis module; 500. Use case execution module; 600. Execution result detection module. DETAILED DESCRIPTION
[0057] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0058] In the description of the present application, it should be understood that the terms "center", "up", "down", "front", "back", "left", "right", "vertical", "liquid level", "top", "bottom", "inside", "outside" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present application. The terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the present application, unless otherwise specified, "multiple" means two or more.
[0059] In the description of this application, it should be noted that, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they can refer to fixed connections, detachable connections, or integral connections; mechanical connections or electrical connections; direct connections or indirect connections through an intermediate medium; and internal connections between two components. Those skilled in the art will understand the specific meanings of the above terms in this application based on the specific circumstances.
[0060] like Figures 1-8 As shown, the present invention provides a rendering test method, system and computer equipment based on supercomputing to at least solve the problems of low test efficiency, low resource utilization and large test errors in existing testing methods for supercomputing rendering systems. Figures 1-8 The present invention provides a detailed description of the supercomputing-based rendering test method, system, and computer equipment.
[0061] Example 1:
[0062] Figure 1 FIG. 1 is a flow chart of a supercomputing-based rendering test method according to an embodiment of the present invention. Figure 1 As shown, the present invention provides a rendering test method based on supercomputing, including: creating a data center step S100, creating a configuration file step S200, using case generation step S300, resource analysis step S400 and using case execution step S500 and execution result detection step S600.
[0063] The step S100 of creating a data center includes creating a data center for storing model files.
[0064] In some embodiments, using Blender as an example, a standardized data center is built to centrally store all Blender-formatted 3D model files. These files are then managed in a standardized manner according to the naming conventions of the actual build content, ensuring the uniqueness and traceability of the model files. The data center supports the addition of diverse 3D model sample sets from the internet to expand the coverage of test scenarios and enhance the comprehensiveness and representativeness of rendering tests.
[0065] The step S200 of creating a configuration file includes creating a configuration file, where the configuration file includes path parameters and command parameters.
[0066] In some embodiments, a Config directory is created, along with an env.conf environment configuration file, to centrally define the path parameters and command parameters required for rendering testing, including but not limited to: a blender file list (blender_list), a data base path (path), a data center path (data_path), an executable rendering program path (exe_path), a rendering result output path (result_path), a supercomputing resource queue (queue_name), rendering command parameter values, and supercomputing command parameter value settings. blender_list is a list of files to be executed. The configuration file allows for flexible control of the test case scope by modifying the blender_list parameters in the file list, enabling rapid configuration and adjustment of test tasks.
[0067] like Figure 2 As shown, the use case generation step S300 includes generating corresponding test cases based on each model file of the data center and creating a use case execution list;
[0068] Based on the required number of nodes for each test case and the static parameters in the configuration file, a corresponding supercomputing command and executable script file are generated for each test case.
[0069] Preferably, the use case generation step S300 includes:
[0070] Based on the model file of the data center, the total number of frames of each model is obtained. Based on the total number of frames of each model, the number of required nodes of the corresponding test case is calculated and recorded in the use case execution list. The expression is as follows:
[0071] N = min (number of blocks, number of frames) * total number of frames
[0072] Where N is the number of required nodes for each test case.
[0073] In some embodiments, the number of blocks refers to the number of parallel task units dynamically divided according to supercomputing resource constraints and model rendering characteristics, and its value is a specified number obtained through comprehensive judgment of multiple conditions.
[0074] Preferably, the use case execution list includes the following fields: test case name, model file name, total number of frames, number of required nodes, resource satisfaction, analysis passed, execution conditions met, whether to execute, and execution results.
[0075] In some embodiments, taking Blender as an example, the use case generation step S300 generates an independent corresponding test case for each 3D model file through an automated process and constructs a use case execution list (case.xls). Specifically, it includes:
[0076] Create a Case directory and a case.xls file containing a test case execution list. To facilitate finding the execution status of a specified blender file, the use case names are named after the blender file name. Each blender file corresponds to a test case.
[0077] Create a use case execution checklist with fields including, but not limited to, the test case name, Blender model file name, total number of frames, number of nodes, resource satisfaction, analysis pass, execution condition satisfaction, execution status, and execution results, enabling full lifecycle tracking of use case execution. This checklist uses multi-dimensional fields to record test status and resource matching, allowing for quick access to use case execution status, filtering unexecuted use cases, and analyzing failure causes, effectively streamlining test process management.
[0078] Retrieve all Blender model files from the data center and use Blender's Python API to obtain the total number of frames for the model. This is recorded in the use case execution list (case.xls). The total number of frames determines the number of nodes required for each test case. The required number of nodes is calculated as: N = min (number of blocks, number of frames) * total number of frames. Dynamically obtaining the total number of frames and calculating the required number of nodes through the API replaces manual counting and splicing commands, significantly reducing operational errors and improving the efficiency and accuracy of use case generation.
[0079] Based on the required number of nodes and static parameters in the configuration file, such as resource queues and rendering commands, the supercomputer's executable bsub command is automatically spliced together, and an independent Shell script is generated for each use case. The file is named blenderfilename.sh to achieve use case isolation and ensure that each test case exists independently. This facilitates rapid restoration and problem location when a use case fails, shortening the troubleshooting cycle.
[0080] The use case generation step S300 provides a highly reliable use case generation and execution framework for supercomputing rendering testing through standardized and automated processes, significantly improving the robustness and maintainability of the test process.
[0081] like Figure 3-Figure 5 As shown, the resource analysis step S400 includes performing an abnormal information analysis on each model file and marking the abnormal information analysis results in the use case execution list;
[0082] Perform supercomputing node checks and determine whether the required number of nodes for each test case meets the execution conditions based on preset rules, and mark them in the use case execution list.
[0083] In some embodiments, as Figure 3As shown, the resource analysis step S400 performs segmented verification of the model file and the supercomputing node through the pre-execution screening mechanism, first calling the FileAnalysis() function to perform model file anomaly detection, and then performing supercomputing node inspection through the NodeAnalysis() function to ensure that the test case meets the execution conditions. Model file anomaly detection can eliminate the risk of failure due to file errors, and then verify the node availability to avoid wasting resources on invalid tasks. Double verification forms a progressive filtering mechanism, which prioritizes solving data quality problems and then adapts resource allocation, significantly improving the robustness of the overall test process.
[0084] Preferably, if Figure 4 As shown, the resource analysis step S400 includes:
[0085] Obtain the model file from the data center and check whether the model file contains abnormal information;
[0086] If included, the corresponding fields of the analysis passed and execution condition satisfied for the test case in the model file in the use case execution list are marked as N;
[0087] If not included, the analysis pass field corresponding to the test case of the model file in the use case execution list will be marked as Y.
[0088] In some embodiments, the model file anomaly information analysis specifically involves calling the FileAnalysis() function to automatically scan the Blender model files in the data center to detect any anomalies such as warnings, errors, or data corruption. If an anomaly is detected, the "Analysis Passed" and "Satisfied Execution Conditions" fields of the test case corresponding to the model file in the use case execution list are marked as "N"; if no anomaly is detected, "Analysis Passed" is marked as "Y".
[0089] In some embodiments, blender model files that fail the analysis can be manually improved and then stored in the data center for re-analysis, forming a closed-loop process of "test-correction-re-test" to continuously optimize the integrity and reliability of the test data set.
[0090] Preferably, if Figure 5 As shown, the resource analysis step S400 further includes:
[0091] Obtain the supercomputing resource queue, perform node inspection on the supercomputing resource queue and remove abnormal nodes, obtain the number of available nodes, and traverse the test cases to obtain the required number of nodes for each test case;
[0092] If the number of available nodes is greater than the number of required nodes, the Resource Satisfaction field and the Execution Condition Satisfaction field corresponding to the test case in the Use Case Execution List are marked as Y;
[0093] If the number of available nodes is less than the required number of nodes, the resource satisfaction field and the execution condition satisfaction field corresponding to the test case in the use case execution list are marked as N.
[0094] In some embodiments, the NodeAnalysis() function is used to traverse the supercomputing resource queue, identify and eliminate faulty nodes, such as node hardware anomalies, excessive node load, etc., obtain the number of available nodes M, and traverse the number of required nodes N of all test cases in the use case execution list; if M≥N, the "resource satisfaction" and "satisfaction of execution conditions" corresponding to the test case in the use case execution list are marked as "Y", if M<N, the "resource satisfaction" and "satisfaction of execution conditions" corresponding to the test case in the use case execution list are marked as "Y".
[0095] In some embodiments, test cases marked as not meeting the execution conditions will not be automatically executed to avoid resource preemption and task failure.
[0096] The use case execution step S500 includes obtaining a list of executable use cases based on the use case execution list, executing the corresponding executable script file, generating a supercomputing task, updating the execution status of each test case in the use case execution list, and storing the log file and rendering image results in the corresponding directory.
[0097] In some embodiments, test cases marked as "Y" for "Satisfying the execution conditions" are screened based on the use case execution list, and the corresponding Shell script files (blender file name.sh) are submitted through the background batch scheduling mechanism. After each script is submitted, an independent supercomputing task is generated. The background batch submission and the supercomputing platform load adaptation mechanism replace the manual execution of commands one by one, which can significantly improve the task execution efficiency and system throughput.
[0098] After the task is submitted, the "Is it executed" field of the corresponding test case in the use case execution list is updated to "Y" to reflect the task execution status in real time. The real-time update of the "Is it executed" field in the use case list supports testers to globally monitor the task progress and quickly locate unexecuted or abnormally interrupted use cases.
[0099] During task execution, log files are automatically stored in the Case / [blender file name] / Log / directory, and 2D rendered images are output to the Case / [blender file name] / Photo / directory. This ensures categorized data storage and quick retrieval. Logs and rendering results are stored by model file name, providing a complete data chain for subsequent result analysis and fault tracing, shortening troubleshooting cycles.
[0100] In some embodiments, through standardized task execution and structured data management, efficient closed-loop operation of supercomputing rendering testing is achieved, ensuring the controllability and traceability of the testing process.
[0101] Preferably, the execution result detection step S600 includes:
[0102] Regularly check the execution status and obtain executed test cases;
[0103] The log file and the rendered image corresponding to the executed test case are obtained, and a test case execution result is determined based on the log file and the rendered image.
[0104] In some embodiments, as Figure 6 As shown, the execution result detection step S600 verifies the test case execution result through an automated multi-dimensional determination mechanism.
[0105] With existing supercomputer test tasks, it's impossible to predict when a task will end. It's necessary to manually check for completed tasks using the bjobs command. After a task completes, the job_finish keyword will be generated in the log, indicating that the task has completed. However, this isn't a sign that the test case has passed, so manual log analysis is required to determine whether the test case has passed. Therefore, in this embodiment, the supercomputer task queue is polled every 20 minutes to detect whether any tasks have completed, and results are analyzed for completed test cases. This timed polling mechanism avoids manual and continuous monitoring, ensuring rapid response and result updates after task completion, shortening the test cycle.
[0106] Extract the job_finished keyword from the completed test case's log file (Case / [blender file name] / Log / ) to confirm that the task has been completed. Obtain the number of 2D images rendered in the Photo directory to confirm whether it is consistent with the total number of model frames to ensure rendering integrity. Check the log file. If there are no abnormal keywords such as crash, ERROR, or memory, the test case is considered to have been executed successfully. Mark the corresponding "Execution Result" field in the test case execution list as "Y", otherwise mark it as "N".
[0107] Through triple verification of log keywords, image quantity, and task status, the limitations of a single judgment condition are overcome, significantly improving the accuracy and reliability of the result judgment. At the same time, combining error keywords with abnormal image quantity information can directly locate the cause of rendering failure (such as memory overflow, model error, etc.), accelerating the problem repair process.
[0108] Example 2:
[0109] Figure 7FIG. 1 is a schematic diagram of a parallel computing system structure of a tensor reduction in an embodiment of the present invention. Figure 7 As shown, the present invention provides a rendering test method based on supercomputing, including a data center creation module 100, a configuration file creation module 200, a use case generation module 300, a resource analysis module 400, a use case execution module 500 and an execution result detection module 600.
[0110] The data center creation module 100 includes creating a data center for storing model files.
[0111] The configuration file creation module 200 includes creating a configuration file, where the configuration file includes path parameters and command parameters.
[0112] The use case generation module 300 includes generating corresponding test cases based on each model file of the data center and creating a use case execution list.
[0113] Based on the required number of nodes for each test case and the static parameters in the configuration file, a corresponding supercomputing command and executable script file are generated for each test case.
[0114] The resource analysis module 400 includes performing abnormal information analysis on each model file and marking the abnormal information analysis results in the use case execution list;
[0115] Perform supercomputing node checks and determine whether the required number of nodes for each test case meets the execution conditions based on preset rules, and mark them in the use case execution list.
[0116] The use case execution module 500 includes obtaining a list of executable use cases based on the use case execution list, executing the corresponding executable script file, generating a supercomputing task, updating the execution status of each test case in the use case execution list, and storing the log file and rendering image results in the corresponding directory.
[0117] The execution result detection module 600 includes periodically performing execution status detection and obtaining executed test cases;
[0118] The log file and the rendered image corresponding to the executed test case are obtained, and a test case execution result is determined based on the log file and the rendered image.
[0119] Example 3:
[0120] Combine Figure 8 As shown, this embodiment discloses a specific implementation of a computer device. The computer device may include a processor 41 and a memory 42 storing computer program instructions.
[0121] Specifically, the processor 41 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.
[0122] Among them, the memory 42 may include a large-capacity memory for data or instructions. By way of example and not limitation, the memory 42 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 42 may include a removable or non-removable (or fixed) medium. Where appropriate, the memory 42 may be inside or outside the data processing device. In a specific embodiment, the memory 42 is a non-volatile memory. In a specific embodiment, the memory 42 includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically alterable ROM (EAROM) or a flash memory (FLASH), or a combination of two or more of these. Under appropriate circumstances, the RAM can be a static random access memory (SRAM) or a dynamic random access memory (DRAM), where the DRAM can be a fast page mode dynamic random access memory (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.
[0123] The memory 42 may be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 41 .
[0124] The processor 41 reads and executes computer program instructions stored in the memory 42 to implement the supercomputing-based rendering test method in the above embodiment.
[0125] In some embodiments, the computer device may further include a communication interface 43 and a bus 40. Figure 8 As shown, the processor 41, the memory 42, the communication interface 43 and the bus 40 are connected and communicate with each other.
[0126] The communication interface 43 is used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.
[0127] The communication interface 43 can also implement data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.
[0128] The bus 40 includes hardware, software, or both, and couples the components of the computer device to each other. The bus 40 includes, but is not limited to, at least one of the following: a data bus, an address bus, a control bus, an expansion bus, and a local bus. By way of example, and not limitation, bus 40 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Bus 40 may include one or more buses, where appropriate. Although embodiments herein describe and illustrate a particular bus, this application contemplates any suitable bus or interconnect.
[0129] In addition, in conjunction with the supercomputing-based rendering test method in the above-mentioned embodiments, embodiments of the present application may provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any of the supercomputing-based rendering test methods in the above-mentioned embodiments is implemented.
[0130] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any other form. Any technician familiar with the profession may use the technical content disclosed above to change or modify it into an equivalent embodiment with equivalent changes for application in other fields. However, any simple modification, equivalent change and modification of the above embodiment made according to the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of protection of the technical solution of the present invention.
Claims
1. A rendering test method based on supercomputing, characterized in that: include: Steps for creating a data center: Create a data center to store model files; Creating a configuration file step: creating a configuration file, the configuration file including path parameters and command parameters; Use case generation step: generating corresponding test cases based on each model file of the data center and creating a use case execution list; Based on the number of nodes required for each test case and the static parameters in the configuration file, generate a corresponding supercomputing command and executable script file for each test case; Resource analysis step: performing abnormal information analysis on each of the model files, and marking the abnormal information analysis results in the use case execution list; Perform supercomputing node checks to determine whether the required number of nodes for each test case meets the execution conditions based on preset rules, and mark the number in the test case execution list; Use case execution steps: obtain a list of executable use cases based on the use case execution list, execute the corresponding executable script file, generate a supercomputing task, update the execution status of each test case in the use case execution list, and store the log file and rendering image results in the corresponding directory.
2. The supercomputer-based rendering test method according to claim 1, characterized in that: It also includes the following steps to perform result detection: Regularly check the execution status and obtain executed test cases; The log file and the rendered image corresponding to the executed test case are obtained, and a test case execution result is determined based on the log file and the rendered image.
3. The supercomputer-based rendering test method according to claim 1, characterized in that: The use case generation step includes: The total number of frames of each model is obtained based on the model file of the data center. The number of required nodes of the corresponding test case is calculated based on the total number of frames of each model and recorded in the test case execution list. The expression is as follows: N = min (number of blocks, number of frames) * total number of frames Where N is the number of required nodes for each test case.
4. The supercomputer-based rendering test method according to claim 1, wherein: The use case execution list Includes the following fields: test case name, model file name, total number of frames, resource satisfaction, analysis passed, execution conditions met, whether executed, and execution results.
5. The supercomputer-based rendering test method according to claim 4, characterized in that: The resource analysis step includes: Obtaining a model file from the data center and checking whether the model file contains abnormal information; If included, the "Analysis Passed" field and the "Satisfied Execution Condition" field corresponding to the test case corresponding to the model file in the use case execution list are marked as N; If not included, the analysis pass field corresponding to the test case corresponding to the model file in the use case execution list is marked as Y.
6. The supercomputer-based rendering test method according to claim 5, characterized in that: The resource analysis step further comprises: Obtain a supercomputing resource queue, perform node inspection on the supercomputing resource queue and remove abnormal nodes, obtain the number of available nodes, and traverse the test cases to obtain the required number of nodes for each test case; If the number of available nodes is greater than the required number of nodes, the resource satisfaction field and the execution condition satisfaction field corresponding to the test case in the use case execution list are marked as Y; If the number of available nodes is less than the required number of nodes, the resource satisfaction field and the execution condition satisfaction field corresponding to the test case in the use case execution list are marked as N.
7. A supercomputer-based rendering test system, applied to the supercomputer-based rendering test method according to any one of claims 1 to 6, comprising: Create data center module: create a data center to store model files; Create configuration file module: create a configuration file, the configuration file includes path parameters and command parameters; Use case generation module: generates corresponding test cases based on each model file of the data center and creates a use case execution list; Based on the number of nodes required for each test case and the static parameters in the configuration file, generate a corresponding supercomputing command and executable script file for each test case; Resource analysis module: performs abnormal information analysis on each model file and marks the abnormal information analysis results in the use case execution list; Perform supercomputing node checks to determine whether the required number of nodes for each test case meets the execution conditions based on preset rules, and mark the number in the test case execution list; Use case execution module: obtains a list of executable use cases based on the use case execution list, executes the corresponding executable script file, generates a supercomputing task, updates the execution status of each test case in the use case execution list, and stores the log file and rendered image results in the corresponding directory.
8. The supercomputer-based rendering test system according to claim 7, characterized in that: It also includes the execution result detection module: Regularly check the execution status and obtain executed test cases; The log file and the rendered image corresponding to the executed test case are obtained, and a test case execution result is determined based on the log file and the rendered image.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the supercomputing-based rendering test method according to any one of claims 1 to 6 is implemented.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the supercomputing-based rendering test method as described in any one of claims 1 to 6 is implemented.