Graphical driver debugging method and device, graphical processor simulation model, equipment, medium

Abstract

The present disclosure provides a graphics driver debugging method and device, a graphics processor simulation model, equipment and a medium, and relates to the technical field of graphics processor modeling simulation. The method comprises the following steps: obtaining a call association relationship and a target call identifier, the call association relationship being used to represent a mapping relationship between batch calls and a graphics application interface and a graphics driver command, and the target call identifier being a call identifier associated with abnormal execution result data; matching a current batch call, a current graphics driver command and a current graphics application interface in a graphics processor simulation model running process according to the target call identifier and the call association relationship; and in the case of successful matching, outputting a corresponding process log. The present scheme can associate abnormal execution result data to a specific batch call, and selectively output a process log based on the call association relationship, thereby reducing log screening complexity, improving the accuracy of graphics driver problem positioning and the debugging efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of graphics processor modeling and simulation technology, and more specifically, to a graphics driver debugging method and apparatus, a graphics processor simulation model, a device, and a medium. Background Technology

[0002] Graphics Processing Units (GPUs), as the core hardware units used to perform graphics rendering calculations, are widely used in image display and graphics processing in various electronic devices. During the design and verification phases of GPU chips, especially in the pre-silicon development stage, it is typically necessary to build GPU simulation models using software modeling to perform functional-level verification of the graphics rendering pipeline. On the one hand, this simulation model can verify the functional correctness of the GPU architecture design before the hardware is fabricated; on the other hand, it can also provide a runtime environment for the early development of graphics drivers, thereby supporting the collaborative design and verification process of software and hardware.

[0003] Currently, in related technologies, due to the multi-level processing relationships between the graphics application programming interface, graphics driver commands, and batch calls, it is difficult to establish a direct correspondence between the final output test logs or rendered images and the specific intermediate calls. When pixel color errors or image anomalies occur, it is difficult to determine the calling link from which the problem originates in a timely manner. In order to obtain more granular information, it is usually necessary to enable full logging, but the log size is huge and the filtering is complex, which not only increases the analysis burden but also easily affects debugging efficiency, thereby extending the overall verification cycle.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this disclosure is to provide a graphics driver debugging method and apparatus, a graphics processor simulation model, a device, and a medium, which can selectively output process logs, thereby reducing the analysis complexity during the debugging process and improving the accuracy and efficiency of problem location.

[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0007] According to a first aspect of the present disclosure, a graphics driver debugging method is provided, comprising: Obtain the call association and target call identifier. The call association is used to characterize the mapping relationship between batch calls and graphics application programming interfaces and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model. Based on the target call identifier and call association, the current batch call, current graphics driver command, and current graphics application interface are matched during the execution of the graphics processor simulation model; If a match is successful, the process log corresponding to the current batch call, current graphics driver command, and current graphics application interface that were matched is output. The process log is used to debug the graphics driver.

[0008] According to a second aspect of the present disclosure, a graphics driver debugging apparatus is provided, comprising: The target identifier acquisition module is used to acquire the call association relationship and the target call identifier. The call association relationship is used to characterize the mapping relationship between batch calls and the graphics application programming interface and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model. The matching module is used to match the current batch calls, current graphics driver commands, and current graphics application interfaces during the execution of the graphics processor simulation model based on the target call identifier and call association. The log output module is used to output the process logs corresponding to the current batch call, the current graphics driver command, and the current graphics application interface when a match is successful. The process logs are used for debugging the graphics driver.

[0009] According to a third aspect of the present disclosure, a graphics processor simulation model is provided, comprising: The graphics rendering unit is used to receive batch calls to rendering tasks generated by the graphics driver and execute the graphics driver commands in the batch calls to generate rendering execution result data corresponding to the batch calls. The resource copy unit is used to receive batch calls to resource copy tasks generated by the graphics driver, and execute the graphics driver commands in the batch calls to generate resource copy result data corresponding to the batch calls. The batch call rendering module is used to associate batch calls with the execution result data generated by the graphics rendering unit and / or resource copying unit based on the call identifier corresponding to the batch call, and output the execution result data according to the call identifier; The call marker module is used to obtain call associations and target call identifiers, and to match the current batch calls, current graphics driver commands, and current graphics application interfaces during the execution of the graphics processor simulation model based on the target call identifier and call associations. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The log unit is used to output the process log corresponding to the current batch call, the current graphics driver command, and the current graphics application interface when the call marker module is successfully matched, so as to debug the graphics driver.

[0010] According to a fourth aspect of the present disclosure, an electronic device is provided, including: a processor; and a memory storing computer-readable instructions, which, when executed by the processor, implement the graphics driver debugging method of the first aspect.

[0011] According to a fifth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the graphics driver debugging method of the first aspect.

[0012] The technical solutions provided in this disclosure can include the following beneficial effects: The graphics driver debugging method in the example embodiments of this disclosure, on the one hand, represents the mapping relationship between batch calls, graphics application programming interfaces (APIs), and graphics driver commands by calling association relationships, and associates batch calls and their execution result data by calling identifiers, so that the execution result data can be traced back to the corresponding batch calls. This reduces the scope of analysis for reverse searching of erroneous calls from the final result when pixel color anomalies, texture anomalies, depth test anomalies, or image anomalies occur, thereby improving the accuracy of problem localization. On the other hand, by using target calling identifiers and calling association relationships, the current batch calls, current graphics driver commands, and current APIs in the graphics processor simulation model operation process are matched, and the corresponding process logs are output when the match is successful. This changes the process log from full output to selective output of anomaly-related calling links, thereby reducing the log data size, reducing log filtering complexity, and improving graphics driver debugging efficiency. Furthermore, by outputting rendering result images, rendering intermediate buffer data, and resource copy result data according to calling identifiers, the execution results under different task types can be organized and viewed at the batch call granularity, thereby further narrowing the scope of anomaly investigation and improving the overall debugging efficiency in the graphics processor functional verification process.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. Figure 1 The schematic diagram illustrates a flowchart of a graphics-driven debugging method according to some embodiments of the present disclosure; Figure 2 The schematic diagram illustrates a process log output via double matching according to some embodiments of the present disclosure; Figure 3 This schematically illustrates a process log of an abnormal call being output in a graphics processor simulation model according to some embodiments of the present disclosure. Figure 4 The schematic diagram illustrates the composition of a graphics-driven debugging apparatus according to some embodiments of the present disclosure; Figure 5 This schematically illustrates a functional configuration diagram of a graphics processor simulation model according to some embodiments of the present disclosure; Figure 6 The schematic diagram illustrates the structural schematic of a computer system of an electronic device according to some embodiments of the present disclosure; Figure 7 A schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure is shown.

[0015] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0016] 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 denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification.

[0017] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “described,” and “the” as used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0018] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0019] Furthermore, the accompanying drawings are for illustrative purposes only and are not necessarily drawn to scale. The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0020] In this embodiment, a graphics driver debugging method is first provided. This graphics driver debugging method can be applied to modeling and simulation host devices, as well as to electronic devices running graphics processor simulation models. This embodiment does not impose any special limitations on this method. Figure 1 The schematic diagram illustrates a flowchart of a graphics-driven debugging method according to some embodiments of the present disclosure. Reference Figure 1 As shown, the graphics driver debugging method may include the following steps: Step S110: Obtain the call association relationship and the target call identifier. The call association relationship is used to characterize the mapping relationship between batch calls and the graphics application programming interface and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model.

[0021] Step S120: Match the current batch call, current graphics driver command, and current graphics application interface during the execution of the graphics processor simulation model based on the target call identifier and call association.

[0022] Step S130: If the match is successful, output the process log corresponding to the current batch call, current graphics driver command and current graphics application interface that were successfully matched. The process log is used to debug the graphics driver.

[0023] According to the graphics driver debugging method in this example embodiment, on the one hand, the mapping relationship between batch calls, graphics application programming interfaces (APIs), and graphics driver commands is represented by the call association relationship. Batch calls and their execution result data are associated with call identifiers, allowing the execution result data to be traced back to the corresponding batch calls. This reduces the scope of analysis for reverse-engineering erroneous calls from the final result when pixel color anomalies, texture anomalies, depth test anomalies, or image anomalies occur, improving the accuracy of problem localization. On the other hand, the current batch calls, current graphics driver commands, and current APIs in the graphics processor simulation model's operation are matched using the target call identifier and call association relationship. When a match is successful, the corresponding process log is output, transforming the process log from full output to selective output based on the anomaly-related call chain. This reduces the log data size, lowers log filtering complexity, and improves graphics driver debugging efficiency. Furthermore, by outputting the rendering result image, rendering intermediate buffer data, and resource copy result data according to the call identifier, the execution results under different task types can be organized and viewed at the batch call granularity, further narrowing the scope of anomaly investigation and improving the overall debugging efficiency during the graphics processor functional verification process.

[0024] The graphics driver debugging method in this example embodiment will be further explained below.

[0025] In step S110, the call association relationship and the target call identifier are obtained. The call association relationship is used to characterize the mapping relationship between batch calls and graphics application programming interfaces and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model.

[0026] In one example embodiment of this disclosure, the graphics driver may be a driver program that runs on the host side and is used to respond to calls from the graphics application programming interface (API). Its function is to convert the graphics workload described by the upper-layer graphics application programming interface into graphics driver commands that can be recognized and executed by the graphics processor simulation model.

[0027] A graphics processor simulation model refers to a simulation runtime environment built through software modeling during the pre-silicon verification stage. It can include functional units such as graphics rendering units, resource copying units, and logging units, and simulates the data interaction process between graphics drivers and graphics processors through these functional units.

[0028] The graphics application programming interface (API) can be understood as the interface call from the upper-layer application to the graphics driver to submit tasks such as rendering, resource binding, resource copying, or state setting; the graphics driver command can be understood as the command data formed by the graphics driver after parsing and converting the graphics application programming interface, which can be recognized by the graphics processor simulation model; batch calling can be understood as the graphics driver or firmware side assembling one or more graphics driver commands according to the submission strategy and submitting them to the execution unit of the graphics processor simulation model.

[0029] The call association can be represented as an identifier mapping table, a call chain table, a context record table, or a data structure with hierarchical indexes, as long as it can characterize the mapping relationship between batch calls and the graphics application programming interface (API) and graphics driver commands. For example, when the graphics driver converts the API into graphics driver commands, the correspondence between the API and the commands can be recorded; when one or more commands are assembled into a batch call, the correspondence between the commands and the batch call can be recorded. Based on these correspondences, a call association can be formed between batch calls, graphics driver commands, and the API. In this way, even if the graphics driver splits, merges, or rearranges an API, its actual execution location in the graphics processor simulation model can be tracked based on the call association.

[0030] A call identifier can be understood as index information used to uniquely or at least distinguishably mark a batch call. The call identifier is neither the execution result data itself, nor the overall number resulting from the combination of the batch call and the execution result data, but rather an identifier key used to establish a unified index relationship between the batch call and the execution result data. The call identifier can be generated when the graphics processor simulation model receives a call marking instruction for a batch call, when the batch call enters the front-end module of the corresponding task unit, or when the batch call is confirmed for execution. The call identifier can be generated using methods such as incrementing counter values, time-sequential numbering, queue sequence numbers, or composite numbers formed by combining task type and sequence number, as long as it allows for a traceable relationship between the subsequently generated execution result data and the corresponding batch call. This embodiment is not limited to these methods.

[0031] Execution result data refers to data generated during or after the execution of a batch call in a graphics processor simulation model, which characterizes the execution status or result. For rendering tasks, execution result data may include frame buffer data, rendered image, depth buffer data, stencil buffer data, or other intermediate rendering buffer data; for resource copying tasks, execution result data may include texture data, buffer data, or other resource copy result data. When establishing the association, the call identifier can be written into the file name, index field, metadata information, cache description information, or output path of the execution result data. Alternatively, the correspondence between the call identifier and the execution result data storage address can be recorded in a separate association table. Through the above processing, the execution result data no longer exists merely as an isolated final output, but can be traced back to the batch call that generated the execution result data.

[0032] The target call identifier is the call identifier associated with the execution result data that contains anomalies. Anomalies in the execution result data can include pixel color errors, missing images, texture errors, depth test anomalies, template test anomalies, resource copy anomalies, or other execution result anomalies. The target call identifier can be determined by developers based on the arrangement and display results of multiple execution result data, or it can be determined by automated detection logic based on image comparison rules, pixel difference detection rules, buffer anomaly detection rules, or resource data verification rules. After determining the target call identifier, it can be written to the configuration file of the graphics processor simulation model. During the runtime of the graphics processor simulation model, the target call identifier is read from the configuration file for subsequent call matching and process log output.

[0033] In step S120, the current batch call, current graphics driver command, and current graphics application interface in the graphics processor simulation model operation are matched according to the target call identifier and call association relationship.

[0034] In one example embodiment of this disclosure, the target call identifier can correspond to a target batch call. The target batch call can be a batch call that generates abnormal execution result data, or a suspected abnormal batch call corresponding to the abnormal execution result data. After determining the target batch call, the target graphics driver command and target graphics application interface associated with the target batch call can be determined based on the call association relationship. The target graphics driver command can be a graphics driver command included in the target batch call, and the target graphics application interface can be a graphics application interface that has a mapping relationship with the target graphics driver command.

[0035] During the re-running or continued execution of the graphics processor simulation model, the current batch call, the current graphics driver command, and the current graphics application programming interface (API) can be matched. The current batch call refers to the batch call currently received or executed during the execution of the graphics processor simulation model; the current graphics driver command is the graphics driver command associated with the current batch call; and the current API is the API corresponding to the current graphics driver command. By matching the target batch call, target graphics driver command, and target API with the current batch call, current graphics driver command, and current API, it can be determined whether the current execution process has hit a call chain related to the abnormal execution result data.

[0036] Understandingly, the current batch call is not limited to a batch call currently executing at a specific moment, but can be understood as a batch call that enters the matching process during the execution, scheduling, playback, reproduction, or log correlation analysis of the graphics processor simulation model. Specifically, the current batch call can include batch calls currently received by the graphics processor simulation model, currently scheduled batch calls, currently executing batch calls, batch calls that have been completed and are read for matching, or historical batch calls currently being traversed during simulation playback. Correspondingly, the current graphics driver command can include graphics driver commands associated with the current batch call that are currently parsed, currently scheduled, currently executed, currently completed and read for matching, or currently traversed during simulation playback; the current graphics application programming interface can include the graphics application programming interface corresponding to the current graphics driver command, determined according to the call association relationship.

[0037] It should be noted that the use of "current" in this embodiment is not intended to limit the matching to the instant when the batch call is being executed, but rather to distinguish between the objects to be matched in the matching process and the target objects corresponding to the target call identifier. In other words, the target batch call, the target graphics driver command, and the target graphics application interface can be the target call chain determined based on abnormal execution result data; the current batch call, the current graphics driver command, and the current graphics application interface can be the call chains to be matched that are extracted one by one and compared with the target call chain during the running, reproduction, playback, or analysis of the graphics processor simulation model. As long as the batch call, graphics driver command, and graphics application interface entering the matching process can be matched with the target call chain according to the target call identifier and call association, and the corresponding process log is output when the matching is successful, all of these are implementation methods of the current batch call, the current graphics driver command, and the current graphics application interface in this disclosure embodiment.

[0038] In an optional implementation, the current batch call can be first matched with the target batch call. For example, the call identifier corresponding to the current batch call can be compared with the target call identifier, or the batch call sequence number, task type, queue sequence number, or other batch description information of the current batch call can be compared with the target batch call. If the first match is successful, the current graphics driver command and the current graphics application interface associated with the successfully matched current batch call can be determined according to the call association relationship, and the current graphics driver command can be matched with the target graphics driver command, and the current graphics application interface can be matched with the target graphics application interface. If the current graphics driver command and the target graphics driver command match successfully, and the current graphics application interface and the target graphics application interface match successfully, the second match can be determined to be successful, and the successfully matched current batch call, current graphics driver command, and current graphics application interface can be obtained.

[0039] In step S130, if a match is successful, the process log corresponding to the current batch call, current graphics driver command, and current graphics application interface that were successfully matched is output. The process log is used to debug the graphics driver.

[0040] In an example embodiment of this disclosure, the process log may include at least one of the following: execution process information of the current batch call, parsing information of the current graphics driver command, scheduling information or execution status information, and graphics driver processing information corresponding to the current graphics application programming interface (API). The execution process information of the current batch call may include information such as the batch call reception time, execution time, task type, execution unit, context state, resource binding status, or execution completion status. The parsing information of the current graphics driver command may include information such as command type, command fields, resource references, status parameters, or parsing results. The scheduling information of the current graphics driver command may include information such as command entering the queue, command dequeueing, command dispatch, command execution order, or command dependency status. The execution status information of the current graphics driver command may include information such as command execution success, execution failure, waiting for resources, status exception, or output exception. The graphics driver processing information corresponding to the current API may include information such as the graphics driver's parsing, conversion, status setting, resource binding, command generation, or submission processing of the API.

[0041] Before a successful match, the output of process logs corresponding to the current batch calls, current graphics driver commands, and current graphics application programming interfaces (APIs) can be suppressed or reduced, keeping the graphics processor simulation model in a non-target log output state. After a successful match, the output of process logs corresponding to the successfully matched current batch calls, current graphics driver commands, and current APIs can be enabled, allowing the graphics processor simulation model to enter the target log output state. This avoids outputting a large amount of irrelevant logs throughout the simulation run, only outputting process logs for graphics driver debugging when the target call chain is hit.

[0042] Outputting process logs can be done in several ways, including displaying them in the debug terminal, writing them to a log file, storing them in association with the target call identifier, or writing them together with the call identifier corresponding to the exception execution result data to the debug database. Process logs can be organized according to the hierarchical relationship between the current batch of calls, the current graphics driver command, and the current graphics application interface, or according to chronological order, call identifier order, or task execution order. This allows driver developers to directly view the graphics driver processing in the call chain corresponding to the exception execution result data based on the process logs, thereby quickly locating the source of the exception.

[0043] Through the above implementation method, a traceable relationship can be established between execution result data and batch calls, and the batch calls can be further mapped to graphics driver commands and graphics application programming interfaces using the call association relationship. In this way, when anomalies occur in the execution result data, the corresponding call chain can be hit during the operation of the graphics processor simulation model by using the target call identifier and call association relationship, and the process log corresponding to the call chain can be selectively output, reducing the output of irrelevant logs and the workload of manual screening, and improving the targeting and efficiency of graphics driver debugging.

[0044] The contents of steps S110 to S130 will be described in detail below.

[0045] In one example embodiment of this disclosure, the following steps can be used to match the current batch call, the current graphics driver command, and the current graphics application programming interface during the execution of the graphics processor simulation model based on the target call identifier and call association relationship. Specifically, these steps may include: Identify the target batch call corresponding to the target call identifier, and determine the target graphics driver command and target graphics application interface associated with the target batch call based on the call association relationship; match the target batch call, target graphics driver command, and target graphics application interface with the current batch call, current graphics driver command, and current graphics application interface to obtain the successfully matched current batch call, current graphics driver command, and current graphics application interface.

[0046] The target call identifier can serve as an index for the target batch call. Since the execution result data has already been associated with the corresponding batch call through the call identifier, after identifying abnormal execution result data, the target batch call can be determined based on the target call identifier associated with that execution result data. The target batch call can be a batch call that generates abnormal execution result data in the graphics processor simulation model, or a suspected abnormal batch call determined based on the abnormal execution result data. For example, when a rendered image first shows abnormal pixel color, missing texture, or incorrect image content, the call identifier corresponding to that rendered image can be used as the target call identifier, and the target batch call that generated that rendered image can be determined based on the target call identifier. Similarly, when a depth buffer data, stencil buffer data, or resource copy result data is abnormal, the call identifier corresponding to that abnormal data can also be used as the target call identifier, and the target batch call can be determined accordingly.

[0047] After identifying the target batch call, the target graphics driver commands and target graphics application programming interfaces (APIs) associated with the target batch call can be further determined based on the call association. The call association characterizes the mapping relationship between batch calls and the APIs and graphics driver commands. Therefore, based on the target batch call, one or more target graphics driver commands that assemble to form the target batch call can be traced back, and the target APIs that generate these one or more target graphics driver commands can be further determined. The target graphics driver commands can be commands included in the target batch call, or a set of commands that have a mapping relationship with the target batch call; the target graphics application programming interface can be an interface call that directly generates the target graphics driver commands, or an interface call that has an upstream correspondence with the target graphics driver commands.

[0048] During the execution of the graphics processor simulation model, the current batch call, current graphics driver command, and current graphics application programming interface (API) can be obtained and matched with the target batch call, target graphics driver command, and target API. The current batch call can be the batch call currently received, scheduled, or executed by the graphics processor simulation model; the current graphics driver command can be the graphics driver command contained in or associated with the current batch call; and the current graphics application programming interface can be the graphics application programming interface associated with the current graphics driver command, determined based on the call association relationship.

[0049] In one implementation, the target batch call can be determined first based on the target call identifier, and then the target graphics driver command and target graphics application programming interface (API) corresponding to the target batch call can be determined based on the call association relationship, thereby forming a target call chain. During the operation of the graphics processor simulation model, the current batch call, the current graphics driver command, and the current API can be combined to form the current call chain, and the current call chain can be compared with the target call chain. When the current batch call matches the target batch call, the current graphics driver command matches the target graphics driver command, and the current API matches the target API, a successful match can be determined, and the successfully matched current batch call, current graphics driver command, and current API can be obtained.

[0050] After determining the target call identifier corresponding to the abnormal execution result data, the target batch call, target graphics driver command, and target graphics application programming interface are further determined by utilizing the call association relationship. This allows the target call identifier to no longer be used only to locate a specific batch call, but also to locate the upstream and downstream related objects of that batch call in the graphics driver processing chain. In this way, when matching is performed during the operation of the graphics processor simulation model, the current running process can be located simultaneously from three levels: batch call, graphics driver command, and graphics application programming interface. This improves the accuracy of the process log output objects and reduces the possibility of irrelevant call chains being falsely hit.

[0051] In one example embodiment of this disclosure, it can be achieved through Figure 2 The steps described in the document involve matching the target batch call, target graphics driver command, and target graphics application programming interface (API) with the current batch call, current graphics driver command, and current graphics application programming interface (API), to obtain the successfully matched current batch call, current graphics driver command, and current graphics application programming interface. (See reference...) Figure 2 As shown, it can specifically include: Step S210: Perform a first match between the current batch call and the target batch call; Step S220: If the first match is successful, determine the current graphics driver command and the current graphics application interface associated with the current batch of calls that were successfully matched in the first match according to the call association relationship, and perform a second match between the current graphics driver command and the target graphics driver command, and between the current graphics application interface and the target graphics application interface. Step S230: If the current graphics driver command and the target graphics driver command are successfully matched, and the current graphics application interface and the target graphics application interface are successfully matched, the second match is determined to be successful, and the currently matched batch call, the current graphics driver command, and the current graphics application interface are obtained.

[0052] The first match can be a batch call granularity match. During operation, the graphics processor simulation model can obtain the current batch call according to the receiving order, execution order, or task queue order, and determine the current call identifier corresponding to the current batch call. Since the target call identifier is the call identifier associated with the execution result data that has an anomaly, the current call identifier corresponding to the current batch call can be compared with the target call identifier. When the current call identifier and the target call identifier are the same, it can be determined that the current batch call and the target batch call have matched successfully, that is, the first match is successful. When the current call identifier and the target call identifier are not the same, it can be determined that the current batch call is not the target batch call, and it can continue to maintain the non-target log output state, or continue to wait for the next batch call to enter the matching process.

[0053] The first matching can also be aided by batch description information. Batch description information may include at least one of the following: batch call sequence number, task type, queue identifier, context identifier, graphics-driven command list, or execution unit identifier. For example, if the current call identifier matches the target call identifier, it can be further determined whether the task type of the current batch call matches the task type of the target batch call, or whether the graphics-driven command list corresponding to the current batch call matches the graphics-driven command list corresponding to the target batch call. Through these auxiliary judgments, false matches caused by identifier reuse, context switching, or parallel execution of multiple queues can be reduced.

[0054] Upon successful initial matching, the current graphics driver command and the current graphics application programming interface (API) associated with the current batch of calls can be determined based on the call association relationship. Specifically, one or more current graphics driver commands corresponding to the current batch of calls can be queried based on the call association relationship, and then the current graphics application programming interface (API) corresponding to the current graphics driver command can be queried based on the call association relationship. The call association relationship can include the correspondence between batch call identifiers and graphics driver command identifiers, or the correspondence between graphics driver command identifiers and graphics application programming interface identifiers, or a link record consisting of batch calls, graphics driver commands, and graphics application programming interfaces. Based on this call association relationship, after the target object is hit at the batch call level, the graphics driver command and graphics application programming interface corresponding to the current running process can be further traced.

[0055] The second matching can be between graphics driver commands and graphics application programming interfaces (APIs). Specifically, the current graphics driver command can be compared with the target graphics driver command, and the current graphics application programming interface can be compared with the target graphics application programming interface. The second matching is considered successful when both the current and target graphics driver commands match successfully. Matching between graphics driver commands can be based on command identifiers, command sequence numbers, command types, command fields, resource reference relationships, or the command's position within a batch; matching between graphics application programming interfaces can be based on interface identifiers, interface types, interface call sequence numbers, interface parameters, or interface context.

[0056] The second matching can be used to further confirm whether the current running process is consistent with the graphics driver processing link corresponding to the abnormal execution result data, based on the successful matching of batch calls. For example, a batch call may be assembled from multiple graphics driver commands, and different graphics driver commands may correspond to different graphics application programming interfaces (APIs). If matching is only based on batch calls, the output scope of the process log may still cover multiple command processing links in the batch call; by further performing a second matching on the current graphics driver command and the current graphics application programming interface, the log output scope can be further limited to the processing link corresponding to the target graphics driver command and the target graphics application programming interface, thereby improving the relevance of the log output.

[0057] When the second match is successful, the current batch call, current graphics driver command, and current graphics application programming interface (API) of the successfully matched data can be obtained, and this matching result can be used as the trigger condition for outputting the process log. In other words, the graphics processor simulation model can allow the log unit to output the process log corresponding to the current batch call, current graphics driver command, and current API only after both the first and second matches are successful; if the first match fails, or if the first match succeeds but the second match fails, the corresponding process log may not be output, or only simplified status information may be output, to avoid irrelevant logs entering the target debugging results.

[0058] By combining the first and second matching methods, the target batch call corresponding to the abnormal execution result data can be quickly located at the batch call level. Then, the target call chain can be further confirmed at the graphics driver command and graphics application interface level. This ensures that the output object of the process log is consistent with the graphics driver processing chain corresponding to the abnormal execution result data. This reduces the data scale caused by full log recording and avoids manual investigation based solely on the final rendered image or a single batch call identifier, thereby improving the location accuracy and analysis efficiency during the graphics driver debugging process.

[0059] In an optional embodiment of this disclosure, the process log may include at least one of the following: execution process information of the current batch call, parsing information of the current graphics driver command, scheduling information or execution status information, and graphics driver processing information corresponding to the current graphics application programming interface.

[0060] The execution process information of the current batch call can be used to characterize the reception, scheduling, execution, and output processes of the current batch call in the graphics processor simulation model. This information may include the call identifier, batch call sequence number, task type, reception time, start execution time, execution completion time, execution unit identifier, execution queue identifier, context identifier, resource binding status, execution completion status, exception status, or other information describing the batch call execution process. By outputting this execution process information, driver developers can determine the specific execution stage and status of the target batch call in the simulation model, thereby identifying whether exceptions occurred during batch call submission, scheduling, execution, or result output.

[0061] The parsing information of the current graphics-driven command can be used to characterize the process by which the graphics processor simulation model recognizes and parses the graphics-driven command. The parsing information can include command type, command fields, command length, command parameters, resource reference relationships, status setting parameters, command parsing results, field parsing results, or command validity verification results. By outputting the parsing information of the current graphics-driven command, it is possible to determine whether the graphics-driven command has command format errors, field configuration errors, resource reference errors, or status parameter errors, thereby facilitating the identification of execution result anomalies caused by errors in the generation or parsing of the graphics-driven command.

[0062] The scheduling information of current graphics-driven commands can be used to characterize the scheduling flow of graphics-driven commands in the graphics processor simulation model. Scheduling information can include the time a command enters the task queue, the time it is dequeued, the time it is dispatched, the execution unit corresponding to the command, the command execution order, the command dependency status, the command waiting status, the resource occupancy status, the context switching status, or the scheduling priority. By outputting the scheduling information of current graphics-driven commands, it is possible to determine whether anomalies are related to the command scheduling order, command dependencies, execution unit allocation, or resource waiting status, thereby reducing the workload of filtering the entire scheduling log.

[0063] The execution status information of the current graphics driver command can be used to characterize the state changes and execution results of the graphics driver command during execution in the graphics processor simulation model. Execution status information can include the command execution start state, command execution completion state, command execution success or failure state, intermediate states generated during command execution, read / write status of the resource corresponding to the command, generation status of the output data corresponding to the command, exception status codes, or error messages, etc. By outputting the execution status information of the current graphics driver command, driver developers can directly observe the state changes of the target graphics driver command during execution, thereby determining whether execution result anomalies are caused by command execution failure, resource read / write anomalies, or intermediate state anomalies.

[0064] The graphics driver processing information corresponding to the current graphics application programming interface (GPU) can be used to characterize the process by which the graphics driver processes the current GPU. This information may include the interface call sequence number, interface type, interface parameters, interface context, the graphics driver's parsing results of the interface parameters, state setting results, resource binding results, graphics driver command generation results, command submission results, or interface processing exception information. By outputting the graphics driver processing information corresponding to the current GPU, the abnormal execution results in the graphics processor simulation model can be traced back to the upper-level GPU processing stage, thus facilitating the determination of whether the exception was caused by interface parameter configuration, state transitions, resource binding, or driver command generation.

[0065] Process logs can be organized according to the hierarchical relationship between the current batch call, the current graphics driver command, and the current graphics application programming interface (API). For example, the current batch call can be used as the first-level index, the current graphics driver command as the second-level index, and the current API as the third-level index to store the corresponding process logs; alternatively, process logs can be stored in association according to the call identifier, command identifier, and interface identifier.

[0066] The output methods of the process log can include displaying it on the debugging terminal, writing it to a log file, writing it to a debugging database, generating structured log records, or exporting it in association with execution result data. The process log can be a text log, structured log, binary log, tabular log, or visual debugging record; this embodiment does not impose any special limitations on this. Compared to full log recording, the process log in this embodiment is output after the current batch call, the current graphics driver command, and the current graphics application interface are successfully matched. Therefore, it can reduce log content unrelated to abnormal execution result data, allowing debuggers to more focusedly analyze the key processing procedures in the target call chain.

[0067] The above methods can output process logs at the batch call granularity, graphics driver command granularity, and graphics application programming interface granularity according to different debugging needs. This allows the graphics processing chain corresponding to the abnormal execution result data to be fully presented at the log level, thereby improving the pertinence and accuracy of problem localization.

[0068] In one example embodiment of this disclosure, the target call identifier can be obtained through the following steps, which may specifically include: Multiple execution result data can be arranged and displayed or stored in association according to the call identifier; the call identifier associated with the execution result data with anomalies can be determined among multiple execution result data, and the call identifier associated with the execution result data with anomalies can be written as the target call identifier into the configuration file of the graphics processor simulation model; the target call identifier can be obtained from the configuration file.

[0069] The graphics processing unit (GPU) simulation model can generate execution result data corresponding to each batch of calls after executing multiple batch calls. Since each execution result data is associated with its corresponding batch call through a call identifier, the multiple execution result data can be arranged and displayed or stored in association according to the call identifier. Arrangement and display can be based on the ascending order of call identifiers, the receiving order of batch calls, the execution order of batch calls, the task queue order, or the task type grouping order. Association and storage can involve naming, indexing, writing to a database, archiving to a corresponding directory, or recording in an association table for the multiple execution result data according to the call identifier.

[0070] The execution result data may include at least one of the following: rendered result image, rendering intermediate buffer data, or resource copy result data. For rendered result images, image files can be named or indexed according to the call identifier, allowing driver developers to view the rendering results corresponding to each batch of calls in the execution order. For rendering intermediate buffer data, depth buffer data, stencil buffer data, or other intermediate buffer data can be output according to the call identifier, enabling driver developers to verify whether there are any anomalies in depth testing, stencil testing, or fragment processing during the rendering process. For resource copy result data, texture data, buffer data, or other resource transfer result data can be output according to the call identifier, enabling driver developers to verify whether there are any anomalies in the resource copy process.

[0071] Anomaly-prone execution result data can be identified from multiple execution result datasets. Anomaly-prone execution result data can exhibit pixel color anomalies, missing images, image misalignment, texture errors, depth value anomalies, template value anomalies, resource copy errors, missing data, or data validation failures. Methods for identifying anomaly-prone execution result data can include manual selection and automatic detection. Manual selection involves developers choosing anomaly-prone execution result data from multiple displayed execution result datasets. Automatic detection involves a graphics processing unit (GPU) simulation model or debugging tool using preset image comparison rules, pixel difference detection rules, depth buffer detection rules, template buffer detection rules, resource data validation rules, or anomaly threshold rules to detect multiple execution result datasets and identify those meeting the anomaly criteria as anomaly-prone execution result data.

[0072] After identifying abnormal execution result data, the call identifier associated with that abnormal execution result data can be obtained and used as the target call identifier. Since the call identifier has already been used to associate batch calls and their execution result data, the target call identifier can be used to indicate the target batch call corresponding to the abnormal execution result data. For example, when a rendered image first exhibits a pixel color error, the call identifier corresponding to that rendered image can be determined as the target call identifier; when depth buffer data or template buffer data is abnormal, the call identifier corresponding to that buffer data can be determined as the target call identifier; when resource copy result data is missing or fails verification, the call identifier corresponding to that resource copy result data can be determined as the target call identifier.

[0073] The target call identifier can be written to the configuration file of the graphics processor simulation model. The configuration file can be a parameter file, debug configuration file, run control file, or simulation environment configuration file that can be read by the graphics processor simulation model before or during operation. The configuration file may include a target call identifier field, as well as log output control fields, task type fields, debug switch fields, or other fields used to control the running state of the graphics processor simulation model. After the target call identifier is written to the configuration file, the graphics processor simulation model can read the configuration file and obtain the target call identifier when starting, restarting, continuing, or entering the target debugging process.

[0074] After obtaining the target call identifier from the configuration file, it can be used as a matching parameter during the execution of the graphics processor simulation model. Based on the target call identifier and call associations, the graphics processor simulation model can match the current batch calls, the current graphics driver commands, and the current graphics application programming interface (API) during execution, and output the corresponding process log when a match is successful. In this way, the target call identifier can serve as a connection point between abnormal execution result data and subsequent process log output, allowing process log output to selectively output based on the batch calls corresponding to the abnormal execution result data, rather than relying on full log recording.

[0075] By first organizing and viewing multiple execution result data using the call identifier as an index, then determining the target call identifier from the execution result data with anomalies, and passing the target call identifier to the subsequent running or debugging process of the graphics processor simulation model through a configuration file, the call chain corresponding to the abnormal execution result data can be directly hit based on the target call identifier when rerunning or continuing to run the graphics processor simulation model. This reduces the workload of manually searching for anomaly locations in a large number of logs and improves the efficiency and accuracy of graphics driver debugging.

[0076] In one example embodiment of this disclosure, the association can be generated in the following way: When the graphics driver converts the graphics application interface into graphics driver commands, a first correspondence between the graphics application interface and the graphics driver commands can be recorded; when one or more graphics driver commands are assembled into a batch call, a second correspondence between the graphics driver commands and the batch call can be recorded; and a call association relationship can be generated based on the first and second correspondences.

[0077] The graphics application programming interface (API) can be used to instruct rendering tasks, resource copying tasks, resource binding tasks, status setting tasks, or other graphics processing tasks. Upon receiving the API, the graphics driver can parse the API's interface type, interface parameters, resource objects, status parameters, or context information, and generate graphics driver commands that the graphics processor simulation model can recognize or further process based on the parsing results.

[0078] When a graphics driver converts a graphics application programming interface (API) into a graphics driver command, a first correspondence between the API and the command can be recorded. This first correspondence may include the correspondence between the API identifier and the command identifier, or it may include the correspondence between the API call sequence number, API type, API context, command type, command sequence number, command fields, or resource reference information. For example, when an API is converted into a command, a one-to-one correspondence between the API and the command can be recorded; when an API is split into multiple commands, a one-to-many correspondence between the API and the commands can be recorded; and when multiple APIs jointly influence the generation of the same command, the association between the APIs and the command can also be recorded.

[0079] After the graphics driver generates graphics driver commands, one or more graphics driver commands can be assembled into batch calls based on task type, submission order, execution queue, context state, or firmware scheduling policy. Batch calls can serve as submission units for the graphics processor simulation model to receive and execute. For rendering tasks, batch calls may include graphics driver commands related to drawing commands, state setting commands, resource binding commands, or fragment processing; for resource copying tasks, batch calls may include graphics driver commands related to texture copying, buffer copying, or resource transfer.

[0080] When one or more graphics-driven commands are assembled into a batch call, a second correspondence between the graphics-driven commands and the batch call can be recorded. This second correspondence may include the correspondence between graphics-driven command identifiers and batch call identifiers, or it may include the correspondence between a command list, the command's position in the batch call, the batch call sequence number, the task type, the execution queue identifier, the context identifier, or the execution unit identifier. For example, when a batch call is assembled from multiple graphics-driven commands, the list of graphics-driven commands included in the batch call can be recorded; when a graphics-driven command is included in a batch call, the batch call identifier corresponding to that graphics-driven command can be recorded; when different task types form different batch calls, the task type to which the graphics-driven command belongs and the corresponding batch call can be recorded.

[0081] Call associations can be generated based on the first and second correspondences. These associations characterize the link mapping between the graphics application programming interface (API), graphics driver commands, and batch calls. For example, the first correspondence can be used to determine the graphics driver command corresponding to a specific API, and then the second correspondence can be used to determine the batch call to which that command is assembled; alternatively, the second correspondence can be used to determine the graphics driver commands included in a batch call, and then the first correspondence can be used to determine the API corresponding to that command. Through this bidirectional or multi-level mapping, when execution result data is abnormal, the process can be traced back from the batch call level to the graphics driver command and the API, or the execution result of the corresponding batch call can be tracked at the API level.

[0082] Call relationships can be stored as a call relationship table, mapping index table, call chain record, context record table, or structured log record. Call relationships can include at least one of the following: batch call identifier, graphics driver command identifier, graphics application programming interface identifier, task type, context identifier, execution queue identifier, command list, interface call sequence number, and command submission sequence number. Call relationships can be recorded synchronously when the graphics driver generates graphics driver commands, updated when graphics driver commands are assembled into batch calls, and supplemented when the graphics processor simulation model receives batch calls.

[0083] The first and second correspondences can be generated by a graphics driver, debugging tool, graphics processor simulation model, or a recording module that works with it. For example, the graphics driver can record the first correspondence when parsing the graphics application programming interface and generating graphics driver commands; the front-end module of the graphics driver or graphics processor simulation model can record the second correspondence when the graphics driver commands are assembled into batch calls; the debugging tool can generate a complete call association based on the first and second correspondences and provide this call association to the graphics processor simulation model for subsequent matching.

[0084] By organizing the previously scattered correspondences between graphics application programming interfaces (APIs), graphics driver commands, and batch calls into call associations, batch calls are no longer merely execution submission units in the graphics processor simulation model. Instead, they form a traceable link with upstream graphics driver commands and APIs. Thus, once the target call identifier corresponding to abnormal execution result data is determined, the target graphics driver command and target graphics application programming interface associated with the target batch call can be identified based on the call associations. This information can then be further used for matching and process log output during the operation of the graphics processor simulation model, thereby improving the accuracy of anomaly localization.

[0085] In one example embodiment of this disclosure, the call identifier can be associated with batch calls and their execution result data in the graphics processor simulation model in the following ways, specifically including: In response to a call flag instruction received by the graphics processor simulation model for a batch call, the system can determine the call identifier corresponding to the batch call; obtain the execution result data generated by the batch call; and write the call identifier into the execution result data to establish the association between the call identifier and the execution result data.

[0086] The call marking instruction can be used to instruct the graphics processing unit (GPU) simulation model to mark the currently received or executed batch calls. The call marking instruction can be generated by the graphics driver, debugging tools, simulation control module, or the call marking module within the GPU simulation model, or it can be automatically triggered internally by the simulation model when it receives a batch call. The call marking instruction can carry the batch call's task type, batch call sequence number, execution queue identifier, context identifier, or other batch description information, or it can simply be used to trigger the GPU simulation model to generate call identifiers for the batch calls according to preset identifier generation rules.

[0087] After receiving a call marker instruction for a batch of calls, the graphics processing unit (GPU) simulation model can determine the call identifier corresponding to the batch call. The call identifier can be a unique count value used to uniquely identify a batch call, or a count value used to distinguish different batch calls within the current simulation task, current execution queue, or current context. The call identifier can be generated according to the order in which the batch calls are received, executed, in the task queue, or based on task type or context information. For example, for multiple batch calls in the same execution queue, incrementing count values ​​can be generated sequentially according to the order in which the batch calls enter the GPU simulation model; for batch calls of different task types, the task type identifier can be combined with the incrementing count value to form a composite call identifier.

[0088] After determining the call identifier corresponding to the batch call, the execution result data generated by the batch call can be obtained during or after the batch call execution. The execution result data can be the final execution result obtained after the graphics processor simulation model executes the batch call, or it can be intermediate execution data generated during the execution of the batch call by the graphics processor simulation model. For rendering tasks, the execution result data can include the rendered image generated from framebuffer data, or it can include depth buffer data, stencil buffer data, or other intermediate rendering buffer data. For resource copying tasks, the execution result data can include resource copying result data, such as texture data, buffer data, or other resource transfer result data.

[0089] Optionally, writing the call identifier into the execution result data may include writing the call identifier into the file name, file header information, index field, metadata information, data description information, output path, or storage directory corresponding to the execution result data. Alternatively, it may include recording the correspondence between the call identifier and the execution result data in an association table corresponding to the execution result data. For example, when outputting the rendered result image, the call identifier can be included as part of the image file name, establishing a recognizable naming relationship between the rendered result image and the corresponding batch call; when outputting depth buffer data or template buffer data, the call identifier can be written into the file header or metadata information of the corresponding data file; when outputting resource copy result data, the call identifier can be associated with the storage address of the resource copy result data.

[0090] Understandably, writing the call identifier into the execution result data does not require changing the graphical or resource content of the execution result data itself. For execution result data that is inconvenient to write directly to the identifier, the association between the call identifier and the execution result data can be recorded by creating a separate index file, mapping table, or debugging database. For example, information such as the call identifier, batch call sequence number, task type, execution result data name, execution result data storage path, generation time, and data type can be recorded in the mapping table, allowing the corresponding execution result data to be queried by the call identifier.

[0091] After establishing the association between the call identifier and the execution result data, a consistent index chain can be formed between batch calls, call identifiers, and execution result data. Thus, when a certain execution result data is determined to be abnormal, the corresponding target call identifier can be determined based on the call identifier written in that execution result data, or based on the call identifier stored in association with that execution result data, and further, the target batch call that generated the abnormal execution result data can be identified.

[0092] In this way, the graphics processor simulation model can synchronously establish the association between batch calls and execution result data during batch call execution, so that the execution result data corresponding to each batch call has a traceable call identifier. Compared with the method of only retaining the final frame-level rendering result or the full log, this embodiment can directly determine the corresponding batch call when the execution result data is abnormal, thereby narrowing the scope of anomaly location and improving the accuracy of selective output of subsequent process logs.

[0093] In one example embodiment of this disclosure, the call identifier corresponding to a batch call can be determined through the following steps, which may include: The call identifier corresponding to the batch call can be generated according to the receiving order or execution order of the batch call in the graphics processor simulation model; the call identifier is associated with the batch description information of the batch call and stored, the batch description information includes at least one of the batch call sequence number, task type and graphics driver command list.

[0094] When the graphics processing unit (GPU) simulation model receives multiple batch calls, it can generate call identifiers according to the order in which the batch calls are received. For example, each time the GPU simulation model receives a batch call, it can use the current count value of a counter as the call identifier for that batch call, and increment the counter after generating the call identifier. This method ensures that the call identifiers are consistent with the order in which the batch calls enter the GPU simulation model, facilitating the subsequent arrangement and display of execution result data according to the call order.

[0095] Graphical processor (GPU) simulation models can also generate call identifiers according to the execution order of batch calls. For example, when multiple batch calls enter different execution queues or wait for different resource conditions, the receiving order of the batch calls may not be entirely consistent with the actual execution order. In this case, a call identifier can be generated for the batch call when it is scheduled to the target execution unit, enters the execution phase, or completes execution confirmation. This allows the call identifier to reflect the actual execution order of the batch calls in the GPU simulation model. This approach is beneficial for tracing the location of anomalies according to the actual execution process when analyzing execution result data.

[0096] The call identifier can be a single incrementing counter value or a composite identifier. A composite identifier can be formed by combining at least two of the following: task type, execution queue identifier, context identifier, batch call sequence number, execution unit identifier, or incrementing counter value. For example, for rendering tasks and resource copying tasks, different task type prefixes can be set respectively, and combined with an incrementing counter value to form the call identifier; for scenarios with multiple execution queues running in parallel, the execution queue identifier can be combined with the queue sequence number to form the call identifier. Using composite identifiers, the distinguishability of call identifiers can be improved in multi-task, multi-queue, or multi-context environments.

[0097] After generating the call identifier, it can be associated with and stored in conjunction with the batch description information of the batch call. The batch description information may include at least one of the following: batch call sequence number, task type, and graphics-driven command list. The batch call sequence number can be used to characterize the position of the batch call in the submission sequence, reception sequence, or execution sequence; the task type can be used to characterize the rendering task, resource copying task, or other graphics processing task corresponding to the batch call; the graphics-driven command list can be used to characterize one or more graphics-driven commands assembled to form the batch call. In addition to the above information, the batch description information may also include at least one of the following: execution queue identifier, context identifier, execution unit identifier, resource binding information, submission time, reception time, start execution time, or execution completion time.

[0098] Optionally, the call identifier and batch description information can be associated and stored using methods such as a call identifier mapping table, a batch call index table, a call chain record table, debug database records, or structured log records. For example, the call identifier mapping table can record the correspondence between the call identifier, batch call sequence number, task type, list of graphics-driven commands, and data storage path for execution results; alternatively, the debug database can use the call identifier as the primary key to associate and store batch description information, execution result data index, and call association index. Through these associated storage methods, subsequent queries can be made based on the call identifier to find the task type of the batch call, the included graphics-driven commands, and the corresponding execution result data.

[0099] The associated storage of call identifiers and batch description information can also be used to assist in matching the current batch call with the target batch call. For example, when the current call identifier matches the target call identifier, it is possible to further compare whether the task type, batch call sequence number, or graphics-driven command list corresponding to the current batch call matches the information corresponding to the target batch call. In scenarios of multi-queue parallel execution or context switching, the execution queue identifier or context identifier can also be combined for auxiliary judgment, thereby reducing mismatches caused by identifier conflicts, identifier reuse, or changes in execution order.

[0100] By establishing a stable correspondence between the call identifier and the key descriptive information of the batch call while generating the call identifier, the call identifier can not only be used to associate execution result data, but also to trace the task attributes, command composition and execution location of the batch call. After the execution result data is determined to be abnormal, the corresponding batch call and its batch description information can be quickly determined based on the target call identifier.

[0101] In an example embodiment of this disclosure, the execution result data can be obtained and output in the following manner: The task type corresponding to the batch call can be determined, including at least one of rendering tasks and resource copying tasks; based on the task type, the execution result data generated by the graphics processor simulation model when executing the batch call is obtained; the execution result data is associated with the batch call based on the call identifier, and the execution result data is output according to the call identifier.

[0102] In this context, a batch call can be an execution submission unit received by the graphics processor simulation model, and different batch calls can correspond to different task types. The task type can be determined based on the graphics-driven commands contained in the batch call, or it can be determined based on the batch call's submission channel, execution queue, task description field, execution unit identifier, or context information. For example, when a batch call contains graphics-driven commands for drawing, fragment processing, pixel output, depth testing, or stencil testing, it can be determined that the batch call corresponds to a rendering task; when a batch call contains graphics-driven commands for texture copying, buffer copying, resource transfer, or data movement, it can be determined that the batch call corresponds to a resource copying task.

[0103] After determining the task type corresponding to the batch call, the execution result data generated by the graphics processor simulation model during or after the batch call can be obtained according to the task type. For rendering tasks, the execution result data may include frame buffer data, rendered image generated from frame buffer data, depth buffer data, stencil buffer data, or other intermediate rendering buffer data. For resource copying tasks, the execution result data may include resource copying result data, such as texture data, buffer data, resource transfer result data, or data movement result data. The execution result data may be generated by the graphics rendering unit, resource copying unit, pixel output module, fragment processing module, data copying module, or other simulation function modules, and this disclosure does not impose any special limitations on this.

[0104] Execution result data can be obtained based on the task type. For example, execution result data can include intermediate execution data collected during batch execution or output result data obtained after batch execution. For instance, for a rendering task, depth buffer data or stencil buffer data can be obtained during fragment processing, or frame buffer data can be obtained after pixel output to further generate the rendered image; for a resource copy task, resource copy result data can be obtained during or after the resource copy process.

[0105] After obtaining the execution result data, the execution result data can be associated with the batch call based on the call identifier. Specifically, the call identifier can be written into the file name, index field, metadata information, file header information, output path, cache description information, or association table corresponding to the execution result data; alternatively, the correspondence between the call identifier, batch call, task type, execution result data type, and execution result data storage location can be recorded in the debug database or call identifier mapping table.

[0106] Outputting execution result data according to the call identifier can include naming, storing, arranging, archiving, or indexing the execution result data according to the call identifier. For example, the call identifier can be used as part of the filename of the rendered result image, allowing driver developers to view each rendered result image in the order of batch calls; alternatively, the call identifier can be used as an index field for depth buffer data, template buffer data, or resource copy result data, allowing debugging tools to query the corresponding data according to the call identifier. The form of the output execution result data can include image files, binary files, structured data files, debug data files, visualization files, or database records, and this disclosure does not impose any special limitations on this.

[0107] After outputting execution result data according to the call identifier, multiple execution result data can be organized at the batch call granularity. Driver developers can view the execution result data corresponding to different batch calls based on the call identifier and identify execution result data with abnormalities. For example, when the rendered result image corresponding to a certain call identifier has a pixel color error, that call identifier can be used as the target call identifier; when the depth buffer data, template buffer data, or resource copy result data corresponding to a certain call identifier has an anomaly, that call identifier can also be used as the target call identifier.

[0108] By acquiring corresponding execution result data for different task types and establishing a connection between the execution result data and batch calls using call identifiers, the rendering results, intermediate rendering results, and resource copy results in the graphics processor simulation model can all be output at the batch call granularity. In this way, when anomalies occur in the execution result data, the corresponding batch call can be directly determined based on the call identifier, reducing the workload of reverse-engineering the source of the anomaly from the final rendering results or full logs, and improving the localization efficiency during graphics driver debugging.

[0109] In an example embodiment of this disclosure, the execution result data may include a rendered result image; in the case of batch calling the corresponding rendering task, the frame buffer data generated by the graphics processor simulation model after the batch call is executed may be obtained; a rendered result image may be generated based on the frame buffer data; the rendered result image may be named or indexed according to the call identifier, so that the rendered result image and the corresponding batch call are associated through the call identifier; and the rendered result image may be output according to the call identifier.

[0110] In the case of batch invoking a corresponding rendering task, the graphics processor simulation model can execute the graphics-driven commands included in the batch invoke and generate frame buffer data after completing the corresponding graphics rendering processing. The frame buffer data can be pixel result data formed during the pixel output stage, which can be used to characterize the image display result or intermediate rendering result obtained after the current batch invoke is executed. The frame buffer data can include color values, transparency values, pixel arrangement information, image size information, pixel format information, or other data related to image output for multiple pixels.

[0111] The graphics processor simulation model can obtain the corresponding frame buffer data after each batch of calls is executed, or it can obtain the frame buffer data at a preset rendering output node. For example, it can read the pixel data in the current frame buffer after the pixel output module completes the pixel writing for the current batch of calls; or it can extract the content of the current frame buffer as the frame buffer data for the batch of calls after the batch of calls corresponding to the rendering task has been executed.

[0112] A rendered image can be generated based on framebuffer data. For example, this could involve converting pixel data in the framebuffer according to a preset image output format and generating a rendered image based on the converted pixel data. Preset image output formats can include BMP, PNG, JPEG, RAW, or other image formats that are easy to debug and view. Taking BMP format as an example, the binary pixel data in the framebuffer can be converted pixel-by-pixel according to BMP image format requirements, and the corresponding file header and image information can be filled in, thereby generating a rendered image that can be opened by image viewing tools.

[0113] Rendered result images can be used to visually represent the image output results after batch call execution. Compared to viewing the final frame image only after all batch calls have been executed, generating rendered result images at the batch call granularity allows driver developers to progressively view the changes in image content after different batch call executions. When a rendered result image corresponding to a certain batch call first exhibits pixel color errors, missing image regions, abnormal texture display, image misalignment, or other visual anomalies, this rendered result image can be identified as abnormal execution result data, and the target call identifier can be determined based on the call identifier corresponding to this rendered result image.

[0114] After generating the rendered image, it can be named or indexed according to the call identifier. Naming can involve using the call identifier as all or part of the rendered image filename; for example, combining the call identifier, task type, and image format suffix into the rendered image filename. Indexing can involve recording the call identifier in the corresponding metadata, file description, database record, or related table.

[0115] Outputting rendered result images according to call identifiers can include outputting the rendered result images to a preset directory, a debugging interface, an image viewing tool, a debugging database, or a visual analysis interface. Multiple rendered result images can be arranged and output in ascending order of call identifiers, the execution order of batch calls, or the grouping order of task types. In this way, driver developers can view the rendered result images one by one in the call order and determine the call identifier corresponding to the anomaly based on the position where the image anomaly first appears.

[0116] The association between the rendered result image and the call identifier can also be used for subsequent process log output. Specifically, when a rendered result image is determined to contain abnormal execution result data, the corresponding call identifier can be read from the file name, metadata information, index information, or association table of the rendered result image, and this call identifier can be written as the target call identifier into the configuration file of the graphics processor simulation model. During the subsequent operation of the graphics processor simulation model, the current batch call, the current graphics driver command, and the current graphics application programming interface can be matched based on the target call identifier and the call association, and the corresponding process log can be output when the match is successful.

[0117] By converting the frame buffer data corresponding to the rendering task into a rendering result image organized by call identifier, the image change process after batch call execution can be presented in a visual way. This method can help developers directly determine the batch call where the exception first occurs from multiple rendering result images, thereby narrowing the scope of exception location and providing accurate target call identifiers for subsequent selective output of process logs.

[0118] In one example embodiment of this disclosure, the generation of a rendered image based on frame buffer data can be achieved through the following steps, which may specifically include: It can read binary pixel data from the frame buffer; perform pixel-by-pixel format conversion on the binary pixel data according to the preset image output format; and generate the rendered image based on the format-converted pixel data.

[0119] The frame buffer data may include pixel data written to the frame buffer by the graphics processor simulation model after executing batch calls. The pixel data may be stored in binary form and may include at least one of the following: pixel color components, transparency components, pixel arrangement order, pixel format, image width, image height, row alignment information, or pixel stride information. Before generating the rendered image, the graphics processor simulation model may read the binary pixel data in the frame buffer and determine the arrangement of the color components of each pixel according to the pixel format corresponding to the frame buffer.

[0120] The pixel format of binary pixel data can include RGBA, BGRA, ARGB, RGB, BGR, floating-point color, or other pixel storage formats used in graphics processing. Since the pixel format in the frame buffer may differ from the image format required for debugging the output image, the binary pixel data can be converted pixel-by-pixel according to a preset image output format. Preset image output formats can include BMP, PNG, JPEG, RAW, or other output formats recognizable by image viewing tools.

[0121] Pixel-by-pixel format conversion can include rearranging, truncating, normalizing, quantizing, byte ordering, or color channel completion for the color components of each pixel. For example, when the frame buffer data uses RGBA arrangement, but the preset image output format requires BGR arrangement, the red, green, and blue components in each pixel can be rearranged according to the preset image output format; when the frame buffer data uses floating-point color format, the floating-point color values ​​can be converted to integer color values ​​with a preset bit width; when the frame buffer data contains alpha components but the preset image output format does not require alpha components, the alpha components can be removed or ignored during the conversion process.

[0122] To generate a rendered image based on format-converted pixel data, the process can include organizing the image file structure according to a preset image output format and writing the format-converted pixel data into the corresponding image file. Taking BMP format as an example, a BMP file header and image information header can be generated based on the image width, image height, pixel bit width, file size, and pixel data offset. The format-converted pixel data is then written into the pixel data area according to BMP format requirements, thereby generating a rendered image that can be directly opened by image viewing tools. For PNG or JPEG formats, the format-converted pixel data can also be encoded according to the corresponding image encoding rules to generate a rendered image in the corresponding format.

[0123] During the generation of the rendered image, the rendered image can also be named or indexed based on the call identifier. For example, the call identifier can be written into the file name, file path, metadata information, or association table of the rendered image, so that the rendered image is associated with the corresponding batch call. In this way, even if multiple batch calls generate multiple rendered images, different rendered images can be distinguished according to the call identifier, and the corresponding batch call can be traced back based on a certain rendered image.

[0124] The generated rendered images can be used to enable developers or automated detection tools to view and analyze the image results after batch execution. Developers can view multiple rendered images sequentially according to the call identifier to determine the location where the image anomaly first appears; automated detection tools can also compare the rendered images with reference images and determine the call identifier corresponding to the rendered image as the target call identifier when pixel differences, color deviations, texture loss, or image region anomalies meet preset anomaly conditions.

[0125] By converting the binary pixel data in the frame buffer into rendered image results that are easy to view and analyze, the image results generated by the graphics processor simulation model at the batch call granularity can be presented intuitively. This method not only reduces the difficulty of directly analyzing binary frame buffer data, but also provides a visual basis for identifying abnormal execution result data and their target call identifiers.

[0126] In an example embodiment of this disclosure, the execution result data may include rendering intermediate buffer data, which includes at least one of depth buffer data and template buffer data; in the case of batch calling the corresponding rendering task, the rendering intermediate buffer data generated by the graphics processor simulation model during the execution of the batch call can be obtained; the rendering intermediate buffer data is associated with the call identifier; and the rendering intermediate buffer data is output according to the call identifier.

[0127] In the case of batch invocation of a corresponding rendering task, the graphics processor simulation model, during the execution of the batch invocation, can generate frame buffer data not only during the pixel output stage but also during fragment processing, depth testing, stencil testing, or other rendering processing stages. Rendering intermediate buffer data can be used to characterize the processing status or test results of the batch invocation at intermediate stages of the rendering pipeline. It can include at least one of depth buffer data and stencil buffer data, and may also include other intermediate data related to fragment processing, depth comparison, stencil comparison, or occlusion determination.

[0128] Depth buffer data can be used to record the depth values ​​corresponding to each pixel position or sampling position during the execution of rendering tasks by the graphics processor simulation model. Depth buffer data can reflect the processing results of depth testing, occlusion relationships, or 3D scene hierarchy relationships after the current batch of calls is executed. When the final rendered image exhibits object occlusion errors, hierarchical errors, missing parts of the image, or depth test anomalies, the depth buffer data under the corresponding call identifier can be checked to determine whether the anomaly is related to depth value writing, depth comparison rules, depth test status, or the depth buffer update process.

[0129] The stencil buffer data can be used to record the stencil values ​​corresponding to each pixel position or sampling position during the rendering process of the graphics processor simulation model. The stencil buffer data can reflect the processing results related to stencil testing, region masking, or conditional rendering after the current batch call execution. When the final rendered image shows local areas not drawn, incorrectly drawn, abnormal region clipping, or stencil test anomalies, the stencil buffer data under the corresponding call identifier can be checked to determine whether the anomaly is related to stencil value writing, stencil comparison rules, stencil test status, or the stencil buffer update process.

[0130] The timing for acquiring intermediate rendering buffer data can be determined based on the processing stage of the rendering pipeline. For example, the corresponding depth buffer data or stencil buffer data can be acquired after fragment processing is executed in the current batch call; a corresponding buffer snapshot can be acquired after depth testing or stencil testing is completed; or the current state of the depth buffer data and / or stencil buffer data can be acquired when the current batch call execution is completed. By acquiring intermediate rendering buffer data during the execution of batch calls, the intermediate processing state before and after rendering result anomalies can be preserved, providing more granular data for subsequent anomaly localization.

[0131] Rendering intermediate buffer data can be associated with call identifiers. This can be achieved by writing the call identifier into the file name, header information, metadata information, index field, output path, or association table corresponding to the rendering intermediate buffer data. For example, the call identifier can be part of the name of the depth buffer data file or the template buffer data file; alternatively, the association table can record the correspondence between the call identifier, buffer data type, batch call sequence number, task type, generation time, and storage address. This method ensures a traceable relationship between the rendering intermediate buffer data and the batch calls that generated the data.

[0132] The rendering intermediate buffer data can be output according to the call identifier, such as binary files, structured data files, visualization files, or debug data files. For depth buffer data, the raw depth values ​​can be output directly, or the depth values ​​can be normalized to generate a depth visualization image, allowing developers to observe the depth distribution in different areas. For template buffer data, the raw template values ​​can be output directly, or the template values ​​can be converted into grayscale images, marker images, or other visualization results to observe template areas and template test results. This disclosure does not impose any special limitations on the output format of the rendering intermediate buffer data.

[0133] Intermediate rendering buffer data can be used in conjunction with the rendered result image. For example, when an image anomaly occurs in the rendered result image corresponding to a certain call identifier, the depth buffer data and / or stencil buffer data corresponding to the same call identifier can be further examined to determine whether the anomaly occurred during the depth testing phase, stencil testing phase, or pixel output phase. Since both the rendered result image and the intermediate rendering buffer data are associated with the same batch of calls through the call identifier, driver developers can comprehensively analyze the final image result and the intermediate buffer status at the same batch call granularity.

[0134] By acquiring depth buffer data and / or stencil buffer data during the execution of rendering tasks, and outputting the corresponding intermediate rendering buffer data according to the call identifier, this method can further present the processing status of batch calls in the intermediate stage of the rendering pipeline, compared to simply viewing the rendered image. This helps drivers developers more accurately determine the stage where the anomaly occurs when image anomalies, occlusion anomalies, depth test anomalies, or stencil test anomalies occur, thereby improving the positioning accuracy of graphics driver debugging.

[0135] In an example embodiment of this disclosure, the execution result data may include resource copy result data; when a batch call is made to a corresponding resource copy task, the resource copy result data generated by the graphics processor simulation model during the execution of the batch call can be obtained, the resource copy result data can be associated with the call identifier, and the resource copy result data can be output according to the call identifier.

[0136] Resource copying tasks can be used to copy, move, or synchronize data between different storage areas, different resource objects, or different graphics processing units. Resource copying tasks can include texture data copying, buffer data copying, copying data from the host side to the graphics processor's data space, copying data between different resources on the graphics processor side, reading back rendering result data, or other resource transfer tasks. When a batch call is made to a corresponding resource copying task, the batch call can include graphics driver commands describing the copy source address, target address, data length, data format, resource type, or copy control parameters.

[0137] During the batch execution of a resource copy task, the graphics processor simulation model can generate resource copy result data through a resource copy unit, a data copy module, or other functional modules used to simulate the resource transfer process. The resource copy result data may include at least one of the following: texture data, buffer data, resource transfer result data, target resource data after copying, copy status information, or data verification results. The resource copy result data can reflect the data content and execution status after the current batch call performs the resource copy operation.

[0138] The timing for obtaining resource copy result data can be determined based on the execution process of the resource copy task. For example, intermediate data of the target resource can be obtained during the execution of the resource copy task, the final data of the target resource can be obtained after the resource copy task is completed, or the corresponding data can be obtained after the copy result is written to the target buffer, target texture, or target storage space. By obtaining resource copy result data, it can be confirmed whether the current batch call has correctly completed the resource copy, and whether the copied resource content meets expectations.

[0139] Resource copy result data can be associated with a call identifier. This can be achieved by writing the call identifier into the file name, header information, metadata information, index field, output path, or association table corresponding to the resource copy result data. For example, the call identifier can be part of the name of a texture data file, buffer data file, or resource transfer result file. Alternatively, the association table can record the correspondence between the call identifier, resource copy task type, batch call sequence number, resource type, source address, target address, data length, generation time, and storage address. This method ensures that the resource copy result data maintains a traceable relationship with the batch calls that generated the data.

[0140] The system can output resource copy result data according to the call identifier. This can include outputting binary files, texture data files, buffer data files, structured data files, visualization files, or debug data files. For texture data, it can directly output the raw texture data, or convert the texture data into image files or visualizations to help developers check for misalignment, missing data, format errors, or color anomalies in the texture content. For buffer data, it can output the raw buffer data, or convert the buffer data into tabular data, structured records, or readable text according to preset parsing rules. For resource transfer result data, it can output debugging information such as copy status, source resource information, target resource information, data length, verification results, or error status.

[0141] Resource copy result data can be used in conjunction with rendered result images or rendering intermediate buffer data. For example, when a rendered result image exhibits missing textures, misaligned textures, or abnormal colors, the resource copy result data corresponding to the same or related call identifiers can be further examined to determine whether the anomaly occurred during texture copying, buffer copying, or resource transfer. Since resource copy result data is associated with corresponding batch calls according to the call identifier, the target call identifier can be directly determined based on the abnormal resource copy result data, further triggering the output of the corresponding call chain's process log.

[0142] Resource copy result data can also be used for automatic anomaly detection. For example, graphics processor simulation models or debugging tools can perform integrity checks, format checks, data length checks, checksum comparisons, or reference data comparisons on resource copy result data according to preset data verification rules. When resource copy result data does not meet the preset verification rules, it can be identified as abnormal execution result data, and the call identifier associated with the resource copy result data can be identified as the target call identifier.

[0143] By acquiring resource copy result data during the execution of the resource copy task and outputting the corresponding resource copy result data according to the call identifier, compared to only observing texture anomalies or resource anomalies in the final rendered image, this method can directly expose the execution result of the resource copy stage and trace the resource copy result data back to the corresponding batch call. This helps to determine whether the anomaly occurred in the resource transfer, data relocation, or texture copy stage, thereby improving the positioning accuracy of graphics driver debugging.

[0144] Figure 3 The illustration shows a schematic diagram of a process log corresponding to an abnormal call in a graphics processor simulation model according to some embodiments of the present disclosure.

[0145] refer to Figure 3 As shown, in step S301, a graphics application programming interface (API) call is received, which is a graphics processing request submitted by the upper-layer graphics application to the graphics driver. Subsequently, in step S302, the API call is converted into a graphics driver command to form command data that can be recognized by the graphics processor simulation model. In step S303, one or more graphics driver commands are assembled into a batch call according to the submission method of the graphics driver commands. In step S304, a call association relationship is constructed based on the correspondence between the graphics driver commands, the batch call, and the API.

[0146] In step S305, the task type of the current batch call is determined to determine whether it is a rendering task; if it is determined to be a rendering task, the process proceeds to step S306 to execute the rendering pipeline processing, in step S307 to generate frame buffer data, and in step S308 to output the execution result to the corresponding configuration file or debug data set according to the call identifier; if it is determined to be a non-rendering task, the process proceeds to step S309 to execute the resource copy task, and in step S310 to export the resource data or copy result data.

[0147] After the execution result is output, abnormal execution result data is manually selected in step S311 to determine the target call identifier; then in step S312, the target call identifier is configured to the call flag module to match the call during the operation of the graphics processor simulation model; in step S313, it is determined whether the current call matches the target call identifier. If the match is successful, the process log is output in step S314 to debug the graphics driver; if the match is unsuccessful, the matching judgment process continues.

[0148] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0149] Furthermore, in this example embodiment, a graphics driver debugging device is also provided. (See reference...) Figure 4 As shown, the graphics driver debugging device 400 includes: a target identifier acquisition module 410, a matching module 420, and a log output module 430. Wherein: The target identifier acquisition module 410 is used to acquire the call association relationship and the target call identifier. The call association relationship is used to characterize the mapping relationship between batch calls and the graphics application programming interface and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model. The matching module 420 is used to match the current batch call, the current graphics driver command, and the current graphics application interface during the operation of the graphics processor simulation model according to the target call identifier and the call association relationship; The log output module 430 is used to output process logs corresponding to the currently matched batch call, the currently matched graphics driver command, and the currently matched graphics application interface when a match is successful. The process logs are used to debug the graphics driver.

[0150] In an example embodiment of this disclosure, based on the aforementioned scheme, the matching module 420 is configured to: determine the target batch call corresponding to the target call identifier, and determine the target graphics driver command and target graphics application interface associated with the target batch call according to the call association relationship; match the target batch call, target graphics driver command and target graphics application interface with the current batch call, current graphics driver command and current graphics application interface to obtain the successfully matched current batch call, current graphics driver command and current graphics application interface.

[0151] In an example embodiment of this disclosure, based on the aforementioned scheme, the matching module 420 is configured to: perform a first match between the current batch call and the target batch call; if the first match is successful, determine the current graphics driver command and the current graphics application interface associated with the current batch call that was successfully matched in the first match according to the call association relationship, and perform a second match between the current graphics driver command and the target graphics driver command, and between the current graphics application interface and the target graphics application interface; if the current graphics driver command and the target graphics driver command are successfully matched, and the current graphics application interface and the target graphics application interface are successfully matched, determine that the second match is successful, and obtain the successfully matched current batch call, the current graphics driver command, and the current graphics application interface.

[0152] In an example embodiment of this disclosure, based on the aforementioned scheme, the process log output by the log output module 430 includes at least one of the following: execution process information of the current batch call; parsing information, scheduling information or execution status information of the current graphics driver command; and graphics driver processing information corresponding to the current graphics application programming interface.

[0153] In an example embodiment of this disclosure, based on the foregoing scheme, the target identifier acquisition module 410 is configured to: arrange and display or store multiple execution result data according to the call identifier; determine the call identifier associated with the execution result data that has an anomaly among the multiple execution result data, and write the call identifier associated with the execution result data that has an anomaly as the target call identifier into the configuration file of the graphics processor simulation model; and obtain the target call identifier from the configuration file.

[0154] In an example embodiment of this disclosure, based on the foregoing scheme, the target identifier acquisition module 410 is configured to generate a call association relationship in the following manner: when the graphics driver converts the graphics application interface into a graphics driver command, a first correspondence relationship between the graphics application interface and the graphics driver command is recorded; when one or more graphics driver commands are assembled into a batch call, a second correspondence relationship between the graphics driver command and the batch call is recorded; and a call association relationship is generated based on the first and second correspondence relationships.

[0155] In an example embodiment of this disclosure, based on the foregoing scheme, the target identifier acquisition module 410 is configured to associate the call identifier with batch calls and their execution result data in the graphics processor simulation model in the following manner: in response to the graphics processor simulation model receiving a call flag instruction for a batch call, determining the call identifier corresponding to the batch call; acquiring the execution result data generated corresponding to the batch call; and writing the call identifier into the execution result data to establish the association between the call identifier and the execution result data.

[0156] In an example embodiment of this disclosure, based on the foregoing scheme, the target identifier acquisition module 410 is configured to: generate a call identifier corresponding to a batch call according to the receiving order or execution order of the batch calls in the graphics processor simulation model; and associate and store the call identifier with the batch description information of the batch call, wherein the batch description information includes at least one of the batch call sequence number, task type, and graphics driver command list.

[0157] In an example embodiment of this disclosure, based on the foregoing scheme, the target identifier acquisition module 410 is configured to acquire and output execution result data in the following manner: determine the task type corresponding to the batch call, the task type including at least one of rendering task and resource copy task; acquire the execution result data generated by the graphics processor simulation model in executing the batch call according to the task type; establish an association between the execution result data and the batch call based on the call identifier, and output the execution result data according to the call identifier.

[0158] In an example embodiment of this disclosure, based on the aforementioned scheme, the execution result data includes the rendered result image; in the case of batch calling the corresponding rendering task, the target identifier acquisition module 410 is configured to: acquire the frame buffer data generated by the graphics processor simulation model after executing the batch call; generate the rendered result image based on the frame buffer data; name or index the rendered result image according to the call identifier, so that the rendered result image and the corresponding batch call are associated through the call identifier; and output the rendered result image according to the call identifier.

[0159] In an example embodiment of this disclosure, based on the foregoing scheme, the target identifier acquisition module 410 is configured to generate a rendered result image based on frame buffer data in the following manner: reading binary pixel data in the frame buffer data; performing pixel-by-pixel format conversion on the binary pixel data according to a preset image output format; and generating a rendered result image based on the format-converted pixel data.

[0160] In an example embodiment of this disclosure, based on the aforementioned scheme, the execution result data includes rendering intermediate buffer data, which includes at least one of depth buffer data and template buffer data; in the case of batch calling the corresponding rendering task, the target identifier acquisition module 410 is configured to: acquire the rendering intermediate buffer data generated by the graphics processor simulation model during the batch call; establish an association between the rendering intermediate buffer data and the call identifier; and output the rendering intermediate buffer data according to the call identifier.

[0161] In an example embodiment of this disclosure, based on the aforementioned scheme, the execution result data includes resource copy result data; in the case of batch calling the corresponding resource copy task, the target identifier acquisition module 410 is configured to: acquire the resource copy result data generated by the graphics processor simulation model during the batch call; establish an association between the resource copy result data and the call identifier; and output the resource copy result data according to the call identifier.

[0162] The specific details of each module of the graphics driver debugging device mentioned above have been described in detail in the corresponding graphics driver debugging methods, so they will not be repeated here.

[0163] It should be noted that although several modules or units of the graphics-driven debugging device have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0164] Furthermore, in an exemplary embodiment of this disclosure, a graphics processor simulation model is also provided, with reference to... Figure 5 As shown, the graphics processor simulation model 500 may include a graphics rendering unit 510, a resource copying unit 520, a call-by-call rendering module 530, a call marking module 540, and a logging unit 550. Wherein: The graphics rendering unit 510 receives batch calls generated when the graphics driver points to a rendering task, and executes the graphics driver commands within the batch calls to generate rendering execution result data corresponding to the batch calls. The graphics rendering unit 510 is a functional unit in the graphics processor simulation model 500 used to simulate the graphics rendering pipeline. It can parse, distribute, and execute the graphics driver commands contained in the batch calls according to the graphics processor's rendering processing logic. Batch calls can be assembled from graphics driver commands generated by the graphics application programming interface (API). When a batch call points to a rendering task, the graphics rendering unit 510 can receive the batch call through the rendering front-end module and identify the drawing calls, rendering state configurations, resource bindings, or other graphics driver commands related to the rendering pipeline contained within it. Subsequently, the graphics rendering unit 510 can drive simulation processing processes such as geometry processing, rasterization processing, fragment processing, and pixel output according to the execution order of the graphics driver commands, so that the batch calls form corresponding rendering execution result data in the graphics processor simulation model 500.

[0165] In practical implementation, rendering execution result data can include frame buffer data, as well as result data related to the rendering process, such as depth buffer data and stencil buffer data. Frame buffer data can be generated during the pixel output stage to characterize the pixel output state after the current batch call execution; depth buffer data and stencil buffer data can be generated during the fragment processing stage or related buffer update processes to characterize depth testing, stencil testing, and fragment processing results. When executing graphics-driven commands in a batch call, the graphics rendering unit can provide the completed result data to the call-by-call rendering module for association and output, or it can temporarily store the result data in the corresponding buffer and establish subsequent index relationships through the call identifier. In this way, the graphics rendering unit not only completes the simulation execution of the rendering task but also provides a source of rendering results for batch call-level debugging data output, enabling subsequent debugging processes to trace back to the corresponding batch call from the rendering execution results.

[0166] The resource copy unit 520 receives batch calls generated by the graphics driver when a resource copy task is requested, and executes the graphics driver commands within the batch calls to generate resource copy result data corresponding to the batch calls. The resource copy unit 520 is a functional unit in the graphics processor simulation model 500 used to simulate resource transfer and data movement processes. It can handle the copying process of texture data, buffer data, or other resource data between the host side and the graphics processor side, and can also handle the data copying process between different resource areas on the graphics processor side. When a batch call generated by the graphics driver points to a resource copy task, the resource copy unit 520 can receive the batch call through the copy front-end module and identify the graphics driver commands related to data copying, texture uploading, buffer moving, or resource writing contained within it.

[0167] During execution, the resource copy unit 520 can simulate the corresponding data transmission or data relocation operation based on information such as the source address, target address, data length, resource type, data format, and copy direction carried in the graphics driver command, and generate resource copy result data after the copy is completed. The resource copy result data can be represented as texture data, buffer data, or other resource data formed in the target storage area, or as a data copy, data snapshot, or data reference that reflects the completion status of the resource copy. For graphics driver debugging, the resource copy result data can reflect whether the resource upload or data relocation was correct. When subsequent rendering results show texture anomalies, color anomalies, or resource content errors, the resource copy result data can be used to determine whether the anomaly originates from the resource input path. By generating resource copy result data corresponding to batch calls through the resource copy unit, resource processing tasks can also be included in a unified call-by-call debugging system, thereby avoiding the debugging scope being limited to the rendering output results.

[0168] The call-by-call rendering module 530 is used to associate batch calls with execution result data generated by the graphics rendering unit and / or resource copying unit based on the call identifier corresponding to the batch call, and output the execution result data according to the call identifier. The call-by-call rendering module 530 is a functional module in the graphics processor simulation model 500 used to organize and output execution result data. Its core function is to use the call identifier as an index to bind the result data generated by different execution units with the corresponding batch calls. The call identifier can be generated when a batch call enters the graphics processor simulation model, or it can be generated according to the receiving order or execution order of the batch calls, used to distinguish different batch calls. After receiving the rendering execution result data generated by the graphics rendering unit and / or the resource copy result data generated by the resource copying unit, the call-by-call rendering module 530 can write the call identifier into the naming information, index information, or metadata information corresponding to the result data, enabling the execution result data to be traced back to the batch call that produced the result.

[0169] In its implementation, the per-call rendering module 530 can generate rendered result images from frame buffer data and name or arrange them according to the call identifier; it can also generate corresponding data files or visualization data from depth buffer data, stencil buffer data, or resource copy result data and store them in association according to the same call identifier. If the same batch of calls generates rendered result images, depth buffer data, and stencil buffer data simultaneously, the per-call rendering module 530 can group these data under the same call identifier, allowing debuggers to view different types of execution results within the same batch call dimension. If the batch call corresponds to a resource copy task, the per-call rendering module 530 can output the resource copy result data in binary, structured, or visualization file format and associate it with the corresponding batch call through the call identifier. Through this module's processing, the graphics processor simulation model 500 no longer only outputs the final rendered result but can output execution result data at the batch call granularity, thus providing a finer-grained data foundation for locating abnormal execution results.

[0170] The call marking module 540 is used to acquire call associations and target call identifiers. Based on the target call identifier and call associations, it matches the current batch calls, current graphics driver commands, and current graphics application programming interfaces (APIs) during the execution of the graphics processor simulation model. The target call identifier is the call identifier associated with the execution result data that contains an anomaly. The call marking module 540 is a functional module in the graphics processor simulation model 500 used to convert the results of preceding anomaly localization into runtime matching conditions. The target call identifier can come from the execution result data. For example, when a rendered result image, depth buffer data, template buffer data, or resource copy result data is determined to be an anomaly, the call identifier corresponding to that execution result data can be determined as the target call identifier. The call associations are used to characterize the correspondence between the graphics application programming interface, graphics driver commands, and batch calls, enabling the call marking module to further determine the associated target graphics driver commands and target graphics application programming interfaces after the target call identifier points to the target batch call.

[0171] During operation, the call marking module 540 can read the pre-configured target call identifier and pass it to the front-end module that receives batch calls. After the current batch call enters the front-end module, the call marking module enables the front-end module to match the current call identifier corresponding to the current batch call with the target call identifier. If a successful match is achieved at the batch call level, the current graphics driver command and the current graphics application programming interface (API) can be further determined based on the call association relationship and matched with the target graphics driver command and the target API. Through this matching process, the graphics processor simulation model can identify at runtime whether the currently executing object belongs to the target call chain to be debugged.

[0172] Log unit 550 is used to output process logs corresponding to the currently matched batch calls, current graphics driver commands, and current graphics application programming interfaces (APIs) when the call marker module matches successfully, for debugging the graphics driver. Log unit 550 is a functional unit in the graphics processor simulation model 500 used to record execution process information. It can record batch call reception information, graphics driver command parsing information, API association information, resource binding status, rendering state configuration, buffer access status, and input / output information for each simulation execution stage. Unlike conventional full log output, log unit 550 can maintain a non-target log output state when the call marker module fails to match, outputting only basic running information or no detailed logs. After the call marker module matches successfully, it enters the target log output state, outputting detailed process logs for the currently matched batch calls, current graphics driver commands, and current APIs.

[0173] In specific implementation, the log unit 550 can work in cooperation with the front-end module, the graphics rendering unit, the resource copying unit and other modules at the execution stage. When the current batch call, the current graphics driver command and the current graphics application programming interface meet the matching conditions, the log unit 550 can record the execution process of the call link in the simulation model, such as the entry time of the current batch call, the number of commands, command types, command parameters, resource access status, rendering state changes, pixel output related information or resource copying related information. The process log can be output in the form of text files, structured log files or data readable by debugging tools, and can be stored in association with the call identifier. By outputting the process log when the matching succeeds, the log content can be focused on the call link corresponding to the abnormal execution result data, reducing log data generated by irrelevant calls, which is convenient for debugging personnel to analyze the source of the abnormality by combining the execution result data and the process log, thereby locating the problematic link of the graphics driver in the interface conversion, graphics driver command generation, batch call assembly or simulation execution process.

[0174] In addition, in the exemplary embodiments of the present disclosure, there is also provided an electronic device capable of implementing the above graphics driver debugging method.

[0175] Those skilled in the art can understand that various aspects of the present disclosure can be implemented as a system, a method or a program product. Therefore, various aspects of the present disclosure can be specifically embodied in the following forms, that is: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, which may be collectively referred to as "circuit", "module" or "system" herein.

[0176] The following refers to Figure 6 to describe the electronic device 600 according to this embodiment of the present disclosure. Figure 6 The electronic device 600 shown is only an example, and shall not impose any limitation on the function and scope of use of the embodiments of the present disclosure.

[0177] As Figure 6 shown, the electronic device 600 is in the form of a general-purpose computing device. Components of the electronic device 600 may include, but are not limited to: the at least one processing unit 610 described above, the at least one storage unit 620 described above, a bus 630 connecting different system components (including the storage unit 620 and the processing unit 610), and a display unit 640.

[0178] Wherein, the storage unit stores program code, and the program code can be executed by the processing unit 610, causing the processing unit 610 to execute the steps according to various exemplary embodiments of the present disclosure described in the "Exemplary Method" section of this specification. For example, the processing unit 610 can execute the steps as Figure 1Step S110 shows obtaining the call association relationship and the target call identifier. The call association relationship is used to characterize the mapping relationship between batch calls, graphics application programming interfaces (APIs), and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model. Step S120 shows matching the current batch calls, current graphics driver commands, and current APIs during the operation of the graphics processor simulation model based on the target call identifier and the call association relationship. Step S130 shows that if the matching is successful, the process log corresponding to the successfully matched current batch calls, current graphics driver commands, and current APIs is output. The process log is used for debugging the graphics driver.

[0179] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 621 and / or cache memory (Cache) 622, and may further include read-only memory (ROM) 623.

[0180] Storage unit 620 may also include a program / utility 624 having a set (at least one) of program modules 625, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0181] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0182] Electronic device 600 can also communicate with one or more external devices 670 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. As shown, network adapter 660 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0183] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0184] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0185] refer to Figure 7 As shown, a program product 700 for implementing the above-described graphics driver debugging method according to an embodiment of the present disclosure is described. This product may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0186] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0187] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0188] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0189] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0190] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0191] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0192] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This specification is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. It is understood that the specification and embodiments are to be considered exemplary only and are intended to illustrate the true scope and technical concepts of this disclosure.

[0193] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A graphics driver debugging method, characterized in that, include: The system obtains the call association relationship and the target call identifier. The call association relationship is used to characterize the mapping relationship between batch calls and the graphics application programming interface and graphics driver commands. The target call identifier is the call identifier associated with the execution result data that has an anomaly. The call identifier is used to associate the batch calls and their execution result data in the graphics processor simulation model. The batch call is when the graphics driver or firmware side assembles one or more graphics driver commands and submits them to the execution unit of the graphics processor simulation model according to the submission strategy. Based on the target call identifier and the call association, the current batch call, current graphics driver command, and current graphics application interface during the operation of the graphics processor simulation model are matched with the target batch call, target graphics driver command, and target graphics application interface; If a match is successful, output the process log corresponding to the current batch call, the current graphics driver command, and the current graphics application interface that were successfully matched. The process log is used to debug the graphics driver.

2. The graphics driver debugging method according to claim 1, characterized in that, The step of matching the current batch calls, current graphics driver commands, and current graphics application programming interfaces (APIs) during the execution of the graphics processor simulation model with the target batch calls, target graphics driver commands, and target graphics APIs based on the target call identifier and the call association relationship includes: Determine the target batch call corresponding to the target call identifier, and determine the target graphics driver command and the target graphics application interface associated with the target batch call based on the call association relationship; The target batch call, the target graphics driver command, and the target graphics application interface are matched with the current batch call, the current graphics driver command, and the current graphics application interface to obtain the successfully matched current batch call, the current graphics driver command, and the current graphics application interface.

3. The graphics driver debugging method according to claim 2, characterized in that, The step of matching the target batch call, the target graphics driver command, and the target graphics application interface with the current batch call, the current graphics driver command, and the current graphics application interface to obtain the successfully matched current batch call, the current graphics driver command, and the current graphics application interface includes: Perform a first match between the current batch call and the target batch call; If the first match is successful, the current graphics driver command and the current graphics application interface associated with the current batch call that was successfully matched in the first match are determined according to the call association relationship, and the current graphics driver command is matched with the target graphics driver command, and the current graphics application interface is matched with the target graphics application interface. If the current graphics driver command and the target graphics driver command are successfully matched, and the current graphics application interface and the target graphics application interface are successfully matched, the second match is determined to be successful, and the currently matched batch call, the current graphics driver command, and the current graphics application interface are obtained.

4. The graphics driver debugging method according to claim 1, characterized in that, The process log includes at least one of the following: The execution process information of the current batch call; The parsing information, scheduling information, or execution status information of the current graphics driving command; The graphics driver processing information corresponding to the current graphics application programming interface.

5. The graphics driver debugging method according to claim 1, characterized in that, Obtain the target call identifier, including: Arrange and display or store multiple execution result data in association according to the call identifier; The call identifier associated with the abnormal execution result data is determined from among the multiple execution result data, and the call identifier associated with the abnormal execution result data is written as the target call identifier into the configuration file of the graphics processor simulation model; Obtain the target call identifier from the configuration file.

6. The graphics driver debugging method according to claim 1, characterized in that, The call association is generated in the following way: When the graphics driver converts the graphics application interface into the graphics driver command, a first correspondence between the graphics application interface and the graphics driver command is recorded; When one or more of the graphics driver commands are assembled into the batch call, a second correspondence between the graphics driver commands and the batch call is recorded; The call association relationship is generated based on the first correspondence and the second correspondence.

7. The graphics driver debugging method according to any one of claims 1 to 6, characterized in that, The call identifier is associated with batch calls and their execution result data in the graphics processor simulation model in the following way: In response to the graphics processor simulation model receiving a call flag instruction for the batch call, the call identifier corresponding to the batch call is determined; Obtain the execution result data corresponding to the batch call; The call identifier is written into the execution result data to establish the association between the call identifier and the execution result data.

8. The graphics driver debugging method according to claim 7, characterized in that, Determining the call identifier corresponding to the batch call includes: Generate a call identifier corresponding to the batch call according to the receiving order or execution order of the batch call in the graphics processor simulation model; The call identifier is associated with and stored in batch description information of the batch call, the batch description information including at least one of batch call sequence number, task type and graphics-driven command list.

9. The graphics driver debugging method according to any one of claims 1 to 6, characterized in that, The execution result data is obtained and output in the following ways: Determine the task type corresponding to the batch call, wherein the task type includes at least one of rendering task and resource copy task; Based on the task type, obtain the execution result data generated by the graphics processor simulation model executing the batch call; The execution result data is associated with the batch call based on the call identifier, and the execution result data is output according to the call identifier.

10. The graphics driver debugging method according to claim 9, characterized in that, The execution result data includes the rendered result image; in the case of batch invoking the corresponding rendering task, the method further includes: Obtain the frame buffer data generated by the graphics processor simulation model after executing the batch call; The rendered image is generated based on the frame buffer data; The rendered result image is named or indexed according to the call identifier, so that the rendered result image is associated with the corresponding batch call through the call identifier; The rendered image is output according to the calling identifier.

11. The graphics driver debugging method according to claim 10, characterized in that, The process of generating the rendered image based on the frame buffer data includes: Read the binary pixel data from the frame buffer data; The binary pixel data is converted pixel by pixel according to the preset image output format; The rendered image is generated based on the pixel data after format conversion.

12. The graphics driver debugging method according to claim 9, characterized in that, The execution result data includes rendering intermediate buffer data, which includes at least one of depth buffer data and template buffer data. When the batch calls the corresponding rendering task, the method further includes: Obtain the rendering intermediate buffer data generated by the graphics processor simulation model during the execution of the batch call; Associate the rendering intermediate buffer data with the call identifier; The rendering intermediate buffer data is output according to the call identifier.

13. The graphics driver debugging method according to claim 9, characterized in that, The execution result data includes resource copy result data; In the case of the batch invoking the corresponding resource copy task, the method further includes: Obtain the resource copy result data generated by the graphics processor simulation model during the execution of the batch call; Associate the resource copy result data with the call identifier; The resource copy result data is output according to the call identifier.

14. A graphics-driven debugging device, characterized in that, include: The target identifier acquisition module is used to acquire call association relationships and target call identifiers. The call association relationships are used to characterize the mapping relationship between batch calls and graphics application programming interfaces and graphics driver commands. The target call identifier is the call identifier associated with execution result data that has an anomaly. The call identifier is used to associate batch calls and their execution result data in the graphics processor simulation model. The batch call is when the graphics driver or firmware side assembles one or more graphics driver commands according to the submission strategy and submits them to the execution unit of the graphics processor simulation model. The matching module is used to match the current batch calls, current graphics driver commands, and current graphics application interfaces during the operation of the graphics processor simulation model with the target batch calls, target graphics driver commands, and target graphics application interfaces based on the target call identifier and the call association relationship; The log output module is used to output process logs corresponding to the currently matched batch call, the currently matched graphics driver command, and the currently matched graphics application interface when a match is successful. The process logs are used to debug the graphics driver.

15. A graphics processor simulation model system, characterized in that, include: The graphics rendering unit is used to receive batch calls to rendering tasks generated by the graphics driver, and execute the graphics driver commands in the batch calls to generate rendering execution result data corresponding to the batch calls; the batch calls are the execution units of the graphics processor simulation model that assemble one or more graphics driver commands according to the submission strategy by the graphics driver or firmware. The resource copy unit is used to receive a batch call to a resource copy task generated by the graphics driver, and execute the graphics driver commands in the batch call to generate resource copy result data corresponding to the batch call. The batch call rendering module is used to associate the batch call with the execution result data generated by the graphics rendering unit and / or the resource copying unit based on the call identifier corresponding to the batch call, and output the execution result data according to the call identifier; The call marking module is used to obtain call associations and target call identifiers, and to match the current batch calls, current graphics driver commands, and current graphics application interfaces during the operation of the graphics processor simulation model with target batch calls, target graphics driver commands, and target graphics application interfaces based on the target call identifiers and the call associations. The target call identifier is the call identifier associated with abnormal execution result data. The logging unit is used to output process logs corresponding to the currently matched batch call, the currently matched graphics driver command, and the currently matched graphics application interface when the call marker module is successfully matched, so as to debug the graphics driver.

16. An electronic device, characterized in that, include: processor; as well as A memory storing computer-readable instructions that, when executed by the processor, implement the graphics driver debugging method as described in any one of claims 1 to 13.

17. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the graphics driver debugging method as described in any one of claims 1 to 13.

Images