Parsing method, device and equipment for general-purpose graphics processor command buffer

Abstract

The application relates to the technical field of instruction analysis, in particular to a general-purpose graphic processor command buffer analysis method, device and equipment. In view of the problems that in the prior art, manual register positioning and semantic judgment are relied on for the command buffer hexadecimal instruction, leading to low analysis efficiency, poor accuracy and difficult maintenance, the application first analyzes a configuration file containing register information, extracts the register information and generates a structured header file, then identifies data rows in a to-be-analyzed file and instruction types of the hexadecimal instructions in the data rows, when the instruction type is a register operation type, extracts a register address in the instruction and matches the register name and function description from the structured header file, further combines the instruction type to analyze the instruction, and forms an analysis log. The application realizes automatic and standardized analysis of the command buffer, improves the efficiency, consistency and accuracy of complex command sequence analysis.

Description

Technical Field

[0001] This application relates to the field of instruction parsing technology, and in particular to a method, apparatus and device for parsing a general graphics processor command buffer. Background Technology

[0002] In the pre-silicon verification process of GPGPU (General-Purpose Graphics Processing Unit), the chip's execution status and the cause of any abnormalities are usually determined by parsing the hexadecimal command sequence in the Command Buffer and combining it with the hardware documentation.

[0003] However, this type of parsing method mainly relies on manual identification of command types, extraction of fields and querying of register semantics. When faced with large differences in command rules, numerous address mapping relationships and complex jump relationships, it is prone to problems such as long parsing time, bit offset or number conversion errors, poor result consistency and subsequent maintenance difficulties.

[0004] Therefore, how to improve parsing efficiency, accuracy, and maintainability in the process of parsing complex command sequences has become a technical problem that needs to be solved in this field. Summary of the Invention

[0005] This application provides a method, apparatus, and device for parsing a general-purpose graphics processing unit (GPU) command buffer to solve the aforementioned technical problems. This solution addresses the parsing requirements of hexadecimal command sequences in a GPU command buffer, uniformly identifying and processing the relationship between the data to be parsed and the command semantics, and outputting parsing results based on the semantic rules corresponding to different commands, thereby achieving efficient and standardized parsing of the command buffer content.

[0006] In a first aspect, embodiments of this application provide a method for parsing a general graphics processor command buffer, including:

[0007] The process involves parsing a configuration file containing general graphics processing command buffer register information, extracting register information including register name, register address, and register function description; generating a structured header file based on the extracted register information; identifying data lines in the log file corresponding to the user-input target path; extracting hexadecimal instructions from the data lines and identifying the instruction type; if the instruction type is a register operation type, extracting the register address from the hexadecimal instruction in the data line; extracting the register name and register function description from the structured header file based on the extracted register address, and parsing the hexadecimal instructions based on the extracted register name, register function description, and instruction type to obtain the parsing result of the data line; and generating the parsing log of the log file based on the parsing result of the identified data line.

[0008] In one possible embodiment, the configuration file containing general graphics processing command buffer register information is parsed, and the register information in the configuration file is extracted, including:

[0009] Based on the file path array, multiple configuration files are parsed one by one to extract the register information of each configuration file; the file path array is used to store the paths of the configuration files; based on the extracted register information, a structured header file is generated.

[0010] In one possible embodiment, the register information of each configuration file is extracted, including:

[0011] For each configuration file, based on predefined name regular expressions, comment regular expressions, and address regular expressions, the register names, register function descriptions, and register addresses of the configuration file are extracted respectively.

[0012] In one possible embodiment, a structured header file is generated based on the extracted register information, including:

[0013] Generate a file containing header and footer content; generate key-value pairs based on the extracted register names, register function descriptions, and register addresses from each configuration file; and write the header content, key-value pairs, and footer content sequentially into the newly created header file to obtain a structured header file.

[0014] In one possible embodiment, in response to a user-inputted target path, identifying the data line in the log file to be parsed corresponding to the target path includes:

[0015] In response to the target path input by the user, if the target path points to a directory, the log file under the target path is identified; based on the file path of the identified log file, the log file to be parsed is read and the data lines in it are identified; if the target path points to a single log file, the log file to be parsed is read and the data lines in it are identified based on the target path.

[0016] In one possible embodiment, reading the log file to be parsed and identifying data lines includes:

[0017] After successfully opening the log file to be parsed, read the log file line by line. For each line read, determine whether the line contains a command start field. If yes, determine that the line is a data line, save the line content and mark it as a command start line. If no, determine whether the line contains a command end field. If yes, determine that the line is a data line, save the line content and mark it as a command end line. If no, determine whether the line is in the command data segment. The command data segment is defined by a set of command start lines and command end lines. If yes, determine that the line is a data line and save the line content.

[0018] In one possible embodiment, the method further includes:

[0019] If the line is not in the command data segment, then the line is determined to be a comment line and its contents are saved.

[0020] Accordingly, based on the instruction type corresponding to the matched register name, the hexadecimal instruction is parsed, and a parsing log is generated, including:

[0021] Based on the instruction type corresponding to the matched register name, the hexadecimal instruction is parsed to obtain the parsing result of the corresponding data line; based on the parsing result of the identified data line and the saved comment line content, a parsing log is generated.

[0022] In one possible embodiment, based on the parsing results of the identified data rows, a parsing log for the log file to be parsed is generated, including:

[0023] Sort the saved lines of content in ascending order of line number to obtain a line sequence; traverse each line in the line sequence; if the currently traversed line is a comment line, output the content of that line to the parsing log; if the currently traversed line is a data line, output the parsing result of that line to the parsing log using hexadecimal instructions.

[0024] In one possible embodiment, the method further includes:

[0025] If the instruction type is a non-register operation type, the hexadecimal instruction of the data line is parsed according to the parsing rules corresponding to the instruction type to obtain the parsing result of the data line.

[0026] Secondly, embodiments of this application provide a parsing apparatus for a general-purpose graphics processor command buffer, comprising:

[0027] The system comprises the following modules: an information extraction module, which parses a configuration file containing general graphics processing command buffer register information and extracts register information including register name, register address, and register function description; a header file generation module, which generates a structured header file based on the extracted register information; a data line recognition module, which identifies the data line in the log file corresponding to the target path input by the user; an instruction type recognition module, which extracts hexadecimal instructions from the data lines and identifies the instruction type; an address extraction module, which extracts the register address from the hexadecimal instructions in the data lines if the instruction type is a register operation type; an instruction parsing module, which extracts the register name and register function description from the structured header file based on the extracted register address, and parses the hexadecimal instructions based on the extracted register name, register function description, and instruction type to obtain the parsing result of the data line; and a parsing log generation module, which generates the parsing log of the log file to be parsed based on the parsing result of the identified data lines.

[0028] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method provided above.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided above.

[0030] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods provided above.

[0031] The method, apparatus, and device for parsing the general graphics processing unit (GPU) command buffer provided in this application generate a mapping relationship between register addresses and register names by parsing various configuration files containing register information of the GPU command buffer. This establishes an association between address information in hexadecimal instructions and the corresponding register semantics. In practical applications, by identifying data lines in the file to be parsed and extracting register addresses from the hexadecimal instructions in the data lines, and matching register names based on the pre-established mapping relationship, the time consumption and errors caused by manually querying address mappings and judging command meanings can be reduced. Subsequently, the hexadecimal instructions are parsed using the instruction type corresponding to the matched register names to form a parsing log, which can improve the efficiency, accuracy, and consistency of complex command sequence parsing, and enhance the convenience of subsequent rule expansion and maintenance. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0033] Figure 1 A flowchart illustrating the parsing method for the general graphics processor command buffer provided in this application. Figure 1 ;

[0034] Figure 2 A schematic diagram illustrating the register information extraction process provided in this application;

[0035] Figure 3 A flowchart of the process for obtaining the file path provided in this application;

[0036] Figure 4 A schematic diagram illustrating the process of identifying data lines and comment lines provided for this application;

[0037] Figure 5 A schematic diagram of the structure of the parsing device for the general graphics processor command buffer provided in this application;

[0038] Figure 6 A schematic diagram of the structure of the electronic device provided in this application.

[0039] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0040] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0041] Pre-silicon verification of general-purpose graphics processors is a crucial step before chip tape-out. Verification personnel typically rely on simulators, logging systems, register documentation, and command log files to inspect and trace the behavior of the chip during execution.

[0042] In this scenario, the command buffer is responsible for issuing control commands, status setting commands, and synchronization commands to the general-purpose graphics processor. Its content is typically in the form of hexadecimal instruction sequences. When graphics rendering tasks, parallel computing tasks, or driver initialization processes experience stuttering, deadlocks, incorrect results, abnormal states, or software crashes, during debugging, engineers often need to export the instructions from the command buffer and record them in a log file (LOG file). By tracing back through the specific data lines in the command buffer, they can identify the relevant register addresses, register names, and corresponding instruction semantics, thereby determining the chip's internal configuration state and execution path at the time of the anomaly.

[0043] Because the command buffers of general-purpose graphics processors are typically large, and the number of registers corresponding to different modules is numerous and their naming is complex, and command sequences often contain configuration commands, jump commands, wait commands, and state loading commands, this type of parsing work is not simply data reading, but a comprehensive analysis process combining register semantics, command type identification, and log reconstruction. Especially in scenarios involving large-scale regression verification, driver integration testing, and architecture version iteration, how to efficiently and reliably recover the control logic corresponding to the command buffer from the log file directly affects the efficiency of pre-silicon verification and the accuracy and efficiency of problem localization. Therefore, high demands are placed on the accuracy and reusability of command buffer parsing methods.

[0044] In existing technologies, the parsing of command buffers for general-purpose graphics processors generally employs a manual parsing approach. Specifically, verifiers first obtain the data lines from the log file to be parsed. Then, based on the hardware manual, register definition documents, or configuration files, they manually distinguish the register address field, command category field, and parameter field in the hexadecimal instructions. Next, they compare the extracted address values ​​with the definitions in the register documentation item by item to confirm the corresponding register names. Finally, they interpret the entire instruction according to the command format rules and organize it into a debug log.

[0045] This technical solution relies on manual completion of two types of mapping relationships: one is to extract the register address from the hexadecimal instruction field, and the other is to match the register address with the register name. Then, the type of instruction is deduced based on the identified register name, and the interpretation and result output are completed.

[0046] The above methods can basically meet the analysis needs when the number of commands is small, the types of registers are limited, or the operators have sufficient experience. However, they have significant shortcomings in real-world engineering environments. First, the number of data lines contained in the command buffer is often large, requiring parsing personnel to repeatedly switch between log files, configuration documents, and register data. This process is lengthy and involves a large amount of repetitive work, significantly extending the overall debugging cycle. Second, the bit width division, offset extraction, and semantic conversion of hexadecimal fields rely on manual processing. If there are deviations in address truncation, base conversion, field location, or command classification, it may cause subsequent log parsing errors, leading to inaccurate problem localization. Third, the instruction types and parsing rules corresponding to different registers may differ. Manual processing is easily influenced by personal experience, and the same command buffer may produce different interpretations in the hands of different personnel, making it difficult to guarantee consistency. In addition, when register documents are updated, chip versions are adjusted, or command formats change, the original manual parsing experience is difficult to transfer directly. The team needs to relearn and repeatedly establish corresponding relationships, resulting in high maintenance costs and fragmented knowledge accumulation. These problems collectively lead to limitations in existing technologies when faced with complex command sequences, such as long parsing time, insufficient accuracy, poor reproducibility, and difficulty in continuous maintenance, making it difficult to meet the high efficiency and high reliability requirements of modern general-purpose graphics processor verification work.

[0047] In view of this, how to improve the parsing efficiency, accuracy, and maintainability in the process of parsing complex command sequences has become an urgent technical problem to be solved. To solve the above problems, this application provides a parsing method for a general graphics processor command buffer, which is applicable to data processing scenarios consisting of register information sources and files to be parsed. When parsing the command buffer, the configuration file containing the register information of the general graphics processing command buffer is first parsed to extract the register address, register name, and register function description, generating a structured header file, so that the address semantics originally scattered in multiple documents can form a unified correspondence. When there is a file to be parsed, the data lines in the file to be parsed are first identified, the hexadecimal instructions are extracted and their instruction types are identified. When the instruction type is a register operation type, the register address is extracted from the hexadecimal instruction in the data line, and the register name and register function description are matched from the structured header file based on the extracted register address. The hexadecimal instructions are parsed according to the matched register name, register function description, and identified instruction type to obtain the parsing result. The parsing results of each data line are summarized to form a parsing log. By connecting the entire process of configuration file parsing, data line recognition, address matching, and instruction parsing, the original hexadecimal instructions in the command buffer are converted into readable semantic logs with clear semantics. This reduces the uncertainty caused by manual searching and judgment, improves the parsing consistency and subsequent maintenance convenience in complex verification scenarios, and provides effective support for problem localization and status tracking.

[0048] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0049] Figure 1 A flowchart illustrating the parsing method for the general graphics processor command buffer provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:

[0050] S101: Parse the configuration file containing general graphics processing command buffer register information, extract the register information from the configuration file, and generate a structured header file based on the extracted register information.

[0051] The register information includes the register name, register address, and register function description.

[0052] The configuration file is a carrier of register information. It contains information about the registers in the general graphics processing command buffer, including register addresses, register names, and register function descriptions. It may also include parameter information. The configuration file can be understood as being read by the parser and used as the basic input for generating structured header files.

[0053] A register address is a unique numerical code assigned to each register at the hardware level, serving as the fundamental identifier for addressing and accessing registers within the chip. In this embodiment, the register address, as core identification information appearing in the configuration file and subsequent data lines, is used to locate the corresponding register name and register function description in the structured header file.

[0054] A register name is a textual identifier assigned to a register address. It has a specific semantic meaning, representing the specific register that the corresponding register address points to, and serves as a crucial basis for subsequent instruction type determination and parsing rules. The register function description, as comment information, explains the register's function.

[0055] In this embodiment, the executing entity can be a parser deployed on a debugging server, R&D workstation, automated regression platform, etc. After startup, the parser first receives the configuration file path specified by the user, or automatically scans a set of configuration files from a pre-defined project directory. The configuration file can be an XML (eXtensible Markup Language) file, a text configuration file, a register definition file, or other data files capable of carrying register names, register addresses, and register function descriptions. The parser performs file-by-file reading and line-by-line scanning of the configuration file, applying predefined pattern recognition rules, such as regular expressions, tag matching rules, or field delimiters, to each line of content to extract the register names, register addresses, and register function descriptions from the configuration file content.

[0056] For register addresses, the parser can perform at least one of the following: string cleaning, hexadecimal format standardization, case neutralization, and address width padding, to avoid ambiguity in subsequent matching of the same address due to differences in document formats. For register names, the parser can retain module prefixes, function prefixes, or hierarchical naming information so that it can accurately distinguish registers of different functional modules when parsing across modules in the command buffer.

[0057] If the configuration file contains duplicate addresses, alias registers, address range definitions, or version difference fields, the parser can also perform disambiguation processing by combining the module name, chip version number, or register validity conditions to form a unique mapping item in the structured header file or a conditional multi-version mapping item.

[0058] Through the above processing, the address semantics that were originally scattered in the register configuration file are transformed into a unified, structured, and programmable header file, providing a foundation for quickly recovering the register meaning from hexadecimal instructions.

[0059] Based on the above analysis, it can be seen that this step moves the manual table lookup process forward to a regularized data preparation process, which not only shortens the subsequent log interpretation chain, but also reduces the parsing deviation caused by inconsistent document formats, manual conversion errors, or differences in experience, thereby improving the consistency and maintainability of the entire command buffer parsing process.

[0060] In one possible embodiment, the structured header file may also include at least one of the following information about the stored registers: access attributes, the module to which they belong, and possibly the corresponding instruction category label, so that subsequent parsing does not need to access the original document, i.e., the configuration file, again.

[0061] S102: In response to the target path input by the user, identify the data line in the log file to be parsed corresponding to the target path.

[0062] The file to be parsed is one of the input objects of the entire parsing method, used to carry the data content to be processed. It mainly refers to the log file of the command buffer, such as the runtime record file in the pre-silicon simulation process of a general-purpose graphics processor. In practical applications, the format of the file to be parsed is not singular; it can be the output result of the command buffer, chip simulation logs or fragments thereof, runtime print information output by the driver program, or command records retained during debugging. Data lines are the lines of records carrying hexadecimal instructions selected from the file to be parsed; they are important objects for extracting register addresses and reconstructing instruction semantics.

[0063] In this embodiment, after generating the structured header file, the parser reads the contents of the file to be parsed line by line upon detecting or receiving the file. Based on the read content, it identifies the data lines. Whether a line is a data line can be determined by whether it contains a command field and its line number. The command field can include a command start field and a command end field. The command start field identifies the beginning of the valid instruction area in the command buffer; the command end field identifies the end of the valid instruction area in the command buffer. Both are used to delineate the complete instruction range in the file.

[0064] For example, the command start field can be CMD_BUF_START, and the command end field can be CMD_BUF_END.

[0065] If a line contains a command field, it is either the start or end line. If a line does not contain a command field, but its line number indicates it is located between a set of start and end lines, it is determined to be a data line. If a line does not contain a command field, and its line number indicates it is not located between a set of start and end lines, it is determined not to be a data line and can be further identified as a comment line or an invalid line. Comment lines are auxiliary lines in the file to be parsed, excluding data lines. They typically do not contain executable hexadecimal instructions and are used for text descriptions, annotations, content segmentation, and other auxiliary purposes.

[0066] The system receives the target path of the file to be parsed and determines whether the path is a single file or a directory structure. When the target path is a directory, it iterates through the log files within the directory that meet the specified rules and establishes a processing order based on filename, timestamp, or preset priority, opening each file sequentially in that order. When the target path is a single file, it directly opens the file using either streaming or full file loading. After successfully opening a file, it reads the content of the file to be parsed line by line, determining the type of line to be read, such as a data line or a comment line, based on the content read and the line number.

[0067] Whether a line belongs to a data line can be determined by identifying at least one of the following: line number, command start field, command end field, fixed prefix, timestamp format, address offset format, and hexadecimal string distribution characteristics.

[0068] Comment lines read can be cached separately so that they can be inserted according to line number when the parsed log is finally generated, thus improving log readability. Invalid lines or debugging information unrelated to the command buffer can be filtered out to reduce the burden of subsequent parsing.

[0069] After identifying the data lines located between the command start and command end markers (or fields), each data line can be assigned an original line number, file name, block number, and relative position in the command buffer to ensure that subsequent parsing results can still be traced back to the corresponding position in the original file, i.e., the file to be parsed.

[0070] If the file to be parsed contains hexadecimal instructions concatenated across lines, multiple command buffer fragments interleaved, or comments and data mixed on the same line, line content normalization processing can be performed first, such as splitting fields, removing irrelevant delimiters, concatenating continuous data segments, and restoring complete instruction boundaries.

[0071] To ensure that the parsing order is consistent with the chip execution order, the identified data rows can be sorted according to the original row number, command block number, or log time order to obtain a data row sequence. The data row sequence is then sent to the next processing stage for data row parsing in sequence.

[0072] This step organizes the large amount of mixed raw text in the file to be parsed into a set of parsable command data, allowing subsequent processing to focus on the instructions that truly affect the GPGPU state configuration and execution path, thus avoiding repetitive work and omissions caused by manual screening.

[0073] Based on the above analysis, this step essentially transforms unstructured log documents into structured instruction inputs, enabling subsequent address extraction and instruction interpretation to be based on explicit, continuous, and traceable data, thereby improving parsing efficiency and ensuring the reproducibility of results.

[0074] In one possible embodiment, the file to be parsed may be a Log file containing a general graphics processor command buffer, and the parser automatically locates the data rows according to a preset format and saves their context information.

[0075] S103: Extract hexadecimal instructions from the data line and identify the instruction type.

[0076] S104: If the instruction type is a register operation type, extract the register address from the hexadecimal instruction in the data line, and based on the extracted register address, extract the register name and register function description from the structured header file.

[0077] Among them, hexadecimal instructions are the specific encoded content in the data line, and are the original representation of the control information issued by the command buffer to the hardware.

[0078] Hexadecimal instructions that operate on registers typically include an opcode, a register address field, a parameter field, a counter field, and other control bits.

[0079] In this embodiment, for the identified data line, the hexadecimal string (i.e., the field prefixed with "0x") is first extracted, and the boundaries of the single-handed instruction and the bit width of each field are determined according to the predetermined encoding format of the command buffer. For scenarios with fixed instruction lengths, such as each instruction being a fixed 32-bit or 64-bit word length, the hexadecimal string can be segmented according to a predetermined length to obtain multiple hexadecimal instructions. For scenarios with variable instruction lengths, such as multi-word instructions or combinations of main command words and parameter words, the main command word is identified first, and then the number of subsequent words to be parsed is determined based on the length field in the main command word, completing the aggregation and truncation of the entire hexadecimal instruction.

[0080] After obtaining the hexadecimal instructions, the instruction type can be identified according to a pre-built instruction type matching rule table. Instruction types are divided into register operation types and non-register operation types. Register operation type hexadecimal instructions can include register read / write, address addressing, etc., while non-register operation type hexadecimal instructions are mainly pipeline control and status management instructions, such as no-operation (Nop), wait (Wait), pipeline blocking (Stall), link (Link), and end (End) instructions.

[0081] For hexadecimal instructions that operate on registers, bitwise operations can be used to extract the register address from the hexadecimal instruction. For example, the hexadecimal instruction can be converted to an unsigned integer first, and then the address field located within the preset bit range can be extracted by right shift and bitwise AND operation. Alternatively, string slicing can be used to directly extract the hexadecimal instruction corresponding to the address based on a fixed offset and complete the base conversion.

[0082] The extracted address value, i.e. the register address, can be further processed by at least one of address base correction, alignment processing, and address space mapping. For example, some commands record register offsets rather than complete physical addresses. In this case, the corresponding module base address can be superimposed, or address unit conversion can be performed, etc., to obtain a standard address that can directly participate in matching.

[0083] Subsequently, a pre-built structured header file is invoked to perform a lookup on the extracted register addresses. If a unique match exists in the mapping relationship, the register name and register function description corresponding to that match are directly output. If multiple candidate matches exist, at least one of the following can be considered: module, data line context, address segment affiliation, and chip version information. This allows for further filtering of the candidate matches to obtain the final match, and the register name and register function description corresponding to that match are then output. If no match is found, the register address can be marked, for example, as an unknown register. The original address (i.e., the register address) or the content of the data line containing the marked address can then be output to the exception log. This allows the corresponding register address, register name, and register function description (e.g., key-value pairs) to be added to the structured header file based on the information recorded in the exception log when maintaining the mapping relationship.

[0084] Through this process, the numerical codes in hexadecimal instructions that were originally difficult to read directly are converted into register names and register function descriptions with clear hardware meanings, making it easier for engineers to understand and analyze.

[0085] Based on the above analysis, this step achieves register name matching by extracting register addresses and pre-built structured header files, significantly reducing human errors caused by manual truncation, number system conversion, and address lookup. Especially in scenarios involving large-scale command sequences and mixed multi-module registers, it can ensure consistent parsing standards and effectively improve the efficiency of batch parsing.

[0086] S105: Based on the extracted register name, register function description, and instruction type of the hexadecimal instruction, parse the hexadecimal instruction to obtain the parsing result of the corresponding data line.

[0087] S106: Based on the parsing results of the identified data rows, generate the parsing log of the log file to be parsed.

[0088] The parsing log, as an output, is a summary of the hexadecimal instruction parsing results. In some embodiments, the parsing log can be obtained by organizing register names, instruction types, parameter definitions, and necessary contextual information into a log text that is easy to read, locate, and trace.

[0089] In this embodiment, after obtaining the register name and register function description corresponding to the register address in the hexadecimal instruction, the execution semantics and operation content of the entire instruction are restored by combining the instruction type of the original hexadecimal instruction, and the parsing result of the instruction is generated.

[0090] First, the original hexadecimal hardware instructions are split into fields, dividing them into operation fields, address fields, and data fields according to the hardware instruction format. Based on the instruction type, it is determined whether the operation is a register read, register write, or address lookup, thus clarifying the instruction's execution action. Then, the execution action, register name, register function description, and the operation data carried by the instruction are correlated to fully reconstruct the actual operation content and business semantics of the instruction. Finally, the above information is integrated into standardized text content, serving as the parsing result for this instruction.

[0091] For example, for register write instructions, parameters such as the write value, write length, and number of consecutive addresses are extracted from hexadecimal. Combined with the register name and register function description, the complete register hardware operation behavior is reconstructed to form the parsing result of this instruction. For wait instructions, the wait condition, comparison mask, and target value are parsed. Combined with the register name and register function description, the hardware state under which the command buffer continues to execute is determined. For jump instructions, the jump target address, offset, and condition bits are parsed, the jump execution logic is recorded, and the jump result is recorded in the log so that subsequent data lines can continue to be parsed according to the correct execution path. For status load or batch configuration instructions, several subsequent data words can be read continuously, combined with the main command word for parsing, and combined with the register name and register function description to generate a complete hardware instruction execution description.

[0092] Furthermore, for hexadecimal instructions that are not register operations, the hexadecimal instructions are parsed according to the parsing rules corresponding to their instruction types to obtain the parsing results of the corresponding data rows.

[0093] During parsing, based on the specific type of the current instruction, the matching parsing rules are invoked to split the hexadecimal instruction into fields and extract key fields and execution parameters. Then, combined with the instruction's own functional definition, the execution logic, triggering conditions, and execution actions of the instruction are interpreted to fully restore the instruction's semantics and obtain the parsing result.

[0094] When generating the parsing log, the original line number, original hexadecimal string, matched register name, identified instruction type, parameter parsing result, and necessary register function description of each data line can be output in a unified format. In some embodiments, the read comment lines can also be saved. Then, when generating the parsing log, the content of the comment lines can be inserted into the parsing log according to the original line numbers to maintain the log context matching the original file to be parsed.

[0095] In some embodiments, if an unknown register or field is found to be abnormal in a row being read, the abnormal status can be marked in the parsing log, indicating that the result needs further verification.

[0096] The parsed logs can be output as text files, structured CSV (Comma-Separated Values) files, JSON (JavaScript Object Notation) records, or database table entries to adapt to different validation toolchains and retrieval needs.

[0097] Through the above processing, the hexadecimal codes in the original command buffer are continuously converted into readable, traceable and reproducible semantic logs, enabling verifiers to quickly see the chip's register configuration status, command execution path and potential blocking causes at abnormal moments.

[0098] The general-purpose graphics processor command buffer parsing method provided in this application organizes configuration file parsing, data line identification, register address extraction, register name and function description extraction, and instruction parsing into a continuous data processing flow. This transforms the analysis work, which originally relied on manual switching between register documents, log files, and command format rules, into an automated process with unified rules, a clear structure, and repeatable execution. This reduces the uncertainty caused by manual searching and judgment, shortens the parsing cycle of complex command sequences, and improves the consistency of parsing results across different personnel, versions, and verification scenarios. Furthermore, the structured header file and parsing rules can be maintained independently. When the register document is updated, the chip version is adjusted, or the command format changes, only the corresponding configuration source or rule base needs to be updated to continue reusing the overall parsing framework. Therefore, it can balance accuracy, maintainability, and engineering scalability, providing a stable log restoration foundation for pre-silicon verification, driver integration, and anomaly localization of general-purpose graphics processors.

[0099] In one possible implementation, the configuration file containing general graphics processing command buffer register information is parsed, and the register information in the configuration file is extracted, including: parsing multiple configuration files one by one based on the file path array, and extracting the register information of each configuration file; the file path array is used to store the paths of the configuration files.

[0100] In this embodiment, the structured header file is used to carry the correspondence between register information such as register address, register name and register function description, and saves the register information in a form that can be directly read by the program, so that the parser can directly call it when processing the command buffer later.

[0101] In implementation, the parser first writes the file paths of multiple configuration files, such as XML files, into a file path array. The parser then opens the corresponding configuration file one by one according to the path in the file path array, reads and parses the contents of the configuration file, identifies the line containing register information, and extracts the relevant register information.

[0102] To adapt to register files of different chip versions and modules, the configuration file can be stored in text format. Each register record in the file can contain a name field, an address field, and a comment field. The name field stores the register name, the address field stores the register address, and the comment field stores a description of the register function to explain the register function. This can be written together when generating the structured header file to enhance readability.

[0103] The extracted register addresses can be stored as hexadecimal strings or converted to a uniform format before being written, ensuring consistency in format during subsequent matching. After summarizing the register information from multiple configuration files, a structured header file is generated. This structured file consists of a file header, the correspondence between the read register information, and a file footer. The file header is used to annotate the basic file attributes and version information, the correspondence between register information forms the main body, and the file footer indicates the end of the file.

[0104] By using an array of file paths from multiple configuration files, the system parses each configuration file to aggregate register information from multiple sources. The extracted register names, register addresses, and register function descriptions are stored in a structured header file format, which facilitates repeated calls during subsequent parsing and reduces the workload of manually searching for configuration information.

[0105] An extractor can be written in Python to extract the aforementioned register information from configuration files, such as XML files, and generate a structured header file. The extractor can first store the file paths of all XML files in an array (file path array) and extract and parse them one by one; it can also define the file header and footer content; save the parsing results of each XML file to form key-value pairs; create a new header file and write the file header content, key-value pairs (parsing results), and footer content sequentially to obtain the structured header file.

[0106] By adopting the above implementation method, register information from multiple configuration files can be uniformly organized into a structured header file, avoiding retrieval difficulties caused by scattered register definitions and improving the consistency and maintainability of address-name correspondence. Since the structured header file is saved in a form that can be directly read by the program, subsequent parsing of the command buffer can significantly reduce manual comparison errors, improve parsing efficiency, and enhance the reusability of configuration files across different projects and versions.

[0107] Based on the aforementioned embodiments, further, the register information of each configuration file is extracted, including: for each configuration file, based on predefined regular expressions, including name regular expressions, comment regular expressions and address regular expressions, the register name, register function description and register address of the configuration file are extracted respectively.

[0108] The register function descriptions are included as supplementary information in the structured header file. This allows the structured header file to simultaneously display supplementary information about the registers, such as their function descriptions, when read, facilitating verification personnel's quick understanding of the registers' purpose. Predefined regular expressions are parsing rules used to match the fixed text format of the configuration file. They can target specific fields, including address, name, and comment fields, thereby reliably extracting the required register information from different configuration files.

[0109] In the implementation, the file path array storing multiple configuration file paths is first read, and then the corresponding configuration files are opened sequentially. Each configuration file typically records register definition information in text format, with text lines arranged in a fixed order, usually recording the register name, register function description, and register address in that order. For this fixed format, regular expressions are pre-constructed to match the name, comment, and address fields, and pattern comparisons are performed on each line of text during parsing. When a text line matches the name, comment, and address fields simultaneously, the parsed three fields are written into the register information structure, forming a complete register record.

[0110] During the parsing process described above, regular expressions can be configured with error-tolerant matching modes to address common writing differences in different configuration files. For example, they can allow separators after name fields, allow register function descriptions to span a fixed length of text, and allow address fields to appear in hexadecimal representation. This design improves adaptability to different versions of configuration files and reduces omissions caused by subtle formatting differences.

[0111] After the register information in the configuration file is extracted, the records of each register are summarized and used as part of the input data for generating the structured header file, thereby ensuring that the register name, register function description and register address are consistently mapped between files.

[0112] This implementation uses regular expressions to extract fields from the configuration file, ensuring that register information is structured before subsequent processing. Because register function descriptions, register names, and register addresses are extracted and retained simultaneously, this information can be directly accessed when building the structured header file, avoiding the need to reread the original configuration file. This improves parsing consistency and reusability, and reduces the probability of omissions when manually organizing register data.

[0113] In one possible implementation, a structured header file is generated based on the extracted register information, including: generating a header file and a footer file; generating key-value pair information based on the extracted register names, register function descriptions, and register addresses from each configuration file; and sequentially writing the header file, key-value pair information, and footer file into the newly created header file to obtain the structured header file.

[0114] The header file defines the initial format of the new header file, typically including register function descriptions, header file compiler macros, referenced system header files, data structure definitions, and structure array variables storing register information. The footer contains a terminator to ensure file structure integrity. Key-value pairs are entries that organize the register names, register function descriptions, and register addresses extracted from various configuration files into entries that can be directly written into the header file. Each entry corresponds to a register definition, facilitating quick address and semantic lookup by name during subsequent parsing. Key-value pairs can use register addresses as keys and the combined result of register names and register function descriptions as values.

[0115] In actual implementation, after parsing multiple configuration files, the register information is first formatted, the register names are converted into identifiers that conform to the header file naming conventions, the register function descriptions are written into the description text of the corresponding lines, and the register addresses are converted into a unified base representation and organized into key-value pairs. Then, based on the file header and file footer content generated according to the preset template and the key-value pairs, a structured header file is generated.

[0116] The target file object can be created in memory, and register entries can be concatenated into key-value pairs in a predetermined order. Field alignment and line spacing are maintained during writing to improve readability and facilitate manual verification. After writing the file header content into a blank document, key-value pairs are written, and finally, file footer content is appended to generate a structured header file.

[0117] This structured header file consolidates the register semantics scattered across multiple configuration files into a unified file. This directly provides the mapping between register addresses and register names during subsequent file parsing, reducing the number of manual register document searches and lowering the probability of errors in address comparison and semantic interpretation. Because the header and footer content jointly constrain the file format, and key-value pairs are written continuously in a structured format, this header file exhibits good standardization, maintainability, and reusability. It facilitates rapid migration and use across different chip versions or verification projects, thereby improving command buffer parsing efficiency and consistency.

[0118] Figure 2 A schematic diagram of the register information extraction process provided in this application is shown below. Figure 2 As shown, the process mainly includes the following steps:

[0119] S201: Open the configuration file;

[0120] S202: Read a line from the configuration file; this step is used to read the contents of the configuration file line by line.

[0121] S203: Determine whether the register name has been found; if not, proceed to step S204; if yes, proceed to step S206.

[0122] It can be determined whether the corresponding flag bit is 1. If it is, then step S204 is executed; otherwise, step S206 is executed.

[0123] It can be determined whether the first part of the read line contains a register name; if so, the register name flag is set to indicate that a register name has been found, and the found register name is temporarily saved; if not, the register name flag remains at 0 to indicate that no register name has been found, and step S204 continues to determine whether the remaining parts contain register names, i.e., whether the second and third parts contain register names. The first part, the second part, and the third part can be the instruction operand segment, the source opcode segment, and the destination operand segment, respectively.

[0124] S204: Determine if a register name is contained; if yes, proceed to step S205; if no, proceed to step S212 to read the next line.

[0125] S205: Mark as discovered register name, extract register name and save temporarily; jump to step S212 to read the next line;

[0126] The discovery register name can be marked by setting the corresponding flag to 1.

[0127] S206: Determine whether annotation information has been found; if not, proceed to step S207; if yes, proceed to step S209.

[0128] It can be determined whether the corresponding flag bit is 1. If it is, then step S209 is executed; otherwise, step S207 is executed.

[0129] Upon discovering annotation information, the corresponding flag is set to 1 to indicate that annotation information has been discovered, and the discovered annotation information is temporarily saved; if no annotation information is discovered, the flag for discovering annotation information remains at 0 to indicate that no annotation information has been discovered.

[0130] S207: Determine whether there is comment information; if yes, proceed to step S208; if no, proceed to step S211 to clear the flag and delete the temporarily stored register name;

[0131] The comment information is the aforementioned register function description. It can be determined whether the second part of the read content contains comment information; if so, the corresponding flag is set to 1 and the comment information is temporarily saved; if not, it is marked as no register name and no comment information found, and the temporarily saved register name is deleted.

[0132] S208: Mark as found annotation information, extract the annotation information and save it temporarily; jump to step S212 to read the next line;

[0133] S209: Determine whether a register address is included; if yes, proceed to step S210; if no, proceed to step S211 to clear the flag and delete the temporarily stored register name and comment information.

[0134] It can determine whether the part excluding the register name and comment information contains the register address.

[0135] S210: Extract the register address, and use the discovered register address as the key and the integrated result of the discovered register name and comment information as the value to form a key-value pair and save it; and execute step S211 to clear the flag bit and delete the temporarily saved register name and comment information.

[0136] S211: Mark as no register name and no comment information found, and delete the temporarily stored information; the corresponding flag bits can be set to 0 to mark as no register name and no comment information found.

[0137] S212: Determine if there is a next row; if yes, return to step S202; if no, proceed to step S213.

[0138] S213: Close the configuration file.

[0139] In one possible implementation, in response to the user-inputted target path, the data lines in the log file to be parsed corresponding to the target path are identified, including:

[0140] In response to the user-inputted target path to be parsed, if the target path points to a directory, then the log files under the target path are identified;

[0141] Based on the identified log file path, read the log file to be parsed and identify the data lines within it;

[0142] If the target path points to a single log file, then based on the target path, the log file to be parsed is read and the data lines within it are identified.

[0143] In this embodiment, the target path is used to indicate the entry point to be parsed. After receiving the target path input by the user, the parsing program first determines the type of the path to identify whether it points to a directory or a single log file. A directory is used to hold multiple files, such as log files. After confirming that the target path is a directory, the parsing program identifies the log files within it based on file extensions, naming rules, or preset filtering conditions, and obtains the file paths of each log file. The file path is used to locate a specific file. The parsing program opens the corresponding log file based on the file path and reads the content line by line to identify the data lines. When the target path itself points to a single log file, the parsing program directly reads the content of the corresponding file to be parsed based on the target path and identifies the data lines within it.

[0144] In the specific implementation, a file system interface can be used to detect and determine the type of the target path. If the result is a directory, the file set under that directory is traversed, and files that meet the log format requirements are recorded as log files. The log file can be a text file, and its content usually contains command data lines, comment lines, and blank lines. When reading, data lines can be identified based on line beginning characteristics, line separators, predefined keywords, or hexadecimal data characteristics, and the data lines are stored in a memory buffer for subsequent register address extraction and instruction parsing.

[0145] If the target path points to a single log file, then there is no need for directory traversal; the file can be opened directly through the target path, and data row identification can be performed.

[0146] Furthermore, if the target path points neither to a directory nor to a single log file, an error will be reported.

[0147] For example, Figure 3 A flowchart of the process for obtaining the file path provided in this application is shown below. Figure 3 As shown, after obtaining the target path, the file path can be extracted using the following steps:

[0148] Determine if the target path is a directory type, i.e., if it points to a directory; if so, filter out all log files in the corresponding directory; check if a log file exists; if so, save the file path of the log file; otherwise, report an error.

[0149] If the target path is not a directory, then determine if the target path is a log file type, i.e., whether it points to a single log file; if so, save the target path, i.e., treat the target path as a file path; otherwise, report an error.

[0150] You can check the file attributes to determine whether the target path corresponds to a directory or a single log file, i.e., whether it points to a directory or a single log file.

[0151] This embodiment unifies directory recognition and single-file direct reading into a single data line recognition chain, enabling the parsing program to adapt to both batch log scenarios and single log scenarios. After file location is completed, the data lines to be parsed can be reliably extracted, providing an input basis for subsequent semantic parsing based on register information and avoiding reading differences and processing omissions caused by different file entry types. This specific implementation improves the adaptability of the files to be parsed, allowing the program to perform batch recognition of multiple log files in a directory or direct processing of a single log file, thereby reducing the workload of manual selection and repetitive configuration. Since data line recognition is completed under a unified file reading logic, it also reduces the probability of path processing errors and file omissions, improving the stability, continuity, and maintainability of command buffer parsing.

[0152] In one possible implementation, reading the log file to be parsed and identifying data lines includes: after successfully opening the log file to be parsed, reading the log file line by line; for each line read, determining whether the line contains a command start field; if so, saving the line content and marking it as a command start line; if not, determining whether the line contains a command end field; if so, saving the line content and marking it as a command end line; if not, determining whether the line is in a command data segment; the command data segment is defined by a set of command start lines and command end lines; if so, determining that the line is a data line and saving the line content.

[0153] The command start field identifies whether the current line corresponds to the start of a command. It is typically presented as a predefined characteristic string, a fixed prefix, or a specific marker in the log file, distinguishing the command start line from ordinary text. The command end field identifies whether the current line corresponds to the end of a command. Its determination criteria work in conjunction with the command start field to fully define the command scope within the same log file. The command data segment refers to a continuous area of ​​content located between a set of command start and command end lines; lines within this area are all components of the same command.

[0154] In the specific implementation, after the log file to be parsed is opened, the file reading module sequentially retrieves each line of text using a line-buffered approach, and sends the content of the current line (i.e., the read text) to the field recognition module for judgment. The field recognition module first performs string matching or pattern matching on the current line to determine if it contains a command start field. If a match is found, the data line determination module confirms the line as a command start line and writes its original content to the buffer or result set. If the current line does not contain a command start field, it continues to determine if it contains a command end field. If a match is found, the line is confirmed as a command end line and its content is saved synchronously. If the current line is neither a command start line nor a command end line, the status control module determines whether the current line is within the command data segment based on the recorded command start and end lines. If it is determined to be within the command data segment, the line is saved as a data line. This ensures that the command start and end marker lines and the continuous command content between them are fully included in the subsequent parsing scope.

[0155] In some embodiments, the content of comment lines that do not belong to the command data segment can also be saved so that the content of the comment lines can be inserted at the corresponding positions when generating the parsing log.

[0156] By combining line-by-line reading with status determination, the system automatically identifies command boundaries in the log file and uniformly saves the command start line, command end line, and content within the command data segment, thus forming a complete set of data lines. Its function is to accurately extract scattered command fragments from the original log, providing stable input for subsequent register address matching and instruction semantic parsing, and avoiding parsing deviations caused by missed reads, misjudgments, or unclear boundaries.

[0157] By adopting this specific implementation method, valid command lines in logs can be identified without relying on manual screening, reducing subjective judgment errors on command boundaries, improving the consistency and completeness of data line extraction, and shortening the processing time for complex logs. Since the command start line, command end line, and command data segment are all uniformly identified and saved, the subsequent parsing module can directly perform address extraction and semantic restoration based on the standardized data, thereby improving the efficiency and reliability of general-purpose graphics processor command buffer parsing.

[0158] In one possible implementation, the method further includes:

[0159] If the line is not in the command data segment, then the line is determined to be a comment line and its contents are saved.

[0160] Accordingly, based on the instruction type corresponding to the matched register name, the hexadecimal instruction is parsed, and a parsing log is generated, including:

[0161] Based on the instruction type corresponding to the matched register name, the hexadecimal instruction is parsed to obtain the parsing result of the corresponding data line;

[0162] A parsing log is generated based on the parsing results of the identified data rows and the saved comment lines.

[0163] In this embodiment, the comment line is used to carry explanatory text that does not directly correspond to the command data. Its content can be used to supplement the command source, debugging scenario, version information or human-marked information, and may also include functional descriptions.

[0164] When reading the file to be parsed line by line, if a line does not fall into the command data segment defined by the command start line and command end line, the line is determined to be a comment line, and the original content of the comment line is saved so that it can be output together with the data line parsing results later.

[0165] The parsing result of the corresponding data line refers to the semantic result obtained from the hexadecimal instruction and the instruction type corresponding to the register name for a single data line. It usually includes the register address, field meaning, parameter value and command action description, so that the original instruction can be restored into text information that is easy to analyze.

[0166] In the implementation, the file to be parsed is scanned line by line. Text lines that do not belong to the command data segment are directly saved as comment lines, which can be in the form of original strings, records with line numbers, or text blocks aggregated by paragraphs. Data lines within the command data segment continue to use the register names obtained from the previous matching, and are parsed according to the instruction type corresponding to that register name. During parsing, hexadecimal fields can be truncated, shifted, masked, and converted according to different instruction formats to generate the parsing result for the corresponding data line. Subsequently, the parsing result is concatenated with the previously saved comment line content, such as concatenating according to the original line numbers, to form a complete parsing log.

[0167] Comment lines can be placed before or after the data row parsing results, or inserted at command block boundaries to maintain the continuity of the log context. This way, the output log retains both the command semantics and any manually added information, making it easier for verifiers to trace the command source and locate anomalies by combining the context.

[0168] The working principle of this method is to separate and identify data lines and comment lines, then perform targeted parsing of the data lines according to the instruction type corresponding to the register name, and finally aggregate them at the log level. Since comment lines do not participate in instruction field calculations, irrelevant text can be avoided from interfering with the parsing results; while the parsing results of the data lines can complement the comment content, so that the log can not only reflect the execution meaning of the command itself, but also the context and explanatory information of the command in the file.

[0169] This implementation method improves the completeness and readability of the parsed logs, preserving descriptive content outside the command data segment and presenting it in conjunction with the data line parsing results. This reduces the number of times manual review of the original files is required and enhances the contextual tracing capability during problem localization. Furthermore, parsing based on the instruction type corresponding to the register name helps improve the consistency and accuracy of log generation, reducing the probability of misjudgments due to differences in human interpretation, thereby improving the efficiency and maintainability of the general-purpose graphics processor command buffer parsing process.

[0170] In one possible implementation, based on the parsing results of the identified data rows, a parsing log for the log file to be parsed is generated, including: sorting the saved rows in ascending order of row number to obtain a row sequence; traversing each row in the row sequence; if the currently traversed row is a comment row, then outputting the content of that row to the parsing log; if the currently traversed row is a data row, then outputting the parsing result of that row to the parsing log.

[0171] The line numbers record the original order of occurrence of each line in the file to be parsed, such as a log file. The line sequence is an ordered set obtained by sorting the saved comment lines and data lines by line number. The parsed log is used to restore the correspondence between comments and data in the original file and output text results that can be used for debugging and analysis. The instruction type indicates the parsing rules corresponding to the register name, so as to perform semantic restoration of hexadecimal instructions of different formats.

[0172] When traversing the current line of data, the parsing can be performed using the method provided in the aforementioned embodiments to obtain the parsing result of the data line. Specifically, this includes: extracting hexadecimal instructions from the data line and identifying the instruction type; if the instruction type is a register operation type, extracting the register address from the hexadecimal instructions in the data line; based on the extracted register address, extracting the register name and register function description from the structured header file, and parsing the hexadecimal instructions based on the extracted register name, register function description, and instruction type to obtain the parsing result of the data line.

[0173] In this implementation, after all lines of the log file to be parsed have been read, the saved line content along with the line numbers is cached, and then sorted by line number in ascending order to form a line sequence, ensuring that the output order is consistent with the original log. When traversing the line sequence, if the current line is detected as a comment line, the original text of that line is directly written to the parsing log; if the current line is detected as a data line, the hexadecimal instructions are extracted and the instruction type is identified. If the instruction type belongs to the register operation type, the register address is extracted, and then the register name and register function description are searched according to the structured header file. The corresponding parsing logic is called according to the identified instruction type, and the instruction is interpreted in combination with the searched register name and register function description to restore its semantics, obtain the parsing result, and write the parsing result to the parsing log.

[0174] For hexadecimal instructions that are not register operations, the corresponding rules can be invoked based on the specific instruction type to parse the instruction and obtain the parsing result.

[0175] For example, non-register operation type hexadecimal instructions may include LoadState, End, Nop, Wait, Link, Stall, ChipEnable, Fence, Link64, Fence64, and Wait64.

[0176] Based on the hexadecimal instructions in the extracted data line, it can sequentially determine whether the instruction type is LoadState, End, Nop, Wait, Link, Stall, ChipEnable, Fence, Link64, Fence64, Wait64, etc. If it is one of these types, it can be parsed according to the rules corresponding to that type to obtain the parsing result; and it can then determine whether there is a next line. If so, it can return to the instruction type determination step; otherwise, it can end.

[0177] This method, through a sorting-then-traversal organization, restores the sequential order of comment lines and data lines in the log, and outputs the comment content and the parsed instruction results continuously according to their original context, thus forming a complete parsed log. Since data line parsing relies on a structured header file formed from register information and the instruction types of hexadecimal instructions within it, it avoids the biases caused by relying solely on human experience to interpret hexadecimal instructions, improving the consistency and accuracy of the parsing results. Simultaneously, directly preserving the original text of the comment lines and outputting them synchronously with the parsing results enhances the readability and traceability of the command buffer log, facilitating verification personnel to quickly locate abnormal instructions and their contextual relationships.

[0178] Figure 4 A schematic diagram illustrating the data line and comment line identification process provided for this application, as shown below. Figure 4 As shown, after determining the file paths of each log file, the identification and saving of comment lines and data lines can be achieved through the following process:

[0179] S401: Read the log file based on the file path;

[0180] S402: Determine whether the log file was opened successfully; if yes, proceed to step S404; if no, proceed to step S414.

[0181] S403: Read the log file line by line;

[0182] S404: Determine if the row number is valid; if yes, proceed to step S405; if no, proceed to step S412.

[0183] S405: Determine whether a command start field is included; if yes, proceed to step S406; if no, proceed to step S407.

[0184] S406: Determine that this line is a comment line, save the content of this line and mark it as the command start line;

[0185] S407: Determine whether a command termination field is included; if yes, proceed to step S408; if no, proceed to step S409.

[0186] S408: Determine this line as a comment line, save the line content and mark it as a command termination line;

[0187] S409: Determine whether it belongs to the command data segment; if yes, proceed to step S410; if no, proceed to step S411.

[0188] S410: Determine that this row is a data row and save the content of this row;

[0189] S411: Determine that this line is a comment line and save its contents;

[0190] S412: Determine if there is a next row; if yes, return to step S404; if no, proceed to step S413.

[0191] S413: Close the log file;

[0192] S414: Determine if a next log file exists; if yes, return to step S401 to read the next log file; otherwise, end.

[0193] In this embodiment of the application, when parsing the general graphics processor command buffer, a structured header file containing the mapping relationship between register addresses, register names, and register function descriptions is first generated. An array of file paths storing multiple configuration file paths is taken as input. The configuration files are opened one by one according to the paths in the array, and register names, register addresses, and corresponding register function descriptions are extracted from each configuration file based on predefined regular expressions. After summarizing the register information extracted from each configuration file, a new structured header file is created. In this header file, the file header content is first written, then key-value pairs are generated based on each register name, register function description, and register address and written sequentially, and finally the file footer content is written, resulting in a structured header file used for subsequent matching, enabling the correspondence between register addresses and register names.

[0194] In one possible implementation, after receiving the target path input by the user, it is first determined whether the target path points to a directory or a single log file. If the target path points to a directory, the log files under that directory are identified, and the log files to be parsed are read one by one according to the identified log file path. If the target path points to a single log file, the log file to be parsed is read directly according to the target path. After the log file is successfully opened, the file content is read line by line in order. For each line, it is determined whether it contains a command start field. If it does, the line is identified as a data line, its content is saved, and it is marked as a command start line. If it does not contain a command start field, it is further determined whether it contains a command end field. If it does, the line is identified as a data line, its content is saved, and it is marked as a command end line. If it contains neither a command start field nor a command end field, it is determined whether the line is located within a command data segment. The command data segment is defined by a set of command start lines and command end lines. Lines within the command data segment are also identified as data lines and their content is saved. Lines not within the command data segment are identified as comment lines and their content is saved.

[0195] After all lines of a log file to be parsed have been read, the saved lines are sorted in ascending order of line number to form a line sequence. This line sequence is then traversed. When the current line is a comment line, its content is directly output to the parsing log. When the current line is a data line, the hexadecimal instruction is extracted from its stored content, and its instruction type is identified. If the instruction type is a register operation, the register address is extracted from the hexadecimal instruction. Based on this register address, the corresponding register name and register function description are matched from the aforementioned structured header file. Combined with the instruction type of the hexadecimal instruction, the hexadecimal instruction is parsed to obtain the parsing result for that data line. The parsing results for each data line are output to the parsing log in their original line order, forming the final parsing log along with the comment lines output during the traversal.

[0196] Figure 5 A schematic diagram of the parsing device for the general-purpose graphics processor command buffer provided in this application is shown below. Figure 5 As shown, the general-purpose graphics processor command buffer parsing device 50 provided in this embodiment includes:

[0197] The information extraction module 510 is used to parse the configuration file containing general graphics processing command buffer register information and extract the register information from the configuration file, including register name, register address and register function description; the header file generation module 520 is used to generate a structured header file based on the extracted register information; the data line recognition module 530 is used to identify the data line in the log file to be parsed corresponding to the target path input by the user; the instruction type recognition module 540 is used to extract hexadecimal instructions from the data line and identify the instruction type; the address extraction module 550 is used to extract the register address from the hexadecimal instruction in the data line if the instruction type is a register operation type; the instruction parsing module 560 is used to extract the register name and register function description from the structured header file based on the extracted register address, and parse the hexadecimal instruction based on the extracted register name, register function description and instruction type to obtain the parsing result of the data line; the parsing log generation module 570 is used to generate the parsing log of the log file to be parsed based on the parsing result of the identified data line.

[0198] In one possible embodiment, the information extraction module 510 is specifically used to: parse multiple configuration files one by one based on the file path array, and extract the register information of each configuration file; the file path array is used to store the paths of the configuration files.

[0199] In one possible embodiment, the information extraction module 510 is specifically used to: extract the register name, register function description and register address of each configuration file based on predefined regular expressions, including name regular expressions, comment regular expressions and address regular expressions.

[0200] In one possible embodiment, the header file generation module 520 is specifically used to: generate a header file containing header content and footer content; generate key-value pair information based on the extracted register names, register function descriptions, and register addresses of each configuration file; and sequentially write the header file content, key-value pair information, and footer content into the newly created header file to obtain a structured header file.

[0201] In one possible embodiment, the data line recognition module 530 is specifically configured to: respond to a target path to be parsed input by the user; if the target path points to a directory, identify log files under the target path; based on the file path of the identified log files, read the log files to be parsed and identify data lines therein; if the target path points to a single log file, read the log files to be parsed and identify data lines therein based on the target path.

[0202] In one possible embodiment, when reading the log file to be parsed and identifying data lines, the data line identification module 520 is specifically configured to: after successfully opening the log file to be parsed, read the log file line by line; for each line read, determine whether the line contains a command start field; if so, determine that the line is a data line, save the line content and mark it as a command start line; if not, determine whether the line contains a command end field; if so, determine that the line is a data line, save the line content and mark it as a command end line; if not, determine whether the line is in a command data segment; the command data segment is defined by a set of command start lines and command end lines; if so, determine that the line is a data line and save the line content.

[0203] In one possible embodiment, the device further includes a comment line saving module, configured to: determine that the line is a comment line and save the line content if the line is not in the command data segment.

[0204] Correspondingly, the parsing log generation module 570 is used to generate parsing logs based on the parsing results of the identified data rows and the saved comment line content.

[0205] In one possible embodiment, the parsing log generation module 570 is specifically used for: a sorting module, which sorts the saved line content in ascending order of line number to obtain a line sequence; traversing each line in the line sequence; if the currently traversed line is a comment line, then outputting the content of that line to the parsing log; if the currently traversed line is a data line, then outputting the parsing result of that line to the parsing log.

[0206] In one possible embodiment, the instruction parsing module 560 is further configured to: if the instruction type is a non-register operation type, parse the hexadecimal instruction of the data line according to the parsing rules corresponding to the instruction type to obtain the parsing result of the data line.

[0207] The parsing device for the general graphics processor command buffer provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0208] Figure 6 A schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0209] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0210] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0211] This electronic device stores the computer execution instructions used to implement the above methods in its memory, which are then directly called and executed by the processor. This enables register access control, host-machine collaborative processing, and virtual client interaction processes in GPGPU virtualization scenarios to be implemented on a unified hardware platform. This transforms the access path organization, task state handling, and resource isolation mechanisms in the methods into executable operations, reducing the overhead of additional manual configuration and distributed implementation, and making register read / write responses more timely in multi-tenant environments. Furthermore, in cloud computing, AI training, and parallel graphics processing scenarios, it improves throughput, execution stability, and resource management efficiency when sharing physical GPUs, thus helping to balance isolation between virtual clients and overall acceleration performance.

[0212] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0213] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0214] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0215] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0216] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0217] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0218] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0219] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0220] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0221] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0222] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0223] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0224] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for parsing a general-purpose graphics processor command buffer, characterized in that, include: Parse the configuration file containing general graphics processing command buffer register information, and extract the register information from the configuration file, including register name, register address and register function description; Based on the extracted register information, a structured header file is generated; In response to the target path input by the user, identify the data line in the log file to be parsed corresponding to the target path; Extract hexadecimal instructions from the data rows and identify the instruction type; If the instruction type is a register operation type, then the register address is extracted from the hexadecimal instruction of the data line; Based on the extracted register address, the register name and register function description are extracted from the structured header file, and the hexadecimal instruction is parsed based on the extracted register name, register function description and instruction type to obtain the parsing result of the data line; Based on the parsing results of the identified data rows, a parsing log is generated for the log file to be parsed.

2. The method according to claim 1, characterized in that, The parsing process involves analyzing a configuration file containing general graphics processor register information and extracting the register information from the configuration file, including: Based on the file path array, the multiple configuration files are parsed one by one to extract the register information of each configuration file; the file path array is used to store the paths of the configuration files.

3. The method according to claim 2, characterized in that, The register function description describes the extraction of register information from each of the configuration files, including: For each configuration file, the register name, register function description, and register address are extracted based on predefined name regular expressions, comment regular expressions, and address regular expressions, respectively.

4. The method according to claim 1, characterized in that, The generation of a structured header file based on the extracted register information includes: Generate a file containing a file header and a file footer; The extracted register names, register function descriptions, and register addresses from each of the aforementioned configuration files are used to generate key-value pairs. The file header content, the key-value pair information, and the file footer content are written sequentially into the newly created header file to obtain the structured header file.

5. The method according to claim 1, characterized in that, The step of responding to the user-inputted target path and identifying the data line in the log file corresponding to the target path includes: In response to the user-inputted target path to be parsed, if the target path points to a directory, then the log files under the target path are identified; Based on the identified log file path, read the log file to be parsed and identify the data lines within it; If the target path points to a single log file, then based on the target path, the log file to be parsed is read and the data lines within it are identified.

6. The method according to claim 5, characterized in that, The process of reading the log file to be parsed and identifying data lines includes: After successfully opening the log file to be parsed, read the log file line by line. For each line read, determine whether the line contains the command start field; If so, save the contents of that line and mark it as the command start line; If not, then determine whether the line contains a command termination field; If so, save the contents of that line and mark it as the command termination line; If not, then determine whether the line is in the command data segment; the command data segment is defined by a set of command start lines and command end lines; If so, then determine that the row is a data row and save the content of that row.

7. The method according to claim 6, characterized in that, The method further includes: If the line is not in the command data segment, then the line is determined to be a comment line and its contents are saved; The parsing results based on the identified data rows generate the parsing log of the log file to be parsed, including: Based on the parsing results of the identified data rows and the content of the saved comment rows, a parsing log is generated for the log file to be parsed.

8. The method according to claim 7, characterized in that, The parsing result based on the identified data lines generates hexadecimal instructions for parsing the log file to be parsed, including: Sort the saved lines of content in ascending order of line number to obtain the line sequence; Iterate through each row in the row sequence; If the currently traversed line is a comment line, then output that line to the parsing log. If the current line being traversed is a data line, then the hexadecimal instruction will parse the result of that line and output it to the parsing log.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: If the instruction type is a non-register operation type, the hexadecimal instruction of the data line is parsed according to the parsing rules corresponding to the instruction type to obtain the parsing result of the data line.

10. A parsing device for a general-purpose graphics processor command buffer, characterized in that, include: The information extraction module is used to parse the configuration file containing general graphics processing command buffer register information and extract the register information in the configuration file, including register name, register address and register function description. The header file generation module is used to generate structured header files based on the extracted register information; The data line recognition module is used to identify the data lines in the log file to be parsed corresponding to the target path input by the user. The instruction type identification module is used to extract hexadecimal instructions from the data row and identify the instruction type. The address extraction module is used to extract the register address from the hexadecimal instruction of the data line if the instruction type is a register operation type. The instruction parsing module is used to extract register names and register function descriptions from the structured header file based on the extracted register addresses, and to parse the hexadecimal instructions based on the extracted register names, register function descriptions and the instruction type to obtain the parsing results of the data lines. The parsing log generation module is used to generate parsing logs for the log file to be parsed based on the parsing results of the identified data rows.

11. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-9.

Images