A GPU task issuing and synchronizing method and system

Abstract

The application provides a GPU task issuing synchronization method and system, a synchronization point is preset in a GPU command stream, task progress is reflected by updating a completion mark in a shared memory page which is pre-allocated and directly addressable by a CPU, a task completion state is obtained by a lock-free batch query on a CPU side, and synchronization judgment is decoupled from an interrupt context to a software scheduling layer, so that unnecessary interrupt processing and lock competition overhead are fundamentally reduced.

Description

Technical Field

[0001] This invention relates to the field of GPU rendering technology, and more specifically, to a method and system for synchronizing GPU task distribution. Background Technology

[0002] In next-generation computing systems, GPUs (Graphics Processing Units) are no longer limited to 3D graphics rendering but are widely used in high-performance computing scenarios such as scientific computing, deep learning, and real-time image preprocessing. These applications typically employ heterogeneous computing architectures, with CPUs handling logic control and task scheduling, and GPUs performing large-scale data-parallel computation. Due to differences in instruction execution and storage systems between CPUs and GPUs, they usually work asynchronously to minimize transmission and computation latency.

[0003] However, this asynchronous collaboration model introduces synchronization risks. When the CPU submits a batch of drawing instructions or computational tasks to the GPU, the GPU often does not immediately complete the relevant operations. If the submitted data is overwritten or released before the GPU is truly ready, it can cause problems such as screen tearing, data corruption, or even program crashes. Therefore, introducing system processing mechanisms in heterogeneous systems is a necessary condition for ensuring system stability.

[0004] Existing memory resource allocation and management mechanisms for specific computing platforms, or interrupt-based display buffer swapping synchronization mechanisms, often focus on local optimization for single tasks or specific hardware environments, lacking a comprehensive consideration of system-level synchronization efficiency in high-concurrency, multi-process scenarios. Especially in complex graphics processing scenarios, traditional solutions rely on frequent interrupt responses or coarse-grained buffer kernel locks, which can easily lead to a significant consumption of CPU processing bandwidth in interrupt context switching and lock contention, causing system response delays and GPU resource idleness. Summary of the Invention

[0005] This invention addresses the technical problems existing in the prior art by providing a GPU task dispatch synchronization method and system, thus solving the problems of system response speed and resource utilization efficiency under complex loads.

[0006] According to a first aspect of the present invention, a GPU task distribution synchronization method is provided, comprising:

[0007] The user-mode driver receives rendering commands submitted by the application thread and dynamically switches the distribution path according to the scale of the commands to be submitted. When the commands to be submitted are large-scale rendering commands, multiple rendering commands are encapsulated into at least one buffer object.

[0008] The user-mode driver creates a corresponding output barrier object for the current submission batch and submits at least one buffer object and the output barrier object to the kernel layer. The output barrier object has a scheduling ready state and a hardware complete state.

[0009] Construct a physical address list of at least one of the buffer objects at the kernel layer, write the physical address list into the GPU hardware execution queue, and set the produced fence object to the scheduling ready state.

[0010] The GPU hardware reads the commands in each buffer object sequentially according to the physical address list and executes the rendering operation. After completion, the kernel layer transitions the produced fence object from the scheduling ready state to the hardware completed state.

[0011] The hardware completion state of the produced fence object is used as a prerequisite for the display module to perform page flipping operation. When the produced fence object is in the hardware completion state, the kernel layer automatically allows the display module to perform page flipping; otherwise, the page flipping operation of the display module is suspended until the produced fence object enters the hardware completion state.

[0012] Based on the above technical solution, the present invention can also be improved as follows.

[0013] Optionally, the step of dynamically switching the distribution path based on the size of the commands to be submitted further includes:

[0014] A dynamic threshold N is built into the user-space driver, where N is a positive integer;

[0015] If the number of commands to be submitted is greater than the dynamic threshold N, then the commands to be submitted are large-scale rendering commands.

[0016] If the number of commands to be submitted is less than or equal to the dynamic threshold N, and the commands to be submitted are small-scale control instructions, the command register direct write mode is adopted to write the control instructions into the GPU command register one by one to ensure the response latency of the control plane.

[0017] Optionally, the output fence object is implemented based on the Linux kernel's dma_fence synchronization primitive or DRM synchronization object. The scheduling ready state is used to mark that the task has entered the GPU hardware execution queue, and the hardware complete state is used to mark that the GPU has completed rendering and written the rendering data to disk. The output fence object defines the task's residence boundary and hardware execution cycle in the software queue through the scheduling ready state and the hardware complete state, and provides a unique hardware complete timestamp for the display module.

[0018] Optionally, during the rendering command submission process, the user-mode driver releases the application thread immediately after submitting the rendering command by calling the glFlush function, and the application thread does not block while waiting for the GPU to complete.

[0019] Optionally, it may also include a cross-frame synchronization link multiplexing step:

[0020] After the current frame rendering is submitted, the user-mode driver exports the output fence object that identifies the hardware completion state of the current frame as an anonymous file descriptor. The anonymous file descriptor only carries status signals and does not involve copying video memory data.

[0021] A new pre-dependency fence object is created for the next frame rendering batch. The hardware completion state of the current frame is injected into the pre-dependency fence object of the next frame through the anonymous file descriptor, so that the hardware completion state of the current frame is implicitly bound as a pre-wait condition when the next frame rendering batch is submitted.

[0022] Optionally, it also includes an asynchronous wake-up step for the preceding dependent fence object:

[0023] When a task to be submitted carries an unmet prerequisite dependency barrier object, the kernel scheduler registers a callback function on the output barrier object associated with the prerequisite dependency barrier object and suspends the task to be submitted.

[0024] When the output fence object is triggered to the completed state, the kernel layer automatically executes the callback function to wake up the task to be submitted.

[0025] Optionally, the hardware completion state of the generated fence object is used as a prerequisite for the display module to perform the page flipping operation, including:

[0026] After the GPU hardware completes rendering, the kernel layer automatically triggers the output fence object to transition from the scheduling ready state to the hardware completed state, and traverses the callback chain attached to the output fence object to execute the wake-up function.

[0027] When the display module initiates an atomic operation to set kernel mode, the kernel layer automatically waits for the signal that the produced fence object has been triggered to the hardware completion state before performing a page flip operation.

[0028] Optionally, a multi-rendering context fault isolation step may also be included:

[0029] Each rendering context is defined as an independent fault isolation domain, and completion signals are passed between different fault isolation domains only through read-only file descriptors;

[0030] When a hardware unresponsive event occurs in a single fault isolation domain, the system iterates through and cleans up any unfinished produced fence objects within that domain, injects an error status code to force the signal state of the produced fence object, and explicitly unregisters the callback functions attached to the produced fence object to eliminate dangling references. Subsequently, a rendering engine-level local reset is performed first to preserve intermediate data in video memory.

[0031] Optionally, an adaptive logical frame slicing step may also be included:

[0032] Real-time detection of the upper limit of the capacity of a single system call at the kernel level;

[0033] When the number of commands to be submitted exceeds the upper limit of the bearer quota, a single logical frame is split into multiple physical batches, and the execution results of each physical batch are uniformly bound to the same shared fence object. The hardware completion state corresponding to the last physical batch is used as the final state signal of the single logical frame.

[0034] Optionally, a dynamic quota adjustment step may also be included:

[0035] Monitor the frequency of timeouts when producing fence objects perform operations with timeout wait times;

[0036] When the timeout frequency is detected to be increasing, the current command submission process is terminated, and the single submission quota is dynamically reduced according to a preset decreasing rule.

[0037] When a reduction in system load is detected, the single-submission quota is allowed to gradually increase.

[0038] According to a second aspect of the present invention, a GPU task distribution synchronization system is provided, comprising:

[0039] The user-mode driver module is used to receive rendering commands submitted by application threads and dynamically switch the delivery path according to the scale of the commands to be submitted. When the commands to be submitted are large-scale rendering commands, multiple rendering commands are encapsulated into at least one buffer object. A physical address list of at least one of the buffer objects is constructed in the kernel layer. The video memory physical addresses of each buffer object in the physical address list are written to the GPU command register in batches through a single system call to complete the batch delivery of rendering commands. The module also creates a corresponding output fence object for the current submission batch and submits the physical address list and the output fence object to the kernel layer. The output fence object has a scheduling ready state and a hardware completed state.

[0040] The kernel-mode scheduling module is used to write the physical address list into the GPU hardware execution queue and set the output fence object to the scheduling ready state; after the GPU hardware completes the rendering operation, the output fence object is transitioned from the scheduling ready state to the hardware completed state.

[0041] GPU hardware is used to read commands from each buffer object sequentially according to the physical address list and execute rendering operations.

[0042] The display control module is used to take the hardware completion state of the produced fence object as a prerequisite condition for the display module to perform page flipping operation. When the produced fence object is in the hardware completion state, the kernel layer automatically allows the display module to perform page flipping; otherwise, the page flipping operation of the display module is suspended until the produced fence object enters the hardware completion state.

[0043] This invention provides a GPU task dispatch synchronization method and system that reuses the existing BufferObject resource structure as a task aggregation carrier, packages discrete rendering commands into batch units, and replaces the traditional "submit-wait" round-trip interaction by combining single batch submission with asynchronous status marking of Fence objects. This fundamentally decouples the command dispatch and completion notification paths, thereby significantly reducing CPU overhead and eliminating pipeline interruption bottlenecks. Attached Figure Description

[0044] Figure 1 A flowchart of a GPU task distribution synchronization method provided in one embodiment of the present invention;

[0045] Figure 2 This is an overall flowchart of a GPU task distribution and synchronization method provided in one embodiment of the present invention;

[0046] Figure 3 For rendering and displaying implicit synchronization timing diagrams;

[0047] Figure 4 A flowchart illustrating the GPU hardware and software synchronization interaction process;

[0048] Figure 5 Flowchart for reusing inter-frame fence objects;

[0049] Figure 6 This is a structural block diagram of a GPU task distribution synchronization system provided in one embodiment of the present invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined with each other to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0051] This invention proposes a GPU task dispatch synchronization method, based on the Linux DRM synchronization mechanism and an end-to-end non-blocking rendering scheduling framework using batch aggregation of buffer objects. It aims to systematically address core pain points in the graphics stack, such as frequent CPU-GPU interactions, high synchronization overhead, and weak fault tolerance. The system establishes an overall design roadmap of "hierarchical instruction transmission, implicit state-driven operation, inter-frame link reuse, and hierarchical fault recovery": The hierarchical instruction transmission mechanism enables dynamic switching between batch memory dispatch and direct memory write modes on the command submission path; the batch memory address dispatch mechanism alleviates CPU-GPU bandwidth pressure; the inter-frame state transition through the synchronization mechanism enables automatic cross-module transmission of rendering completion signals; and the hierarchical fault recovery mechanism constructs a highly reliable driver-level fault-tolerant system.

[0052] Figure 1 A flowchart of a GPU task distribution synchronization method according to an embodiment of the present invention is shown. The method includes the following steps:

[0053] Step 1: The user-mode driver receives rendering commands submitted by the application thread and dynamically switches the distribution path according to the scale of the commands to be submitted. When the commands to be submitted are large-scale rendering commands, multiple rendering commands are encapsulated into at least one buffer object.

[0054] Understandably, existing rendering synchronization architectures typically employ interrupt-driven completion notification mechanisms. The application layer or driver actively waits for hardware completion signals from preceding rendering tasks at critical synchronization points (such as frame boundaries, resource contention points, or memory readback points). Only after confirming the completion of these signals can the construction and submission of subsequent command batches proceed. This creates a logically serialized synchronization constraint of "submit—wait—submit again." In high-load, multi-batch scenarios, this constraint causes the CPU to frequently enter a blocked state, consuming computing power in interrupt responses and thread context switching. Furthermore, it can easily lead to pipeline interruptions in the GPU command loop due to untimely instruction supply.

[0055] Based on this, the existing Buffer Object resource structure is reused as the task aggregation carrier, and discrete rendering commands are packaged into batch units. The traditional "submit-wait" round-trip interaction is replaced by a single batch submission combined with the asynchronous status flag of the produced fence object. This fundamentally decouples the command issuance and completion notification path, thereby significantly reducing CPU overhead and eliminating pipeline interruption bottlenecks.

[0056] See also Figure 2 In the specific scheduling logic, the application-mode driver receives rendering commands submitted by application threads and dynamically switches the delivery path based on the size of the commands to be submitted, in order to achieve an optimal balance between throughput and response latency. The user-mode driver has a built-in dynamic threshold N (default value is 4), and uses this as the basis for classifying and processing the tasks to be submitted: For large-scale rendering commands (the number of commands to be submitted is greater than the dynamic threshold N), the system switches to memory batch mode, encapsulates the commands to be submitted into buffer objects and forms a queue, and submits the buffer objects to the kernel, only writing the physical starting address of the entire batch of buffer objects in memory to the GPU command register, completing the batch delivery of rendering commands; the GPU hardware directly addresses and reads the batch commands in memory through the command stream parser, compressing multiple data transfers into a single address transfer, fundamentally avoiding cache coherence overhead and memory wall bottlenecks. For small-scale control instructions such as shader compilation (the number of commands to be submitted is less than or equal to the dynamic threshold N), the system adopts memory write-through mode, writing the instructions one by one to the 32 / 64-bit GPU command register through synchronous blocking interaction, in order to ensure the responsiveness of the control plane. During the rendering command submission process, the user-mode driver releases the application thread immediately after submitting the rendering command by calling the glFlush function, and the application thread does not block while waiting for the GPU to complete.

[0057] like Figure 2As shown, the command issuance process of this invention dynamically switches paths based on the relationship between the number of commands to be submitted in a single frame and the threshold N, ensuring that the system operates in the optimal transmission mode under different load scenarios. Specifically, the user-space application layer initiates a rendering request, and the user-space driver packages the rendering request to construct a command stream. When the number of commands in the command stream > N, it is a large-scale rendering command. Multiple rendering commands are copied to a video memory buffer object, and a batch of buffer objects are submitted to the kernel layer. The kernel layer writes the starting physical address of a batch of buffer objects into the GPU command register. When the number of commands in the command stream is ≤ N, the commands are directly written to memory, and each command is submitted to the kernel layer. The kernel driver parses the command stream and writes each command into the GPU command register. Subsequently, after the GPU receives the commands, it executes the rendering operation.

[0058] Step 2: The user-mode driver creates a corresponding output barrier object for the current submission batch and submits at least one buffer object and the output barrier object to the kernel layer. The output barrier object has a scheduling ready state and a hardware complete state.

[0059] Understandably, for the submission of the current batch of tasks by an application thread, the user-space driver creates a corresponding output fence object for the current batch, and then submits the encapsulated buffer object and the output fence object together to the kernel layer. The output fence object is implemented based on the Linux kernel's `dma_fence` synchronization primitive or DRM synchronization object. The output fence object has two states: scheduled ready and hardware complete. The scheduled ready state marks that the task has entered the GPU hardware execution queue, and the hardware complete state marks that the GPU has completed rendering and written the rendering data to disk. The output fence object defines the task's residency boundary in the software queue and the hardware execution cycle through the scheduled ready and hardware complete states, and provides a unique hardware complete timestamp for the display module.

[0060] Step 3: Construct a physical address list of at least one of the buffer objects in the kernel layer, write the physical address list into the GPU hardware execution queue, and set the produced fence object to the scheduling ready state.

[0061] Understandably, the kernel layer receives buffer objects and output fence objects sent by the user-mode driver, which are lists of physical addresses for at least one buffer object. The list of physical addresses stores the physical memory address of each buffer object.

[0062] The kernel layer pushes the list of physical addresses to the GPU hardware execution queue, and at the same time sets the output fence object of the batch of rendering tasks to the scheduling ready state, indicating that it is ready.

[0063] Step 4: The GPU hardware reads the commands in each buffer object sequentially according to the physical address list and executes the rendering operation. After completion, the kernel layer transitions the produced fence object from the scheduling ready state to the hardware completed state.

[0064] The GPU hardware reads rendering commands from the buffer objects based on the physical memory addresses of each buffer object in the physical address list, executes the rendering operation, and updates the status of the output fence object of the current batch task to the hardware complete state, indicating that the GPU hardware rendering is complete.

[0065] Based on the dual-mode delivery mechanism in step 1 above, this invention further embeds the kernel dma_fence mechanism deeply into the OpenGL|ES / EGL frame loop, constructing a fully parallel non-blocking pipeline for application processing, GPU rendering, and display output. The system introduces a dependency fence interception mechanism for rendering tasks; the output fence object of the current frame is the preceding dependency fence object for the next frame's rendering batch. After the current frame rendering is submitted, the user-space driver exports the output fence object identifying the hardware completion state of the current frame as an anonymous file descriptor. This anonymous file descriptor only carries status signals and does not involve copying video memory data. A new preceding dependency fence object is created for the next frame's rendering batch. The hardware completion state of the current frame is injected into the preceding dependency fence object of the next frame through the anonymous file descriptor, so that the next frame's rendering batch implicitly binds the hardware completion state of the current frame as a preceding waiting condition when it is submitted.

[0066] If a batch of tasks carries unmet preconditions, the scheduler suspends the task by registering a `dma_fence_cb` callback function. When the output fence object corresponding to the precondition task is triggered to the completion state, the kernel layer automatically calls the callback function to wake up the task to be executed and re-add it to the GPU hardware execution queue. This asynchronous callback replaces CPU polling, effectively resolving resource contention in batch concurrency scenarios. Simultaneously, defining a two-level output state of scheduling readiness and hardware completion for the output fence object precisely defines the task's residency boundary in the software queue and the hardware execution cycle, providing the display module with a unique hardware completion timestamp.

[0067] Based on this, the user-space driver releases the application thread immediately after glFlush commits the rendering. After the GPU rendering is completed, the kernel layer automatically triggers the output fence object associated with the rendering task and sets it to the hardware completion state.

[0068] Step 5: Use the hardware completion state of the produced fence object as a prerequisite for the display module to perform the page flipping operation. When the produced fence object is in the hardware completion state, the kernel layer automatically allows the display module to perform the page flipping operation; otherwise, the page flipping operation of the display module is suspended until the produced fence object enters the hardware completion state.

[0069] Understandably, after the GPU hardware completes rendering, the kernel layer automatically triggers the transition of the output fence object for that batch of tasks from the scheduling-ready state to the hardware-complete state, and traverses the callback chain attached to the output fence object to execute the wake-up function to wake up the next batch of rendering tasks. When the display module initiates the kernel mode setting atomic operation, the kernel layer automatically waits for the signal that the output fence object has been triggered to the hardware-complete state before performing the page flipping operation.

[0070] When the display module initiates a KMS (Kernel Mode Set) atomic operation, the kernel layer automatically waits for the hardware completion signal before performing a page flip. See [link to relevant documentation]. Figure 3 This is a timing diagram of the entire rendering process, in which a non-blocking pipeline with fully parallel application processing, GPU rendering, and display output is built in the T0 to T4 interval.

[0071] like Figure 3 The illustrated timing architecture confirms the parallel gains brought by the aforementioned barrier interception mechanism. The application thread completes its rendering task submission at time T0 and returns immediately without blocking or waiting. The GPU exclusively utilizes hardware resources to execute the rendering task during the T1-T3 interval, forming a significant parallel working window with the application thread. The existence of this window is the core advantage of this invention compared to traditional interrupt-based synchronization, signifying that the synchronization responsibility has been completely transferred from CPU-active polling to implicit kernel-based state machine transitions. Table 1 details the key nodes in the above timing process and their corresponding system states.

[0072] Table 1 Key nodes in the time sequence and their corresponding system states

[0073] T0 The application calls glDrawArrays / glFlush to submit rendering commands, carrying the handle of the Fence object as (the generated Fence). Application thread (user mode) T1 The GPU receives the command stream and begins asynchronously executing the rendering pipeline (vertex shading -> rasterization -> fragment shading). GPU rendering pipeline (hardware) T2 The application thread returns immediately after glFlush, without blocking or waiting, and continues to execute the data preparation (vertex / texture / matrix calculation) for the next frame. Application thread (user mode) T3 Once GPU rendering is complete, the kernel automatically signals the hardware to complete the fence, implicitly passing the produced fence as a dependency fence for the display module via the DRM Fence object. GPU rendering pipeline -> Display module (kernel mode) T4 When the display module receives the dependent fence signal, it executes a Flip / Page Flip to switch the display buffer and completes the display output. Display module (kernel mode)

[0074] The implementation of the above-mentioned timing architecture relies on fine-grained underlying state-driven logic, combined with Figure 4The entire driver logic is explained below. During the rendering task submission phase, the user-space driver associates a production fence object with each batch of rendering commands and initializes it to the scheduling-ready state. Then, a single IOCTL call submits the command buffer and fence handle to the kernel layer. Upon receiving the batch, the kernel scheduler pushes the command buffer to the GPU hardware execution queue. At this point, the production fence object enters the scheduling state, allowing the application thread to return immediately without blocking and continue building subsequent logic. During the GPU execution phase, after the hardware completes rendering, it updates the completion flag in the kernel-pre-allocated shared memory page through a write operation and triggers a hardware interrupt. The kernel interrupt service routine responds to this interrupt, transitioning the state of the corresponding production fence object from the scheduling-ready state to the hardware-completed state. It then traverses the dependent fence callback chain attached to this production fence object, executing wake-up functions one by one to drive the display module to perform page flipping operations. Through this process, the submission of rendering tasks, asynchronous GPU execution, state transitions, and display output triggering are all autonomously driven by the kernel based on the fence state machine, achieving full-link parallel execution of the application thread and the GPU rendering pipeline.

[0075] The aforementioned parallel execution logic within a single frame based on a fence state machine provides solid underlying support for the asynchronous processing of rendering tasks. However, in real-world applications, rendering behavior typically exists as a continuous sequence of frames. If each frame independently creates, destroys, and re-establishes dependencies, it not only introduces a large amount of redundant system call overhead but also leads to cross-frame state fragmentation, making it difficult to meet the stringent requirements for rendering continuity and memory security under high-load scenarios. Therefore, this invention, based on single-frame state-driven processing, further constructs a cross-frame synchronization link reuse mechanism to achieve seamless state transitions across multiple frame lifecycles.

[0076] In the cross-frame synchronous link multiplexing mechanism, after the current frame rendering is submitted, the user-mode driver converts the output fence object used to identify the hardware completion state into an anonymous file descriptor. This anonymous file descriptor only carries status signals and does not involve copying video memory data, thus achieving zero-copy transfer between user mode and kernel mode. Subsequently, the system creates a new pre-dependency fence object for the next frame and injects the hardware completion state of the previous frame into this new pre-dependency fence object through this anonymous file descriptor, making the rendering task of the next frame logically implicitly bound to the output fence signal of the previous frame. For example... Figure 5As shown, this process configures the completion signal of the fence object produced in the previous frame as a pre-waiting condition when the next frame rendering batch is submitted. This prevents the GPU hardware scheduler from issuing command batches for the next frame until the incomplete state of the previous frame is triggered. This cross-frame blocking mechanism based on the fence signal chain establishes a mandatory execution order constraint of "the next frame will not start until the previous frame is completed" at the hardware scheduling level. This avoids the system call overhead caused by rebuilding the synchronization object frame by frame and gives user-mode drivers the ability to track the GPU rendering progress non-blockingly without relying on CPU polling.

[0077] While the aforementioned inter-frame state transition mechanism can achieve efficient reuse of synchronization links under ideal operating conditions, in actual engineering deployments, the system inevitably faces abnormal conditions such as instantaneous kernel memory exhaustion, GPU hardware suspension, and limited submission interfaces, which may lead to synchronization link breakage or state inheritance failure. Therefore, this invention further constructs a hierarchical anomaly recovery system on top of the reuse mechanism as a reliability guarantee for inter-frame synchronization links. This system takes the full lifecycle management of synchronization primitives as its core, covering multiple key stages such as resource allocation, hardware execution, state transfer, and batch submission. Through four-dimensional coordination of resource degradation switching, hierarchical hardware reset, fault link isolation, and dynamic traffic adjustment, it ensures that the synchronization state maintains internal consistency after recovery and automatically restores to the normal inter-frame synchronization object reuse process.

[0078] Specifically, to address the risk of instantaneous kernel memory exhaustion, the system employs a resource provisioning mechanism with adaptive backoff capabilities. The system implements a three-level exponential backoff retry process, retrying sequentially after delay windows of 100ms, 200ms, and 400ms to proactively avoid peak resource contention. When the retry strategy is exhausted and the regular synchronization object still cannot be instantiated, the system automatically switches to a hot standby channel: dynamically creating a production barrier based on the kernel synchronization primitive abstraction interface and encapsulating it as an independent file descriptor as a temporary synchronization handle injected into the rendering submission process. This design, without altering the upper-layer driver interface, dynamically downgrades the scheduling granularity from batch level to task level, fully preserving the GPU command submission path and completion notification functionality, achieving a smooth degradation of service capabilities.

[0079] To address the risk of GPU hardware suspension, the system employs a tiered reset hardware resilience recovery logic. The system abandons a global reset strategy, prioritizing a rendering engine-level local reset that only resets the graphics pipeline state machine and instruction pointers to intentionally preserve intermediate rendering results in video memory. Only when the local reset fails does the system trigger a full GPU hardware reset as a fallback strategy. After the reset process completes, the system explicitly unregisters callback functions attached to the suspension fence object to eliminate dangling references in the kernel callback chain, ensuring the consistency of the scheduler state.

[0080] Building upon this foundation, to prevent the propagation of abnormal states across frames, the system employs a state decoupling mechanism for fault domain isolation. Each rendering context is defined as an independent fault isolation domain, with completion signals transmitted between different fault isolation domains solely through read-only file descriptors. When a hardware unresponsive event occurs in a single fault isolation domain, the system iterates through and cleans up any incomplete produced fence objects within that domain, injects an error status code to forcibly trigger the signal state of the produced fence object, and explicitly unregisters callback functions attached to the produced fence object to eliminate dangling references. Subsequently, a rendering engine-level local reset is prioritized to preserve intermediate data in video memory. In other words, if a cross-frame state export or import operation fails, the system immediately instantiates a completely new fence object that is entirely decoupled from the historical frame state and forcibly severs the implicit dependency chain between the current frame and the previous frame, strictly limiting the impact of the fault to the lifecycle of the current single frame.

[0081] Furthermore, to overcome the physical limitations of the kernel's single IOCTL carrying quota, the system designed a logical frame slicing mechanism based on shared synchronization primitives. The system detects the kernel's carrying limit in real time and automatically splits a single logical frame into multiple physical batches when the amount of data to be submitted exceeds the limit. At the same time, the execution results of each physical batch are uniformly bound to the same shared synchronization handle, and the hardware completion signal of the last batch is used as the final state signal of the logical frame, thereby maintaining the atomicity of the logical frame under hardware constraints.

[0082] To further enhance system stability, a dynamic quota adjustment mechanism based on negative feedback is introduced. The system monitors the frequency of synchronous primitive executions with timeout wait operations as a system load feedback signal. When an increase in the timeout frequency is detected, the system immediately suspends the current submission process and dynamically reduces the single-submission quota according to a preset decreasing rule. Conversely, when the system load decreases, the quota is allowed to gradually increase. Through the synergy of this load-reverse adjustment control logic and the immediate suspension strategy, the system achieves an adaptive balance between single-batch processing granularity and system responsiveness.

[0083] See Figure 6 This illustration shows a GPU task distribution synchronization system provided in an embodiment of the present invention, the system comprising:

[0084] User-mode driver module 601 is used to receive rendering commands submitted by application threads, dynamically switch the distribution path according to the scale of the commands to be submitted, wherein when the commands to be submitted are large-scale rendering commands, multiple rendering commands are encapsulated into at least one buffer object; and a corresponding output fence object is created for the current submission batch, and at least one of the buffer objects and the output fence object are submitted to the kernel layer, wherein the output fence object has a scheduling ready state and a hardware complete state;

[0085] The kernel-mode scheduling module 602 is used to construct a physical address list of at least one of the buffer objects at the kernel layer, write the physical address list into the GPU hardware execution queue, and set the produced fence object to the scheduling ready state.

[0086] GPU hardware 603 is used to read commands from each buffer object sequentially according to the physical address list and execute rendering operations. After completion, the kernel layer transitions the produced fence object from the scheduling ready state to the hardware completed state.

[0087] The display control module 604 is used to take the hardware completion state of the produced fence object as a prerequisite condition for the display module to perform page flipping operation in the synchronous process from rendering to display. When the produced fence object is in the hardware completion state, the page flipping is performed; otherwise, the page flipping operation is suspended until the produced fence object enters the hardware completion state.

[0088] It is understood that the GPU task distribution synchronization system provided by the present invention corresponds to the GPU task distribution synchronization method provided in the foregoing embodiments. The relevant technical features of the GPU task distribution synchronization system can be referred to the relevant technical features of the GPU task distribution synchronization method, and will not be repeated here.

[0089] This invention provides a GPU task delivery synchronization method and system. Through a hierarchical instruction transmission mechanism, it dynamically switches between batch memory delivery and direct register write paths based on instruction size, overcoming the bandwidth limitations of data transmission between the CPU and GPU. Based on a state machine transition design using Fence objects, the synchronization responsibility is transferred from CPU-driven polling to implicit kernel driving, achieving deep parallelism between application processing logic, GPU rendering pipeline, and display output module. Through a zero-copy migration mechanism for cross-frame synchronization states, using file descriptors to pass hardware completion states between frames, a strong hardware-level order constraint is established: "If the previous frame is not completed, the next frame will not begin," effectively avoiding state fragmentation and memory race conditions. Furthermore, a hierarchical anomaly recovery system encompassing resource degradation switching, hierarchical hardware reset, fault link isolation, and dynamic traffic adjustment is adopted, endowing the system with fault recovery capabilities under abnormal operating conditions. This invention is applicable to graphics rendering subsystems on mobile, embedded, and desktop devices, particularly meeting the rendering needs of high-resolution, high-refresh-rate scenarios, providing a technical implementation approach for high-performance graphics computing environments with low CPU usage, low rendering latency, and high latency determinism.

[0090] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0091] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied 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.

[0092] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (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 computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0093] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular 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.

[0094] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable 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.

[0095] Although preferred embodiments of the 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 both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0096] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A GPU task distribution synchronization method, characterized in that, include: The user-mode driver receives rendering commands submitted by the application thread and dynamically switches the distribution path according to the scale of the commands to be submitted. When the commands to be submitted are large-scale rendering commands, multiple rendering commands are encapsulated into at least one buffer object. The user-mode driver creates a corresponding output barrier object for the current submission batch and submits at least one buffer object and the output barrier object to the kernel layer. The output barrier object has a scheduling ready state and a hardware complete state. Construct a physical address list of at least one of the buffer objects at the kernel layer, write the physical address list into the GPU hardware execution queue, and set the produced fence object to the scheduling ready state. The GPU hardware reads the commands in each buffer object sequentially according to the physical address list and executes the rendering operation. After completion, the kernel layer transitions the produced fence object from the scheduling ready state to the hardware completed state. The hardware completion state of the produced fence object is used as a prerequisite for the display module to perform page flipping operation. When the produced fence object is in the hardware completion state, the kernel layer automatically allows the display module to perform page flipping; otherwise, the page flipping operation of the display module is suspended until the produced fence object enters the hardware completion state.

2. The method according to claim 1, characterized in that, The method of dynamically switching the distribution path based on the size of the commands to be submitted also includes: A dynamic threshold N is built into the user-space driver, where N is a positive integer; If the number of commands to be submitted is greater than the dynamic threshold N, then the commands to be submitted are large-scale rendering commands. If the number of commands to be submitted is less than or equal to the dynamic threshold N, and the commands to be submitted are small-scale control instructions, the command register direct write mode is adopted to write the control instructions into the GPU command register one by one to ensure the response latency of the control plane.

3. The method according to claim 1, characterized in that, The output fence object is implemented based on the Linux kernel's dma_fence synchronization primitive or DRM synchronization object. The scheduling ready state is used to mark that the task has entered the GPU hardware execution queue, and the hardware complete state is used to mark that the GPU has completed rendering and written the rendering data to disk. The output fence object defines the task's residence boundary and hardware execution cycle in the software queue through the scheduling ready state and the hardware complete state, and provides a unique hardware complete timestamp for the display module.

4. The method according to claim 1, characterized in that, During the submission of rendering commands, the user-mode driver immediately releases the application thread after submitting the rendering command by calling the glFlush function, and the application thread does not block while waiting for the GPU to complete.

5. The method according to claim 1, characterized in that, It also includes the cross-frame synchronization link multiplexing step: After the current frame rendering is submitted, the user-mode driver exports the output fence object that identifies the hardware completion state of the current frame as an anonymous file descriptor. The anonymous file descriptor only carries status signals and does not involve copying video memory data. A new pre-dependency fence object is created for the next frame rendering batch. The hardware completion state of the current frame is injected into the pre-dependency fence object of the next frame through the anonymous file descriptor, so that the hardware completion state of the current frame is implicitly bound as a pre-wait condition when the next frame rendering batch is submitted.

6. The method according to claim 5, characterized in that, It also includes the asynchronous wake-up step of the preceding dependent fence object: When a task to be submitted carries an unmet prerequisite dependency barrier object, the kernel scheduler registers a callback function on the output barrier object associated with the prerequisite dependency barrier object and suspends the task to be submitted. When the output fence object is triggered to the completed state, the kernel layer automatically executes the callback function to wake up the task to be submitted.

7. The method according to claim 1, characterized in that, Using the hardware completion state of the generated fence object as a prerequisite for the display module to perform page flipping operations includes: After the GPU hardware completes rendering, the kernel layer automatically triggers the output fence object to transition from the scheduling ready state to the hardware completed state, and traverses the callback chain attached to the output fence object to execute the wake-up function. When the display module initiates an atomic operation to set kernel mode, the kernel layer automatically waits for the signal that the produced fence object has been triggered to the hardware completion state before performing a page flip operation.

8. The method according to claim 1, characterized in that, It also includes multi-rendering context fault isolation steps: Each rendering context is defined as an independent fault isolation domain, and completion signals are passed between different fault isolation domains only through read-only file descriptors; When a hardware unresponsive event occurs in a single fault isolation domain, the system iterates through and cleans up any unfinished produced fence objects within that domain, injects an error status code to force the signal state of the produced fence object, and explicitly unregisters the callback functions attached to the produced fence object to eliminate dangling references. Subsequently, a rendering engine-level local reset is performed first to preserve intermediate data in video memory.

9. The method according to claim 1, characterized in that, It also includes the adaptive logical frame slicing step: Real-time detection of the upper limit of the capacity of a single system call at the kernel level; When the number of commands to be submitted exceeds the upper limit of the bearer quota, a single logical frame is split into multiple physical batches, and the execution results of each physical batch are uniformly bound to the same shared fence object. The hardware completion state corresponding to the last physical batch is used as the final state signal of the single logical frame.

10. The method according to claim 1, characterized in that, It also includes a dynamic quota adjustment step: Monitor the frequency of timeouts when producing fence objects perform operations with timeout wait times; When the timeout frequency is detected to be increasing, the current command submission process is terminated, and the single submission quota is dynamically reduced according to a preset decreasing rule. When a reduction in system load is detected, the single-submission quota is allowed to gradually increase.

Images