A processor behavior analysis method, device, equipment and medium

Abstract

The present disclosure discloses a processor behavior analysis method, device, equipment and medium, and belongs to the technical field of computers. The method comprises: after detecting a processor behavior trigger event, obtaining buffer data generated by a target layer of the processor; performing type identification on the buffer data to obtain a type identification result; calling a corresponding analysis rule to analyze the buffer data according to the type identification result to obtain processor command data; and generating an analysis result file based on the processor command data. According to the technical scheme, the buffer data of the target layer in the graphics processor is directly obtained, type identification is performed, and a corresponding analysis rule is called to perform analysis, so that the actual execution content of the processor can be truly reflected, and the problem of insufficient analysis accuracy caused by the dependence of the prior art on the API layer is effectively solved.

Description

Technical Field

[0001] This disclosure belongs to the field of computer technology, and specifically relates to a processor behavior analysis method, apparatus, device, and medium. Background Technology

[0002] In the fields of computer graphics processing and operating system driver technology, GPU buffer data parsing is a key technical means for GPU driver development, graphics debugging, and problem localization.

[0003] In existing technologies, taking GPU graphics processing units as an example, the analysis of GPU execution behavior is mostly based on the graphics application programming interface (API) layer. By intercepting, recording, and replaying the call information of the API layer, the expected execution behavior of the GPU is deduced. However, such solutions can only obtain the call order and parameter information of high-level interfaces, and cannot directly obtain the actual behavior data of the GPU. Their analysis results depend on the expectation of execution behavior and lack objectivity.

[0004] The parsing of GPU behavioral data is of great significance in GPU analysis. Therefore, how to achieve objective parsing of GPU behavioral data is a technical challenge faced by those skilled in the art. Summary of the Invention

[0005] This disclosure provides a processor behavior analysis method, apparatus, device, and medium, aiming to solve the problems of existing GPU behavior analysis schemes based on the graphics application programming interface layer, such as the inability to directly obtain effective data, insufficient analysis accuracy, and difficulty in accurately reflecting the actual execution content of the GPU. It achieves accurate identification and analysis of buffered data at this layer, improves the accuracy of GPU behavior analysis, and provides an accurate data foundation for a series of scenarios such as driver debugging and problem localization.

[0006] In a first aspect, embodiments of this disclosure provide a processor behavior parsing method, the method comprising: After detecting a processor behavior trigger event, the buffer data generated by the target layer of the processor is obtained; The buffered data is then subjected to type identification to obtain the type identification result; Based on the type identification result, the corresponding parsing rule is invoked to parse the buffer data to obtain processor command data; A parsing result file is generated based on the processor command data.

[0007] Furthermore, the step of performing type identification on the buffered data to obtain the type identification result includes: Obtain the core feature set of the buffered data, wherein the core feature set includes features for representing the type of buffered data; The core feature set is matched with the pre-stored format feature library to obtain the type recognition result.

[0008] Furthermore, the core feature set includes at least one of the following: buffer header identifier field, memory allocation identifier, data length and structure features, and trigger event associated metadata.

[0009] Furthermore, the type of the buffered data includes control flow type and / or shader program type; The step of parsing the buffered data according to the type identification result and calling the corresponding parsing rule to obtain processor command data includes: If the type identification result includes the control flow type, then the control flow parsing rules are invoked to parse the buffered data to obtain the processor command data; If the type identification result includes the shader program type, then the shader program parsing rules are invoked to parse the buffer data to obtain the processor command data.

[0010] Furthermore, the control flow parsing rules include at least one of the following: display driver model instruction encoding rules, processor architecture instruction encoding rules, and processor hardware instruction set mapping rules; The call control flow parsing rules parse the buffered data to obtain the processor command data, including: The buffer data is parsed by invoking at least one of the display driver model instruction encoding rules, the processor architecture instruction encoding rules, and the processor hardware instruction set mapping rules to obtain processor instruction sequences and / or processor execution flow information.

[0011] Furthermore, the shader program parsing rules include at least one of API shader compilation rules, shader disassembly rules, and shader intermediate representation conversion rules; The shader program parsing rules are used to parse the buffered data to obtain the processor command data, including: The buffered data is parsed by calling at least one of the API shader compilation rules, shader disassembly rules, and shader intermediate representation conversion rules to obtain at least one of the shader binary instruction stream, shader assembly instruction sequence, and shader intermediate representation form across processor architecture.

[0012] Furthermore, the type of buffered data also includes resource status configuration type; The step of parsing the buffered data according to the type identification result and calling the corresponding parsing rule to obtain processor command data includes: If the type identification result includes the resource status configuration type, then the resource status parsing rules are invoked to parse the buffer data to obtain structured processor status data and / or resource configuration information.

[0013] Secondly, embodiments of this disclosure provide a processor behavior analysis apparatus, the apparatus comprising: The buffer data acquisition module is used to acquire the buffer data generated by the target layer of the processor after detecting a processor behavior trigger event; A type identification module is used to identify the type of the buffered data and obtain the type identification result; The parsing module is used to parse the buffered data by calling the corresponding parsing rules according to the type identification result, so as to obtain processor command data; The result file generation module is used to generate a parsed result file based on the processor command data.

[0014] Thirdly, embodiments of this disclosure provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0015] Fourthly, embodiments of this disclosure provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0016] Fifthly, embodiments of this disclosure provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0017] The technical solution provided in this disclosure directly obtains the buffer data of the target layer in the graphics processor, performs type identification, and calls the corresponding parsing rules for parsing. This can truly reflect the actual execution content of the processor, effectively solving the problem of insufficient parsing accuracy caused by the reliance on API layer derivation in the prior art. Furthermore, this parsing method can significantly improve the accuracy and efficiency of processor driver debugging, graphics calculation analysis, and problem localization, providing reliable technical support for related development work. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the processor behavior parsing method provided in Embodiment 1 of this disclosure; Figure 2 This is a schematic diagram of the grabbing process provided in Embodiment 1 of this disclosure; Figure 3This is a schematic diagram of the processor behavior analysis device provided in Embodiment 2 of this disclosure; Figure 4 This is a schematic diagram of the structure of the electronic device provided in Embodiment 3 of this disclosure. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this disclosure clearer, specific embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this disclosure and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this disclosure are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0020] The technical solutions of the embodiments of this disclosure will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure are within the scope of protection of this disclosure.

[0021] The terms "first," "second," etc., used in this disclosure and in the claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character "=" generally indicates that the preceding and following objects are in an "or" relationship.

[0022] The processor behavior analysis method, apparatus, device, and medium provided in this disclosure will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0023] Example 1 Figure 1 This is a flowchart illustrating the processor behavior parsing method provided in Embodiment 1 of this disclosure. Figure 1As shown, the specific steps include the following: S11, after detecting a processor behavior trigger event, obtain the buffer data generated by the target layer of the processor; A processor can refer to a graphics processing unit (GPU), which is used to process graphics and image data, perform parallel computing, and graphics rendering tasks.

[0024] Processor behavior trigger events can refer to trigger events generated when the processor performs operations such as graphics rendering, parallel computing, instruction submission, and driver invocation, which are used to start buffer data fetching, or they can be fetch instruction events initiated by the user or the system.

[0025] The target layer can refer to the user-mode driver layer (UMD) under the display driver model architecture, or it can be the driver layer related to the generation of buffered data in the processor instruction generation and submission chain.

[0026] This solution is applicable to the display driver model architecture, namely WDDM (Windows Display Driver Model), which is a graphics driver architecture defined by Microsoft for Windows systems to standardize the interaction logic between the graphics processor and the system. In this architecture, the target layer can refer to the user-mode driver layer, namely UMD (User Mode Driver), which is the driver layer running in user mode within the display driver model architecture and is responsible for converting high-level graphics interface calls into low-level data that the graphics processor can recognize.

[0027] Buffer data can be a set of underlying data generated by the user-mode driver layer after processing graphics interface calls, and is to be submitted to the kernel-mode driver layer. It serves as the core data basis for the graphics processor to perform related operations. Specifically, it can be control flow buffer data, which stores the instruction flow executed by the graphics processor, including various operation instructions and parameter configurations. It can also be shader program code buffer data, which stores the binary code of the shader program. The shader program is a program that runs on the graphics processor and is responsible for completing specific computational tasks in graphics rendering.

[0028] This solution allows the GPU Buffer Capture Tool to acquire data using a GPU Buffer parsing tool. This tool can directly extract various types of buffered data generated from the user-mode driver layer without intervening in the kernel-mode driver layer or hardware layer.

[0029] S12, perform type identification on the buffered data to obtain the type identification result of the buffered data; Type identification refers to the process of determining the category of buffered data. The core is to distinguish between buffered data as control flow buffered data or shader program code buffered data.

[0030] The type identification result is the result obtained after the type identification process, which is used to characterize the category to which the buffered data belongs. This result is the basis for subsequent calls to the corresponding parsing module.

[0031] This solution can be implemented using the recognition module of the graphics processor buffer parsing tool. This module extracts the features of the buffered data and matches them with a preset feature library to determine the type of the buffered data.

[0032] S13, based on the type identification result, call the corresponding parsing rule to parse the buffer data to obtain processor command data; Among them, a pre-set parsing module can be used for parsing. This module can be a pre-built functional module used to perform targeted parsing of different types of buffered data. Each parsing module corresponds to the parsing requirements of a type of buffered data.

[0033] Parsing rules can be a set of rules pre-configured in the parsing module to guide the parsing of buffered data. The content parsing rules of different parsing modules are set according to the type of buffered data and parsing requirements. After the parsing process, the parsed buffered data information can be obtained, which can be used for visualization and structured presentation of the buffered data.

[0034] Processor command data can be readable instructions, flow information, status information, or configuration information obtained after parsing, used to accurately reflect the processor's execution content. Specifically, this can be implemented by the control and parsing module of the processor buffer parsing tool, which automatically matches and initiates the corresponding parsing rules based on the type identification results to complete data parsing and conversion.

[0035] Specifically, this can be achieved through the control and parsing module of the graphics processor buffer parsing tool. This module automatically matches and activates the corresponding parsing module based on the type identification result. The parsing module then performs layer-by-layer parsing and data transformation on the buffered data according to pre-configured content parsing rules.

[0036] S14, Generate a parsing result file based on the processor command data.

[0037] The parsing result file can be the output file after structuring the processor command data, used for persistent storage, viewing, debugging, and problem localization. This solution can present the parsing results in a format that can be accessed and viewed by developers, such as displaying and storing them according to preset methods.

[0038] The technical solution provided in this embodiment directly parses the buffered data of the user-mode driver layer under the display driver model architecture, breaking through the limitations of existing technologies that rely on high-level interface derivation and analysis. It can directly obtain and parse the low-level execution data of the graphics processor, truly reflecting the actual execution content of the graphics processor. At the same time, through type identification and targeted parsing by corresponding parsing modules, the accuracy of the parsing is ensured, providing data support for graphics processor driver development, debugging, and problem localization.

[0039] In one embodiment, optionally, performing type identification on the buffered data to obtain the type identification result of the buffered data includes: The buffered data is preprocessed to remove redundant data and then the core feature set of the buffered data is extracted. The core feature set is matched with the pre-stored format feature library to obtain the type identification result corresponding to the buffer data; wherein, the type identification result is control flow buffer type, shader program code buffer type or resource state configuration type.

[0040] Preprocessing refers to the preliminary data processing operations performed on the buffered data. Its core purpose is to remove invalid data and ensure the accuracy of subsequent feature extraction.

[0041] Redundant data can be invalid data such as padding data and checksum data in buffer data that have no actual business significance. This type of data will affect the efficiency and accuracy of feature extraction and type recognition.

[0042] The core feature set, which can be a set of features extracted from buffered data that can characterize the type of buffered data, is the core basis for subsequent matching with the feature library.

[0043] Specifically, a core feature set can be extracted from the preprocessed buffer data using a preset feature extraction algorithm.

[0044] The format feature library can be a pre-built database that stores feature information of various types of buffered data under the target layer. This database contains typical features of control flow buffer data, shader program code buffer data, and resource state configuration buffer data, and serves as a reference for type identification.

[0045] After extracting the core feature set, the core feature set can be compared one by one with the feature information in the format feature library, and the type of buffer data can be determined based on the comparison results.

[0046] It is understood that the above-described type identification process, which includes preprocessing, feature extraction, and feature library matching, is only an exemplary implementation. In practical applications, other type identification methods can be adopted based on differences in architecture and data format characteristics. For example, preprocessing can be omitted to directly extract features, judgment can be based on structure parsing, or judgment can be based on metadata. As long as the distinction between buffered data types can be achieved, it is not limited to the above methods.

[0047] This technical solution provides a specific type recognition process. By preprocessing to remove redundant data, the extraction accuracy of the core feature set is effectively improved. Then, by matching with a pre-stored feature library, type determination is achieved, ensuring the accuracy of the type recognition result. This provides a precise basis for subsequent calls to the corresponding parsing rules and avoids parsing deviations caused by type recognition errors.

[0048] In one embodiment, optionally, the core feature set includes at least one of the following: buffer header identifier field, memory allocation identifier, data length and structure features, and trigger event associated metadata.

[0049] The buffer header identifier field can be a field located at the beginning of the buffer data that identifies the basic attributes of the buffer data. Different types of buffer data have different header identifier fields. For example, control flow buffer data will contain an instruction flow identifier field.

[0050] Memory allocation identifiers can refer to the identification information generated by the processor when allocating memory for buffered data. Different types of buffered data have different memory allocation rules, and the corresponding memory allocation identifiers also differ.

[0051] Data length and structural characteristics can refer to the overall data length of buffered data and the internal data organization structure. There are obvious differences in the data length range and internal structure of control flow buffered data, shader program code buffered data, and resource state configuration buffered data.

[0052] The metadata associated with the triggering event can refer to the scenario, task, or call information related to the processor behavior triggering the event, such as the type of graphics interface call corresponding to the buffered data, the type of computing task to which it belongs, etc.

[0053] It is understood that the features listed above are only some of the preferred features. In practical applications, other features that can be used to distinguish types can be added or replaced according to the characteristics of the buffered data format and architecture, as long as effective type distinction can be achieved, and are not limited to the types of features listed above.

[0054] This technical solution provides a detailed description of the core feature set, defining the feature range from multiple dimensions such as the header identifier of the buffered data, memory allocation, data structure, and associated metadata. This provides a clear basis for the extraction of the core feature set, ensuring that the extracted core feature set is sufficiently representative, further improving the accuracy of type recognition, and also providing a clear feature reference standard for the construction of the feature library.

[0055] In one embodiment, optionally, the type of the buffered data includes control flow type and / or shader program type; The step of parsing the buffered data according to the type identification result and calling the corresponding parsing rule to obtain processor command data includes: If the type identification result includes the control flow type, then the control flow parsing rules are invoked to parse the buffered data to obtain processor command data; If the type identification result includes the shader program type, then the shader program parsing rules are invoked to parse the buffer data to obtain processor command data.

[0056] Among them, the control flow parsing rules can be a pre-built set of rules specifically designed for parsing the content of control flow buffer data. The parsing logic of these rules is set according to the characteristics of the control flow buffer data.

[0057] Shader program parsing rules can be a pre-built set of rules specifically designed for parsing the content of shader program code buffer data. The parsing logic of these rules is tailored to the characteristics of shader program code buffer data.

[0058] This solution establishes a one-to-one correspondence between type identification results and parsing rules. When the identification result is a control flow type, the control flow parsing rules are automatically invoked; when the identification result is a shader program type, the shader program parsing rules are automatically invoked.

[0059] It is understandable that the above-mentioned method of calling parsing rules separately according to a single type is only a typical implementation. In practical applications, other methods such as multi-type mixed recognition and parallel parsing, batch parsing, and on-demand parsing can also be supported, as long as the corresponding parsing rules can be matched according to the type. It is not limited to the above-mentioned method of parsing separately.

[0060] This technical solution can achieve a precise correspondence between parsing rules and buffered data types, allowing different types of buffered data to be parsed and processed in a targeted manner. This avoids the problem of inaccurate and incomplete parsing caused by general parsing logic, and improves the overall parsing quality and efficiency.

[0061] In one embodiment, optionally, the control flow parsing rules include at least one of: display driver model instruction encoding rules, processor architecture instruction encoding rules, and processor hardware instruction set mapping rules; The call control flow parsing rules parse the buffered data to obtain the processor command data, including: The buffer data is parsed by invoking at least one of the display driver model instruction encoding rules, the processor architecture instruction encoding rules, and the processor hardware instruction set mapping rules to obtain the processor instruction sequence and / or processor execution flow information.

[0062] The instruction encoding rules can be rules formulated by the display driver model architecture and the corresponding processor architecture to standardize the form of processor instruction encoding. Different processor architectures have different instruction encoding rules.

[0063] Processor hardware instruction set mapping rules refer to the rules that map the processor's binary instruction codes to corresponding instruction names and parameter meanings. These rules are the core basis for implementing binary instruction parsing.

[0064] A processor instruction sequence can refer to a set of processor instructions arranged in execution order after the control flow buffer data has been parsed. This set clearly shows the order in which the processor's instructions are executed.

[0065] Processor execution flow information can refer to the overall execution flow of the processor obtained by combining business logic analysis with the instruction sequence, such as instruction branching, looping, batch processing and other logical information.

[0066] This solution can perform instruction boundary division, instruction code decoding, and parameter parsing on control flow buffer data according to pre-configured instruction encoding rules and hardware instruction set mapping rules, and finally generate processor instruction sequence or execution flow information.

[0067] It is understood that the rules listed above are only preferred parsing rules. In practical applications, appropriate instruction parsing rules can be added or replaced according to different processor architectures and different driver versions, as long as effective parsing of control flow data can be achieved. It is not limited to the above combination of rules.

[0068] This technical solution provides clear rules for the parsing process of control flow buffer data, accurately parses the raw binary control flow data into instruction sequences and execution flow information that can be understood by developers, clearly restores the processor's instruction execution logic, and provides accurate underlying data support for driver-level instruction analysis and problem localization.

[0069] In one embodiment, optionally, the shader program parsing rules include at least one of API shader compilation rules, shader disassembly rules, and shader intermediate representation conversion rules; The shader program parsing rules are used to parse the buffered data to obtain the processor command data, including: The buffered data is parsed by calling at least one of the API shader compilation rules, shader disassembly rules, and shader intermediate representation conversion rules to obtain at least one of the shader binary instruction stream, shader assembly instruction sequence, and shader intermediate representation form across processor architecture.

[0070] Application Programming Interface (API) is the interface between an application and the processor, such as Direct3D and Vulkan. Different interfaces have different shader compilation specifications.

[0071] Shader compilation specifications can refer to the rules defined by the application programming interface (API) for standardizing the compilation process and format of shader programs.

[0072] Shader disassembly rules can refer to rules that convert shader binary instruction streams into assembly instruction sequences, enabling reverse analysis of shader binary code.

[0073] Shader intermediate representation conversion rules can refer to rules that convert shader assembly instruction sequences into intermediate representations that are cross-processor architectures. These rules strip away hardware-related coding details while preserving the core logic of the shader program.

[0074] Shader binary instruction stream can refer to the original sequence of shader program binary instructions extracted from the shader program code buffer data; it is the underlying execution code of the shader program.

[0075] Shader assembly instruction sequence refers to the set of assembly instructions obtained after disassembling the shader binary instruction stream, which is easier for developers to understand than binary instructions.

[0076] Intermediate shader representations across processor architectures refer to shader program representations that are stripped of hardware-related details and can be used across different processor architectures, such as SPIR-V and DXIL, which facilitate cross-platform shader program analysis and optimization.

[0077] Specifically, the shader program code buffer data can be structurally split, instructions extracted, and format converted according to pre-configured compilation specifications, disassembly rules, and intermediate representation conversion rules, ultimately generating various forms of parsing results.

[0078] It is understandable that the rules listed above are only typical parsing rules. In practical applications, corresponding parsing rules can be added or replaced according to different APIs and different shader formats, as long as the effective parsing of shader data can be achieved, and it is not limited to the above combination of rules.

[0079] This technical solution can parse the original binary data of the shader program into different forms of information such as binary instruction streams, assembly instruction sequences, and cross-architecture intermediate representations, meeting the analysis needs of developers in different scenarios. At the same time, the cross-architecture intermediate representation improves the universality of the parsing results, providing comprehensive data support for the debugging, optimization, and cross-platform development of shader programs.

[0080] In one embodiment, optionally, the type of the buffered data may further include a resource status configuration type; The step of parsing the buffered data according to the type identification result and calling the corresponding parsing rule to obtain processor command data includes: If the type identification result includes the resource status configuration type, then the resource status parsing rules are invoked to parse the buffer data to obtain structured processor status data and / or resource configuration information.

[0081] Among them, the resource status configuration type buffer data is used to carry processor running status, resource binding and parameter configuration information.

[0082] Resource status parsing rules are pre-defined parsing logics for status and configuration data structures, used to extract processor status and resource configuration related content.

[0083] Structured processor status data can be processor running status information that has been standardized and organized; resource configuration information can be the resource bindings, parameter settings, and other content required for processor execution.

[0084] It is understood that the above parsing method for resource status configuration types is only an exemplary implementation. In practical applications, other methods such as structure parsing, field mapping, and status extraction can be used according to the configuration data format of different architectures, as long as the effective parsing of status and configuration data can be achieved, and it is not limited to the above methods.

[0085] This technical solution enables specialized analysis of resource status configuration data, improves the full coverage of buffered data types, and fills in the state information analysis link outside of control flow and shader programs, thereby enhancing the overall analysis completeness, comprehensiveness, and ability to locate driving problems.

[0086] To enable those skilled in the art to better understand this solution, this disclosure also provides a preferred embodiment.

[0087] This disclosure presents a method and tool for parsing GPU Buffers. The purpose is to enable developers to effectively parse core data such as control stream and shader code from GPU Buffers obtained from the User Mode Driver (UMD). This allows for accurate reflection of the actual execution content of the GPU in user mode, thereby improving the efficiency and accuracy of GPU driver debugging, graphics computing analysis, and problem localization from the data parsing level.

[0088] This disclosure, based on existing mature GPU buffer capture tools, develops a method and supporting tools for parsing GPU buffer content at the user-mode driver layer within the Windows Display Driver Model (WDDM) architecture. It achieves refined parsing of raw buffer data through a four-step core process. The complete technical solution is as follows: Step 1: Obtain data from the GPU Buffer; Developers use existing GPU Buffer capture tools to directly obtain target buffer data from the UMD layer of the WDDM architecture. The reason for capturing directly from the UMD layer is to obtain the original data that is actually generated by the driver layer and is about to be submitted to the kernel, avoiding the deviation caused by the derivation of high-level interface data. The target data captured includes at least GPU execution core data such as Control Stream and Shader Code.

[0089] Step 2: Buffer type identification; Given that different types of buffers carry different execution functions of the GPU, mixing them during parsing can lead to data corruption and distorted parsing results. Therefore, it is essential to accurately distinguish the buffer types during the parsing process. The tool described in this disclosure uses its identification module to classify and identify the captured buffer data. The purpose of this step is to provide a preliminary basis for the targeted parsing of different types of buffers. The identified types include at least Control Stream Buffers, Shader Code Buffers, and other types of buffers, ensuring that each type of buffer can be matched with the corresponding parsing logic.

[0090] Step 3, Content Analysis; The tool's control and parsing module automatically calls the corresponding preset parsing module to perform parsing work based on the identified Buffer type. The reason for configuring dedicated parsing modules for different types of Buffers is that the data formats and execution logic of various Buffers are significantly different, and targeted parsing can improve the accuracy of the results: parsing Control Stream Buffers into GPU instruction sequences or execution flow information, parsing Shader Code Buffers into binary instructions, assembly or intermediate representations, and parsing other Buffers into structured states or configuration data, thus achieving professional parsing of various types of data.

[0091] Step 4: Output the results; The tool's output module outputs the parsing results of various buffers in the form of logs, structured files, or visualizations. The purpose of using multiple output formats is to adapt to the usage needs of developers in different scenarios such as driver debugging, problem localization, and performance analysis, so that developers can directly retrieve, view, and analyze the parsing results.

[0092] Through the above complete technical solution, this disclosure can directly parse the GPU Buffer content that is actually generated and submitted by the user-mode driver layer, restore the GPU execution process from the underlying data level, and thus achieve accurate analysis of the actual execution behavior of the GPU.

[0093] Based on the above method, this disclosure also designs a tool specifically for parsing GPU buffer content. The tool adopts a modular architecture to improve its scalability and versatility, adapting to different GPU architectures and driver implementations. Specifically, it includes four core modules: an input module, a recognition module, a control and parsing module, and an output module. The tool also features both offline and online parsing modes. The dual parsing modes are designed to meet the different analysis needs of developers: offline parsing allows developers to directly parse the captured buffer file, suitable for backtracking analysis of batch data; online parsing, through collaboration with a playback tool that has memory address access capabilities, acquires and parses the UMD layer buffer data in real time, enabling instant analysis of GPU memory content, thus facilitating developers to accurately locate and diagnose GPU operational problems.

[0094] Figure 2 This is a schematic diagram illustrating the GPU buffer data capture and parsing process provided in Embodiment 1 of this disclosure. Figure 2As shown, the GPU buffer parsing tool described in this disclosure is a Decoder Tool module. GPU buffer data generated by the User Mode Driver Layer (UMD) is captured and encapsulated into a trace file, which serves as the input source for the Decoder Tool. Encapsulating the captured buffer data into a trace file aims to standardize the storage and transmission of the raw buffer data, facilitating reading and processing by the parsing tool. After the trace file is parsed by the Decoder Tool according to a preset process, it finally outputs a highly readable formatted parsing result file (Decoded file), enabling developers to directly understand and use the parsing results.

[0095] The Decoder Tool is structured into four main modules based on functional division of labor. The core functions and execution methods of each module are as follows: Input module: Its core function is data reception. This module is specifically responsible for receiving buffer data output by the GPU Buffer capture tool. Figure 2 The Trace file in the document has a separate input module to standardize data access and adapt to the output formats of different data capture tools. Recognition Module: Its core function is type determination. This module is independently responsible for identifying and classifying the type of the input Buffer data. Allowing this module to handle the recognition work alone can improve the efficiency and accuracy of type determination and avoid confusion with other processes. Control and Parsing Module: As the core processing module of the tool, it is responsible for the flow control of the entire parsing process. This module first identifies the specific task type being processed, such as a computation task or a graphics task, and then calls different parsing sub-modules according to the task type to adapt to the characteristics of the buffer data under different tasks. Next, based on the buffer type and task type, it calls the corresponding parsing control flow sub-module to execute content parsing and simultaneously completes the formatting of the parsed content, preparing it for subsequent output. Output module: Its core function is result integration and presentation. This module is responsible for assembling the parsing results of different types of buffers according to the execution logic order of the buffer. The sequential assembly is to restore the actual execution flow of the GPU, so that the parsing results are more in line with the actual running state of the GPU, and output the assembled parsing results to a file.

[0096] Compared with existing technologies, this disclosure achieves a technological upgrade in GPU buffer parsing through core designs such as direct parsing of the UMD layer, modular design, and dual-mode parsing, and has at least the following beneficial effects: By accurately identifying the type of the captured user-driven GPU Buffer and configuring dedicated parsing logic for ControlStream Buffer and Shader Code Buffer respectively, the system effectively distinguishes and performs refined analysis of different types of GPU execution data, solving the problem of result distortion caused by mixed parsing in existing technologies. By analyzing the associations of multiple types of buffers, the correspondence between Control Stream and Shader execution can be accurately restored, filling the gap in existing technologies that cannot analyze the linkage logic between the two, and improving the completeness of the analysis of the overall execution behavior of the GPU. Furthermore, since the acquisition and parsing of the Buffer are both completed in user mode, no modifications are required to the kernel mode driver, and there is no need to rely on dedicated hardware support provided by GPU manufacturers, which greatly reduces the intrusion into the system and reduces the usage cost and environment configuration cost for developers. The modular structure is used to realize buffer recognition and parsing. Each module has independent functions and standardized interfaces. Developers can flexibly adjust or extend the functions of the corresponding modules according to the needs of different GPU architectures and driver implementations, so that this disclosure can be adapted to different application environments and improve the scalability and versatility of the solution. It provides both offline and online parsing capabilities. Offline parsing can quickly analyze batch-fetched buffer data to meet the needs of backtracking and debugging, while online parsing has the ability to analyze GPU memory content in real time, adapting to real-time problem diagnosis scenarios and providing developers with flexible and efficient auxiliary diagnostic capabilities to improve problem-solving efficiency.

[0097] Regarding the technical solutions proposed in this disclosure, without departing from the core inventive idea, developers can make appropriate adjustments or replacements to the specific implementation methods of the technical means according to the actual application scenario, hardware environment, development requirements and other specific implementation environments, so as to obtain the same or similar technical effects as this disclosure.

[0098] For example, without changing the basic technical idea of ​​obtaining GPU execution-related data from the UMD layer under the WDDM architecture, the triggering time for GPU buffer capture can be changed from manual triggering to automatic timed triggering. The buffer type identification method can be changed from feature library matching to data structure parsing. The specific implementation form of the parsing module can be changed from a software module to a hardware-software hybrid module. Different implementation methods can be used to replace it. Alternatively, while keeping the core idea of ​​parsing the content of the user-mode driver layer buffer unchanged, the developers can merge, split, or rearrange the capture and parsing process according to the data processing requirements. For example, the two steps of buffer capture and type identification can be merged into one process to improve data processing efficiency.

[0099] Furthermore, for different graphics or computing application programming interfaces (APIs), different GPU architectures, or different driver implementations, developers can make targeted adjustments to the specific format and parsing rules of the buffer content according to the specific buffer data format. This can also achieve effective analysis of execution data such as Control Stream and Shader Code, and its technical effect is basically consistent with this public proposal.

[0100] It should be noted that although the above alternatives differ in specific implementation details, they all adhere to the core technical idea of ​​this disclosure: parsing the GPU Buffer content at the user-mode driver layer to reflect the actual execution behavior of the GPU, and should all fall within the protection scope of this disclosure.

[0101] This public proposal proposes a technical solution to accurately distinguish and identify Control Stream Buffer and Shader Code Buffer, and to configure dedicated parsing logic for each to parse them separately. This solution solves the problem of result distortion caused by mixed parsing in existing technologies, and enables refined analysis of GPU core execution data. The analysis is based on the actual Buffer data submitted to the GPU by the UMD layer, rather than the analysis method derived from high-level API calls. This method ensures the authenticity of the parsing results from the data source and can accurately reflect the actual execution content of the GPU. Furthermore, this disclosure provides a modular and scalable tool architecture specifically designed for buffer identification, parsing, and result output. This architecture enhances the tool's scalability and versatility through a modular design with independent functions, enabling it to adapt to different GPU architectures and driver implementation environments. It possesses both offline and online parsing capabilities. The online parsing capability allows the tool to work in conjunction with a playback tool, enabling real-time access to GPU memory and parsing of buffer content via the playback tool, thereby achieving instant analysis and precise localization of GPU runtime issues.

[0102] Compared with the closest existing technical solutions (debugging solutions based on the graphics API layer or kernel-mode driver KMD layer), this public proposal innovates in many aspects such as data acquisition, parsing methods, and tool design, and has at least the following technical advantages: By directly using existing scraping tools to obtain raw buffer data from the UMD layer and completing the classification and parsing of the data in user mode, it can accurately reflect the actual execution content of the GPU from the underlying data level, rather than relying solely on high-level API calls to deduce GPU execution behavior, thus fundamentally solving the problem of insufficient parsing accuracy in existing technologies. This disclosure can accurately classify Buffers into Control Stream Buffers, Shader Code Buffers, and other types of Buffers, configure dedicated parsing logic for different types of Buffers, realize fine-grained parsing for different functions, and at the same time, it can perform correlation parsing of Control Stream Buffers and Shader Code Buffers to restore the execution linkage between the two, thereby improving the accuracy and completeness of data analysis. The entire solution runs in user mode, requiring no modification to the kernel driver or dedicated hardware, resulting in low system intrusion. At the same time, the tool adopts a modular architecture design, which can be flexibly expanded and adjusted, and is suitable for different GPU architectures and driver implementation environments, possessing strong versatility and scalability. During Trace playback, the Decoder Tool offers both offline and online parsing methods, allowing developers to choose flexibly based on their actual needs. The online method can work in conjunction with the playback tool to acquire GPU Buffer content in real time and complete parsing synchronously, enabling real-time diagnosis of GPU runtime issues. The parsing tool provided in this disclosure can convert the original, unstructured buffer content into structured, visualized output results, allowing developers to intuitively and clearly view the GPU's execution data. This provides intuitive and easy-to-use data support for developers' driver debugging, problem localization, and performance analysis, significantly improving development efficiency.

[0103] Example 2 Figure 3 This is a schematic diagram of the processor behavior parsing device provided in Embodiment 2 of this disclosure. Figure 3 As shown, the device includes: The buffer data acquisition module 310 is used to acquire buffer data generated by the target layer of the processor after detecting a processor behavior trigger event; Type recognition module 320 is used to perform type recognition on the buffer data and obtain type recognition results; The parsing module 330 is used to parse the buffer data by calling the corresponding parsing rules according to the type identification result, so as to obtain processor command data; The result file generation module 340 is used to generate a parsing result file based on the processor command data.

[0104] The processor behavior analysis device in this disclosure can be a system, or a component, integrated circuit, or chip in a terminal. The system can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This disclosure does not impose specific limitations.

[0105] The processor behavior analysis device in this embodiment can be a system with an operating system. This operating system can be Android, iOS, or other possible operating systems; this embodiment does not impose any specific limitations.

[0106] The processor behavior analysis apparatus provided in this disclosure can implement the various processes of the above embodiments, and will not be described again here to avoid repetition.

[0107] Example 3 like Figure 4 As shown, this disclosure also provides an electronic device 400, including a processor 401, a memory 402, and a program or instructions stored in the memory 402 and executable on the processor 401. When the program or instructions are executed by the processor 401, they implement the various processes of the processor behavior parsing method embodiments described above and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0108] It should be noted that the electronic devices in the embodiments of this disclosure include mobile electronic devices and non-mobile electronic devices as described above.

[0109] Example 4 This disclosure also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the processor behavior parsing method embodiments described above and achieve the same technical effect. To avoid repetition, these will not be described again here.

[0110] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0111] Example 5 This disclosure also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the processor behavior parsing method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0112] It should be understood that the chip mentioned in the embodiments of this disclosure may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0113] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element. Furthermore, it should be noted that the scope of the methods and systems in this disclosure is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0114] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this disclosure.

[0115] The embodiments of this disclosure have been described above with reference to the accompanying drawings. However, this disclosure is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this disclosure without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this disclosure.

[0116] The above description is merely a preferred embodiment of the present disclosure and the technical principles employed. The present disclosure is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of the present disclosure. Therefore, although the present disclosure has been described in detail through the above embodiments, the present disclosure is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present disclosure, the scope of which is determined by the scope of the claims.

Claims

1. A processor behavior parsing method, characterized in that, include: After detecting a processor behavior trigger event, the buffer data generated by the target layer of the processor is obtained; The buffered data is then subjected to type identification to obtain the type identification result; Based on the type identification result, the corresponding parsing rule is invoked to parse the buffer data to obtain processor command data; A parsing result file is generated based on the processor command data.

2. The method according to claim 1, characterized in that, The step of performing type identification on the buffered data to obtain the type identification result includes: Obtain the core feature set of the buffered data, wherein the core feature set includes features for representing the type of buffered data; The core feature set is matched with the pre-stored format feature library to obtain the type recognition result.

3. The method according to claim 2, characterized in that, The core feature set includes at least one of the following: buffer header identifier field, memory allocation identifier, data length and structure features, and trigger event associated metadata.

4. The method according to claim 1, characterized in that, The types of the buffered data include control flow type and / or shader program type; The step of parsing the buffered data according to the type identification result and calling the corresponding parsing rule to obtain processor command data includes: If the type identification result includes the control flow type, then the control flow parsing rules are invoked to parse the buffered data to obtain the processor command data; If the type identification result includes the shader program type, then the shader program parsing rules are invoked to parse the buffer data to obtain the processor command data.

5. The method according to claim 4, characterized in that, The control flow parsing rules include at least one of the following: display driver model instruction encoding rules, processor architecture instruction encoding rules, and processor hardware instruction set mapping rules; The call control flow parsing rules parse the buffered data to obtain the processor command data, including: The buffer data is parsed by invoking at least one of the display driver model instruction encoding rules, the processor architecture instruction encoding rules, and the processor hardware instruction set mapping rules to obtain processor instruction sequences and / or processor execution flow information.

6. The method according to claim 4, characterized in that, The shader program parsing rules include at least one of the following: API shader compilation rules, shader disassembly rules, and shader intermediate representation conversion rules; The shader program parsing rules are used to parse the buffered data to obtain the processor command data, including: The buffered data is parsed by invoking at least one of the API shader compilation rules, the shader disassembly rules, and the shader intermediate representation conversion rules to obtain at least one of the shader binary instruction stream, the shader assembly instruction sequence, and the shader intermediate representation form across processor architectures.

7. The method according to claim 4, characterized in that, The types of buffered data also include resource status configuration types; The step of parsing the buffered data according to the type identification result and calling the corresponding parsing rule to obtain processor command data includes: If the type identification result includes the resource status configuration type, then the resource status parsing rules are invoked to parse the buffer data to obtain structured processor status data and / or resource configuration information.

8. A processor behavior analysis device, characterized in that, include: The buffer data acquisition module is used to acquire the buffer data generated by the target layer of the processor after detecting a processor behavior trigger event; A type identification module is used to identify the type of the buffered data and obtain the type identification result; The parsing module is used to parse the buffered data by calling the corresponding parsing rules according to the type identification result, so as to obtain processor command data; The result file generation module is used to generate a parsed result file based on the processor command data.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the processor behavior parsing method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the processor behavior parsing method as described in any one of claims 1-7.

Images