Simulation excitation data extraction method and device of graphics processor, equipment and medium

Abstract

The invention discloses a simulation excitation data extraction method and device of a graphics processor, equipment and a medium, and belongs to the technical field of computers. The method comprises the following steps: acquiring a to-be-simulated graphic display frame; the graphic display frame comprises an interactive interface of a driving program and a system kernel, and calling logic for triggering operation of the graphic processor is packaged in the interactive interface; configuring a command execution environment of the graphics processor through a preset interaction function; in the process of executing the calling logic through the interaction interface and triggering the operation of the graphics processor, obtaining interaction data between the driving program and a system kernel through an interceptor; and performing structured processing on the interaction data to obtain simulation excitation data of the graphics processor. The problem that an existing instruction generation method is high in complexity can be solved. The problems that an existing excitation data writing method is low in efficiency, and the accuracy and coverage rate of excitation data are insufficient can be solved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a method, apparatus, device, and medium for extracting simulation stimulus data of a graphics processor. Background Technology

[0002] In modern computing, Graphics Processing Units (GPUs) have become core components for graphics rendering, scientific computing, artificial intelligence (AI) acceleration, and high-performance computing (HPC). Due to the high parallelism and complexity of GPU architecture, simulation technology is an indispensable step in hardware design and optimization. GPU simulation helps designers verify the correctness of new architectures, optimize their performance, and debug potential functional defects before actual hardware manufacturing.

[0003] However, traditional manual stimulus data writing methods are labor-intensive and prone to human error, especially when dealing with complex GPU hardware designs. The generation and adjustment of each stimulus data point requires significant manual intervention and experience-based judgment, resulting in inefficiency and insufficient accuracy and coverage. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, device, and medium for extracting simulation stimulus data for a graphics processor, which can solve the problems of low efficiency and insufficient accuracy and coverage of existing stimulus data writing methods.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a method for extracting simulation stimulus data from a graphics processor, the method comprising: Obtain the graphics display framework to be simulated; the graphics display framework includes the interaction interface between the driver and the system kernel, and the interaction interface encapsulates the calling logic that triggers the operation of the graphics processor; The command execution environment of the graphics processor is configured through preset interactive functions; During the process of executing the calling logic through the interactive interface and triggering the operation of the graphics processor, the interceptor obtains the interaction data between the driver and the system kernel. The interactive data is structured to obtain the simulation stimulus data of the graphics processor.

[0006] Secondly, embodiments of this application provide a simulation stimulus data extraction device for a graphics processor, the device comprising: The acquisition module is used to acquire the graphics display framework to be simulated; the graphics display framework includes an interaction interface between the driver and the system kernel, and the interaction interface encapsulates the calling logic that triggers the operation of the graphics processor. A configuration module is used to configure the command execution environment of the graphics processor through preset interactive functions; The interception module is used to obtain the interaction data between the driver and the system kernel through an interceptor during the process of executing the calling logic through the interaction interface and triggering the operation of the graphics processor. The processing module is used to perform structured processing on the interactive data to obtain the simulation stimulus data of the graphics processor.

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

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

[0009] Beneficial effects: In this embodiment, the command execution environment of the graphics processor is configured through a preset interactive function. During execution, the system call interception technique is used to automatically generate simulation stimulus data that meets the hardware design requirements, reducing data redundancy and manual processing costs, and greatly improving the efficiency and coverage of stimulus generation. Secondly, the interceptor captures data without modifying the core execution logic of the driver, and does not affect the normal operation of the graphics display framework. This approach is low-intrusive and ensures the reliability of extraction and the realism of the scene. Finally, the structured processing directly outputs a format compatible with simulation tools, eliminating the need for additional format conversion and significantly shortening the preparation cycle of simulation stimulus data. Attached Figure Description

[0010] Figure 1 This is a flowchart of a method for extracting simulation stimulus data of a graphics processor according to an embodiment of this application.

[0011] Figure 2 This is a flowchart illustrating the specific steps involved in extracting simulation stimulus data for a graphics processor, as provided in an embodiment of this application.

[0012] Figure 3 This is a block diagram of a command device for a graphics processor provided in an embodiment of this application.

[0013] Figure 4 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0016] A graphics processing unit (GPU), also known as a display core, visual processor, or display chip, is a microprocessor specifically designed for performing image and graphics-related calculations in personal computers, workstations, game consoles, and some mobile devices.

[0017] The central processing unit (CPU), also known as the processor, is the core of a computer system for computing and control, and is the final execution unit for information processing and program execution.

[0018] In modern computing, GPUs have become core components for graphics rendering, scientific computing, artificial intelligence (AI) acceleration, and high-performance computing (HPC). Due to the high parallelism and complexity of GPU architectures, simulation technology is an indispensable step in hardware design and optimization. GPU simulation helps designers verify the correctness of new architectures, optimize their performance, and debug potential functional defects before actual hardware manufacturing. However, existing simulation technologies face many challenges in efficiently generating simulation stimulus data, extracting detailed operational data, and meeting real-time performance analysis requirements.

[0019] In GPU hardware design, the simulation process is typically divided into high-level abstract model simulation and register transfer level (RTL) simulation. High-level simulation is used for rapid prototyping and initial verification, while RTL simulation provides more accurate timing and logical behavior, capturing more hardware details. To fully verify the complex architecture design of a GPU, a large amount of simulation stimulus data needs to be generated. This data is used to drive the simulator to execute various operating scenarios, ensuring that the hardware design can correctly handle all possible inputs and states.

[0020] Although GPU simulation technology plays an important role in hardware design and optimization, existing simulation techniques have significant limitations in stimulus data generation and simulation data extraction: 1. Insufficient data extraction granularity: Existing simulation tools typically only extract coarse-grained performance metrics (such as GPU utilization and memory bandwidth), failing to capture more detailed operational data, such as instruction-level execution, detailed system call information, and cache hit rates. This lack of fine-grained data makes comprehensive analysis of GPU hardware behavior difficult, limiting the depth of hardware design optimization.

[0021] 2. Stimulus data generation is complex and time-consuming: Generating effective simulation stimulus data requires covering all possible operation paths and states of the GPU, which usually relies on manual design and debugging. Due to the high complexity of GPU architecture, manually generating stimulus data is time-consuming, labor-intensive, and error-prone, making it difficult to fully cover all functional paths of the design.

[0022] To address the aforementioned problems, this application provides a method, apparatus, electronic device, and storage medium for extracting simulation stimulus data of a graphics processor. The following detailed description, in conjunction with the accompanying drawings, through specific embodiments and application scenarios, illustrates the method for extracting simulation stimulus data of a graphics processor provided in this application.

[0023] Figure 1 This is a flowchart of a method for extracting simulation stimulus data of a graphics processor according to an embodiment of this application. The method includes the following steps.

[0024] Step 101: Obtain the graphics display framework to be simulated.

[0025] In this embodiment of the application, the graphics display framework includes an interaction interface between the driver and the system kernel.

[0026] In some embodiments, the graphics display framework can be Mesa3D, DirectX, Vulkan driver framework, etc. Among these, Mesa3D is a key open-source graphics library in the Linux operating system, providing software implementations for various graphics application programming interfaces (APIs), enabling applications to interact with GPU hardware from different manufacturers. The Gallium3D framework within Mesa3D further simplifies driver development.

[0027] In this embodiment, the interaction interface encapsulates the calling logic that triggers graphics processor operations. That is, the interaction interface internally encapsulates multiple functions or commands corresponding to the calling logic. These functions or commands are used to translate commands issued by the upper-layer application into low-level instructions that the GPU can understand.

[0028] In some embodiments, the interaction interface may be the Direct Rendering Manager (DRM) interface.

[0029] Step 102: Configure the command execution environment of the graphics processor through a preset interactive function.

[0030] In this embodiment of the application, the command execution environment is the configuration required before the GPU executes the command.

[0031] For example, when the command is a drawing task, the interactive function does not directly execute the drawing task, but prepares for the drawing task.

[0032] In some embodiments, the interaction function includes at least one of a context creation function, a context cleanup function, a status query function, and a command wait function.

[0033] In some embodiments, the context creation function is used to create a context; the context cleanup function is used to clean up the context; the status query function is used to query and obtain the execution status of the command stream of the graphics processor, the execution status including one of the reset state, running state and suspended state; and the command wait function is used to synchronize the execution timing of the GPU and the CPU.

[0034] For example, the interaction functions include a context creation function, which creates a context for rendering; allocates memory to store game textures, model vertex data, etc.; and sets the state of the rendering pipeline, such as enabling depth testing and setting texture filtering methods.

[0035] In some embodiments, the command execution environment of the graphics processor is set to call interception mode through a preset interaction function. This call interception mode is used to skip system kernel calls, avoid interaction with real hardware or kernel modules, and reduce the impact on the system.

[0036] Step 103: During the process of executing the call logic through the interactive interface and triggering the graphics processor operation, the interceptor obtains the interaction data between the driver and the system kernel.

[0037] In some embodiments, the interceptor is deployed in the driver's calling function.

[0038] In some embodiments, when an application calls the graphics API, the graphics framework's calling logic begins to execute, sending system calls such as ioctl to the system kernel through the driver to request the GPU to perform specific operations.

[0039] In some embodiments, the dynamic link library of the graphics display framework to be simulated is modified to inject interceptor code into the call functions that enable communication between the driver and the Windows kernel. For example, modifications and extensions to libdrm can be used to intercept OpenGL system commands.

[0040] In some embodiments, the data captured by the interceptor includes: command stream, resource information, synchronization information, context, and state. The command stream includes: drawing commands, memory operation commands, etc.; resource information includes: the memory address, size, and format operated on by the commands; synchronization information is used to ensure the state of synchronization objects that ensure commands are executed sequentially; context and state represent which context is currently executing, and various state configurations of the GPU.

[0041] For example, when a frame needs to be drawn, the upper-layer application calls the driver's interface. The driver translates the drawing commands sent by the upper-layer application into a low-level command stream that the GPU can understand, and then sends it to the system kernel via a system call. The system kernel then submits the command to the physical GPU. During this process, the interceptor captures and records all these low-level command streams, as well as related resource information, synchronization signals, etc.

[0042] In other embodiments, the data captured by the interceptor also includes: system call parameters, return values, timestamps, call stacks, etc.

[0043] Step 104: Perform structured processing on the interactive data to obtain the simulation stimulus data of the graphics processor.

[0044] In some embodiments, structuring includes parsing, classifying, organizing, and formatting.

[0045] In some embodiments, the captured raw data is a binary stream or a scattered log. The binary stream or scattered log is parsed, classified, organized, and formatted to obtain the simulation stimulus data for the graphics processor.

[0046] For example, the captured raw data can be converted into a standard format, such as JSON, Protobuf, or a custom binary format.

[0047] In some embodiments, the simulation stimulus data of the graphics processor is the input specification of the simulation stimulus data for the simulation tool.

[0048] In summary, in this embodiment, by configuring the command execution environment of the graphics processor through a preset interactive function and by using system call interception technology during execution, the present invention can automatically generate simulation stimulus data that meets hardware design requirements, reducing data redundancy and manual processing costs, and greatly improving the efficiency and coverage of stimulus generation. Secondly, by capturing data without modifying the core execution logic of the driver, the interceptor does not affect the normal operation of the graphics display framework, resulting in low invasiveness and ensuring the reliability and realism of the extraction. Finally, the structured processing directly outputs a format compatible with simulation tools, eliminating the need for additional format conversion and significantly shortening the preparation cycle of simulation stimulus data.

[0049] Figure 2 This is a flowchart illustrating the specific steps of a method for extracting simulation stimulus data from a graphics processor, as provided in an embodiment of this application. The method includes the following steps.

[0050] Step 201: Obtain the graphics display framework to be simulated.

[0051] The method for this step has been explained in step 101 above, and will not be repeated here.

[0052] In some embodiments, after step 201, the above-described simulation stimulus data method for graphics processors performs at least one of steps 202 to 205.

[0053] Step 202: Create an independent execution environment for the graphics processor's command flow through the context creation function.

[0054] In this embodiment of the application, step 202 is used to isolate the resource allocation and state configuration of different tasks.

[0055] In some embodiments, the independent execution environment of the command stream includes: an independent virtual address space, dedicated command buffers, private hardware state, and resource ownership and binding.

[0056] For example, the context creation function could be gsgpu_cs_ctx_create.

[0057] It should be noted that a GPU context can be regarded as an independent execution environment. The GPU context contains information such as command buffer, state, and resources, which allows different applications or tasks to be executed concurrently on the GPU without interfering with each other.

[0058] Understandably, the purpose of creating independent execution environments is to achieve task isolation and concurrent execution. This prevents interference between different applications or different tasks of the same application at the GPU level, ensuring data security and program stability. On the other hand, it allows multiple tasks to run on the GPU simultaneously, enabling the GPU to quickly switch between different execution environments, thereby efficiently handling workloads from multiple sources.

[0059] In some embodiments, step 202 may include sub-steps 2021 to 2024.

[0060] Sub-step 2021: Bind the context to be created to the target graphics processor and initialize the mutex lock of the context.

[0061] Sub-step 2022 involves sending a context creation request carrying resource allocation parameters to the system kernel through a preset data interface, so that the system kernel can allocate hardware resources to the context according to the resource allocation parameters.

[0062] Sub-step 2023: Receive the context identifier returned by the system kernel.

[0063] Sub-step 2024 initializes the command ring semaphore list of the context and returns the creation result containing the context identifier to the caller of the calling logic, thus completing the creation of the independent execution environment.

[0064] In the embodiments of this application, the preset data interface may be the Direct Rendering Manager (DRM) interface, for example, the preset data interface may be drm Command Write Read.

[0065] In this embodiment of the application, in a multi-threaded environment, in order to prevent multiple threads from modifying the state of the context at the same time, the context object usually contains a mutex.

[0066] In this embodiment, a context creates many synchronization semaphores, such as Semaphores or Fences, during command execution. These semaphores are stored in the command ring semaphore list and used to achieve CPU-GPU synchronization, as well as GPU internal task synchronization.

[0067] In one possible implementation, before sub-step 2021, the above-mentioned simulation stimulus data extraction method for the graphics processor may further include: determining the operation object and result carrier corresponding to the context to be created through parameter initialization; setting the call tracing mode through conditional compilation; and performing data verification and memory allocation on the system.

[0068] For example, memory allocation is performed using the memory allocation function (calloc) to allocate memory of size struct gsgpu_context for the context.

[0069] In one possible implementation, binding the context to be created to the target graphics processor in sub-step 2021 may include associating the context object with the GPU device object to which it belongs.

[0070] In one possible implementation, the mutex lock for the context is initialized in sub-step 2021, including: initializing the mutex lock (sequence_mutex) in the gpu_context structure.

[0071] In one possible implementation, resource allocation parameters include: the number and size of command buffers, the size of the GPU address space, and the priority of the context. These resource allocation parameters characterize the amount of resources required for the context to be created.

[0072] In one possible implementation, the context creation request in sub-step 2022 can be a context creation command (DRM_GSGPU_CTX) that requests the system kernel to create a context. This context creation request carries the number and size of command buffers required for the context to be created, the size of the GPU address space, and the priority of the context.

[0073] In one possible implementation, sub-step 2023 includes: ending the context document (ID) returned by the system kernel.

[0074] In this embodiment, the context ID is a system-wide unique number or handle assigned by the system kernel. The context ID is a unique credential for a specific context, and all subsequent operations, such as querying status, submitting commands, and destroying the context, require identification of the context ID.

[0075] In one possible implementation, sub-step 2024 includes: initializing each element in the array as an empty doubly linked list head; and returning the creation result of the newly created and initialized context identifier to the caller of the calling logic through an output parameter, so that the caller can use the context identifier to submit a command.

[0076] For example, a triple loop iterates through the three-dimensional array sem_list in gpu_context, and the list_inithead function initializes each element in the three-dimensional array as an empty doubly linked list head, resulting in sem_list (semaphore list). sem_list is used to manage context-related synchronization objects to ensure that commands are executed in the correct order.

[0077] For example, the pointer to the newly created and initialized gpu_context object is cast to the gsgpu_context_handle type and returned to the caller via the output parameter (*context).

[0078] It's important to note that by skipping system kernel calls during the process of sending a context creation request carrying resource allocation parameters to the system kernel, interaction with the actual hardware or kernel modules is avoided. This allows the system to focus on capturing and analyzing the command stream without affecting other GPU programs or the system's state, thus minimizing the impact on the system. For example, the following code can be used to skip system kernel calls: / * * r = drmCommandWriteRead(dev->fd, DRM_GSGPU_CTX,&args, sizeof(args)); * if (r) *goto error; / In one possible implementation, after sub-step 2024, the above-mentioned method for extracting simulation stimulus data of the graphics processor may further include: if a preset value is returned, determining that the context creation function has been successfully executed; if a preset value is not returned, reporting an error and releasing the memory previously allocated by the system.

[0079] In this way, a context creation function object is created in user-space memory, and the creation result containing the context identifier is returned to the caller. Command flow tracing can provide a context handle containing the context identifier, which subsequent interactive functions can use to associate with the commands they submit.

[0080] Step 203: Destroy the independent execution environment using the context cleanup function.

[0081] In this embodiment of the application, step 203 is used to release the user-mode resources and kernel-mode resources occupied by the independent execution environment.

[0082] For example, the context cleanup function is gsgpu_cs_ctx_free.

[0083] In some embodiments, kernel-mode resources include: a context-exclusive GPU address space, a command buffer and synchronization object allocated in the kernel for that context, and state information related to the GPU hardware.

[0084] In some embodiments, the context cleanup function is used to destroy the GPU context created by the context creation function and release the hardware resources occupied by the GPU context, including CPU memory, synchronization objects, etc.

[0085] In some embodiments, step 203 may include sub-steps 2031 to 2034.

[0086] Sub-step 2031: Send a context cleanup request to the system kernel through a preset data interface.

[0087] Sub-step 2032: Destroy the mutex lock corresponding to the context to be destroyed according to the context identifier to be destroyed.

[0088] Sub-step 2033: Traverse and release all semaphore resources in the command ring semaphore list.

[0089] Sub-step 2034 releases the context structure and user-mode resources corresponding to the context to be destroyed, and synchronizes the reclamation results of kernel-mode resources to destroy the independent execution environment.

[0090] In this embodiment, the context cleanup request carries a context identifier to be destroyed, and the driver uses the context identifier to find the corresponding context object in its internal data structure.

[0091] In one possible implementation, before sub-step 2031, the above-mentioned method for extracting simulation stimulus data of the graphics processor may further include: parameter initialization; setting the call interception mode through conditional compilation; and verifying whether the context to be destroyed is empty.

[0092] In one possible implementation, the preset data interface in sub-step 2031 could be drm CommandWrite Read.

[0093] In one possible implementation, substep 2031 sends a GSGPU_CTX_OP_FREE_CTX command to the system kernel, informing the system kernel to release the resources associated with the context ID; skipping interaction with the real kernel and hardware, and performing cleanup only in user space.

[0094] In one possible implementation, the mutex lock corresponding to the context to be destroyed in sub-step 2032 is the mutex lock initialized in the creation function below.

[0095] For example, destroy the mutex (sequence_mutex) initialized in the context creation function (gsgpu_cs_ctx_create2).

[0096] In one possible implementation, sub-step 2033 may include: traversing all semaphore resources in the command ring semaphore list; for each found semaphore, removing the semaphore from its linked list, resetting the semaphore's internal state, and decrementing the semaphore object's reference count.

[0097] For example, a linked list traversal macro is used to traverse the command ring semaphore list; for each found semaphore, the semaphore is removed from its linked list, the internal state of the semaphore is reset, and the reference count of the semaphore object is reduced; if the reference count drops to zero, the memory occupied by the semaphore is also released.

[0098] In one possible implementation, substep 2033 may include: using the free function to release the memory block pointed to by the context pointer, which was allocated by calloc in the context function.

[0099] Understandably, the driver calls the `free()` function to completely release the entire data structure representing the context from memory. The context structure contains mutexes, a list of semaphores, and all other information describing the context's state. The driver then cleans up any other user-space memory it allocated for this context. Because the system kernel may need some time to asynchronously reclaim all hardware resources, after releasing its own user-space resources, the driver waits for confirmation from the system kernel to ensure that the kernel has also completely cleaned up, thus ensuring the synchronization and integrity of the entire destruction process.

[0100] In one possible implementation, after sub-step 2034, the above-mentioned method for extracting simulation stimulus data of the graphics processor may further include: if a preset value is returned, determining that the context cleanup function has been successfully executed; if a preset value is not returned, reporting an error.

[0101] In this way, by using the context cleanup function to release resources such as memory, GPU address space, and synchronization objects, residual resources are prevented from interfering with the normal operation of other contexts, thus improving the overall system performance.

[0102] Step 204: Obtain the execution status of the command stream using the status query function.

[0103] In this embodiment of the application, the execution state includes one of the following: reset state, running state, and suspended state.

[0104] In this embodiment, the status query function is used to query the GPU for the real-time status of the current task, ensuring that the CPU and GPU are synchronized.

[0105] In some embodiments, a reset state indicates that the GPU currently has no command stream being executed and all resources have been reset to their initial state.

[0106] In some embodiments, the running state indicates that the GPU is executing a command in the command stream, or that the command stream has been submitted and is in the waiting queue.

[0107] In some embodiments, a suspended state indicates that the GPU is paused in executing a command stream for some reason and needs to wait for specific conditions to be met before it can continue. For example, the command stream contains a "wait for fence" instruction, and the GPU needs to wait for other command streams to finish executing before it can continue; or, the resources that the GPU needs to access are not yet ready.

[0108] For example, the state query function is gsgpu_cs_query_reset_state.

[0109] In some embodiments, step 204 may include sub-steps 2041 to 2043.

[0110] Sub-step 2041: Construct a status query request.

[0111] Sub-step 2042 sends the status query request to the system kernel through a preset data interface, so that the system kernel can generate status response data according to the context identifier to be queried and the status query type.

[0112] Sub-step 2043: Receive the status response data returned by the system kernel and parse the status response data to obtain the execution status of the command stream.

[0113] In this embodiment of the application, the status query request includes the context identifier to be queried and the status query type.

[0114] In one possible implementation, before sub-step 2041, the above-mentioned method for extracting simulation stimulus data of the graphics processor may further include: parameter initialization; setting the call interception mode through conditional compilation; and verifying whether the context to be queried is empty.

[0115] In one possible implementation, sub-step 2041 may include: setting the opcode to the query state corresponding to the status query type and specifying the context identifier to be queried, thereby constructing a status query request.

[0116] For example, the opcode is set to "query status" by using args.in.op=GSGPU_CTX_OP_QUERY_STATE, and the context ID to be queried is specified by using args.in.ctx_id=context->id.

[0117] In one possible implementation, sub-step 2042 may include: sending a status query request to the DRM kernel driver via drm Command Write Read.

[0118] In one possible implementation, after receiving a status query request, the system kernel locates the corresponding GPU driver instance and internal data structure based on the context ID in the request, interacts with the GPU hardware, reads relevant hardware registers or queries internal states, and generates status response data. This status response data can be a binary data stream.

[0119] In one possible implementation, sub-step 2043 may include: receiving a binary data stream returned by the system kernel, the driver parsing the binary data stream according to a preset format to obtain a status value, which represents the execution status of the command stream.

[0120] For example, the execution states of the command flow specifically represented by different state values ​​are as follows: GSGPU_CONTEXT_STATE_RUNNING: The command stream is being executed on the GPU; GSGPU_CONTEXT_STATE_FINISHED: The command stream has been executed successfully; GSGPU_CONTEXT_STATE_ERROR: An error occurred during command stream execution; GSGPU_CONTEXT_STATE_SUSPENDED: The command stream is suspended while waiting for a certain condition.

[0121] It's important to note that by skipping kernel calls during the status query request process, interaction with the actual hardware or kernel modules is avoided. This allows the system to focus on capturing and analyzing the command stream, minimizing impact on other GPU programs and the system's overall state. In non-call interception mode, `drmCommandWriteRead` is invoked to send the query request to the kernel. However, in call interception mode, the kernel processes the query and fills `args.out` with the results (`reset_status` and `hangs`). The status query function then returns these results to the caller via output parameters (`state` and `hangs`). Thus, in call interception mode, the actual kernel call is skipped, further reducing system impact.

[0122] In one possible implementation, since the actual kernel call is skipped, the output parameters are set to specified values ​​in call interception mode. For example, setting `state` and `hangs` to 0 indicates no reset and no hangs.

[0123] In one possible implementation, after sub-step 2043, the above-mentioned method for extracting simulation stimulus data of the graphics processor may further include: if a preset value is returned, determining that the state query function has been successfully executed; if a preset value is not returned, reporting an error.

[0124] In this way, by querying the execution status of the command stream through the status query function, the execution sequence of the command stream can be synchronized, which is beneficial for system scheduling and allocating GPU resources to other waiting tasks.

[0125] Step 205: Synchronize the execution timing of the graphics processor and the central processing unit through the command wait function.

[0126] In this embodiment of the application, step 205 causes the command stream to be executed according to a preset dependency relationship.

[0127] In this embodiment, the command wait function is used to wait after submitting the command stream to ensure that the GPU completes the task before executing subsequent logic.

[0128] For example, the command wait function is gsgpu_ioctl_wait_cs.

[0129] In some embodiments, the command wait function is used for graphics rendering synchronization, computation task synchronization, multi-command stream dependencies, and resource release security.

[0130] In some embodiments, step 205 may include sub-steps 2051 to 2054.

[0131] Sub-step 2051: Construct command awaiting request.

[0132] Sub-step 2052: Send the command wait request to the system kernel through a preset data interface so that the system kernel can determine the execution status information based on the target command stream identifier, the wait timeout threshold and the dependency parameters.

[0133] Sub-step 2053: Receive the execution status information returned by the system kernel.

[0134] Sub-step 2054: Control the execution timing of the central processing unit based on the execution status information.

[0135] In this embodiment of the application, the command wait request includes the identifier of the target command stream, the wait timeout threshold, and the dependency parameters.

[0136] In this embodiment, the wait timeout threshold is the maximum time the CPU can wait. Setting a wait timeout threshold prevents the CPU from waiting indefinitely for a GPU that may have already frozen. The dependency parameter characterizes the waiting conditions.

[0137] In one possible implementation, the identifier of the target command stream can be the context ID to which the command stream belongs, and the dependency parameter can be the identifier (Fence ID) of the GPU command stream to be waited for.

[0138] In one possible implementation, sub-step 2051 may include: constructing a command wait request based on the context ID to which the command stream belongs, the wait timeout threshold, and the dependency parameters.

[0139] For example, a command wait request is constructed based on the context handle to which the command stream belongs, the type of the target hardware intellectual property (IP) block, the instance number of the target IP block, the hardware command ring ID where the command stream is located, the timeout threshold for the synchronization object handle to be waited for, the wait flag, and the busy output parameter. Here, the hardware command ring ID where the command stream is located represents the identifier (Fence ID) of the GPU command stream to be waited for, and busy indicates whether the GPU is still busy.

[0140] In one possible implementation, sub-step 2052 may include: initializing a union for communicating with the kernel, filling the union with the identifier of the target command stream, the wait timeout threshold and the identifier of the GPU command stream to be waited for, and sending a command wait request to the system kernel in the form of a union via the drmCommandWriteRead interface.

[0141] In one possible implementation, it is determined whether the timeout is an absolute time point; if the timeout is not an absolute time, gsgpu_cs_calculate_timeout is called to convert the relative timeout into the absolute time format expected by the system kernel.

[0142] For example, the command wait request is the DRM_IOCTL_GSGPU_WAIT_CS command, which is sent to the system kernel in the form of a union through the drmCommandWriteRead interface.

[0143] In one possible implementation, after receiving a wait request, the system kernel will find the corresponding synchronization object based on the identifier (Fence ID) of the GPU command stream to be waited for, check its current state, and generate execution status information.

[0144] In this embodiment of the application, the execution status information includes: the target command stream has been completed, the target command stream is still being executed, or the target command stream has timed out and not completed.

[0145] In one possible implementation, sub-step 2053 may include: receiving a status code returned by the system kernel, which represents execution status information.

[0146] For example, the status code is *busy. *busy=0 indicates that the command stream being waited for has been completed, and *busy=1 indicates that the wait has timed out and the GPU is still executing the command stream.

[0147] In one possible implementation, sub-step 2054 may include: if the execution status information indicates that the target command stream has been completed, reading the result data written by the GPU and submitting a new command stream to the GPU; if the execution status information indicates that the target command stream is still being executed, controlling the CPU to wait; if the execution status information indicates that the target command stream has timed out and has not been completed, recording an error log and notifying the application that a timeout error has occurred.

[0148] In this way, by using the command wait function as a synchronization point between the CPU and GPU, the correctness of data access and the orderliness of program execution are ensured.

[0149] In another possible implementation, prior to sub-step 2051, the above-mentioned method for extracting simulation stimulus data of the graphics processor may also include: setting the interception mode through conditional compilation.

[0150] In this way, the actual waiting process is skipped, and the command flow is simulated to complete instantly, avoiding test blocking caused by waiting for the real GPU.

[0151] Step 206: In response to triggering a graphics processor operation, record the raw data via the interceptor.

[0152] In this embodiment of the application, the raw data includes: input parameters of the interaction interface, output parameters returned by the system kernel, and execution context information.

[0153] For example, the input parameters of the interactive interface include: the address and size of the submitted command stream buffer, the opcode to be executed, the context ID, etc.; the output parameters returned by the system kernel include: the newly created context ID, the queried GPU status, the signal value of the synchronization object, etc.

[0154] In this embodiment of the application, the execution context information includes a timestamp, a process identifier (PID), and a call stack. For example, In some embodiments, triggering graphics processor operations can be an application calling APIs such as OpenGL / Vulkan, or a function call within the driver. The interceptor is activated when these calls require interaction with the GPU hardware or kernel.

[0155] For example, modifications and extensions to libdrm are used to intercept OpenGL system commands.

[0156] In some embodiments, step 206 may include: submitting a GPU command stream via a command submission function in response to triggering a graphics processor operation; and recording raw data via an interceptor during the submission of the GPU command stream by the command submission function.

[0157] In one possible implementation, submitting a GPU command stream via a command submission function may include: initializing the command submission function; setting a call interception mode via conditional compilation; printing a list of buffer objects and traversing the command blocks; and writing the virtual address of a drawing call to an output file when a drawing call is detected, with the output file used to store the raw data of the drawing call.

[0158] For example, access the global or static table `bo_list_table`, look up the corresponding list of buffer objects based on `bo_list_handle`, iterate through this list, and print the handle (`bo_handle`) of each buffer object. Iterate through each command block in the `chunks` array. Print the ID (`chunk_id`), length (`length_dw`), and data pointer (`chunk_data`) of each block.

[0159] For example, upon checking the IB block representation to identify a draw call, the virtual address (va_start) and size (ib_bytes) of the IB are extracted, and fprintf(drawcall_file, "0x%llx\n", va) indicates that the draw call address is written to an output file (drawcall.dat).

[0160] Step 207: Identify and extract command stream data from the raw data, and use the command stream data as interactive data.

[0161] In this embodiment of the application, the command stream data includes the address of the indirect buffer, the size of the indirect buffer, and the binary instruction stream.

[0162] In some embodiments, it is determined which interactions in the raw data are operations that submit command streams; the contents of the command stream buffer are extracted from the input parameters of the operation.

[0163] For example, it can identify calls to ioctl commands that contain the DRM_GSGPU_SUBMIT_CMD opcode; and extract the underlying instructions to be executed by the GPU from the opcode buffer.

[0164] The above technical solutions can capture more detailed operational data and hardware behavior, support performance optimization and design verification under complex workloads, and improve the accuracy and reliability of simulation results.

[0165] Step 208: Classify the interactive data according to the preset data dimensions, and convert the classified interactive data into a format supported by the simulation tool.

[0166] In this embodiment of the application, the data dimension includes at least one of context configuration data, resource attribute data, command stream data, and synchronization timing data.

[0167] In some embodiments, context configuration data includes: the context ID, the priority specified at creation time, the allocated command buffer size, etc.

[0168] In some embodiments, resource attribute data includes: the size, format, and address of the buffer object (BO); the size, pixel format, and sampling method of the texture; and resource creation, destruction, and binding operations.

[0169] In some embodiments, the command stream data includes: drawing commands, compute shader dispatch commands, state setting commands, etc.

[0170] In some embodiments, the synchronization timing data includes: creation, signaling, and waiting operations of synchronization semaphores, timestamps of command submissions, and results of query operations.

[0171] In some embodiments, different simulation tools have different input formats and data structures. The categorized structured data is mapped and packaged into different formats. For example, captured command stream binary data is populated into a Command Packet structure defined by the simulator.

[0172] Step 209: Verify the completeness and consistency of the classified interactive data and remove redundant data to obtain simulation stimulus data that conforms to the input specifications of the simulation tool.

[0173] In some embodiments, verifying the integrity and consistency of the categorized interactive data includes checking for missing data and checking for logical contradictions between data.

[0174] In some embodiments, removing redundant data includes removing extraneous data that does not affect the simulation results. For example, removing duplicate query operations, as well as debugging logs or irrelevant status queries.

[0175] By using the above technical solutions, the integrity and consistency of the interactive data are verified, eliminating possible errors or inconsistencies in the original data and improving the accuracy of the simulation. Eliminating redundant data can greatly reduce the amount of data that the simulation tool needs to process, thereby speeding up the simulation and reducing the demand for computing resources.

[0176] In summary, in this embodiment, a system call interception mechanism is introduced into the DRM module to monitor the interaction between the GPU driver and the kernel in real time, and to record in detail the instruction stream and data transmission operations from user space to kernel space; through optimized stimulus data generation and automated testing processes, simulation time and resource consumption are reduced, adapting to complex simulation tasks and high-performance computing requirements.

[0177] Figure 3 This is a block diagram of a simulation stimulus data extraction device for a graphics processor provided in an embodiment of this application, such as... Figure 3 As shown, the simulation stimulus data extraction device 300 for the graphics processor includes: The acquisition module 301 is used to acquire the graphics display framework to be simulated; the graphics display framework includes the interaction interface between the driver and the system kernel, and the interaction interface encapsulates the calling logic that triggers the operation of the graphics processor. Configuration module 302 is used to configure the command execution environment of the graphics processor through preset interactive functions; The interception module 303 is used to obtain the interaction data between the driver and the system kernel through an interceptor during the process of executing the call logic through the interactive interface and triggering the operation of the graphics processor. The processing module 304 is used to perform structured processing on the interactive data to obtain the simulation stimulus data of the graphics processor.

[0178] Optionally, the interaction functions include at least one of the following: context creation function, context cleanup function, status query function, and command wait function; configuration module 302 includes at least one of the following: The context creation submodule is used to create an independent execution environment for the graphics processor's command flow through the context creation function, so as to isolate the resource allocation and state configuration of different tasks; The context cleanup submodule is used to destroy the independent execution environment through context cleanup functions, so as to release the user-mode and kernel-mode resources occupied by the independent execution environment; The status query submodule is used to obtain the execution status of the command stream through the status query function; the execution status includes one of the following: reset status, running status, and suspended status; The command wait submodule is used to synchronize the execution timing of the graphics processor and the central processing unit through the command wait function, so that the command stream is executed according to the preset dependency relationship.

[0179] Optionally, context-created submodules include: The first initialization unit is used to bind the context to be created to the target graphics processor and initialize the mutex lock of the context; The first sending unit is used to send a context creation request carrying resource allocation parameters to the system kernel through a preset data interface, so that the system kernel can allocate hardware resources for the context according to the resource allocation parameters. The identifier receiving unit is used to receive the context identifier returned by the system kernel; The second initialization unit is used to initialize the command ring semaphore list of the context and return the creation result containing the context identifier to the caller of the calling logic, thus completing the creation of the independent execution environment.

[0180] Optional, the context cleanup submodule includes: The second sending unit is used to send a context cleanup request to the system kernel through the data interface; the context cleanup request carries a context identifier to be destroyed; The destruction unit is used to destroy the mutex lock corresponding to the context to be destroyed based on the context identifier to be destroyed; The first release unit is used to traverse and release all semaphore resources in the command ring semaphore list; The second release unit is used to release the context structure and user-mode resources corresponding to the context to be destroyed, and to synchronize the reclamation results of kernel-mode resources in order to destroy the independent execution environment.

[0181] Optional, the status query submodule includes: The first construction unit is used to construct a status query request, which includes the context identifier to be queried and the status query type. The third sending unit is used to send the status query request to the system kernel through a preset data interface, so that the system kernel can generate status response data according to the context identifier to be queried and the status query type. The data parsing unit is used to receive status response data returned by the system kernel and parse the status response data to obtain the execution status of the command stream.

[0182] Optional command-waiting submodules include: The second construction unit is used to construct a command wait request, which includes the identifier of the target command stream, the wait timeout threshold, and dependency parameters. The fourth sending unit is used to send a command waiting request to the system kernel through a preset data interface, so that the system kernel can determine the execution status information based on the identifier of the target command stream, the waiting timeout threshold, and the dependency parameters. The information receiving unit is used to receive execution status information returned by the system kernel. The execution status information includes: the target command stream has been completed, the target command stream is still being executed, or the target command stream has timed out and has not been completed. The timing control unit is used to control the execution timing of the central processing unit based on the execution status information.

[0183] Optionally, the interceptor is deployed in the driver's calling function. Interceptor module 303 includes: The interception and recording submodule is used to record raw data in response to the triggering of graphics processor operations. The raw data includes the input parameters of the interaction interface, the output parameters returned by the system kernel, and the execution context information. The execution context information includes the timestamp, process identifier, and call stack. The data extraction submodule is used to identify and extract command stream data from the raw data and use the command stream data as interactive data; the command stream data includes the address of the indirect buffer, the size of the indirect buffer, and the binary instruction stream.

[0184] Optionally, processing module 304 includes: The data classification submodule is used to classify interactive data according to preset data dimensions and convert the classified interactive data into a format supported by the simulation tool; the data dimensions include at least one of context configuration data, resource attribute data, command stream data, and synchronization timing data; The data processing submodule is used to verify the integrity and consistency of the classified interactive data and remove redundant data to obtain simulation stimulus data that conforms to the input specifications of the simulation tool.

[0185] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0186] Figure 4 This is a structural block diagram of an electronic device 400 according to an exemplary embodiment. For example... Figure 4 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the simulation stimulus data extraction method of the graphics processor in the foregoing embodiment.

[0187] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory including instructions that can be executed by a processor of electronic device 400 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0188] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described graphics processor simulation stimulus data extraction method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0189] This application also provides a computer program product, including a computer program that, when executed by a processor, implements a method for extracting simulation stimulus data of a graphics processor.

[0190] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0191] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0192] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0193] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0194] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0195] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0196] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

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

Claims

1. A method for extracting simulation stimulus data from a graphics processor, characterized in that, The method includes: Obtain the graphics display framework to be simulated; the graphics display framework includes the interaction interface between the driver and the system kernel, and the interaction interface encapsulates the calling logic that triggers the operation of the graphics processor; The command execution environment of the graphics processor is configured through preset interactive functions; During the process of executing the calling logic through the interactive interface and triggering the operation of the graphics processor, the interceptor obtains the interaction data between the driver and the system kernel. The interactive data is structured to obtain the simulation stimulus data of the graphics processor.

2. The method according to claim 1, characterized in that, The interaction function includes at least one of a context creation function, a context cleanup function, a status query function, and a command wait function. Configuring the command execution environment of the graphics processor through the preset interaction function includes at least one of the following: The context creation function creates an independent execution environment for the command flow of the graphics processor to isolate the resource allocation and state configuration of different tasks. The context cleanup function destroys the independent execution environment to release the user-mode and kernel-mode resources occupied by the independent execution environment. The execution status of the command stream is obtained through the status query function; the execution status includes one of the following: reset status, running status, and suspended status. The command wait function synchronizes the execution timing of the graphics processor and the central processing unit so that the command stream is executed according to a preset dependency relationship.

3. The method according to claim 2, characterized in that, The step of creating an independent execution environment for the command flow of the graphics processor through the context creation function to isolate the resource allocation and state configuration of different tasks includes: Bind the context to be created to the target graphics processor and initialize the mutex lock of the context; A context creation request carrying resource allocation parameters is sent to the system kernel through a preset data interface, so that the system kernel allocates hardware resources to the context according to the resource allocation parameters; Receive the context identifier returned by the system kernel; The command ring semaphore list of the context is initialized, and the creation result containing the context identifier is returned to the caller of the calling logic, thus completing the creation of the independent execution environment.

4. The method according to claim 3, characterized in that, The step of destroying the independent execution environment through the context cleanup function to release the user-mode and kernel-mode resources occupied by the independent execution environment includes: A context cleanup request is sent to the system kernel through the data interface; the context cleanup request carries a context identifier to be destroyed; Destroy the mutex lock corresponding to the context to be destroyed based on the context identifier to be destroyed; Iterate through and release all semaphore resources in the command ring semaphore list; Release the context structure and user-mode resources corresponding to the context to be destroyed, and synchronize the reclamation results of the kernel-mode resources to destroy the independent execution environment.

5. The method according to claim 2, characterized in that, The step of obtaining the execution status of the command stream through the status query function includes: Construct a status query request, which includes the context identifier to be queried and the status query type; The status query request is sent to the system kernel through a preset data interface, so that the system kernel generates status response data according to the context identifier to be queried and the status query type. The system receives the status response data returned by the system kernel and parses the status response data to obtain the execution status of the command stream.

6. The method according to claim 2, characterized in that, The step of synchronizing the execution timing of the graphics processor and the central processing unit through the command waiting function, so that the command stream is executed according to a preset dependency relationship, includes: Construct a command wait request, which includes the identifier of the target command stream, a wait timeout threshold, and dependency parameters; The command waiting request is sent to the system kernel through a preset data interface, so that the system kernel can determine the execution status information based on the identifier of the target command stream, the waiting timeout threshold, and the dependency parameters. The system receives the execution status information returned by the system kernel; the execution status information includes: the target command stream has been completed, the target command stream is still being executed, or the target command stream has timed out and not completed. The execution timing of the central processing unit is controlled based on the execution status information.

7. The method according to claim 1, characterized in that, The interceptor is deployed in the driver's calling function. During the execution of the calling logic through the interaction interface to trigger the graphics processor operation, the interceptor obtains the interaction data between the driver and the system kernel, including: In response to the triggering of the graphics processor operation, the interceptor records raw data; the raw data includes the input parameters of the interaction interface, the output parameters returned by the system kernel, and execution context information; the execution context information includes a timestamp, process identifier, and call stack. Identify and extract command stream data from the raw data, and use the command stream data as the interaction data; the command stream data includes the address of the indirect buffer, the size of the indirect buffer, and the binary instruction stream.

8. The method according to claim 1, characterized in that, The step of structuring the interactive data to obtain the simulation stimulus data of the graphics processor includes: The interactive data is categorized according to preset data dimensions, and the categorized interactive data is converted into a format supported by the simulation tool; the data dimensions include at least one of context configuration data, resource attribute data, command stream data, and synchronization timing data; The integrity and consistency of the categorized interactive data are verified and redundant data is removed to obtain simulation stimulus data that conforms to the input specifications of the simulation tool.

9. A device for extracting simulation stimulus data from a graphics processor, characterized in that, The device includes: The acquisition module is used to acquire the graphics display framework to be simulated; the graphics display framework includes an interaction interface between the driver and the system kernel, and the interaction interface encapsulates the calling logic that triggers the operation of the graphics processor. A configuration module is used to configure the command execution environment of the graphics processor through preset interactive functions; The interception module is used to obtain the interaction data between the driver and the system kernel through an interceptor during the process of executing the calling logic through the interaction interface and triggering the operation of the graphics processor. The processing module is used to perform structured processing on the interactive data to obtain the simulation stimulus data of the graphics processor.

10. An electronic device, characterized in that, It includes a memory, a processor, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the simulation stimulus data extraction method for a graphics processor as described in any one of claims 1-8.

11. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the simulation stimulus data extraction method for a graphics processor as described in any one of claims 1-8.

Images