Testing gpu methods and apparatus

Abstract

Embodiments of the present disclosure disclose a method and device for testing GPU. The specific implementation of the method comprises: selecting a target GPU resource from a pre-created GPU resource set according to a test requirement, and generating a shader program for triggering GPU exception based on the target GPU resource; sending an instruction to the GPU to execute the shader program, and obtaining a test result obtained by the GPU executing the shader program. The implementation can comprehensively cover various boundary conditions and error use scenarios, including illegal behaviors not defined in the specification document, and effectively detect the behavior of the GPU under abnormal conditions.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer technology, and more specifically to methods and apparatus for testing GPUs. Background Technology

[0002] Modern GPU architectures contain sophisticated texture processing units to handle various types of texture resources, including 1D, 2D, and 3D textures, texture arrays, and multisampled textures. Texture processing involves complex memory access patterns, resource format conversions, sampling operations, and atomic operations. To ensure the stability and security of the GPU, comprehensive testing of the texture processing units is necessary.

[0003] In the field of GPU testing, functional testing is typically used to verify whether the basic functions of the texture processing unit are correct, such as whether operations like texture sampling, filtering, and addressing meet expectations. In addition, there are tests targeting specific hardware characteristics, such as performance testing and compatibility testing. Summary of the Invention

[0004] Embodiments of this disclosure present methods and apparatus for testing GPUs.

[0005] In a first aspect, embodiments of this disclosure provide a method for testing a GPU, comprising: selecting a target GPU resource from a pre-created set of GPU resources according to test requirements, and generating a shader program for triggering GPU anomalies based on the target GPU resource; sending an instruction to the GPU to execute the shader program, and obtaining test results obtained by the GPU executing the shader program.

[0006] In some embodiments, a target GPU resource is selected from a pre-created set of GPU resources according to test requirements, and a shader program for triggering GPU anomalies is generated based on the target GPU resource, including: selecting a target GPU resource from the set of GPU resources with pre-set boundary conditions, wherein the boundary conditions include legal range thresholds of the GPU resource; and generating a shader program for triggering GPU out-of-bounds access based on the boundary conditions.

[0007] In some embodiments, the target GPU resource includes at least one of a raw buffer and a typed buffer; and generating a shader program for triggering GPU out-of-bounds access based on boundary conditions includes: generating a shader program for triggering out-of-bounds access to the raw buffer and / or the typed buffer based on a first code template, wherein the first code template is a preset standardized code framework, and the first code is used to automatically generate a shader program for triggering out-of-bounds access to the raw buffer and / or the typed buffer.

[0008] In some embodiments, the target GPU resource includes at least one of the following texture resources: 2D texture, 1D texture, 3D texture, cube map; and a shader program for triggering GPU out-of-bounds access is generated based on boundary conditions, including: generating a shader program for triggering texture image coordinate out-of-bounds access of the target GPU resource based on a preset second code template, wherein the second code template is a preset standardized code framework, and the second code template is used to automatically generate a shader program for triggering texture image coordinate out-of-bounds access.

[0009] In some embodiments, the target GPU resource includes a GPU resource that supports atomic operations; and a shader program for triggering GPU out-of-bounds access is generated based on boundary conditions, including: generating a shader program for triggering the target GPU resource to perform atomic operations under concurrent access and / or boundary address conditions based on a preset atomic operation test template, wherein the third code template is a preset standardized code framework, and the third code template is used to automatically generate shader programs that trigger abnormal behavior of GPU atomic operations.

[0010] In some embodiments, a target GPU resource is selected from a pre-created GPU resource set according to testing requirements, and a shader program for triggering GPU anomalies is generated based on the target GPU resource, including: selecting a target GPU resource with predetermined attributes from the GPU resource set, wherein the predetermined attributes include at least one of the following: texture dimension, resource view type, number of samples, number of multi-level asymptotic texture Mip-Map layers, and resource format; and generating a shader program for triggering a mismatch between the usage of the target GPU resource and the predetermined attributes.

[0011] In some embodiments, the target GPU resource includes texture resources of at least two texture dimensions; and generating a shader program to trigger a mismatch between the usage of the target GPU resource and predetermined attributes includes: generating a shader program to trigger the mixed use of texture resources of at least two texture dimensions based on a preset fourth code template, wherein the fourth code template is a preset standardized code framework, and the fourth code template is used to automatically generate a shader program that triggers an anomaly in the mixed use of texture resources of different dimensions.

[0012] In some embodiments, generating a shader program to trigger a mismatch between the usage of a target GPU resource and a predetermined attribute includes: generating a shader program to trigger a mismatch between the resource view type and the actual resource type of the target GPU resource based on a preset fifth code template, wherein the fifth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios where the resource view type and the actual resource type are inconsistent.

[0013] In some embodiments, the target GPU resource includes a GPU resource with a preset baseline sampling number set; and a shader program for generating a shader program to trigger a mismatch between the usage of the target GPU resource and a predetermined attribute includes: generating a shader program based on a preset sixth code template to trigger a mismatch between the preset baseline sampling number and the actual sampling number of the target GPU resource, wherein the sixth code template is a preset standardized code framework, and the sixth code template is used to automatically generate a shader program that triggers an error scenario of mismatch between the sampling number of multisampled textures.

[0014] In some embodiments, the target GPU resource includes a GPU resource with a predetermined number of Mip-Map levels set; and generating a shader program to trigger a mismatch between the usage of the target GPU resource and a predetermined attribute, including: generating a shader program to trigger access to a Mip-Map level that does not exist in the target GPU resource based on a preset seventh code template, wherein the seventh code template is a preset standardized code framework, and the seventh code template is used to automatically generate a shader program that triggers illegal Mip-Map level access.

[0015] In some embodiments, generating a shader program to trigger a mismatch between the usage of a target GPU resource and a predetermined attribute includes: generating a shader program based on a preset eighth code template to trigger a resource format conversion request for the target GPU resource that is incompatible with a predetermined resource format. The eighth code template is a preset standardized code framework, and the eighth code template is used to automatically generate shader programs that trigger error scenarios that trigger resource format incompatibility conversion.

[0016] In some embodiments, generating a shader program to trigger a mismatch between the usage of a target GPU resource and a predetermined attribute includes: generating a shader program to trigger a mismatch between the declared attribute and the attribute actually used by the shader, based on a preset ninth code template, wherein the ninth code template is a preset standardized code framework, and the ninth code template is used to automatically generate a shader program to trigger an error scenario where the declared resource attribute is inconsistent with the actual usage attribute.

[0017] In some embodiments, the method further includes: comparing and analyzing the test results with the expected results to identify abnormal results; and generating a test report based on the abnormal results.

[0018] Secondly, embodiments of this disclosure provide an apparatus for testing a GPU, comprising: a generation unit configured to select a target GPU resource from a pre-created set of GPU resources according to test requirements, and generate a shader program for triggering GPU anomalies based on the target GPU resource; and a testing unit configured to send instructions to the GPU to execute the shader program, and obtain test results obtained by the GPU executing the shader program.

[0019] In some embodiments, the generation unit is further configured to: select a target GPU resource with pre-set boundary conditions from a pre-created set of GPU resources, wherein the boundary conditions include legal range thresholds of the GPU resource; and generate a shader program based on the boundary conditions to trigger GPU out-of-bounds access.

[0020] In some embodiments, the target GPU resource includes at least one of a raw buffer and a typed buffer; and the generation unit is further configured to: generate a shader program for triggering out-of-bounds access to the raw buffer and / or the typed buffer based on a preset first code template, wherein the first code template is a preset standardized code framework, and the first code template block is for automatically generating shader programs that trigger out-of-bounds access to the raw buffer and / or the typed buffer.

[0021] In some embodiments, the target GPU resource includes at least one of the following texture resources: 2D texture, 1D texture, 3D texture, cube map; and the generation unit is further configured to: generate a shader program for triggering out-of-bounds access to texture image coordinates of the target GPU resource based on a preset second code template, wherein the second code template is a preset standardized code framework, and the second code template is used to automatically generate a shader program for triggering out-of-bounds access to texture image coordinates.

[0022] In some embodiments, the target GPU resource includes GPU resources that support atomic operations; and the generation unit is further configured to: generate a shader program based on a preset third code template to trigger the target GPU resource to perform atomic operations under concurrent access and / or boundary address conditions, wherein the third code template is a preset standardized code framework, and the third code template is used to automatically generate shader programs that trigger abnormal behavior of GPU atomic operations.

[0023] In some embodiments, the generation unit is further configured to: select a target GPU resource with predetermined attributes from a pre-created set of GPU resources, wherein the predetermined attributes include at least one of the following: texture dimension, resource view type, number of samples, number of multi-level asymptotic texture Mip-Map layers, and resource format; and generate a shader program to trigger a mismatch between the usage of the target GPU resource and the predetermined attributes.

[0024] In some embodiments, the target GPU resources include texture resources of at least two texture dimensions; and the generation unit is further configured to: generate a shader program for triggering the mixed use of texture resources of at least two texture dimensions based on a preset fourth code template, wherein the fourth code template is a preset standardized code framework, and the fourth code template is used to automatically generate shader programs that trigger anomalies in the mixed use of texture resources of different dimensions.

[0025] In some embodiments, the generation unit is further configured to: generate a shader program based on a preset fifth code template to trigger a mismatch between the target shader resource view type and the actual resource type of the target GPU resource, wherein the fifth code template is a preset standardized code framework and is used to automatically generate a shader program that triggers an error scenario where the resource view type is inconsistent with the actual resource type.

[0026] In some embodiments, the predetermined attributes include: sample count, the target GPU resource includes a GPU resource with a baseline sample count set; and the generation unit is further configured to: generate a shader program based on a preset sixth code template to trigger a mismatch between the preset baseline sample count and the actual sample count of the target GPU resource, wherein the sixth code template is a preset standardized code framework, and the sixth code template is used to automatically generate a shader program that triggers an error scenario of mismatch between the sample counts of multisampled textures.

[0027] In some embodiments, the target GPU resource includes GPU resources with a set number of Mip-Map levels; and the generation unit is further configured to: generate a shader program for triggering access to Mip-Map levels that do not exist in the target GPU resource based on a preset seventh code template, wherein the seventh code template is a preset standardized code framework, and the seventh code template is used to automatically generate shader programs that trigger illegal Mip-Map level access.

[0028] In some embodiments, the generation unit is further configured to: generate a shader program based on a preset eighth code template to trigger a resource format conversion request for the target GPU resource that is incompatible with a predetermined resource format, wherein the eighth code template is a preset standardized code framework and the eighth code template is used to automatically generate a shader program that triggers an error scenario of incompatible resource format conversion.

[0029] In some embodiments, the generation unit is further configured to: generate a shader program that triggers a mismatch between the declared attributes and the attributes actually used by the shader, based on a preset ninth code template, wherein the ninth code template is a preset standardized code framework, and the ninth code template is used to automatically generate a shader program that triggers an error scenario where the declared resource attributes are inconsistent with the actual used attributes.

[0030] In some embodiments, the apparatus further includes a determining unit configured to: compare and analyze test results with expected results to determine abnormal results; and generate a test report based on the abnormal results.

[0031] Thirdly, embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more computer programs stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform the method as described in any one of the first or second aspects.

[0032] Fourthly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method as described in any one of the first or second aspects.

[0033] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, implements the method as described in any one of the first or second aspects.

[0034] The GPU testing method and apparatus provided in the embodiments of this disclosure select target resources from a preset GPU resource set and generate an exception trigger shader program, and then execute instructions to obtain test results. This can accurately and efficiently trigger GPU exceptions and collect test data, comprehensively cover GPU exception usage scenarios, stably reproduce exception test cases, clearly reflect the behavior of the GPU under abnormal conditions, effectively improve the completeness, repeatability and detection efficiency of GPU robustness testing, and ensure the stability of GPU operation.

[0035] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0036] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture diagram to which one embodiment of this disclosure can be applied; Figure 2 This is a flowchart of one embodiment of a method for testing GPUs according to this disclosure; Figure 3 This is a flowchart of yet another embodiment of the GPU testing method according to this disclosure; Figure 4This is a schematic diagram of the structure of one embodiment of a test GPU device according to the present disclosure; Figure 5 This is a schematic diagram of the structure of a computer system suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0037] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0038] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0039] Figure 1 An exemplary system architecture is shown that can be applied to embodiments of the GPU testing methods or GPU testing devices disclosed herein.

[0040] like Figure 1 As shown, the system architecture may include a test management layer 110, a test execution engine 120, and a result analysis module 130.

[0041] The test management layer 110 includes a test resource management module 111 and a shader program generation module 112. The test resource management module 111 is responsible for creating and managing various types of texture resources, including 1D, 2D, and 3D textures, texture arrays, buffers, etc., and setting precise boundary conditions. The shader program generation module 112 generates shader programs to trigger specific boundary conditions and error usage scenarios.

[0042] Test Execution Engine 120: Responsible for executing test cases, monitoring GPU behavior, and capturing exceptions and errors.

[0043] The results analysis module 130 includes a results collector 131, an anomaly detector 132, and a report generator 133. First, the results collector 131 comprehensively collects debugging logs, resource access results, device operating status, and test metadata during the GPU testing process, performing deduplication, standardization, and correlation preprocessing. Then, the anomaly detector 132 filters out valid anomalies from the preprocessed data, eliminating meaningless noise. Finally, the report generator 133 calls a preset template, integrates the anomaly data and test metadata, and visualizes and renders data such as device status and anomaly percentage into a structured report containing a test overview, environmental information, detailed anomaly analysis, statistical charts, and conclusions and recommendations, providing reproducible experimental evidence for GPU fault tolerance analysis and patent writing.

[0044] Test Execution Engine 120 includes the following core test modules: 1. Boundary Access Test Module 121: Test for out-of-bounds access to the original buffer; Test for out-of-bounds access to a typed buffer; Verify the GPU's behavior when accessing texture data beyond its allocated boundaries.

[0045] 2. Image boundary test module 122: Test for out-of-bounds texture image coordinates; Verify the correct handling mechanism when coordinates exceed limits; 3. Dimensional Texture Test Module 123: Test the use of different textures in combination; Verify correct addressing and boundary checks for cross-dimensional types; 4. Resource View Figure 1 Consistency testing module 124: Test the situation where the shader resource view type is inconsistent with the actual resource type.

[0046] 5. MSAA (Multisample Anti-Aliasing) Mismatch Test Module 125: Test for mismatch in the number of samples used in multisampling antialiasing; Verify the handling mechanism when the number of samples in multisampling antialiasing is mismatched.

[0047] 6. Mip-Map test module 126: Test Mip-Map level access control; Verify the behavior when accessing a non-existent Mip-Map level.

[0048] 7. Atomic Operation Test Module 127: Test the performance of atomic operations under boundary conditions; Verify the correctness of atomic operations under concurrent access and boundary address conditions.

[0049] 8. Format Conversion Test Module 128: Test format conversion robustness; Securely handle requests with incompatible formats.

[0050] 9. Declaring and using the conformance test module 129: Test for discrepancies between the declared and actual usage of test resources; Verify the behavior of resources when they are declared in one way but used in another way in a shader.

[0051] Continue to refer to Figure 2The diagram illustrates a flow 200 of an embodiment of a GPU testing method according to this disclosure. The GPU testing method includes the following steps: Step 201: Select a target GPU resource from a pre-created set of GPU resources according to the test requirements, and generate a shader program to trigger GPU exceptions based on the target GPU resource.

[0052] In this embodiment, testing requirements can be divided into two main categories: boundary testing and error application scenario testing. For each type of test, all applicable GPU resources are traversed as target GPU resources, and shader programs to trigger GPU anomalies can be generated using preset templates or large language models.

[0053] Before testing, a GPU resource set can be pre-created for subsequent testing. The process of creating a GPU resource set is as follows: Initialize the GPU basic environment (device, memory heap, descriptor heap), and then create multiple types of GPU resources, including textures and buffers, to form the GPU resource set. Examples include 1D, 2D, and 3D textures, texture arrays, buffers, etc., and set precise boundary conditions. "Boundary conditions" refer to the "legal range thresholds of texture resources (such as coordinate out-of-bounds or Mip-level out-of-bounds)."

[0054] For example, a 2D depth texture is selected from the GPU resource set as the target GPU resource. Its inherent texture dimension is 2D, which creates a texture dimension mismatch with the subsequent 3D texture SRV (ShaderResourceView). An instruction can be automatically generated based on test requirements using a preset template: "Generate a pixel shader to trigger a GPU exception due to the dimension mismatch between the 2D texture and the 3D texture SRV, including texture sampling logic." This instruction and the target GPU resource are then input into a large language model, which generates the shader program.

[0055] Step 202: Send an instruction to the GPU to execute the shader program and obtain the test results obtained by the GPU executing the shader program.

[0056] In this embodiment, the shader program is converted from source code to cross-platform code using the graphics API's compiler. Then, the GPU manufacturer drives its built-in compiler to perform architectural optimization and progressive conversion, ultimately generating hardware machine code instructions that the GPU's computing unit can directly recognize and execute. These instructions are then sent to the GPU, which executes them to obtain the test results.

[0057] Test results can be obtained from multiple dimensions, such as: 1. GPU debug log results: Error code DXGI_ERROR_INVALID_RESOURCE was captured, and the log indicated "SRV view dimension does not match the actual resource dimension", clarifying the cause of the exception; 2. Resource access results: Shader sampling returns all 0 values ​​(GPU fault tolerance mechanism triggered), with no garbled data output; 3. GPU device status results: stable memory usage (no leakage), normal GPU core load, and no device hangs or program crashes.

[0058] Meanwhile, you can change the test requirements (such as boundary testing) and repeat steps 202-203 to obtain test results for various test requirements.

[0059] The method provided in the above embodiments of this disclosure can achieve the following technical effects: 1. Comprehensive boundary condition coverage: Through a specially designed test module, it can systematically cover boundary conditions and out-of-bounds access scenarios for various texture types.

[0060] 2. Enhanced error detection capability: It can effectively detect the behavior of the texture processing unit when faced with incorrect usage patterns, thereby improving system security.

[0061] 3. Systematic anomaly handling verification: Comprehensive verification of the handling mechanisms for anomalies such as format conversion, resource view inconsistency, and atomic operations.

[0062] 4. Improve GPU system stability: Improve the overall stability and reliability of the GPU system by early detection and fix of robustness issues.

[0063] In some optional implementations of this embodiment, a target GPU resource is selected from a pre-created GPU resource set according to the test requirements, and a shader program for triggering GPU exceptions is generated based on the target GPU resource. This includes: selecting a target GPU resource with pre-set boundary conditions from the GPU resource set, wherein the boundary conditions include the legal range threshold of the GPU resource; and generating a shader program for triggering GPU out-of-bounds access based on the boundary conditions.

[0064] "Boundary conditions" refer to "the legal range threshold of texture resources (such as coordinate out-of-bounds or Mip-level out-of-bounds)". These are target GPU resource types with predetermined boundary conditions suitable for boundary testing. The boundary conditions of these resources are fixed at creation time, clearly defined, and reproducible in out-of-bounds scenarios. They are primarily divided into two categories: buffer types and texture types.

[0065] I. Buffer-type GPU resources (linear data organization, clear boundaries, high-frequency test objects)

[0066] The boundaries of these resources are based on "linear indexes / byte offsets," making out-of-bounds scenarios easy to construct and verify. 1. Structured Buffer Predefined boundary conditions: Valid element index range [0, total number of elements - 1] (e.g., if 1024 elements are created, the boundary is 0~1023), and the out-of-bounds boundary is ≥ the total number of elements; additionally, "structure member alignment boundary" can be included (e.g., if the structure is aligned to 16 bytes, accessing an unaligned offset is out of bounds).

[0067] Test value: The most commonly used index out-of-bounds test object, which can trigger write / read out-of-bounds exceptions.

[0068] 2. Typed buffers

[0069] Predefined boundary conditions: Two-layer boundary - ① Valid element index range [0, total number of elements - 1] (e.g., UINT4 type buffer, 1024 elements correspond to 0~1023); ② Valid component range of a single element [0, number of components - 1] (e.g., UINT4 only supports 0~3 components, accessing the 4th component is out of bounds).

[0070] Test value: It can simultaneously verify two scenarios: "element index out of bounds" and "data component out of bounds".

[0071] 3. Byte address buffer

[0072] Predefined boundary conditions: Two layers of boundaries — ① Effective byte offset range [0, total number of bytes in the buffer - 1] (e.g., 0~1023 for a 1024-byte buffer); ② Hardware alignment boundary (e.g., if 4-byte / 8-byte alignment is required, accessing an unaligned offset is considered out of bounds).

[0073] Test value: Verify byte-level fine-grained out-of-bounds scenarios, closely aligning with underlying data access testing.

[0074] 4. Vertex / Index Buffer

[0075] Predetermined boundary conditions: ① Vertex buffer: valid vertex index range [0, total number of vertices - 1]; ② Index buffer: valid index value range [0, total number of vertices - 1] (index value exceeding the vertex range is considered indirect out-of-bounds), valid index array index [0, total number of indices - 1].

[0076] Test value: To verify the boundary tolerance of the graphics rendering pipeline and closely resemble real-world rendering scenarios.

[0077] II. Texture-based GPU resources (structured image organization, multi-dimensional boundaries, covering complex scenes)

[0078] The boundaries of these resources have multi-dimensional characteristics, allowing for the construction of various boundary-crossing scenarios such as "coordinates / hierarchy / index": 1. 2D / 3D textures (including multi-level asymptotic mipmaps) Predefined boundary conditions (multi-dimensional): ① Resolution boundary: 2D texture [0, width-1]×[0, height-1], 3D texture adds [0, depth-1] (e.g., for a 1024×1024 2D texture, accessing x=1024 or y=1024 is out of bounds); ② Mip level boundary: effective level range [0, total Mip level-1] (e.g., level 3 Mip corresponds to 0~2, accessing level 3 is out of bounds).

[0079] Test value: High-frequency texture out-of-bounds test object, which can verify "texture coordinate out-of-bounds" and "Mip level out-of-bounds".

[0080] 2. Texture array (2D / 3D / cube texture array)

[0081] Predefined boundary conditions (3D boundary): ① Single texture resolution boundary (same as ordinary 2D / 3D texture); ② Array index boundary: effective array layer range [0, total array layer - 1] (e.g., 16-layer texture array corresponds to 0~15, accessing layer 16 is out of bounds); ③ Mip layer boundary (same as ordinary texture).

[0082] Test value: Verify array index out-of-bounds errors in multi-texture batch management scenarios, and cover complex texture resource testing.

[0083] 3. Multisampling Alignment (MSAA) Texture

[0084] Predefined boundary conditions: ① Base resolution boundary (same as ordinary 2D texture); ② Sampling point index boundary: effective sampling point range [0, number of samples - 1] (e.g., 4XMSAA corresponds to 0~3, accessing sampling point 4 is out of bounds).

[0085] Test value: Verify the scenario of MSAA texture-specific sampling points exceeding the limit, and test the fit of anti-aliasing rendering.

[0086] 4. Cube Map Texture

[0087] Predefined boundary conditions: ① Single-face resolution boundary (same as 2D texture); ② Cube face index boundary: effective face range [0,5] (corresponding to the 6 faces up, down, left, right, front, and back; accessing face 6 is considered out of bounds); ③ Mip level boundary (same as normal texture).

[0088] Test value: Verify scenarios such as face index out-of-bounds errors of cube maps and scene matching with environment maps.

[0089] Based on predetermined boundary conditions, shader programs are generated using pre-defined templates or large language models to trigger out-of-bounds access by the GPU. For example, a structured buffer UAV (Unordered Access View) is created for the target GPU resource to ensure that the shader can access element indices. Based on predetermined boundary conditions of the target GPU resource (e.g., valid index ≤ 1023), logic for accessing index 1024 (out-of-bounds boundary) is deliberately written to generate the shader program.

[0090] Boundary conditions are the most vulnerable and least covered areas for GPU anomalies. Constructing out-of-bounds access directly using legal critical points can accurately target boundary vulnerabilities. Execution based on preset resources ensures test reproducibility and comparability. It can accurately trigger GPU resource boundary out-of-bounds anomalies, focusing on legal critical point scenarios, significantly improving the targeting and effectiveness of GPU boundary robustness detection, and ensuring GPU stability and no crashes during critical access.

[0091] In some optional implementations of this embodiment, the target GPU resource includes at least one of a raw buffer and a typed buffer; and the generation of a shader program to trigger GPU out-of-bounds access based on boundary conditions includes: generating a shader program to trigger target GPU out-of-bounds access based on a preset first code template, wherein the first code template is a preset standardized code framework, and the first code template block is for automatically generating shader programs to trigger out-of-bounds access to the raw buffer and / or the typed buffer. The specific steps are as follows: Step 1: Select the target GPU resources (raw buffers and typed buffers) that meet the buffer boundary conditions from the GPU resource set created by the test resource management module.

[0092] In one example, an original buffer with a size of 1024 bytes is selected, and the predetermined boundary conditions are "effective byte offset range [0, 1023], out-of-bounds boundary is ≥ 1024 bytes", and the byte-level boundary properties of the buffer are solidified. In one example, a typed buffer of UINT4 data type (16 bytes per element) is selected, with a total of 64 elements and a total size of 1024 bytes. The predetermined boundary condition is "valid element index range [0,63], out-of-bounds boundary is ≥64 index", which solidifies the element-level boundary properties of the typed buffer. At the same time, both types of buffers are marked as "allowing out-of-order access" to prepare for subsequent shader reads and writes.

[0093] Step 2: The shader program generation module generates shader code to trigger out-of-bounds access to the target GPU based on a preset first code template.

[0094] Load the preset first code template: This template contains a fixed structure (resource binding declaration, out-of-bounds access logic framework, result write-back specification), buffer access syntax template, out-of-bounds parameter configuration interface, and supports one-click replacement of out-of-bounds boundary values; In one example, based on the "byte address access" sub-template of the template, the out-of-bounds parameter is configured as "1025 bytes", generating shader code to implement the write operation to the 1025th byte of the original buffer.

[0095] Step 3: The test execution engine executes the test case and monitors the GPU's response to this out-of-bounds access.

[0096] Bind the two types of buffer resources and the corresponding out-of-bounds shader code into a complete test case, configure the GPU execution parameters, initialize the computation command queue, submit the test case to the GPU, trigger shader execution, and complete the out-of-bounds access.

[0097] Monitor GPU responses in real time. For example, enable the GPU debug layer to monitor three types of core response data (out-of-bounds error codes, resource access validity, and GPU device running status) and record real-time data snapshots when out-of-bounds events occur.

[0098] Step 4: The results analysis module records how the system handles this type of out-of-bounds access and generates a report.

[0099] Record the handling results of out-of-bounds events in the original buffer and the typed buffer respectively; compare the differences in the handling of out-of-bounds events in the two types of buffers (differences in the verification logic between byte-level and element-level out-of-bounds events); based on the preset report template, integrate monitoring data, processing results, and difference analysis to generate a structured test report and mark the fault tolerance conclusions of the buffer boundary test.

[0100] Raw buffers and typed buffers are frequently accessed linear resources by the GPU, posing a high risk of out-of-bounds access. A standardized first-order code template is used to generate out-of-bounds logic in batches and uniformly. Templated generation reduces writing costs and ensures test case consistency. It automates and standardizes testing for out-of-bounds access to raw and typed buffers, improving the coverage, consistency, and efficiency of buffer boundary anomaly detection, and stably reproducing linear memory out-of-bounds scenarios.

[0101] In some optional implementations of this embodiment, the target GPU resource includes at least one of the following texture resources: 2D texture, 1D texture, 3D texture, cube map; and a shader program for triggering GPU out-of-bounds access is generated based on boundary conditions, including: generating a shader program for triggering texture image coordinate out-of-bounds access of the target GPU resource based on a preset second code template, wherein the second code template is a preset standardized code framework, and the second code template is used to automatically generate a shader program for triggering texture image coordinate out-of-bounds access.

[0102] Step 1: Select the target GPU resource (covering multiple texture types) that meets the image boundary conditions from the GPU resource set created by the test resource management module.

[0103] For example, with a resolution of 1024×1024, a format of RGBA8_UNORM, and a predefined boundary condition of "effective texture coordinate range [0.0,1.0]×[0.0,1.0] (corresponding to physical pixels 0~1023×0~1023), and the boundary is any coordinate dimension <0.0 or >1.0", the two-dimensional coordinate boundary attribute of the 2D texture is fixed. Step 2: The shader program generation module generates shader code based on a preset second code template to trigger out-of-bounds access to the target GPU resource texture image coordinates.

[0104] This template includes a fixed structure (texture resource binding declaration, texture sampling logic framework, out-of-bounds coordinate configuration interface, result write-back specification), sampling syntax sub-templates for different texture types, and out-of-bounds coordinate parameterization configuration items, supporting one-click replacement of texture type and out-of-bounds coordinate values; In one example, based on the "2D texture sampling" sub-template of the template, the out-of-bounds coordinates are configured as "(1.0,1.1)" (y-axis is out of the valid range), and shader code is generated to implement the sampling operation of the out-of-bounds coordinates of the 2D texture; Step 3: The test execution engine executes the test case and monitors the GPU's response to this out-of-bounds access.

[0105] The four texture resources and their corresponding out-of-bounds shader code are bound to independent test cases, and the GPU execution parameters (sampler state, pipeline binding rules) are configured uniformly. The graphics command queue is initialized, and each test case is submitted to the GPU in sequence to trigger shader execution and complete the coordinate out-of-bounds sampling operation of various textures. Real-time monitoring of GPU response, for example, enabling the GPU debugging layer to monitor three types of core response data (texture out-of-bounds error codes, sampling result validity, and GPU device running status), and recording real-time data snapshots when each texture out-of-bounds error occurs to avoid data confusion between different use cases.

[0106] Step 4: The results analysis module records how the system handles this type of out-of-bounds access and generates a report.

[0107] Record the processing results for four types of texture coordinate out-of-bounds errors respectively (① Error log: capture warning; ② Sampling result: out-of-bounds coordinate sampling returns the GPU's default fault tolerance value (such as edge pixel value, all 0 value), with no invalid garbled output; ③ Device status: stable memory usage, no crash or memory leak, and normal pipeline execution process). Compare the differences in out-of-bounds handling for different texture types (1D / 2D / 3D / cube maps) (e.g., the differences in vector magnitude verification for cube maps and coordinate range verification logic for ordinary textures). Based on a preset report template, the system integrates monitoring data, processing results, and difference analysis to generate a structured image boundary test report. It also marks the fault tolerance conclusions of various texture coordinate out-of-bounds tests and clarifies the GPU's ability to verify image boundaries.

[0108] Textures are core processing objects of the GPU, and their multi-dimensional coordinates are prone to going out of bounds. The second code template uniformly constructs coordinate out-of-bounds tests for different texture types. It can batch-cover out-of-bounds sampling for various texture dimensions. It automatically covers multi-dimensional texture coordinate out-of-bounds testing, comprehensively detecting the fault tolerance capability of texture processing units when image coordinates go out of bounds, improving the completeness and reproducibility of texture anomaly testing.

[0109] In some optional implementations of this embodiment, the target GPU resource includes a GPU resource that supports atomic operations; and a shader program for triggering GPU out-of-bounds access is generated based on boundary conditions, including: generating a shader program for triggering the target GPU resource to perform atomic operations under concurrent access and / or boundary address conditions based on a preset third code template, wherein the third code template is a preset standardized code framework, and the third code template is used to automatically generate shader programs that trigger abnormal behavior of GPU atomic operations.

[0110] Step 1: Select the target GPU resource (supporting atomic operations) that meets the boundary conditions of atomic operations from the GPU resource set created by the test resource management module.

[0111] For example, structured buffers and byte address buffers. Both types of buffers are marked as "allow out-of-order access" to enable atomic operation support, preparing for subsequent concurrent atomic operations.

[0112] Step 2: The shader program generation module generates shader code based on a preset third code template to trigger an atomic operation exception on the target GPU resources.

[0113] Load the preset third code template: This template contains a fixed structure (resource binding declarations that support atomic operations, atomic operation syntax framework, concurrent thread configuration interface, boundary address configuration items, and result write-back specifications), and includes commonly used atomic operation sub-templates such as Inter_locked_Add (atomic addition) and Inter_locked_Exchange (atomic exchange). It supports one-click configuration of the number of concurrent threads and boundary address parameters. In one example, atomic operation code is generated for a structured buffer: ① Based on the template "Concurrent Access to Critical Boundary" sub-template, the number of concurrent threads is configured to be 1024, the target element index is 1023 (critical boundary), and shader code is generated to implement multi-threaded concurrent execution of the Inter_locked_Add atomic addition operation on the critical boundary element; ② Based on the template "Boundary Address Out of Boundary" sub-template, the target element index is configured to be 1024 (out-of-bounds address), and shader code is generated to implement the Inter_locked_Exchange atomic swap operation on the out-of-bounds address; Step 3: The test execution engine executes the test case and monitors the GPU's response to this atomic operation boundary access.

[0114] Two types of buffers supporting atomic operations and their corresponding four sets of atomic operation shader code are bound to independent test cases, with unified GPU execution parameters (thread group size, atomic operation memory model). Execution instructions are submitted: the computation command queue is initialized, and each test case is submitted to the GPU sequentially, triggering concurrent execution of the computation shaders to complete all test scenarios for critical boundary concurrent atomic operations and boundary address out-of-bounds atomic operations. Real-time monitoring of GPU response, for example, enabling the GPU debugging layer and vendor performance analysis tools to monitor four types of core response data (atomic operation out-of-bounds error codes, atomic operation result validity, concurrent access race condition handling, and GPU device running status), and recording real-time data snapshots and thread execution timing when each atomic operation boundary scenario occurs.

[0115] Step 4: The results analysis module records how the system handles boundary accesses of this type of atomic operation and generates a report.

[0116] The processing results for four types of atomic operation boundary scenarios are recorded respectively (① Error log: capture and warning; ② Operation result: concurrent atomic operations at critical boundaries are executed in an orderly manner (guaranteed by GPU built-in atomic lock), and the results are accurate without data corruption; atomic operations that exceed the boundary address are invalid, with no data modification and memory pollution; ③ Device status: stable memory usage, no crashes or memory leaks, no deadlocks in concurrent thread execution, and normal pipeline process).

[0117] Compare the differences in processing logic between "concurrent access to critical boundaries" and "boundary address out-of-bounds access", and compare the priority differences in atomic operation boundary verification between structured buffers and byte address buffers.

[0118] Based on a preset report template, monitoring data, operation results, and difference analysis are integrated to generate a structured atomic operation boundary test report. The report marks the boundary fault tolerance and concurrent processing capabilities of various resources that support atomic operations, and clarifies the GPU's verification and guarantee mechanism for atomic operation boundaries.

[0119] Concurrency combined with boundary addresses is the most dangerous combination for atomic operations, easily leading to data corruption and deadlocks. The third template specifically constructs atomic operations for critical boundaries and out-of-bounds addresses. It can stably reproduce race conditions and illegal atomic behaviors at boundaries. It effectively verifies the robustness of GPU atomic operations under concurrent access and boundary addresses, avoiding data races, memory pollution, and device hangs, thus improving GPU stability in high-concurrency and abnormal scenarios.

[0120] In some optional implementations of this embodiment, a target GPU resource is selected from a pre-created GPU resource set according to the test requirements, and a shader program for triggering GPU anomalies is generated based on the target GPU resource. This includes: selecting a target GPU resource with predetermined attributes from the GPU resource set; and generating a shader program for triggering a mismatch between the usage of the target GPU resource and the predetermined attributes. The predetermined attributes include at least one of the following: texture dimension, resource view type, number of samples, number of multi-level asymptotic texture Mip-Map layers, and resource format.

[0121] Step 1: Select a GPU resource set with clearly defined predefined attributes from the GPU resource set created by the test resource management module (for testing erroneous usage scenarios).

[0122] For example, 2D texture resources with the predefined attribute "read-only", structured buffers with the predefined attribute "supports only atomic operations of integer types", etc.

[0123] Step 2: The shader generation module generates shader programs to trigger mismatches between GPU resource usage and predetermined attributes.

[0124] GPU resource loading error usage scenario test template: This template contains a fixed structure (resource binding declaration, error usage logic framework, mismatch scenario configuration interface), a library of correspondences between various resource predefined attributes and error usage methods, and supports the targeted construction of mismatch scenarios.

[0125] In one example, mismatched shader code is generated for a "read-only 2D texture": the predefined property is "read-only", the incorrect usage is constructed as "attempt to write modified texture pixels", the shader code is generated, and after binding the texture SRV, it attempts to write pixel values ​​via RWTexture2D syntax (which conflicts with the read-only property).

[0126] Step 3: The test execution engine executes the test cases for the error use case and monitors the GPU's response to this exception.

[0127] Each of the three types of GPU resources and their corresponding mismatched shader code is bound to an independent test case for an incorrect usage scenario, with unified GPU execution parameters (pipeline status, resource binding rules). The graphics / computation command queue is initialized, and each test case is submitted to the GPU in sequence to trigger shader execution and complete the incorrect usage operations of each type of resource.

[0128] Monitor GPU response in real time. For example, enable the GPU debugging layer and vendor performance analysis tools to monitor three types of core response data (attribute mismatch error codes, validity of erroneous operation execution, and GPU device running status). Record real-time data snapshots and pipeline execution logs when each error usage scenario occurs to avoid data confusion between different use cases.

[0129] Step 4: The results analysis module records how the system handles such error scenarios and generates a report.

[0130] The processing results for three types of resource usage errors are recorded respectively: (① Error log: capture specific error warnings such as (read-only resource write violation), (atomic operation type mismatch), (sampling mode mismatch); (② Operation result: all operations that do not match the predetermined attributes are invalid, there is no data modification, no memory pollution, and the GPU returns the default invalid value; (③ Device status: stable memory usage, no program crash, no memory leak, pipeline execution flow normally interrupts the error operation, and does not affect other normal logic).

[0131] Compare the differences in handling logic for different types of resources (textures / buffers) in error usage scenarios, and compare the differences in error priority and interception mechanisms for "access permission mismatch", "operation type mismatch", and "sampling mode mismatch".

[0132] Based on a preset report template, the system integrates monitoring data, operation results, and difference analysis to generate a structured GPU resource misuse scenario test report. It marks the fault tolerance conclusions of various resource predefined attributes and misuse methods, and clarifies the GPU's ability to verify and intercept resource misuse scenarios.

[0133] Many GPU anomalies stem from "inconsistencies between declaration and usage," rather than simple out-of-bounds errors. Mismatched usage based on inherent texture attributes can trigger undefined behaviors. This requires covering illegal usage patterns, not just functionally correct paths. Systematically covering anomalous usage scenarios with mismatched GPU resource attributes comprehensively tests the GPU's ability to intercept and tolerate illegal usage patterns, significantly improving the detection rate of hidden vulnerabilities in testing.

[0134] In some optional implementations of this embodiment, the target GPU resource includes texture resources of at least two texture dimensions; and the generation of a shader program to trigger a mismatch between the usage of the target GPU resource and predetermined attributes includes: generating a shader program to trigger the mixed use of texture resources of at least two texture dimensions based on a preset fourth code template, wherein the fourth code template is a preset standardized code framework, and the fourth code template is used to automatically generate a shader program that triggers an anomaly in the mixed use of texture resources of different dimensions.

[0135] This embodiment targets GPU resources with a predetermined texture dimension attribute. Based on a "preset fourth code template," it implements anomaly testing for the mixed use of different texture dimensions. The steps are as follows: Step 1: Select the target GPU resource with different texture dimension predefined attributes from the GPU resource set created by the test resource management module.

[0136] For example, there are predefined texture resources with 1D, 2D, and 3D dimensions. All textures are clearly labeled with predefined dimension attributes, providing a benchmark for constructing scenarios that use different dimensions in combination.

[0137] Step 2: The shader program generation module generates shader programs based on the preset fourth code template to trigger the mixed use of different texture dimensions.

[0138] Load the preset fourth code template: This template contains a fixed structure (multi-dimensional texture binding declaration, texture sampling logic framework, dimension mixing configuration interface, result write-back specification), and has built-in 1D / 2D / 3D texture sampling syntax sub-templates. It supports configuring mismatched combinations of "actual texture dimension" and "sampling instruction dimension" to achieve mixed use of dimensions.

[0139] In one example, the first set of dimension blending shader code is generated: based on the template configuration of the "1D texture + 2D sampling instruction" blending scene, after binding the 1D texture SRV, the UV coordinates of the 1D texture are sampled using Texture2D.Sample (2D sampling instruction) (which does not match the 1D texture dimension attributes), and the shader code is generated.

[0140] Step 3: The test execution engine executes the test case for this texture dimension mix and monitors the GPU's response to this anomaly.

[0141] Each of the three different texture resources and the corresponding three sets of blending shader code is bound to an independent test case, with unified GPU execution parameters (sampler state, pipeline binding rules). The graphics command queue is initialized, and each test case is submitted to the GPU in sequence to trigger shader execution, completing the operation of blending various texture dimensions.

[0142] Monitor GPU response in real time. For example, enable the GPU debugging layer and vendor performance analysis tools to monitor three types of core response data (texture dimension mismatch error code, validity of mixed sampling results, and GPU device running status). Record real-time data snapshots and pipeline execution logs when each dimension mixed scene occurs to avoid data confusion between different use cases.

[0143] Step 4: The results analysis module records the system's processing method for this type of texture dimension mixing and generates a report.

[0144] The processing results of three sets of texture dimension blending scenes were recorded respectively: (① Error log: a special warning was captured (texture dimension and sampling instruction mismatch), and the log clearly marked "actual texture dimension is X, sampling instruction expects dimension Y"; (② Sampling result: sampling operations of all dimensions returned the GPU default fault tolerance value (all 0 values ​​or edge invalid values), no garbled data output, and no pollution of other normal resources; (③ Device status: stable memory usage, no program crash, no memory leak, pipeline normally interrupted the error sampling logic, and did not affect the execution of other processes).

[0145] Compare the differences in processing logic between "low-dimensional → high-dimensional" (1D → 2D, 2D → 3D) and "high-dimensional → low-dimensional" (3D → 1D) mixed scenes, and compare the differences in error interception priority and fault tolerance mechanism between different texture dimensions.

[0146] Based on a preset report template, monitoring data, sampling results, and difference analysis are integrated to generate a structured test report on the mixed use of texture dimensions. The report marks the fault tolerance conclusions of various mixed texture dimension scenarios and clarifies the GPU's ability to verify and intercept texture dimension attributes.

[0147] Mixing different texture dimensions can lead to addressing and resolution errors, and data corruption. The fourth template automatically generates cross-dimensional mismatch access. It allows for batch verification of the dimension validation mechanism. It efficiently triggers anomalies caused by mixing textures of different dimensions, accurately detects GPU texture dimension validation logic, and improves the security and stability of cross-dimensional resource usage.

[0148] In some optional implementations of this embodiment, generating a shader program to trigger a mismatch between the usage of the target GPU resource and predetermined attributes includes: generating a shader program based on a preset fifth code template to trigger a mismatch between the target shader resource view type and the actual resource type of the target GPU resource. The fifth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios where the resource view type and the actual resource type are inconsistent. The specific steps are as follows: Step 1: Select the target GPU resource with a clear actual resource type from the GPU resource set created by the test resource management module (and mark the corresponding predefined SRV attribute).

[0149] For example, GPU resources with actual resource types such as "2D texture", "structured buffer", and "3D texture" are included. All resources are clearly labeled with their actual resource type and corresponding pre-matched SRV type, providing a benchmark for constructing scenarios where "SRV type and actual resource type are inconsistent".

[0150] Step 2: The shader program generation module generates a shader program that triggers an inconsistency between the SRV type and the actual resource type, based on the preset fifth code template.

[0151] Load the preset fifth code template: This template contains a fixed structure (resource binding declaration, SRV type configuration interface, resource access logic framework, result write-back specification), has a built-in correspondence library of various actual resource types and non-matching SRV types, supports configuring mismatched combinations of "actual resource type" and "bound SRV type", and retains complete view type error access logic.

[0152] In one example, the first set of mismatched shader code is generated: based on the template configuration of "actual 2D texture + bound 3D texture SRV" mismatch scene, a 3D texture SRV is created and bound to the 2D texture resource (deviation from the pre-matched 2D texture SRV), shader code is generated, and the 3D coordinates of the 2D texture bound to the 3D texture SRV are sampled using Texture3D.Sample (3D texture access instruction), triggering the "SRV type is inconsistent with actual resource type" exception.

[0153] Step 3: Test the execution engine to execute the resource view Figure 1 Consistency test cases monitor the GPU's response to this anomaly.

[0154] Three types of actual resources and their corresponding three sets of mismatched shader code are bound to independent test cases, with unified GPU execution parameters (sampler state, descriptor heap binding rules, pipeline state objects). The graphics command queue is initialized, and each test case is submitted to the GPU in sequence to trigger shader execution and complete various access operations where "SRV type does not match actual resource type".

[0155] Real-time monitoring of GPU response, for example, enabling GPU debugging layer and monitoring tools to monitor three types of core response data (view type mismatch error code, validity of erroneous access operation, and GPU device running status), and recording real-time data snapshots, pipeline execution logs and resource access trajectories when each mismatch scenario occurs, to avoid data confusion between different use cases.

[0156] Step 4: The results analysis module records how the system handles such view type mismatches and generates a report.

[0157] The processing results for three sets of view type mismatch scenarios were recorded respectively: (① Error log: Specific warnings such as view type and resource type mismatch and resource view invalid for target resource were captured. The log clearly marked "actual resource type is X, bound SRV type is Y, and the two are incompatible"; (② Access result: all resource access operations with view type mismatch were invalid. Sampling / reading returned the GPU default fault tolerance value (all 0 values ​​or edge invalid values). There was no data pollution, no garbled output, and no modification of the valid data of the target resource; (③ Device status: stable memory usage, no program crashes, no memory leaks, normal pipeline interruption of error access logic, and no impact on the execution flow of other normal resources).

[0158] Compare the differences in processing logic between "view dimension mismatch within the same category" (2D texture → 3D texture SRV, 3D texture → 1D texture SRV) and "view type mismatch across categories" (structured buffer → 2D texture SRV), and compare the differences in the priority and fault tolerance mechanism for intercepting view mismatch errors corresponding to different actual resource types.

[0159] Based on a pre-defined report template, monitoring data, access results, and discrepancy analysis are integrated to generate a structured shader resource view. Figure 1 The consistency test report marks the fault tolerance conclusions for various resource scenarios where "SRV type is inconsistent with actual resource type", clarifies the GPU's ability to verify and intercept resource view type consistency, and provides data support for subsequent optimization of resource view binding logic.

[0160] View type mismatch is a common driver-level exception. The fifth template is specifically designed to handle view-resource incompatibility scenarios. It verifies the view binding validation mechanism and effectively detects exceptions caused by mismatches between shader resource views and actual resource types, preventing GPU hangs, memory leaks, or program crashes due to view errors.

[0161] In some optional implementations of this embodiment, the target GPU resource includes a GPU resource with a set baseline sampling number; and a shader program for generating a shader program to trigger a mismatch between the usage of the target GPU resource and its predetermined attributes, including: generating a shader program based on a preset sixth code template to trigger a mismatch between the preset baseline sampling number and the actual sampling number of the target GPU resource. The sixth code template is a preset standardized code framework used to automatically generate a shader program that triggers an error scenario where the sampling number of a multisampled texture does not match. The specific steps are as follows: Step 1: Select the target GPU resource with a preset number of baseline samples from the GPU resource set created by the test resource management module.

[0162] For example, 2D color textures with a preset reference sampling number of "1X (single sampling)", 2D depth textures with preset reference sampling numbers of "4X (4-fold multi-sampling)" and "8X (8-fold multi-sampling)".

[0163] Step 2: The shader program generation module generates shader programs that trigger inconsistent sample counts based on the preset sixth code template.

[0164] Load the preset sixth code template: This template contains a fixed structure (multisampling texture binding declaration, sampling logic framework, sample number configuration interface, result write-back specification), and has built-in exclusive sampling syntax sub-templates for single sampling / 4X / 8X multisampling. It supports configuring mismatched combinations of "resource preset baseline sample number" and "shader actual sample number" and retains complete sample number error access logic.

[0165] In one example, the first set of mismatched shader code is generated: based on the template configuration of "1X single-sample texture + 4X actual number of samples" for the mismatched scene, after binding the 1X single-sample texture SRV, the HLSL multisampling-specific instruction Texture2DMS.SampleMS (specifying the actual number of samples 4 and the sampling index 0) is used to sample (which is inconsistent with the baseline number of samples 1X) and generate shader code.

[0166] Step 3: The test execution engine executes the multisampling test case and monitors the GPU's response to this anomaly.

[0167] Three texture resources with preset baseline sample counts and their corresponding three sets of shader code with mismatched sample counts are bound as independent test cases, and GPU execution parameters (multisampling sampler state, descriptor heap binding rules, and pipeline state objects) are configured uniformly. The graphics command queue is initialized, and each test case is submitted to the GPU in sequence to trigger shader execution and complete various sampling operations where the preset baseline sample count is inconsistent with the actual sample count.

[0168] Monitor GPU response in real time, record real-time data snapshots, pipeline execution logs, and multi-sampled data access trajectories when each mismatch scenario occurs, and avoid data confusion between different use cases.

[0169] Step 4: The results analysis module records how the system handles this type of sample number mismatch and generates a report.

[0170] The processing results for three sets of sampling mismatch scenarios were recorded respectively: (① Error log: Specific warnings such as mismatch between captured texture sampling number and resource sampling number, invalid sampling index, etc. were recorded. The log clearly marked "The preset baseline sampling number of the resource is X, and the actual sampling number is Y. The two are incompatible"; (② Sampling result: All sampling operations with mismatched sampling numbers are invalid. The GPU default fault tolerance value (all 0 values ​​or invalid values ​​of edge sampling points) is returned. There is no multisampling data disorder, no memory pollution, and the effective sampling data of the target resource is not modified; (③ Device status: The memory usage is stable. There is no program crash or memory leak. The pipeline interrupts the erroneous sampling logic normally and does not affect the execution flow of other normal multisampling resources).

[0171] Compare the differences in processing logic for three mismatch scenarios: "single sampling → multiple sampling" (1X → 4X), "few multiple sampling → multiple sampling" (4X → 8X), and "multiple sampling → single sampling" (8X → 1X). Compare the differences in the priority and fault tolerance mechanism for intercepting sampling number mismatch errors corresponding to textures with different baseline sampling numbers.

[0172] Based on a preset report template, monitoring data, sampling results, and difference analysis are integrated to generate a structured GPU resource multisampling mismatch test report. The report marks the fault tolerance conclusions for various resource scenarios where "the preset baseline sampling number is inconsistent with the actual sampling number". It clarifies the GPU's ability to verify and intercept the consistency of multisampling numbers, providing data support for subsequent optimization of multisampling texture binding and sampling logic.

[0173] Sample count mismatch can lead to out-of-bounds sampling point indices and anti-aliasing failure. The sixth template constructs various combinations of sample count mismatches to verify sample count consistency. It accurately detects sample count mismatch anomalies in multi-sampled textures, strengthens the GPU's verification of resource sampling validity, and improves the robustness of the rendering pipeline.

[0174] In some optional implementations of this embodiment, the target GPU resource includes a GPU resource with a set number of Mip-Map levels; and the generation of a shader program to trigger a mismatch between the usage of the target GPU resource and its predetermined attributes includes: generating a shader program based on a preset seventh code template to trigger access to Mip-Map levels that do not exist in the target GPU resource, wherein the seventh code template is a preset standardized code framework, and the seventh code template is used to automatically generate shader programs that trigger illegal Mip-Map level access. The specific steps are as follows: Step 1: Select the target GPU resource with a predetermined number of Mip-Map levels from the GPU resource set created by the test resource management module.

[0175] For example, a 2D color texture with a predetermined number of Mip-Map layers of 3 (effective layers 0~2), a 2D depth texture with a predetermined number of Mip-Map layers of 1 (only effective layer 0), and a 3D voxel texture with a predetermined number of Mip-Map layers of 5 (effective layers 0~4).

[0176] Step 2: The shader program generation module generates shader programs that trigger access to the Mip-Map level based on the preset seventh code template.

[0177] Load the preset seventh code template: This template contains a fixed structure (Mip texture binding declaration, Mip level sampling logic framework, invalid Mip level configuration interface, result write-back specification), built-in 2D / 3D texture Mip level sampling syntax sub-template, supports the configuration of mismatched combinations of "resource reservation valid Mip level" and "shader actually accessing Mip level", and retains complete Mip level out-of-bounds access logic.

[0178] In one example, the first set of mismatched shader code is generated: based on the template configuration of "level 3 Mip texture + access level 3" mismatched scene, after binding the 2D texture SRV, the HLSLTexture2D.SampleLevel instruction (explicitly specifying Mip level 3, sampling coordinates (0.5,0.5)) is used to sample and access the non-existent Mip level 3 (outside the predetermined valid range 0~2), generating shader code.

[0179] Step 3: The test execution engine executes the Mip-Map level test case and monitors the GPU's response to this anomaly.

[0180] Three texture resources with a predetermined number of Mip-Map levels and their corresponding three sets of Mip-Map level out-of-bounds shader code are bound to independent test cases, with unified GPU execution parameters (sampler state, Mip filtering mode, descriptor heap binding rules, and pipeline state object). Each test case is submitted to the GPU, triggering shader execution to complete various sampling operations for "accessing a non-existent Mip-Map level". GPU response is monitored in real-time, recording real-time data snapshots, pipeline execution logs, and Mip-Map level access trajectories for each mismatch scenario to avoid data contamination between different test cases.

[0181] Step 4: The results analysis module records the system's handling of this type of Mip level out-of-bounds error and generates a report.

[0182] The processing results for three sets of Mip level out-of-bounds scenarios were recorded respectively: (① Error log: Specific warnings such as captured texture Mip level exceeding the valid range and invalid Mip level sampling were recorded. The log clearly indicated that "the number of Mip levels reserved for the resource is X, the valid level range is 0~Y, and the actual accessed Mip level Z does not exist"); (② Sampling results: All sampling operations that accessed non-existent Mip levels returned the GPU's default fault tolerance value (mostly the closest valid highest Mip level data or all 0 values), with no Mip data corruption, no memory pollution, and no modification to the valid Mip chain data of the target resource; (③ Device status: Stable memory usage, no program crashes, no memory leaks, and normal pipeline interruption of the sampling logic of the incorrect Mip level, without affecting the execution flow of other normal Mip level resources). By comparing the differences in processing logic between "multiple Mip levels (level 3 / 5) out of bounds" and "single Mip level (level 1) out of bounds", and by comparing the differences in error interception priority and fault tolerance mechanism between 2D textures and 3D textures for Mip level out of bounds, we can analyze the GPU's default completion strategy for "no Mip level".

[0183] Based on a preset report template, monitoring data, sampling results, and difference analysis are integrated to generate a structured GPU resource Mip-Map level out-of-bounds test report. The report marks the fault tolerance conclusions for various resource "accessing non-existent Mip-Map levels" scenarios, clarifies the GPU's ability to verify and intercept the consistency of the number of Mip-Map levels, and provides data support for subsequent optimization of Mip texture binding and sampling logic and prevention of Mip level out-of-bounds.

[0184] Accessing data beyond the total Mip level will result in an illegal address resolution. The seventh template-directed construction of invalid level access verifies the GPU's protection of Mip level ranges. It reliably triggers illegal Mip-Map level access exceptions, comprehensively detecting the GPU's multi-level asymptotic texture boundary protection mechanism to prevent out-of-bounds reading of invalid texture data.

[0185] In some optional implementations of this embodiment, generating a shader program to trigger a mismatch between the usage of the target GPU resource and predetermined attributes includes: generating a shader program based on a preset eighth code template to trigger a resource format conversion request for the target GPU resource that is incompatible with a predetermined resource format. The eighth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios that cause resource format incompatibility conversion. The specific steps are as follows: Step 1: Select the target GPU resource with a predetermined resource format from the GPU resource set created by the test resource management module.

[0186] For example, 2D depth textures with a predefined resource format of D32_FLOAT (32-bit floating-point depth format), 2D color textures with a predefined resource format of RGBA8_UNORM (8-bit unsigned normalized color format), and structured buffers with a predefined resource format of UINT32 (32-bit unsigned integer format).

[0187] Step 2: The shader program generation module generates a shader program that triggers an incompatible format conversion request based on the preset eighth code template.

[0188] Load the preset eighth code template. In one example, generate the first set of incompatible shader code: based on the template configuration of "D32_FLOAT depth texture → RGBA8_UNORM color format" incompatible conversion scene, after binding the D32_FLOAT depth texture SRV, generate HLSL pixel shader code, attempt to force the sampled depth floating-point value (float type) to convert to RGBA8_UNORM normalized four-channel color value, and attempt to use RWTexture2D <unormfloat4>Syntax writeback (initiates an explicit color format conversion request that is incompatible with the predefined depth format).

[0189] Step 3: The test execution engine executes the resource format conversion test case and monitors the GPU's response to this anomaly.

[0190] Three GPU resources with predetermined resource formats and their corresponding three sets of incompatible format conversion shader code are bound to independent test cases. GPU execution parameters (sampler state, format mapping rules, pipeline state objects) are uniformly configured. Each test case is submitted to the GPU, triggering shader execution to complete various "conversion requests for incompatible predetermined resource formats". The GPU response is monitored in real time, and real-time data snapshots, pipeline execution logs, and format conversion trajectories are recorded when each incompatible format conversion scenario occurs, avoiding data confusion between different test cases.

[0191] Step 4: The results analysis module records how the system handles incompatible format conversions and generates a report.

[0192] This study records the processing results of various incompatible format conversion scenarios, comparing the processing logic differences between three incompatible conversion scenarios: "depth format → color format," "color format → floating-point format," and "integer format → floating-point format." It also compares the error interception priorities and fault tolerance mechanisms for incompatible conversions of texture and buffer resources, analyzing the GPU's default interception strategy for "incompatible format conversions." Based on a preset report template, it integrates monitoring data, conversion results, and difference analysis to generate a structured GPU resource format incompatibility conversion test report. The report marks the fault tolerance conclusions for various resource "conversion requests incompatible with predetermined resource formats" scenarios, clarifying the GPU's ability to verify and intercept resource format consistency. This provides data support for subsequent optimization of GPU resource format binding and conversion logic, and for avoiding incompatible format conversion requests.

[0193] Forced conversion of incompatible formats can lead to data parsing errors and garbled output. The eighth template constructs illegal conversions such as depth to color and integer to floating-point, which can verify and block format security checks. It effectively detects and handles anomalies caused by incompatible GPU resource format conversions, ensuring that incompatible format requests are safely blocked and preventing memory pollution and device malfunctions.

[0194] In some optional implementations of this embodiment, generating a shader program to trigger a mismatch between the usage of the target GPU resource and a predetermined attribute includes: generating a shader program to trigger a mismatch between the declared attribute and the attribute actually used by the shader, based on a preset ninth code template. The ninth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios where the declared resource attribute is inconsistent with the actual usage attribute.

[0195] In one example, the specific steps are as follows: Step 1: Select the target GPU resource that meets the buffer boundary conditions from the GPU resource set created by the test resource management module, such as a 2D texture resource.

[0196] Step 2: Declare it as a 1D texture type through the shader resource view.

[0197] Configure the parameter for "declared property does not match actual property": declare the property as "1D texture", and specify the actual property as "2D texture".

[0198] Step 3: The shader generation module generates shader code that accesses the texture in a 1D manner.

[0199] The shader program generation module loads the preset ninth code template, which includes a resource binding framework, an interface for configuring inconsistent properties in scenarios, shader syntax sub-templates, and a result write-back specification. It automatically concatenates the shader code to generate a complete shader program.

[0200] Step 4: Test the execution engine to run the test and observe the GPU's handling behavior for this inconsistency.

[0201] The test execution engine first binds the previously prepared "target GPU resources (2D textures), inconsistently declared SRVs (1D texture types), and 1D access mode shader code" into complete executable test cases, while configuring unified GPU execution parameters to avoid parameter interference with test results. Then, it triggers the GPU to execute inconsistent access operations. The test execution engine caches the captured error logs, sampling result data, device status curves, and other raw data in the local test database, providing complete, unprocessed raw data support for the result analysis in subsequent step 5, preventing data loss or tampering.

[0202] Step 5: The results analysis module records and analyzes the test results.

[0203] The results analysis module extracts all raw data cached in step 4 from the local test database, cleans and structures it to form a standardized list of test results records, ensuring data traceability and comparability. Based on the structured and effective data, in-depth analysis is conducted to uncover the underlying logic and patterns of GPU processing behavior. Based on the results of this in-depth analysis, clear test conclusions and actionable optimization suggestions are generated.

[0204] Inconsistencies between declarations and usages are the most subtle and difficult-to-detect anomaly type. The ninth template constructs scenarios where the declared type ≠ the used type, covering gray-area behaviors not explicitly defined in the specification. It deeply detects hidden vulnerabilities in GPU resource declarations and actual usages, strengthens GPU verification of resource lifecycle and usage consistency, and improves overall system security.

[0205] Further reference Figure 3 This illustrates a flow 300 of yet another embodiment of a GPU testing method. Flow 300 of this GPU testing method includes the following steps: Step 301: Select a target GPU resource from a pre-created set of GPU resources according to the test requirements, and generate a shader program to trigger GPU exceptions based on the target GPU resource.

[0206] Step 302: Send an instruction to the GPU to execute the shader program and obtain the test results obtained by the GPU executing the shader program.

[0207] Steps 301-302 are basically the same as steps 201-202, so they will not be described again.

[0208] Step 303: Compare and analyze the test results with the expected results to identify abnormal results.

[0209] In this embodiment, the GPU debugging layer and performance analysis tools are enabled to capture and obtain three types of core test results in real time: ① error logs and error codes output by the GPU; ② sampling result data of 1D access to textures; ③ device operation data such as GPU memory usage and pipeline execution status.

[0210] If the test results match the expected results, a valid texture color value should be returned, there should be no related error logs, and the GPU device should be stable and without any abnormalities. Compare the actual test results with the expected results: For example, ① the actual error warning was captured, which is inconsistent with the expected result of "no error log"; ② the actual sampling result returned all 0 invalid values, which is inconsistent with the expected result of "returning valid color values"; ③ the actual GPU device state was stable, which is consistent with the expected result of "device state stable". The errors "error log generation" and "invalid value returned by sampling result" were identified as abnormal results in this test, clarifying the abnormal behavior triggered by the GPU in this scenario.

[0211] Step 304: Generate a test report based on the abnormal results.

[0212] In this embodiment, the details of the abnormal results are compiled, including the original error log text, invalid sampling result data, and a comparison table of the differences between the abnormal and expected results.

[0213] The analysis includes in-depth explanations of the underlying causes of the anomaly (the declared attributes do not match the actual attributes of the resource, and the GPU cannot parse the data structure) and the performance of the GPU's fault tolerance mechanism (returning an invalid value instead of crashing).

[0214] Generate a structured test report, which includes test scenario metadata, a list of abnormal results, in-depth analysis conclusions, and subsequent optimization suggestions.

[0215] Archive the original test data and error log screenshots as report attachments to form a complete test archive, providing a reference for subsequent GPU resource testing and development.

[0216] In this embodiment, automatic comparison can quickly filter out real anomalies, and the anomalies are output in reports, facilitating reproduction, location, and repair. This achieves automated analysis of test results and closed-loop anomaly output, improving the efficiency of GPU anomaly location, forming reproducible and traceable test evidence, and directly supporting GPU robustness optimization and problem remediation.

[0217] Further reference Figure 4 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a GPU testing device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0218] like Figure 4 As shown, the test GPU device 400 of this embodiment includes: a generation unit 401, configured to select a target GPU resource from a pre-created GPU resource set according to test requirements, and generate a shader program for triggering GPU anomalies based on the target GPU resource; and a test unit 402, configured to send an instruction to the GPU to execute the shader program, and obtain the test results obtained by the GPU executing the shader program.

[0219] In this embodiment, the specific processing of the generation unit 401 and the testing unit 402 of the testing GPU device 400 can be referred to Figure 2 The corresponding steps 201 and 202 in the embodiment.

[0220] In some optional implementations of this embodiment, the generation unit 401 is further configured to: select a target GPU resource with pre-set boundary conditions from the GPU resource set, wherein the boundary conditions include the legal range threshold of the GPU resource; and generate a shader program to trigger GPU out-of-bounds access based on the boundary conditions.

[0221] In some optional implementations of this embodiment, the target GPU resource includes at least one of a raw buffer and a typed buffer; and the generation unit 401 is further configured to: generate a shader program for triggering out-of-bounds access to the raw buffer and / or the typed buffer based on a preset first code template, wherein the first code template is a preset standardized code framework, and the first code template block is for automatically generating shader programs that trigger out-of-bounds access to the raw buffer and / or the typed buffer.

[0222] In some optional implementations of this embodiment, the target GPU resource includes at least one of the following texture resources: 2D texture, 1D texture, 3D texture, cube map; and the generation unit 401 is further configured to: generate a shader program for triggering out-of-bounds access of texture image coordinates of the target GPU resource based on a preset second code template, wherein the second code template is a preset standardized code framework, and the second code template is used to automatically generate a shader program for triggering out-of-bounds access of texture image coordinates.

[0223] In some optional implementations of this embodiment, the target GPU resource includes GPU resources that support atomic operations; and the generation unit 401 is further configured to: generate a shader program based on a preset third code template to trigger the target GPU resource to perform atomic operations under concurrent access and / or boundary address conditions, wherein the third code template is a preset standardized code framework, and the third code template is used to automatically generate shader programs that trigger abnormal behavior of GPU atomic operations.

[0224] In some optional implementations of this embodiment, the generation unit 401 is further configured to: select a target GPU resource with predetermined attributes from the GPU resource set, wherein the predetermined attributes include at least one of the following: texture dimension, resource view type, number of samples, number of multi-level asymptotic texture Mip-Map layers, and resource format; and generate a shader program to trigger a mismatch between the usage of the target GPU resource and the predetermined attributes.

[0225] In some optional implementations of this embodiment, the target GPU resources include texture resources of at least two texture dimensions; and the generation unit 401 is further configured to: generate a shader program for triggering the mixed use of texture resources of at least two texture dimensions based on a preset fourth code template, wherein the fourth code template is a preset standardized code framework, and the fourth code template is used to automatically generate shader programs that trigger the abnormal mixed use of texture resources of different dimensions.

[0226] In some optional implementations of this embodiment, the generation unit 401 is further configured to: generate a shader program based on a preset fifth code template to trigger a mismatch between the target shader resource view type and the actual resource type of the target GPU resource, wherein the fifth code template is a preset standardized code framework used to automatically generate a shader program that triggers an error scenario where the resource view type is inconsistent with the actual resource type.

[0227] In some optional implementations of this embodiment, the target GPU resource includes a GPU resource with a preset baseline sampling number; and the generation unit 401 is further configured to: generate a shader program based on a preset sixth code template to trigger a mismatch between the preset baseline sampling number and the actual sampling number of the target GPU resource, wherein the sixth code template is a preset standardized code framework, and the sixth code template is used to automatically generate a shader program that triggers an error scenario of mismatch between the sampling number of multisampled textures.

[0228] In some optional implementations of this embodiment, the target GPU resource includes GPU resources with a set number of Mip-Map levels; and the generation unit 401 is further configured to: generate a shader program for triggering access to Mip-Map levels that do not exist in the target GPU resource based on a preset seventh code template, wherein the seventh code template is a preset standardized code framework, and the seventh code template is used to automatically generate shader programs that trigger illegal Mip-Map level access.

[0229] In some optional implementations of this embodiment, the generation unit 401 is further configured to: generate a shader program based on a preset eighth code template to trigger a resource format conversion request for the target GPU resource that is incompatible with a predetermined resource format. The eighth code template is a preset standardized code framework and is used to automatically generate a shader program that triggers an error scenario of incompatible resource format conversion.

[0230] In some optional implementations of this embodiment, the generation unit 401 is further configured to: generate a shader program that triggers a mismatch between the declared attributes and the actual attributes used by the shader, based on a preset ninth code template, wherein the ninth code template is a preset standardized code framework, and the ninth code template is used to automatically generate a shader program that triggers an error scenario where the declared resource attributes are inconsistent with the actual attributes used.

[0231] In some optional implementations of this embodiment, the device further includes a determining unit (not shown in the figures), configured to: compare and analyze the test results with the expected results to determine abnormal results; and generate a test report based on the abnormal results.

[0232] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security and network security.

[0233] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0234] An electronic device includes: one or more processors; and a storage device having one or more computer programs stored thereon, wherein when the one or more computer programs are executed by the one or more processors, the one or more processors implement the method described in process 200 or 300.

[0235] A computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in process 200 or 300.

[0236] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0237] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0238] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0239] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as road planning methods. For example, in some embodiments, the road planning method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the road planning method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the road planning method by any other suitable means (e.g., by means of firmware).

[0240] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0241] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0242] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0243] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including voice input, speech input, or tactile input).

[0244] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0245] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be servers in distributed systems or servers incorporating blockchain technology. Servers can also be cloud servers, or intelligent cloud computing servers or intelligent cloud hosts with artificial intelligence technology.

[0246] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0247] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for testing a GPU, comprising: Select a target GPU resource from a pre-created set of GPU resources according to the test requirements, and generate a shader program to trigger GPU anomalies based on the target GPU resource; Send instructions to the GPU to execute the shader program, and obtain the test results obtained by the GPU executing the shader program.

2. The method according to claim 1, wherein, The step of selecting a target GPU resource from a pre-created set of GPU resources according to test requirements, and generating a shader program to trigger GPU anomalies based on the target GPU resource, includes: Select a target GPU resource with pre-set boundary conditions from the GPU resource set, wherein the boundary conditions include the legal range threshold of the GPU resource; A shader program is generated based on the boundary conditions to trigger GPU out-of-bounds access.

3. The method according to claim 2, wherein, The target GPU resource includes at least one of a raw buffer and a typed buffer; as well as The process of generating a shader program based on the boundary conditions to trigger GPU out-of-bounds access includes: Based on the first code template, a shader program is generated to trigger out-of-bounds access to the original buffer and / or the typed buffer, wherein the first code template is a preset standardized code framework, and the first code template is used to automatically generate shader programs that trigger out-of-bounds access to the original buffer and / or the typed buffer.

4. The method according to claim 2, wherein, The target GPU resources include at least one of the following texture resources: 2D texture, 1D texture, 3D texture, cube map; as well as The process of generating a shader program based on the boundary conditions to trigger GPU out-of-bounds access includes: Based on the second code template, a shader program is generated to trigger out-of-bounds access to the texture image coordinates of the target GPU resource. The second code template is a preset standardized code framework and is used to automatically generate a shader program that triggers out-of-bounds access to the texture image coordinates.

5. The method according to claim 2, wherein, The target GPU resources include GPU resources that support atomic operations; as well as The process of generating a shader program based on the boundary conditions to trigger GPU out-of-bounds access includes: Based on a preset third code template, a shader program is generated to trigger the target GPU resource to perform atomic operations under concurrent access and / or boundary address conditions. The third code template is a preset standardized code framework, which is used to automatically generate shader programs that trigger abnormal behavior of GPU atomic operations.

6. The method according to claim 1, wherein, The step of selecting a target GPU resource from a pre-created set of GPU resources according to test requirements, and generating a shader program to trigger GPU anomalies based on the target GPU resource, includes: Select a target GPU resource with predetermined attributes from the GPU resource set, wherein the predetermined attributes include at least one of the following: texture dimension, resource view type, number of samples, number of multi-level asymptotic texture Mip-Map layers, and resource format; Generate a shader program to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes.

7. The method according to claim 6, wherein, The target GPU resources include texture resources of at least two texture dimensions; and The generation of the shader program used to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes includes: Based on a preset fourth code template, a shader program is generated to trigger the mixed use of texture resources of at least two texture dimensions. The fourth code template is a preset standardized code framework, which is used to automatically generate shader programs that trigger anomalies in the mixed use of texture resources of different dimensions.

8. The method according to claim 6, wherein, The generation of the shader program used to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes includes: Based on a preset fifth code template, a shader program is generated to trigger a mismatch between the resource view type and the actual resource type of the target GPU resource. The fifth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios where the resource view type and the actual resource type are inconsistent.

9. The method according to claim 6, wherein, The target GPU resources include GPU resources with a baseline sampling number set; as well as The generation of the shader program used to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes includes: Based on a preset sixth code template, a shader program is generated to trigger a mismatch between the baseline sampling number and the actual sampling number of the target GPU resource. The sixth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios where the sampling number of multisampled textures does not match.

10. The method according to claim 6, wherein, The target GPU resources include GPU resources with a set number of Mip-Map levels; as well as The generation of the shader program used to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes includes: Based on a preset seventh code template, a shader program is generated to trigger access to a Mip-Map level that does not exist in the target GPU resources. The seventh code template is a preset standardized code framework used to automatically generate shader programs that trigger illegal Mip-Map level access.

11. The method according to claim 6, wherein, The generation of the shader program used to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes includes: Based on a preset eighth code template, a shader program is generated to trigger a resource format conversion request for the target GPU resource that is incompatible with a predetermined resource format. The eighth code template is a preset standardized code framework, which is used to automatically generate shader programs that trigger error scenarios that cause resource format incompatibility conversion.

12. The method according to claim 6, wherein, The generation of the shader program used to trigger a mismatch between the usage of the target GPU resources and the predetermined attributes includes: Based on a preset ninth code template, a shader program is generated to trigger an error scenario where the declared property is inconsistent with the property actually used by the shader. The ninth code template is a preset standardized code framework used to automatically generate shader programs that trigger error scenarios where the declared resource property is inconsistent with the actual property used.

13. The method according to any one of claims 1-12, wherein, The method further includes: The test results are compared and analyzed with the expected results to identify abnormal results; A test report is generated based on the abnormal results.

14. An apparatus for testing a GPU, comprising: The generation unit is configured to select a target GPU resource from a pre-created set of GPU resources according to test requirements, and generate a shader program to trigger GPU anomalies based on the target GPU resource; The test unit is configured to send instructions to the GPU to execute the shader program and to obtain the test results obtained by the GPU executing the shader program.

15. An electronic device comprising: One or more processors; Storage device, on which one or more computer programs are stored, When the one or more computer programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-13.

16. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-13.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-13.

Images