A graphics rendering mechanism identification method based on rendering pipeline alignment

Abstract

The present invention discloses a method for identifying a graphics rendering mechanism based on rendering pipeline alignment. The method pre-executes a benchmark test program in CPU mode and GPU mode respectively, completes pre-alignment of the key stage processing interval and the stable working interval in the two modes to form a first sampling interval to achieve alignment of the rendering pipeline. The second sampling interval is formed based on the pre-alignment of frame complexity. The target sampling interval is obtained by finding the intersection of the first sampling interval and the second sampling interval. During actual testing, CPU load data of each of the two modes is obtained, the CPU load data is sampled according to the target sampling interval, and the correlation between the two sampling data is calculated to determine the graphics rendering mechanism of the tested system. The unified rendering action ensures that the sampling data covers the complete rendering cycle. The reasonable distribution of data density under different load scenarios is ensured by analyzing the frame complexity. The combination of the two improves the representativeness and statistical effectiveness of the data, and effectively improves the accuracy of identifying the graphics rendering mechanism.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer software development, and in particular relates to a graphics rendering mechanism identification method based on rendering pipeline alignment. Background Art

[0002] Existing methods for determining graphics rendering modes primarily include tool-based detection, code analysis, and performance data analysis. Tool-based detection includes driver-level tools, system information tools, and platform-specific tools. Driver-level tools, such as Intel Shader Analyzer, are offline static analysis tools designed specifically for Intel GPU architectures. They can compile Dxbc or HLSL code and inspect the generated GPU instruction set architecture (ISA) for DX11 and DX12. System information tools, such as glxinfo, are commonly used terminal command-line tools that can retrieve information about graphics card support for OpenGL, the graphics rendering mode, and the system's currently used graphics card. Platform-specific tools, such as Android GPU Inspector (AGI), are Google's official performance analysis tool for Android apps, which can view frame timelines, GPU utilization, command queues, memory usage, and more. Code analysis involves identifying rendering modes through specific OpenGL benchmarks, such as the glmark2 benchmark, combined with compiler and reverse engineering techniques. Performance data analysis refers to some performance analysis tools, such as Huawei's DevEco Profiler, which can monitor application performance indicators, record trace records, and determine the graphics rendering mechanism by analyzing trace data.

[0003] However, when using the above method to identify the graphics rendering mode, the test results can be changed by modifying specific properties of the system under test, resulting in incorrect conclusions. Therefore, the existing method for identifying the graphics rendering mechanism still has problems such as low detection accuracy. Summary of the Invention

[0004] In view of this, the present invention provides a graphics rendering mechanism identification method based on rendering pipeline alignment, which determines the target sampling interval through the key stage processing interval, the stable working interval and the pre-alignment based on the frame complexity, extracts the load data of the system under test, and identifies the graphics rendering mechanism by the correlation of the load data.

[0005] The present invention provides a method for identifying a graphics rendering mechanism based on rendering pipeline alignment, which specifically includes the following steps:

[0006] Step 1: For a system under test that is preliminarily determined to have a GPU mode, set rendering processing as a key stage and determine a benchmark program that includes the key stage;

[0007] Step 2: pre-run the benchmark test program in the CPU mode and the GPU mode respectively, determine that the processing interval of the key stage in the benchmark test program is the CPU processing interval and the GPU processing interval, and the intersection of the two processing intervals is the first pre-sampling interval;

[0008] Step 3: Pre-run the benchmark test program separately to obtain performance data of the system under test, and determine the stable working interval as the CPU stable working interval and the GPU stable working interval based on the performance data. The intersection of the two stable working intervals is the second pre-sampling interval; the intersection of the first pre-sampling interval and the second pre-sampling interval is the first sampling interval;

[0009] Step 4: Pre-run the benchmark test program separately to obtain the graphics rendering parameters of each frame of data to determine the complexity of the data frame. The more complex the data frame, the smaller the sampling interval. Determine the respective sampling periods based on the sampling interval. The intersection of the two sampling periods is the second sampling interval. The intersection of the first sampling interval and the second sampling interval is the target sampling interval.

[0010] Step 5. During the actual test, the benchmark program is run in the two modes of the system under test respectively to obtain the CPU load data of the system under test in the two modes. The CPU load data are sampled respectively using the target sampling interval to obtain the respective load data; the correlation between the two load data is calculated. If the correlation is greater than the threshold, it is determined that the graphics rendering mechanism of the system under test does not have a GPU mode; otherwise, it is determined that a GPU mode exists.

[0011] Furthermore, the benchmark test program includes a built-in benchmark test program and an external test program, wherein the built-in benchmark test program is used to implement a composite rendering scene, and the external test program is a test program provided by the user, including key stages and having compatibility requirements.

[0012] Furthermore, the benchmark test procedure includes multiple key stages.

[0013] Furthermore, the key stage is matrix calculation, texture lighting binding or shader rendering.

[0014] Furthermore, the CPU processing interval and the GPU processing interval are both obtained by performing multiple runs to obtain multiple processing intervals, and then taking the intersection of the multiple processing intervals as the final result.

[0015] Furthermore, the CPU processing interval and the GPU processing interval are both obtained by adding timestamps to the start and end positions of key stages in the benchmark test program.

[0016] Furthermore, the method for preliminarily determining that the system under test has a GPU mode is to use a glxinfo configuration query tool or modify the environment variables of the system under test for determination.

[0017] Furthermore, the complexity of the data frame is determined according to the range of the graphics rendering parameter values, and the data frame is divided into a simple frame, a medium frame or a complex frame, wherein the simple frame has the largest sampling interval and the complex frame has the smallest sampling interval.

[0018] Furthermore, the graphics rendering parameters include the number of polygons, texture resolution and light source type.

[0019] Furthermore, the method of calculating the correlation between the two load data is to perform quantitative calculation using the Pearson correlation coefficient. Beneficial effects

[0020] The present invention determines a benchmark test program including a key stage for a system under test with a GPU mode, pre-executes the benchmark test program in CPU mode and GPU mode respectively, completes pre-alignment of key stage processing intervals and stable working intervals in CPU mode and GPU mode to obtain a first sampling interval to achieve alignment of a rendering pipeline, obtains a second sampling interval through pre-alignment based on frame complexity, and then obtains a target sampling interval from the intersection of the first sampling interval and the second sampling interval. During actual testing, the benchmark test program is independently run in the CPU mode and GPU mode of the system under test to obtain CPU load data of the system under test in the two modes, extracts the CPU load data according to the target sampling interval to form first load data and second load data, calculates the correlation between the first load data and the second load data, and determines the graphics rendering mechanism of the system under test according to the value of the correlation. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 The figure is a schematic diagram of a processing flow established by adopting a method for identifying a graphics rendering mechanism based on rendering pipeline alignment provided by the present invention in an embodiment.

[0022] Figure 2 The figure is a processing flow diagram of a built-in benchmark test program established by adopting a graphics rendering mechanism identification method based on rendering pipeline alignment provided by the present invention in an embodiment.

[0023] Figure 3 Schematic diagram of a sampling process implemented by a graphics rendering mechanism identification method based on rendering pipeline alignment provided by the present invention in an embodiment.

[0024] Figure 4 This is a load data diagram in CPU mode obtained by using a graphics rendering mechanism identification method based on rendering pipeline alignment provided by the present invention in an embodiment.

[0025] Figure 5 This is a load data graph in GPU mode obtained by using a graphics rendering mechanism identification method based on rendering pipeline alignment provided by the present invention in an embodiment.

[0026] Figure 6 The figure is a schematic diagram of an actual test process implemented by a graphics rendering mechanism identification method based on rendering pipeline alignment provided by the present invention in an embodiment. DETAILED DESCRIPTION

[0027] The present invention is described in detail below with reference to the accompanying drawings and with reference to the embodiments.

[0028] The present invention provides a graphics rendering mechanism identification method based on rendering pipeline alignment, the core idea of ​​which is: for a system under test with a GPU mode, a benchmark test program including a key stage is determined, and by pre-executing the benchmark test program in CPU mode and GPU mode respectively, pre-alignment of the key stage processing interval and the stable working interval in CPU mode and GPU mode is completed to obtain a first sampling interval to achieve alignment of the rendering pipeline, and a second sampling interval is obtained by pre-alignment based on frame complexity, and then a target sampling interval is obtained by the intersection of the first sampling interval and the second sampling interval. During actual testing, the benchmark test program is independently run in the CPU mode and GPU mode of the system under test to obtain CPU load data of the system under test in the two modes, the CPU load data is extracted according to the target sampling interval to form first load data and second load data, the correlation between the first load data and the second load data is calculated, and the graphics rendering mechanism of the system under test is determined according to the value of the correlation.

[0029] The present invention provides a method for identifying a graphics rendering mechanism based on rendering pipeline alignment, the processing flow is as follows: Figure 1 As shown, the specific steps include:

[0030] Step 1: Get the graphics configuration information of the system under test and determine whether the system under test supports direct rendering using the graphics card, that is, whether there is a GPU mode. If it does, proceed to step 2; otherwise, end this process.

[0031] Specifically, the present invention can use the glxinfo configuration query tool to obtain the graphics configuration information of the system under test. When using the glxinfo command to query the graphics configuration details of the system under test, the output result is checked to see if there is a "direct rendering: Yes" message. This information indicates that the current system supports direct rendering using the graphics card, which means that OpenGL applications can directly interact with the graphics card, thereby improving graphics performance and rendering efficiency. If this item is displayed as "no", it means that the current system does not support direct rendering using the graphics card.

[0032] Step 2: Set the rendering process as the key stage and determine the benchmark program that includes the key stage. The benchmark program includes a built-in benchmark program and an external test program. Among them, the built-in benchmark program is used to implement composite rendering scenes. By implementing composite rendering scenes, the performance of the key stage can be systematically verified; the external test program is a test program provided by the user that includes the key stage. Its compatibility requirements ensure the comparability of test results between different test programs. This design makes the benchmark consistent and adaptable to the needs of different users, such as the rendering mechanism identification needs in different fields such as game engines, industrial design software or scientific research simulation.

[0033] Among them, the key stages can be matrix calculation, texture lighting binding or shader drawing, etc.

[0034] Furthermore, to improve the accuracy of identifying the graphics rendering mechanism, the benchmark test program determined by the present invention includes multiple key stages.

[0035] Step 3. Pre-run the benchmark test program independently in the CPU mode and GPU mode of the system under test, determine the processing intervals of the key stages in the benchmark test program in the CPU mode and the GPU mode, and record them as the CPU processing interval and the GPU processing interval respectively; obtain the first pre-sampling interval by taking the intersection of the CPU processing interval and the GPU processing interval, and the first pre-sampling interval is the processing interval when the key stage in the benchmark test program is executed on the system under test.

[0036] During actual testing, ensuring comparability between performance data obtained in CPU mode (software rendering) and GPU mode (hardware acceleration) is a key issue during benchmark execution. Due to differences in rendering pipeline execution speed between the two modes, unsynchronized sampling directly impacts the accuracy of performance comparisons. To address this, unified sampling of rendering actions is required, ensuring that sampling intervals are aligned at key stages of the rendering pipeline.

[0037] The sampling process needs to accurately match the same rendering operation cycle in both CPU mode (software rendering) and GPU mode (hardware acceleration) to eliminate interference variables caused by differences in rendering actions.

[0038] The CPU processing interval, the GPU processing interval, and the first pre-sampling interval are all represented by the time period during which the processing process occurs.

[0039] Furthermore, in order to improve the accuracy of the CPU processing interval or the GPU processing interval, the present invention independently pre-runs the benchmark test program in the CPU mode and the GPU mode respectively, and uses multiple runs to obtain multiple processing intervals, and then uses the intersection of the multiple processing intervals as the final result to obtain the CPU processing interval and the GPU processing interval.

[0040] Furthermore, the CPU processing interval or the GPU processing interval can be obtained by adding timestamps to the start and end positions of key stages in the benchmark program.

[0041] Step 4. Pre-run the benchmark test program independently in the CPU mode and GPU mode of the system under test, obtain performance data of the system under test in the two modes, select the processing interval in which the performance change in the key stage is less than the threshold as the stable working interval, and record it as the CPU stable working interval and the GPU stable working interval; obtain the second pre-sampling interval by the intersection of the CPU stable working interval and the GPU stable working interval, and the second pre-sampling interval is the working interval in which the system performance remains relatively stable when the benchmark test program is executed on the system under test; and obtain the first sampling interval by finding the intersection of the first pre-sampling interval and the second pre-sampling interval.

[0042] The CPU stable working interval, the GPU stable working interval and the second pre-sampling interval are all represented by time periods. The present invention can use CPU load data as performance data.

[0043] Furthermore, in order to improve the accuracy of the CPU stable working range and the GPU stable working range, the present invention independently pre-runs the benchmark test program in the CPU mode and the GPU mode respectively, and uses multiple runs to obtain multiple stable working ranges, and then uses the intersection of the multiple stable working ranges as the final result to obtain the CPU stable working range and the GPU stable working range.

[0044] Step 5. Pre-run the benchmark program independently in the CPU mode and GPU mode of the system under test, obtain the graphics rendering parameters of each frame of data in the two modes, determine the complexity of the data frame according to the range of the graphics rendering parameter values, and classify the data frame into simple frames, medium frames, or complex frames. Set corresponding sampling intervals for frames of different complexities, with the simple frame sampling interval having the largest sampling interval and the complex frame sampling interval having the smallest sampling interval. Determine the sampling time of the relevant frames in the two modes based on the sampling intervals and record them as the CPU sampling period and the GPU sampling period; obtain the second sampling interval from the intersection of the CPU sampling time and the GPU sampling time, and obtain the target sampling interval from the intersection of the first sampling interval and the second sampling interval.

[0045] In the process of drawing frames by the benchmark program, frame complexity evaluation is also a key stage in determining the sampling points. Through comprehensive analysis of the number of polygons, texture usage and lighting calculation complexity, the hardware performance under different loads can be located.

[0046] Unified rendering actions ensure that sampling covers the entire rendering cycle, and frame complexity analysis ensures a reasonable distribution of data density under different load scenarios. The combination of the two improves the representativeness and statistical effectiveness of the data.

[0047] Among them, graphics rendering parameters may include the number of polygons, texture resolution, and light source type.

[0048] Furthermore, in order to improve the accuracy of the CPU sampling period and the GPU sampling period, the present invention uses multiple runs to obtain multiple groups of CPU sampling periods and GPU sampling periods when independently pre-running the benchmark test program in the CPU mode and the GPU mode, and uses the intersection of multiple groups of data to obtain the final CPU sampling period and GPU sampling period.

[0049] Among them, the simple frame sampling interval is the largest, for example, sampling once every 5 frames, the medium frame is sampled once every 2 frames, and the complex frame is sampled frame by frame.

[0050] Step 6. During the actual test, the benchmark program is run independently in the CPU mode and GPU mode of the system under test to obtain the CPU load data of the system under test in the two modes. The target sampling interval determined in step 5 is used to sample the performance data of the entire process to obtain the first load data and the second load data respectively; the correlation between the first load data and the second load data is calculated. If the correlation is greater than the threshold, it is determined that the graphics rendering mechanism of the system under test does not support GPU rendering; otherwise, it is determined that GPU rendering is supported.

[0051] The correlation between the first load data and the second load data may be analyzed by using a Pearson correlation coefficient for quantitative analysis, with the Pearson correlation coefficient being set to be high correlation when greater than 0.8 and strong correlation when greater than 0.9. Example

[0052] In this embodiment, a graphics rendering mechanism identification method based on rendering pipeline alignment provided by the present invention is adopted to realize the visual identification of the graphics rendering mechanism of the Linux system. The processing flow is as follows: Figure 1 As shown, the specific process includes:

[0053] S1. Use the glxinfo configuration query tool to verify whether the system under test supports direct rendering using the graphics card. If it does, execute S2; otherwise, end this process.

[0054] However, although glxinfo is a query tool provided by graphics card driver manufacturers, it cannot fully guarantee that the current environment supports direct rendering. In order to verify the actual status of direct rendering, it is necessary to combine it with other tests to provide a more reliable verification of direct rendering capabilities.

[0055] S2. Switch the rendering mode by setting or modifying the Linux environment variables. If the rendering mode can be switched to direct rendering using the graphics card, execute S3; otherwise, terminate this process.

[0056] In the Linux operating system, you can choose to use the central processing unit (CPU) or graphics processing unit (GPU) for graphics rendering by setting or modifying environment variables. By using the echo command, you can check the current system environment variables to verify whether GPU rendering is supported. Specifically:

[0057] Use the echo $LIBGL_ALWAYS_SOFTWARE command to determine whether OpenGL is forced to use software rendering. If the variable exists and its value is 1, it means that the system is using software rendering, which also means that hardware rendering support is not correctly configured.

[0058] Use the echo $_GLX_VEMDOR_LIBRARY_NAME command to view the vendor library used by GLX (OpenGL extension library). If the name returned is NVIDIA, AMD, or other manufacturers, it indicates that the system supports direct rendering.

[0059] By analyzing the values ​​of the above two environment variables, we can determine whether the environment supports direct rendering. However, this step cannot completely replace actual performance testing and verification. Specific benchmark programs should be executed to quantify rendering performance and further verify the rendering mechanism.

[0060] S3. Visual curve rendering verification for graphics processing.

[0061] For the implementation of visual curve rendering verification for graphics processing, a specific benchmark program is used. While providing real-time performance feedback, it also improves the reliability and scientificity of the rendering mechanism verification results through statistical analysis.

[0062] Use the sampling tool to analyze and record CPU usage in both CPU mode (software rendering) and GPU mode (hardware acceleration). Use the two sets of CPU usage data to plot curves for a visual display of the test. Also, calculate the Pearson correlation coefficient between the two sets of data to analyze the strength of the correlation and determine whether the system has effective direct rendering capabilities.

[0063] S3.2. Establish benchmark testing procedures, including built-in benchmark testing procedures and external testing procedures.

[0064] The built-in benchmark program is built using C++ language and OpenGL graphics library to implement composite rendering scenes. The processing flow is as follows: Figure 2 The composite rendering scene is centered around a 3D cube with a lighting texture. Its rendering process follows the standardized pipeline logic of "state initialization - matrix transformation - texture and lighting binding - geometry drawing".

[0065] First, the program resets the rendering state by clearing the color and depth buffers, and enables depth testing to ensure that the occlusion relationship of objects in the three-dimensional scene conforms to visual laws; at the same time, the camera state is updated in real time according to user input, driving the dynamic generation of the perspective projection matrix and the view matrix, forming the basis for the coordinate transformation from the three-dimensional world to the two-dimensional screen.

[0066] After completing the matrix system construction, the program enters the stage of binding textures and lighting parameters: the Diffuse color map and Normal map are loaded separately through the multi-channel texture interface. The former gives the basic texture color to the object surface, and the latter simulates microscopic bump details by perturbing the normal vector; in the lighting parameter configuration link, the ambient light, diffuse reflection and specular reflection components are defined based on the Phong lighting model, and the corresponding position parameters and attenuation functions are set for different types of light sources (point light sources, parallel light, spotlights). For example, point light sources need to calculate the distance attenuation coefficient, while spotlights introduce intensity interpolation within the conical illumination range.

[0067] When the rendering state and parameters are all ready, the program passes the matrix stack consisting of the model matrix, view matrix, and projection matrix to the shader program. The vertex shader completes the vertex coordinate transformation based on this matrix stack and outputs the texture coordinates and world space normal vector to the fragment shader. The fragment shader combines the texture sampling results with the lighting model to calculate the basic brightness of the ambient light, the scattering effect of diffuse reflection, and the highlight area of ​​the specular reflection on a pixel-by-pixel basis. Finally, it generates a rendering result with material texture through color mixing. Throughout the entire process, the cube surface is mapped according to the texture coordinates, and the shadow is calculated through the real-time dot product of the normal vector and the light vector, realizing the rendering of a three-dimensional scene with both texture details and lighting effects.

[0068] The external test program also meets the following requirements: it is built using C++ language and OpenGL graphics library, and includes standardized pipeline logic requirements for matrix transformation, texture lighting binding, and geometry drawing.

[0069] S3.3. Determine the target sampling interval.

[0070] When benchmarks are rendering, rendering performance is affected by a variety of factors, including rendering algorithms, resource allocation, and scene complexity. Therefore, if the sampling points in CPU mode (software rendering) and GPU mode (hardware acceleration) are inconsistent or subject to external interference, the data obtained by the sampling tool may be unrepresentative.

[0071] Therefore, the following technical strategies need to be considered and implemented when sampling test data: interference suppression, CPU core binding, and processing and confirmation of sampled data. This is to control variables and reduce interference, improve the validity and reliability of the sampling results, and thus obtain more accurate utilization data.

[0072] S3.3.1. Interference suppression.

[0073] When acquiring utilization samples, especially in rendering tests, it's crucial to suppress noise. I / O operations (such as disk reads and network transfers) can cause inaccurate CPU and GPU utilization, affecting the validity of the sampling results. By increasing the test program's priority, you can reduce the impact of non-relevant processes and obtain cleaner data.

[0074] First, before running the benchmark program, shut down unnecessary background services and processes. Then, use the nice command to increase the priority of the rendering program when starting it, for example, nice –n -20 . / benchmark program.

[0075] S3.3.2. CPU core binding.

[0076] Binding the benchmark program to a specific CPU core helps reduce context switching and improves the consistency of sampled data. This embodiment uses the taskset command to bind the benchmark program to a specific core while starting it, for example, taskset 0x3 . / benchmark program.

[0077] S3.3.3. Processing and determination of sampling data.

[0078] S3.3.3.1. Unify rendering actions.

[0079] (1) Align key stages of the rendering pipeline.

[0080] The test was pre-run 5 times independently in both CPU mode and GPU mode. The rendering pipeline was divided into different key stage intervals, including matrix calculation, texture lighting binding and shader drawing. The final key stage interval was determined by taking the intersection of the two mode intervals to ensure that the intervals taken were in the key stages of the two modes. For example, the interval of matrix calculation in CPU mode is 3-8 seconds, and the interval of matrix calculation in GPU mode is 2-5 seconds. Then the final matrix calculation sampling interval is the overlapping interval of 3-5 seconds. Similarly, the texture lighting binding interval results and shader drawing interval results are obtained, as shown in the following table:

[0081] Table 1 The first pre-sampling interval

[0082] Rendering pipeline stages CPU mode range GPU mode range Intersection interval (sampling result 1) Matrix calculations 3-8 seconds 2-5 seconds 3-5 seconds Texture Lighting Binding 1-6 seconds 3-7 seconds 3-6 seconds Shader drawing 4-9 seconds 5-10 seconds 5-9 seconds

[0083] (2) Align the sampling intervals within the key phase.

[0084] The test was pre-run 5 times independently in both CPU mode and GPU mode. The complete performance data curve was recorded and the respective stable working ranges were analyzed. Specifically, the range where the rate of change of CPU occupancy was lower than the threshold was used as the stable range. The final sampling interval was the intersection of the stable ranges of the two modes to ensure that both the CPU and GPU were in their best working states during the test. For example, the stable range of matrix calculation in CPU mode is 3-8 seconds, while that in GPU mode is 2-7 seconds. Then the final sampling interval is the overlapping range of 3-7 seconds. Similarly, the texture lighting binding interval results and the shader drawing interval results are obtained, as shown in the following table:

[0085] Table 2 The second pre-sampling interval

[0086] Rendering pipeline stages CPU stable range GPU stable range Intersection interval (sampling result 2) Matrix calculations 3-8 seconds 2-7 seconds 3-7 seconds Texture Lighting Binding 2-5 seconds 4-6 seconds 4-5 seconds Shader drawing 6-10 seconds 5-8 seconds 6-8 seconds

[0087] (3) Unify the rendering action sampling interval.

[0088] Finally, the overlapping interval of the first pre-sampling interval and the second pre-sampling interval is taken as the unified rendering action sampling interval, which is the first sampling interval, as shown in the following table:

[0089] Table 3 The first sampling interval

[0090] Rendering pipeline stages Intersection interval (sampling result 3) Matrix calculations 3-5 seconds Texture Lighting Binding 4-5 seconds Shader drawing 6-8 seconds

[0091] S3.3.3.2. Frame complexity analysis.

[0092] (1) Collect data

[0093] The test was run independently in both CPU and GPU modes. The sampling tool collected key metrics for each frame during both runs, including polygon count, texture resolution, and light type.

[0094] (2) Quantitative analysis

[0095] During the quantitative analysis phase, the collected raw data were converted into standardized complexity scores: polygon count was graded by threshold (<10k was simple, 10k-50k was medium, and >50k was complex); texture resolution was graded by threshold (<512×512 was simple, 512×2048 was medium, and >2048×2048 was complex); and light source type was graded by its computational complexity (parallel light was simple, point light was medium, and spotlight was complex).

[0096] For the same data frame, the value of each indicator is the intersection of the values ​​in CPU mode and GPU mode. Among multiple indicators, the rating of the frame data is determined by the highest rating. For example, if the rating is medium based on the number of polygons, simple based on the texture resolution, and complex based on the light source type, then the data frame is complex.

[0097] (3) Determine the sampling interval

[0098] The test was run again in both CPU and GPU modes. For simple frames, samples were taken every five frames; for medium frames, samples were taken every two frames; and for complex frames, samples were taken frame by frame. The sampling tool records the corresponding rendering time or range of the sampled frames. For example, the first sample of a simple frame corresponds to the rendering time of the fourth second, the first sample of a medium frame corresponds to the rendering time of the fifth to sixth seconds, and the rendering range of a complex frame corresponds to 8-15 seconds.

[0099] S3.3.3.3. Determination of sampling data.

[0100] The first sampling interval obtained by the unified rendering action is intersected with the second sampling interval obtained by the frame complexity analysis to obtain the final target sampling interval, as shown in the following table:

[0101] Table 4 Target sampling interval

[0102] Sampling results 3 (a, b, c) Sampling result 4 (a, b, c) Determined sampling data 3-5 seconds 2.0-5.5 seconds 3-5 seconds 4-5 seconds 3.0-5.5 seconds 4-5 seconds 6-8 seconds 6.0-8.0 seconds 6-8 seconds

[0103] S3.3.4. Establish a sampling process.

[0104] The sampling tool includes the implementation of the above three technical strategies, and improves the validity and reliability of the sampling results by controlling variables and reducing interference in many aspects, so as to obtain utilization data more accurately, such as Figure 3 shown.

[0105] S4. Visual curve rendering verification.

[0106] During the benchmark program's execution, the CPU load data for both rendering modes was recorded based on the sampling process, and the two sets of data were plotted into comparative curves using data visualization methods. From the visualized curve plotting results, it can be observed that the CPU usage in software rendering mode exhibits a continuously high load, with large fluctuations in the curve, reflecting that the CPU has to bear all the graphics computing pressure in pure software rendering scenarios, such as Figure 4 As shown; in hardware acceleration mode, the CPU usage curve moves down significantly and tends to be flat, as shown Figure 5 As shown, it shows that the GPU has successfully taken over the main graphics computing tasks and effectively achieved a reasonable distribution of computing load. The verification process is as follows Figure 6 shown.

[0107] To further verify the correlation between the two modes, we used the Pearson correlation coefficient (above 0.8 indicates a high correlation, and above 0.9 indicates a strong correlation) for quantitative analysis. The results showed a correlation coefficient of -0.0488 between the two sets of data. This statistical indicator fully demonstrates that hardware acceleration mode significantly reduces the CPU rendering burden. Based on this comprehensive analysis of the test data, we can conclude that the current environment has excellent direct rendering capabilities.

[0108] In summary, the above are only preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A graphics rendering mechanism identification method based on rendering pipeline alignment, characterized in that: The specific steps include: Step 1: For a system under test that is preliminarily determined to have a GPU mode, set rendering processing as a key stage and determine a benchmark program that includes the key stage; Step 2: pre-run the benchmark test program in CPU mode and GPU mode respectively, determine that the processing interval of the key stage in the benchmark test program is the CPU processing interval and the GPU processing interval, and the intersection of the two processing intervals is the first pre-sampling interval; Step 3: Pre-run the benchmark test program separately to obtain performance data of the system under test, and determine the stable working interval as the CPU stable working interval and the GPU stable working interval based on the performance data. The intersection of the two stable working intervals is the second pre-sampling interval; the intersection of the first pre-sampling interval and the second pre-sampling interval is the first sampling interval; Step 4: Pre-run the benchmark test program separately to obtain the graphics rendering parameters of each frame of data to determine the complexity of the data frame. The more complex the data frame, the smaller the sampling interval. Determine the respective sampling periods based on the sampling interval, and the intersection of the two sampling periods is the second sampling interval; The intersection of the first sampling interval and the second sampling interval is the target sampling interval; Step 5. During the actual test, the benchmark program is run in the two modes of the system under test respectively to obtain the CPU load data of the system under test in the two modes. The CPU load data are sampled respectively using the target sampling interval to obtain the respective load data; the correlation between the two load data is calculated. If the correlation is greater than the threshold, it is determined that the graphics rendering mechanism of the system under test does not have a GPU mode; otherwise, it is determined that a GPU mode exists.

2. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The benchmark test program includes a built-in benchmark test program and an external test program, wherein the built-in benchmark test program is used to implement a composite rendering scene, and the external test program is a test program provided by the user, including key stages and having compatibility requirements.

3. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The benchmark testing procedure consists of several key stages.

4. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The key stages are matrix calculation, texture lighting binding or shader drawing.

5. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The CPU processing interval and the GPU processing interval are both obtained by performing multiple runs to obtain multiple processing intervals, and then taking the intersection of the multiple processing intervals as the final result.

6. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The CPU processing interval and the GPU processing interval are both obtained by adding timestamps to the start and end positions of key stages in the benchmark test program.

7. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The method for preliminarily determining that the system under test has a GPU mode is to use the glxinfo configuration query tool or modify the environment variables of the system under test for determination.

8. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The complexity of the data frame is determined according to the range of the graphics rendering parameter values, and the data frame is divided into a simple frame, a medium frame or a complex frame, wherein the simple frame has the largest sampling interval and the complex frame has the smallest sampling interval.

9. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The graphics rendering parameters include polygon number, texture resolution and light source type.

10. The method for identifying a graphics rendering mechanism according to claim 1, wherein: The method of calculating the correlation between the two load data is to perform quantitative calculation using the Pearson correlation coefficient.

Images