Task processing method, device and system, electronic equipment and storage medium

Abstract

The invention provides a task processing method, device and system, electronic equipment and a storage medium, and relates to the technical field of graphic task processing.The task processing method comprises the steps that a resource copying command and a graphic processing command in a main thread command stream are recognized; the resource copy command is allocated to the special processing thread to be executed, the graphic processing command in the command stream is allocated to a graphic processing thread to be executed, and the special processing thread is a created thread independent of the main thread and the graphic processing thread; and determining the parallel execution condition of the special processing thread and the graphic processing thread according to the dependency relationship between the resource copy command and the graphic processing command. According to the method, the load balance between the CPU and the GPU can be realized, the main thread (CPU) and the special processing thread (CPU) for executing the resource copy command can be parallel, the CPU thread and the GPU thread which have no dependency relationship are parallel, and the delay of task execution is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of task processing, and in particular to a task processing method, device, system, electronic device and storage medium. BACKGROUND

[0002] In traditional graphics processing, an application program issues different types of commands, including drawing, dispatching, copying or clearing commands. However, for some resource copy commands, if they are given to a graphics processor for processing, not only the highly parallel processing advantage of the graphics processor cannot be fully utilized, but also the efficiency is low due to frequent scheduling of the graphics processor. In addition, the resource copy commands in the prior art are usually executed on the same central processing unit thread as the application program, resulting in serial execution of tasks and increasing the delay of submitting tasks to the graphics processor. SUMMARY

[0003] To overcome the problems in the related art, the present application provides a task processing method, device, system, electronic device and storage medium, which can not only achieve load balancing between a CPU and a GPU, but also enable a main thread (CPU) and a special processing thread (CPU) executing resource copy commands to be parallel, and enable CPU threads and GPU threads without a dependent relationship to be parallel, thereby reducing the latency of task execution.

[0004] According to a first aspect of an embodiment of the present application, a task processing method is provided, and the method comprises:

[0005] identifying resource copy commands and graphics processing commands in a main thread command stream;

[0006] allocating the resource copy commands to a special processing thread for execution and allocating graphics processing commands in the command stream to a graphics processing thread for execution, wherein the special processing thread is a thread created independently of the main thread and the graphics processing thread;

[0007] determining parallel execution of the special processing thread and the graphics processing thread according to a dependent relationship of the resource copy commands and the graphics processing commands.

[0008] In some example embodiments of the present application, based on the foregoing scheme, the method further comprises: the main thread command stream comprises other commands in addition to the resource copy commands and the graphics processing commands, and parallel execution of the main thread, the special processing thread and the graphics processing thread is determined according to a dependent relationship of the resource copy commands, the graphics processing commands and the other commands.

[0009] In some example embodiments of the present application, based on the foregoing scheme, the special processing thread runs on a central processing unit, and the graphics processing thread runs on a graphics processing unit.

[0010] In some example embodiments of the present application, based on the foregoing scheme, after identifying the resource copy commands and the graphics processing commands in the main thread command stream, the task processing method further comprises:

[0011] storing the resource copy commands and the graphics processing commands separately in different command buffers;

[0012] allocating the resource copy commands to the dedicated processing thread for execution and allocating the graphics processing commands to the graphics processing thread for execution comprises:

[0013] submitting the command buffer address corresponding to the resource copy commands to the dedicated processing thread and submitting the command buffer address corresponding to the graphics processing commands to the graphics processing thread.

[0014] In some example embodiments of the present application, based on the foregoing scheme, after storing the resource copy commands and the graphics processing commands separately in different command buffers, the task processing method further comprises:

[0015] in response to the requirements of the application program, recording the dependency relationship between the commands in different command buffers;

[0016] establishing execution timing logic across the command buffers according to the dependency relationship.

[0017] In some example embodiments of the present application, based on the foregoing scheme, establishing execution timing logic across the command buffers according to the dependency relationship comprises:

[0018] if there is a dependency relationship across the command buffers, serializing the commands in different command buffers using a semaphore mechanism.

[0019] In some example embodiments of the present application, based on the foregoing scheme, the semaphore mechanism comprises:

[0020] triggering a first semaphore after the dedicated processing thread completes the resource copy commands;

[0021] waiting for the first semaphore to be released before the graphics processing thread executes the graphics processing commands.

[0022] In some example embodiments of the present application, based on the foregoing scheme, establishing execution timing logic across the command buffers according to the dependency relationship comprises:

[0023] if there is no dependency relationship across the command buffers, performing the following operations in parallel:

[0024] executing the resource copy commands using the dedicated processing thread;

[0025] The graphics processing thread executes the graphics processing command.

[0026] In some example embodiments of the present application, based on the foregoing scheme, the resource copy command comprises any one or more of a data copy command, a resource clearing command and a resource updating command.

[0027] In some example embodiments of the present application, based on the foregoing scheme, the thread created independently of the main thread and the graphics processing thread comprises:

[0028] The thread resource is dynamically applied when the resource copy command is first detected;

[0029] The thread resource is released when there is no resource copy command to be executed.

[0030] According to a second aspect of an embodiment of the present application, a task processing apparatus is provided, comprising:

[0031] A command identification unit is configured to identify a resource copy command and a graphics processing command in a main thread command stream;

[0032] A command distribution unit is configured to distribute the resource copy command to a special processing thread for execution and distribute the graphics processing command in the command stream to a graphics processing thread for execution, wherein the special processing thread is a thread created independently of the main thread and the graphics processing thread;

[0033] A command execution determination unit is configured to determine parallel execution of the special processing thread and the graphics processing thread according to a dependency relationship of the resource copy command and the graphics processing command.

[0034] According to a third aspect of an embodiment of the present application, a task processing system is provided, comprising the task processing apparatus described above, and further comprising:

[0035] A graphics application program is configured to issue a command stream to the task processing apparatus;

[0036] A central processing unit is configured to run the main thread and the special processing thread scheduled by the task processing apparatus.

[0037] A graphics processing unit is configured to run the graphics processing thread scheduled by the task processing apparatus.

[0038] According to a fourth aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory having computer readable instructions stored thereon, the computer readable instructions being executed by the processor to implement the method of the first aspect.

[0039] According to a fifth aspect of the embodiments of the present application, a computer readable storage medium is provided, which stores a computer program. The computer program, when executed by a processor, implements the method in the first aspect.

[0040] The technical solutions provided by the embodiments of the present application can have the following beneficial effects:

[0041] The technical design of distributing the resource copy command to the independent special processing thread and distributing the graphics processing command to the graphics processing thread to be executed respectively can break the limitation that the commands must be executed in series in the traditional single thread processing mode, and the main thread operation, the resource copy operation and the graphics processing operation can be performed simultaneously, instead of waiting for each other, so that the processing period of the whole graphics task is shortened, and the overall processing efficiency of the command stream is improved. On the other hand, the special processing thread focuses on processing the resource copy task, and the graphics processing thread focuses on processing the calculation task, so that the overall load of the system is reasonably distributed among different threads, and the situation that a single thread is overloaded while other resources are idle is avoided, so that the system load is balanced, and the stable operation ability of the system under high load is improved. In addition, since the special processing thread is specially used for processing the resource copy command, the mutual blocking of the resource copy operation and other tasks when they are executed in series in the same thread can be avoided. The task submitted by the application program can be advanced without waiting for the resource copy to be completed, the residence time of the task in the central processing unit is reduced, and thus the delay of the graphics processing unit can be reduced.

[0042] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF DRAWINGS

[0043] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate one embodiment consistent with the present application and, together with the description, serve to explain the principles of the application.

[0044] Figure 1 A flowchart schematically showing a task processing method according to some embodiments of the present application is shown;

[0045] Figure 2 A flowchart schematically showing a task processing method according to some embodiments of the present application is shown;

[0046] Figure 3 A flowchart schematically showing a task processing method according to some embodiments of the present application is shown;

[0047] Figure 4 A flowchart schematically showing a task processing method according to some embodiments of the present application is shown;

[0048] Figure 5A schematic diagram of a task processing device according to yet some embodiments of the present application is shown schematically;

[0049] Figure 6 A schematic diagram of a task processing system according to yet some embodiments of the present application is shown schematically;

[0050] Figure 7 A schematic diagram of a computer system of an electronic device according to some embodiments of the present application is shown schematically;

[0051] Figure 8 A schematic diagram of a computer readable storage medium according to some embodiments of the present application is shown schematically. DETAILED DESCRIPTION

[0052] The example embodiments will be described in detail herein with reference to the attached drawings. The description of the example embodiments is only to illustrate and not to limit the present application. The following description of the example embodiments is not meant to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the appended claims.

[0053] The terms used in the present application are merely for the purpose of describing particular embodiments and are not intended to limit the present application. The singular forms "a," "an," and "the" used in the present application and its claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0054] Furthermore, the accompanying drawings are only schematic and are not necessarily drawn to scale. The block diagrams in the drawings show only the functionality of the embodiments and not the specific ones if any. The functional blocks can be implemented in software or hardware or a combination thereof. The drawings are intended to be merely illustrative and not limiting.

[0055] In the present example embodiments, a task processing method is first provided, which can be applied to a terminal device. The terminal device can be various electronic devices having an image processing unit and a display unit, including but not limited to a desktop computer, a laptop computer, a smartphone, a tablet computer, a VR / AR head-mounted device, a projector, and the like. Figure 1 A flowchart of a task processing method according to some embodiments of the present application is shown schematically. Referring to Figure 1 As shown, the task processing method comprises the following steps:

[0056] In step S110, a resource copy command and a graphics processing command in a main thread command stream are identified.

[0057] In step S120, the resource copy command is assigned to the special processing thread for execution, and the graphic processing command in the command stream is assigned to the graphic processing thread for execution, wherein the special processing thread is a thread created independently of the main thread and the graphic processing thread.

[0058] In step S130, parallel execution of the special processing thread and the graphic processing thread is determined according to the dependency relationship between the resource copy command and the graphic processing command.

[0059] The technical design of the present application assigns the resource copy command to the independent special processing thread and the graphic processing command to the graphic processing thread for separate execution. On the one hand, the design breaks the limitation that the commands must be executed in series in the traditional single-thread processing mode, and the graphic processing operation, the resource copy operation and the graphic processing operation of the main thread itself can be performed simultaneously when there is no dependency relationship between the resource copy command and the graphic processing command, instead of waiting for each other, thereby shortening the processing period of the entire task and improving the overall processing efficiency of the command stream. On the other hand, the special processing thread focuses on processing the resource copy task, and the graphic processing thread focuses on processing the graphic processing command, so that the overall load of the system is reasonably distributed among different threads, avoiding the situation that a single thread is overloaded while other resources are idle, thereby achieving the equalization of system load and improving the stable operation ability of the system. In addition, since the special processing thread is specifically used to process the resource copy command, the mutual blocking of the resource copy operation and other tasks in the same thread when executed in series can be avoided. The task submitted by the application program can be advanced without waiting for the resource copy to be completed, thereby reducing the residence time of the task in the central processing unit and reducing the latency of the graphic processing unit.

[0060] In some possible implementation manners of the present application, the resource copy command can be "copying data in the CPU memory to the GPU accessible video memory", and the graphic processing command can be "performing drawing, rendering and other operations based on the copied data". That is, the graphic processing command can be executed only after the completion of the resource copy command. At this time, the main thread identifies the resource copy command and assigns the resource copy command to the special processing thread for execution, and the main thread can continue to identify the next command stream, thereby realizing the parallel execution of the main thread and the special processing thread.

[0061] In some other embodiments, the main thread command stream can further include other commands in addition to the resource copy command and the graphic processing command, and the parallel execution of the main thread, the special processing thread and the graphic processing thread is determined according to the dependency relationship between the resource copy command, the graphic processing command and the other commands.

[0062] The other commands can be data preprocessing commands, post-processing commands, UI updating commands, etc. The resource copy command can be "copying data after data preprocessing to GPU accessible video memory", and the graphics processing command can be "performing drawing, rendering, etc. based on the copied data". That is, the resource copy command is executed after the execution of other commands, and the graphics processing command is executed after the completion of the resource copy command. At this time, the main thread identifies the resource copy command and assigns the resource copy command to the dedicated processing thread for execution, and the main thread can continue to preprocess the next command stream or post-process the data after the execution of the previous graphics processing command, etc., to realize the parallelism of the main thread, the dedicated processing thread and the graphics processing thread. For example, for some small and frequent resource copy commands, such as resource copy commands with a single data amount less than 256 KB and a trigger frequency exceeding a preset number (e.g., 30 times) within a very short time window (e.g., 10 ms), if the resource copy command is given to the graphics processor for processing, the execution time of such command is usually only microseconds, such as small size texture slice copy, local data migration of frame buffer, etc., but when triggered frequently (e.g., thousands of times per second), a series of fixed overheads (usually tens of microseconds) such as command buffer submission, hardware context switching, bus data handshake, etc. need to be experienced. This means that the scheduling cost of a single command far exceeds the actual processing cost, forming a resource mismatch of big horse pulling small cart.

[0063] More importantly, the high-frequency triggering of lightweight commands will continuously interrupt the main thread rendering pipeline of the GPU. For example, in 3D scene rendering, if hundreds of small texture copy operations are inserted every frame, the GPU's shader core will frequently switch between rendering calculation and data copy modes, causing the originally continuous parallel computing pipeline to be cut into fragmented short tasks, reducing cache hit rate, and thus increasing the fluctuation range of the overall rendering frame rate. At the same time, the synchronization signals generated by the high-frequency command interaction between the CPU and the GPU also occupy the Peripheral Component Interconnect Express (PCIe) bus bandwidth, indirectly affecting the transmission efficiency of large resources (such as scene models, high-resolution textures), forming a systematic performance bottleneck.

[0064] Therefore, in the embodiments of the present application, the resource copy commands meeting the small load and frequent characteristics can be screened out by presetting a byte number threshold, such as 512 KB or less, and combining a sliding time window, such as more than 50 times within 100 ms; secondly, the multiple small load copy commands meeting the conditions in the continuous time window are sorted according to the resource address continuity, such as different sub-area copying of the same texture object or data migration of the continuous memory block, and are combined into a single batch copy task; finally, a dynamic trigger condition is set, such as the cumulative command number reaching 20 or the waiting time being longer than 10 ms, and the single batch task is then distributed to a dedicated processing thread for execution, while the normal command stream conversion of the main thread and the graphics processing thread of the graphics application program is maintained.

[0065] In this way, on the one hand, the scheduling frequency of the dedicated processing thread and the context switching overhead are reduced through command merging, and the CPU occupancy rate in the small load and frequent copy scenario is effectively reduced; on the other hand, since the batch task is still executed in an independent thread, and the dependency relationship judgment logic of the merged command and the non-resource copy command remains unchanged, the original multi-thread parallel efficiency is not affected, and the thread scheduling jitter caused by high-frequency small commands is avoided, and the stability of the graphics rendering frame rate is improved.

[0066] In the following, the image brightness adjustment method in the present example embodiment will be further described.

[0067] In step S110, the resource copy commands and the graphics processing commands in the main thread command stream are identified. The "identification" command can be an intermediate module (such as a command parser of a graphics driver or a rendering framework) responsible for command stream processing, which has the ability to analyze the command stream structure and identify the command type. In the embodiments of the present application, the command stream receiving module and the command stream identification module can be the same structure, such as a driver program.

[0068] The command stream is a series of graphics task instruction sets sorted according to the execution logic, and in some embodiments, the command stream can include resource operation commands, such as resource copy commands (such as data transmission from the central processor memory to the graphics processor memory), resource creation commands (such as texture, buffer), graphics rendering commands (such as drawing triangles, setting shader parameters, etc.), computing commands, format conversion commands, and resource release commands. Generally, resource copy commands and graphics processing commands are to be sent to the GPU for execution. In the present application, a dedicated thread of the CPU is used to process the resource copy commands.

[0069] In some embodiments, the command stream can come from a graphics library, such as OpenGL, Vulkan, DirectX, or an engine module, such as Unity's Render Pipeline, which can convert and optimize the original instructions to generate a standardized command stream. In other embodiments, the command stream can come from user interaction input, such as when a 3D model is dragged by a mouse, continuously generating model pose update commands; or when a slider control is adjusted to change rendering parameters, generating shader uniform variable update commands. Or in other embodiments, the command stream comes from the application's own business code written by the developer, such as in a game engine, model matrix update commands triggered by character movement, viewport adjustment commands generated by camera switching; in image editing software, pixel drawing commands generated by user brush operations, texture processing commands generated by filter application.

[0070] The application program issues the command stream to the driver and creates a dedicated processing thread in the CPU through the main thread's creation command request, which is used to process resource copy commands;

[0071] The driver records the type of command issued by the application program and the dependency relationship between commands, and stores the recorded information in different buffers inside the driver. Different buffers store different types of commands. The driver identifies the resource copy commands in the command stream and submits the buffer address storing the resource copy commands to the dedicated processing thread running in the CPU, and submits the buffer address storing the graphics drawing commands and computing task commands to the graphics processing thread running in the GPU.

[0072] The other commands in the main thread command stream, excluding resource copy commands, graphics drawing commands, and computing task commands, are still executed in the main thread.

[0073] The application can ultimately achieve parallel execution of commands by the main thread, dedicated processing thread, and graphics processing thread, and the parallel execution of commands by the dedicated processing thread and graphics processing thread is the main parallel mode that can achieve better parallel effect.

[0074] That is, the main thread is mainly responsible for the generation of the command stream, the analysis of the dependency relationship and the task allocation, and does not directly participate in time-consuming data processing or rendering operations, the dedicated processing thread is mainly responsible for the copy processing of the resource copy command, and the graphics processing thread is mainly responsible for the drawing or rendering of the graphics data. In some embodiments, the command stream can include some graphics processing commands that do not need to be processed by the data drawing or rendering operation, at this time, the main thread can identify these commands, submit these commands to the graphics processing thread for execution, and submit the resource copy command to the dedicated processing thread for execution, which not only can realize the load balancing of CPU and GPU, but also can avoid the queuing blockage of different types of commands in a single thread, and greatly improve the command execution efficiency. For example, when the graphics processing thread focuses on the rendering core logic, the dedicated processing thread can complete the copy of the texture, buffer and other resources in parallel, without waiting for the rendering task to end before starting the copy operation, reducing the total time consumption of the overall task; at the same time, the main thread is only responsible for instruction scheduling and dependency management, without being involved in specific data processing, and can respond to new task requirements more quickly, generate subsequent command streams, and further optimize the real-time performance of the system.

[0075] The resource copy command can be a single type, such as only including a data copy command, only including a resource clearing command or only including a resource updating command; or a combination of multiple types, such as a command stream simultaneously including a data copy command and a resource updating command, or simultaneously including a data copy command and a resource clearing command, or simultaneously including a resource clearing command and a resource updating command, or simultaneously including a data copy command, a resource clearing command and a resource updating command.

[0076] In this way, it can be ensured that all operations involving resource data transfer, covering and modification can be included in the identification range, so as to be allocated to the dedicated thread for processing in the subsequent step, covering more actual scenarios (such as a graphics task with complete data uploading and partial data updating).

[0077] In some embodiments, the data copy command can include:

[0078] Data transmission between the central processing unit (CPU) memory and the graphics processing unit (GPU) memory (such as video random access memory (VRAM)), such as uploading texture data from the CPU to the GPU, or downloading the calculation result (such as the rendered image data) in the GPU memory to the CPU memory;

[0079] Copy between different resources within GPU, such as copying frame buffer data to a texture, copying buffer data to another buffer, copying pixel data from one texture to another, or copying color / depth attachment data from frame buffer to a texture or buffer.

[0080] Resource clear command is to overwrite the whole or part of a target resource with a preset fixed value (not the data of other resources), to reset the resource state (such as initialization, clear residual data), which is a special form of fixed source data conversion to target resource in resource copy command. In some embodiments, resource clear command can include:

[0081] Frame buffer clear command: overwrite the color attachment, depth attachment or stencil attachment of a frame buffer used in rendering process with a fixed value, to ensure no residual data before rendering a new frame. For example, clear color buffer with black (RGB(0,0,0)) or transparent color (RGBA(0,0,0,0)) to avoid residual image from previous frame; clear depth buffer with maximum depth value (such as 1.0) to reset depth test state; or clear stencil buffer with 0 value to reset the flag state of stencil test.

[0082] Buffer clear command: overwrite the whole or specified byte range of a buffer in GPU or CPU, such as vertex buffer, index buffer, temporary buffer for computation, with a fixed value, to initialize data or reset intermediate result. For example, fill the buffer storing vertex position with 0 to reset the initial position data of a model; clear the temporary buffer output by a computation shader program (with 0) to avoid confusion of results from multiple computations.

[0083] Texture clear command: overwrite the specified area (such as the whole texture, a mipmap level, a texture slice) of a texture resource (such as 2D texture, cube map) with a fixed color value, to initialize the texture or clear invalid area. For example, clear the unused area of a user interface texture with transparent color (RGBA(0,0,0,0)) to avoid color mixing during rendering; overwrite a level of a 3D texture with a solid color as default fill value.

[0084] Resource update command is to modify the partial data of a resource incrementally, not to overwrite or migrate completely, only to update the changed part of the resource, to reduce unnecessary data transmission overhead. In some embodiments, resource update command can include:

[0085] Partial data update of GPU buffer: that is, for GPU buffer storing vertex, index, calculation parameter and other data, only part of bytes or data blocks are updated, instead of retransmitting the entire buffer. For example, in 3D model animation, bone transformation only causes the position data of part of vertices to change, so only the coordinate data of the corresponding vertices in the vertex buffer is updated, instead of the entire vertex buffer.

[0086] Partial region update of texture resource: that is, for 2D texture, cube map and other texture resources, only part of pixels in the specified rectangular region or mipmap level is updated, instead of retransmitting the entire texture. For example, in game user interface, when the button switches from "normal state" to "click state", only the partial region of the button texture showing the state change, such as the edge highlight part, is updated.

[0087] Dynamic update of constant buffer / uniform buffer: for constant buffer or uniform buffer storing shader parameters, such as model matrix, lighting parameter, camera position, only the parameter values changed between frames are updated, instead of full retransmission. For example, in first-person perspective game, only the view matrix of the camera is updated every frame (changed due to player movement), while the lighting intensity and other unchanged parameters are not updated.

[0088] Partial data migration across memory regions: in resource transmission from CPU memory to GPU memory, only the partial data that has changed is transmitted, instead of the complete resource. For example, in 3D modeling software, after the user modifies a certain local face of the model, only the vertex data of the face is updated from the CPU memory to the vertex buffer of the GPU memory.

[0089] In addition, resource copy commands can be identified in one or a combination of the following ways:

[0090] Based on command identification: the commands defined by the Application Programming Interface (API) of the graphics application program all have unique operation codes, such as vkCmdCopyBuffer in Vulkan Application Programming Interface (Vulkan API) or CopyResource in DirectX 12 Application Programming Interface (DirectX 12 API), so the resource copy command can be directly identified by matching the operation code.

[0091] Based on command parameter features: although some commands are not directly marked as "copy", the parameters contain features such as source resource address, target resource address, copy length / region, such as resource handle, memory offset, which can be indirectly determined as resource copy commands through these features.

[0092] Excluding non-copy commands: By exclusion, distinguish, for example, identify that rendering commands (such as Draw), state setting commands (such as SetViewport), resource creation commands (such as CreateTexture) are all not involved in data transfer, and the remaining commands that meet the "data transfer" feature are resource copy commands.

[0093] In S120, the resource copy commands are assigned to the special processing thread execution, and the graphics processing commands in the command stream are assigned to the graphics processing thread execution, wherein the special processing thread is a thread created independently of the main thread and the graphics processing thread.

[0094] The core requirement of the resource copy command is efficient data transfer, which relies on the memory bus bandwidth of the CPU and the in-core computing resources (such as address calculation for processing local updates), and the special processing thread as an independent CPU thread can focus on using these resources and will not be disturbed by GPU-related operations.

[0095] In some embodiments, the resource copy command can include any one or more of a data copy command, a resource clearing command, and a resource update command.

[0096] Although the data copy command, the resource clearing command, and the resource update command have different operation methods, they all focus on the transfer, overwrite, or modification of resource data, which is different from rendering, shader calculation, and other commands that rely on GPU computing power, so they are classified as resource copy commands, providing clear standards for subsequent identification, assignment, and processing. Thus, it can avoid the narrow understanding of resource copy, such as considering it as only complete copying, ensuring that resource clearing, local updating, and other operations can also be included in the processing range of the special processing thread, preventing resource state errors caused by missing commands, such as unprocessed clearing commands causing screen residues.

[0097] Data copy (complete migration), resource clearing (initialization / reset), and resource update (incremental modification) are high-frequency operations in graphics processing. After being classified, they can be efficiently processed by a set of thread scheduling logic, reducing thread switching or functional redundancy caused by classification confusion, and improving the overall throughput of resource copy tasks.

[0098] A graphics processing command is an instruction that requires GPU rendering or calculation, such as setting rendering state, drawing triangles, executing compute shaders, etc. The core requirement of the graphics processing command is "parallel computing capability", which relies on the hardware of the GPU's shader core, texture unit, etc. The graphics processing thread as a bridge to interact with the GPU can efficiently translate these commands into GPU executable instructions and manage the GPU execution flow.

[0099] The special processing thread is independent of the main thread of the graphics application, that is, the special processing thread and the main thread of the graphics application are independent of each other in execution scheduling, context, and the like, which is embodied as follows:

[0100] Scheduling independence: The special processing thread can be allocated a CPU time slice independently, and its execution progress is independent of the main thread, for example, when the main thread is paused, the special processing thread can continue to process the copy command; when the special processing thread is paused, the main thread can continue to process the copy command.

[0101] Context independence: The special processing thread has its own stack space, program counter, and execution state, and does not need to share the execution context of the main thread, which can avoid interference from function calls, local variables, and the like of the main thread.

[0102] Shared but not dependent resources: As threads in the same application process, the special processing thread and the main thread share process-level resources, such as graphics resource data in memory, a command stream buffer, and the like, but this sharing is cooperative rather than dependent. That is, the special processing thread does not need to wait for the main thread to release resources before execution.

[0103] In the embodiments of the present application, the special processing thread is only responsible for executing the identified resource copy command, does not participate in user interaction processing, command stream generation of the main thread, and does not participate in rendering calculation of the graphics processing thread. Due to the existence of the special processing thread, an exclusive execution carrier can be provided for the resource copy command, which can be parallel with the main thread and the graphics processing thread, that is:

[0104] The main thread can continue to generate a new command stream without waiting for resource copy to complete;

[0105] The graphics processing thread can focus on executing rendering commands without being interrupted by memory operations for resource copy;

[0106] The special processing thread handles resource copy alone, uses the idle core of the CPU or the memory bandwidth, and avoids competing for resources with other tasks.

[0107] In S130, according to the dependency relationship between the resource copy command and the graphics processing command, the parallel execution of the special processing thread and the graphics processing thread is determined.

[0108] The parallel execution of the special processing thread and the graphics processing thread includes parallel processing of the special processing thread and the graphics processing thread, and sequential execution of the special processing thread and the graphics processing thread.

[0109] When the graphics processing command can be executed only after the resource copy command is executed, the special processing thread and the graphics processing thread are executed sequentially. Correspondingly, when the graphics processing command can be executed without waiting for the resource copy command to be executed, the special processing thread and the graphics processing thread can be executed simultaneously, that is, in parallel.

[0110] The following describes the details of steps S110 to S130.

[0111] In some embodiments, the special processing thread and the main thread can be designed to run on a central processing unit (CPU), and the graphics processing thread can be designed to run on a graphics processing unit (GPU).

[0112] On the one hand, the CPU is good at processing complex memory addressing and control logic: resource copying often involves data transmission across storage areas, such as CPU memory transmission to GPU video memory, memory mapping for different resources within the GPU, cache consistency (such as ensuring that data written by the CPU can be correctly read by the GPU), data block fragmentation, and other details. The memory management unit and cache controller of the CPU can efficiently coordinate these operations.

[0113] On the other hand, the CPU is suitable for serial control and breakpoint continuation: resource copying can need to handle exceptions such as insufficient memory, transmission interruption, or adjust the transmission order according to priority, such as transmitting small textures first to ensure fast rendering, and then transmitting large textures. The instruction set and interrupt mechanism of the CPU can flexibly handle these logics, while the GPU lacks complex control logic support.

[0114] In addition, the core task of the graphics processing thread is to execute graphics processing commands, such as rendering drawing, shader calculation, and rendering state setting. The essence of these tasks is large-scale parallel computing, and the number of stream processors of the GPU is usually tens of times that of the CPU core. Therefore, the hardware architecture has a large number of parallel computing cores and can simultaneously perform parallel processing on hundreds or thousands of vertices / pixels. Moreover, since the graphics processing command needs to directly operate resources (such as textures and frame buffers) in the GPU video memory, the memory controller of the GPU is closer to the computing core, and can read data at a speed much higher than that of the CPU accessing the GPU video memory, thereby reducing data transmission delay.

[0115] Further, the core task of the main thread is to handle user input, business logic (such as judgment of character movement in a game), command stream generation, and the like, which rely on the general computing ability of the CPU, complex logic scheduling, and interrupt response ability; the main thread and the special processing thread are in the CPU, and can efficiently communicate through shared memory (such as a command buffer, a resource handle), reducing the delay of cross-hardware interaction (such as not needing to pass command parameters through a bus). At the same time, the multi-core architecture of the CPU can allocate the two threads to different cores (such as the main thread in core 0 and the special processing thread in core 1), realizing parallelism of logic calculation and resource processing, avoiding excessive load on a single core, and improving the overall utilization of the CPU.

[0116] Therefore, running the graphics processing thread on the graphics processor and running the main thread and the special processing thread on the central processor essentially lets the most suitable hardware handle the most skilled task, not only can realize precise matching of tasks and hardware characteristics, significantly improve the single-task processing efficiency of resource copying and graphics calculation; but also can achieve parallel cooperation of the CPU and the GPU, and parallel cooperation of different threads in the CPU, eliminate hardware alternation idling and resource contention problems; at the same time, reduce the cross-hardware interaction delay, guarantee the continuity of command execution; enhance system stability and maintainability, realize task isolation and targeted debugging optimization.

[0117] In an optional implementation, after identifying the resource copying command in the command stream, the resource copying command and the graphics processing command can be stored separately in different command buffers; on this basis, in response to the submission command, the resource copying command is allocated to the special processing thread for execution, and the graphics processing command is allocated to the graphics processing thread for execution, including: in response to the submission command, the command buffer address corresponding to the resource copying command is submitted to the special processing thread, and the command buffer address corresponding to the graphics processing command is submitted to the graphics processing thread. Through the design of separate storage in different command buffers, the resource copying command and the graphics processing command are transformed from logical identification to physical isolation. That is, after identifying the two types of commands, they are no longer stored mixedly in the same buffer, but are stored in independent special buffers, such as a resource copying command buffer and a graphics processing command buffer. This physical isolation can avoid the analysis interference caused by mixed commands, provide a direct data source for subsequent targeted submission, and ensure the accuracy and efficiency of allocation and execution.

[0118] In this way, not only can the special processing thread and the graphics processing thread directly access the corresponding buffer without secondary screening from the mixed command stream, but also the command analysis overhead during thread execution is reduced, and the command extraction cost is reduced. In addition, during the waiting process of submitting the command, the two types of buffers can be pre-verified respectively (such as resource address legality check), and the execution efficiency after submission is improved. In addition, different buffers can be set with independent access permissions, such as allowing only CPU read and write for the copy command buffer, and allowing GPU access for the graphics processing command buffer, so as to avoid incorrect modification of the command.

[0119] In response to the submission command, the special processing thread receives the resource copy command buffer and directly executes the copy, clearing, updating and the like in sequence; the graphics processing thread receives the calculation command buffer and executes the GPU-related commands such as rendering drawing and shader calling. The essence of this mechanism is batch scheduling in units of buffer, which can reduce the communication times between threads and improve the overall execution throughput of the command stream compared with single command distribution.

[0120] Through physical isolation of the buffer, the special processing thread on the CPU and the graphics processing thread on the GPU can be more efficiently coordinated, that is, when the special thread processes the copy command, the graphics thread can read the calculation command buffer in parallel and prepare the GPU execution environment, and the two can realize parallel data without interference through independent buffers, thereby ultimately strengthening the core effect of reducing delay and balancing load.

[0121] After the separation of the command buffer, the resource copy command and the graphics processing command can be executed in parallel, but in actual scenarios, the two types of commands may have a dependency relationship, for example, the calculation command needs to wait for the resource copy to be completed before execution. If the dependency relationship is ignored and directly parallel, errors may occur, such as the rendering command using an uncompleted copied texture.

[0122] On this basis, after separating and storing the resource copy command and the graphics processing command in different command buffers, the dependency relationship between the commands in different command buffers can be recorded in response to the requirements of the application program; and according to the dependency relationship, the execution timing logic across the command buffers is established.

[0123] The dependency relationship includes resource dependency and execution order dependency. The resource dependency is that the resources (such as textures and buffers) required by the calculation command need to be generated or updated through the resource copy command first, for example, the calculation command of drawing a role depends on the copy command of uploading the role texture. The execution order dependency refers to that even without direct resource association, some commands also need to be executed in a fixed order, for example, the copy command of clearing the frame buffer needs to be executed before the calculation command of rendering a new frame, otherwise the new frame data will be covered.

[0124] The recording manner of the dependency relationship can be determined by responding to a display declaration of an application program or automatic analysis of the system. For example, the application program can actively mark the dependency through an API, such as calling SetDependency (compute command A, copy command B), to explicitly indicate that the compute command A needs to be executed after the copy command B. The system can also automatically analyze the parameters of the commands, such as whether the resource referenced by the compute command is created by a certain copy command, to infer an implicit dependency relationship and record the same.

[0125] Of course, not all commands have a dependency relationship. For commands that do not have a dependency relationship, the commands can be executed in parallel, and for commands that have a dependency relationship, the commands can be executed in series.

[0126] That is, the execution timing logic across the command buffers is to control the execution order of the commands in the two buffers through synchronization or execution scheduling rules. The execution scheduling rules can be implemented in one of the following manners:

[0127] Semaphore synchronization: A semaphore is set for a pair of dependent commands. For example, after a dedicated processing thread executes a copy command for uploading a texture, a semaphore is released. A graphics processing thread needs to wait for the semaphore before executing a compute command for rendering using the texture.

[0128] Fence marking: A fence marking dependency node is inserted in the command buffer. For example, a fence F1 is inserted at the completion of uploading a texture in the copy command buffer, and a rendering start in the compute command buffer is marked to wait for F1. The system ensures that the compute command is executed after F1 is triggered.

[0129] Priority dynamic adjustment: The execution priority of a corresponding thread is temporarily adjusted for a pair of dependent commands. For example, if a graphics processing command A depends on a copy command B, the priority of the dedicated processing thread can be temporarily increased to allow B to be quickly completed, and then the priority of the graphics processing thread is restored to execute A, thereby reducing the waiting time.

[0130] The resource copy command often involves the transmission of data between different storage areas (such as CPU memory and GPU memory), and the occupation of the data transmission channel is relatively concentrated. The graphics processing command depends more on the computing power of the computing unit. After separation, the two types of commands can avoid interfering with each other in the same buffer, and the execution block caused by resource contention can be reduced. At the same time, the cross-buffer execution timing logic established based on the dependency relationship can accurately plan the execution order of the commands, such as ensuring that the resource copy for the compute command is completed before starting, thereby avoiding invalid waiting and greatly improving the execution efficiency of the overall command flow.

[0131] After recording the dependency relationship, not only can the demand timing of different commands for hardware resources (such as bus bandwidth and computing core) be clearly mastered, so that resources can be more reasonably allocated in the time dimension, but also the application program can define the association between commands according to the business logic of the application program, thereby enhancing the control of the graphic task processing flow.

[0132] The establishment of the cross-buffer execution timing logic only controls the timing of the dependent commands, and the non-dependent commands can still be freely parallel. Not only can the efficiency loss caused by forced serialization to ensure safety be avoided, but also even if the commands are distributed in different buffers, they can still be strictly executed in order according to the dependency relationship, thereby avoiding problems such as graphic rendering errors and data inconsistency caused by chaotic command execution order, and improving the reliability of graphic task processing.

[0133] In addition, as the complexity of the graphic application increases, the number and type of commands will continue to increase. The separation of storage and dependency management mechanism can better adapt to the growth of the command scale. New types of commands can be allocated to appropriate buffers according to similar logic and quickly integrated into the execution process by defining the dependency relationship with the graphic processing command, without the need to make substantial adjustments to the overall architecture, thereby reducing the difficulty of system expansion.

[0134] In some embodiments, according to the dependency relationship, the establishment of the execution timing logic across the command buffers can include serializing the commands in different command buffers by using a semaphore mechanism if there is a dependency relationship across the command buffers.

[0135] The semaphore mechanism is used to control the sequence of task execution according to the semaphore (an integer, such as 0, 1, etc.). For example, when the main thread of the graphic application program identifies the resource copy command, the resource copy command is given a semaphore (for example, 0). After the dedicated processing thread completes the resource copy command, the main thread is given a new semaphore (for example, 1). At this time, the main thread issues a processing command to execute the graphic processing command when it receives the semaphore 1.

[0136] Through the wait-release mechanism of the semaphore, such as the release of the semaphore after the completion of the resource copy command, the computing command dependent thereon needs to wait for the semaphore before execution, thereby strictly ensuring the sequential execution of the dependent commands and avoiding resource access conflicts (such as the use of an incomplete copied texture by a rendering command) or data inconsistency (such as the overwriting of the original data by the calculation result) caused by parallel execution of dependent commands. The problem of graphic abnormalities (such as screen tearing and display disorder) caused by dependency errors is effectively solved.

[0137] The semaphore only enforces the serial execution of dependent commands, and does not affect the parallel execution of commands without dependencies, such as the resource copy command A and the rendering command B that does not depend on A, which can still be executed simultaneously. This on-demand serial mode avoids the inefficient design of enforcing the serial execution of all commands for security, and balances between correctness and parallel efficiency, maximizing the utilization of hardware resources brought by the separate storage of the command buffer.

[0138] As a lightweight synchronization primitive, the semaphore controls the dependencies between commands through hardware-level state flags, such as the built-in semaphore register of the GPU, without the need for coordination through the CPU, reducing the additional overhead of thread switching, context saving, and other overheads brought by traditional software synchronization (such as lock mechanism), and minimizing the delay of cross-buffer dependency processing.

[0139] In complex graphics scenarios with multiple command streams and multiple resource interactions, such as real-time rendering + background resource updating, the semaphore mechanism can flexibly build multi-dimensional dependency chains, such as multi-level dependencies A→B→C, support arbitrary complex cross-buffer command timing control, and can handle both simple parallel scenarios and high complexity dependencies, improving the generality and robustness of the solution.

[0140] In some example embodiments, the semaphore mechanism includes triggering a first semaphore after the dedicated processing thread completes the resource copy command; and waiting for the first semaphore to be released before the graphics processing thread executes the graphics processing command.

[0141] That is, the dedicated processing thread is responsible for executing the resource copy command, and when all the resource copy commands to be executed are completed, i.e., the target resource is in a ready state, the dedicated processing thread actively triggers the first semaphore, updates its state from unreleased to released, to mark the completion of the resource copy task.

[0142] The graphics processing thread checks the state of the first semaphore before executing the graphics processing command that depends on the copied resource. If the semaphore is not released, i.e., the resource copy is not completed, the graphics processing thread enters a waiting state and suspends the execution of the compute command; until the first semaphore is released, i.e., the resource copy is completed, and then the subsequent compute command is executed.

[0143] Through the mechanism of triggering the semaphore after the completion of the dedicated thread and waiting for the semaphore before the execution of the graphics thread, the order of executing the compute command after the completion of the resource copy is enforced, avoiding the premature execution of the graphics processing thread that accesses the unready resource, such as using the incomplete uploaded texture to cause rendering errors, or reading the unupdated buffer to cause parameter errors, and fundamentally eliminating the graphics abnormalities (such as screen flickering, data disorder) caused by dependency conflicts.

[0144] The first semaphore is only valid for dependent commands, and the dedicated processing thread and the graphics processing thread can still independently execute independent tasks before and after the semaphore trigger. For example, when the dedicated thread executes a copy, the graphics thread can process graphics processing commands that do not depend on the resource. This can avoid global serialization, while ensuring safety, maximizing the parallel execution space of the two threads, and reducing unnecessary waiting time.

[0145] No dependency can refer to two types of commands that are not associated in resource use (such as a calculation command that does not depend on a resource transmitted by a copy command) and execution order (such as not needing to wait for the other to complete before proceeding independently). For example, a resource copy command for a non-urgent texture loaded in the background after copying and a calculation command for rendering a UI element ready for the current frame.

[0146] The dedicated processing thread focuses on executing resource copy commands, and the graphics processing thread synchronously executes graphics processing commands. The two threads achieve parallel execution without interaction and interference through independent command buffers and hardware resources, without any synchronization waiting.

[0147] In the non-dependent scenario, on the one hand, the CPU (running the dedicated processing thread) and the GPU (running the graphics processing thread) can work at full capacity at the same time, avoiding the situation where one hardware is idle due to waiting for another hardware, thereby improving the overall resource utilization of the system. On the other hand, parallel execution changes the time consumption of resource copying and graphics calculation from "serial superposition" to "parallel overlap". For example, copying a texture takes 5ms, and rendering the current frame takes 8ms. The total time consumption of serial execution is 13ms, while the total time consumption of parallel execution can be only 8ms (taking the longer task time), directly reducing the overall processing delay and improving the response speed of graphics tasks. In addition, parallel execution of non-dependent commands does not require the intervention of a synchronization mechanism, avoiding the additional overhead of synchronization primitives such as semaphores, barriers, and the like (such as state checking and thread wake-up delay), while reducing the risk of exceptions caused by synchronization logic errors, allowing the system to remain stable in high-parallel scenarios.

[0148] This mechanism, together with serial processing in the dependent scenario, constitutes a complete scheduling strategy, that is, by dynamically judging the dependency relationship, the adaptive scheduling of "parallel execution for non-dependent scenarios and serial execution for dependent scenarios" is achieved, which guarantees the correctness of execution in complex scenarios and releases the maximum parallel potential in simple scenarios, ultimately achieving global optimization of efficiency and safety.

[0149] In some example embodiments, creating a dedicated processing thread independent of the main thread of the graphics application includes: dynamically applying thread resources when a resource copy command is first detected; and releasing the thread resources when there are no resource copy commands to be executed.

[0150] In this example, instead of creating a dedicated processing thread in advance at the start, a thread resource (including stack space, scheduling priority, etc.) is dynamically applied when a resource copy command is first detected, and the thread is initialized as a dedicated processing thread for executing subsequent resource copy commands.

[0151] When the dedicated processing thread completes all the resource copy commands to be executed and detects that no new resource copy command enters the queue, the thread resource is released, and the CPU scheduling right, memory stack, and other system resources occupied by the thread are recovered, so as to avoid the thread consuming resources in an idle state.

[0152] Since the dynamic management mechanism creates a thread only when there is a command and releases the thread when there is no command, on the one hand, the resource consumption of the thread in an idle state can be significantly reduced; on the other hand, the dynamic release of the thread can reduce the number of active threads, reduce the scheduling pressure of the CPU, concentrate more resources on the main thread or the graphic processing thread, avoid resource waste, and adapt to the dynamic changes of different load intensities.

[0153] The schematic diagram of the graphic task processing process of an embodiment of the task processing method of the application is shown in Figure 2 .

[0154] According to a second aspect of the embodiment of the application, a task processing device 300 is further provided, as shown in Figure 3 , which comprises a command identification unit 310, a command distribution unit 320, and a command execution determination unit 330.

[0155] The command identification unit 310 is configured to identify the resource copy command and the graphic processing command in the main thread command stream.

[0156] The command distribution unit 320 is configured to distribute the resource copy command to the dedicated processing thread for execution and distribute the graphic processing command in the command stream to the graphic processing thread for execution, wherein the dedicated processing thread is a thread created independently of the main thread and the graphic processing thread.

[0157] The command execution determination unit 330 is configured to determine the parallel execution of the dedicated processing thread and the graphic processing thread according to the dependency relationship of the resource copy command and the graphic processing command.

[0158] In an exemplary embodiment of the application, based on the foregoing scheme, as shown in Figure 4 , the graphic task processing device 300 can further comprise a separate storage unit 340 configured to separately store the resource copy command and the graphic processing command in different command buffers.

[0159] The data submitting unit 330 is further configured to submit the command buffer address corresponding to the resource copy command to the special processing thread and submit the command buffer address corresponding to the graphics processing command to the graphics processing thread.

[0160] In an exemplary embodiment of the present application, based on the foregoing scheme, referring to Figure 5 As shown in the figure, the graphics task processing apparatus 300 can further include a relationship recording unit 350 configured to record the dependency relationship between commands in different command buffers in response to the requirement of the application program.

[0161] A logic establishing unit 360 is configured to establish the execution timing logic across the command buffers according to the dependency relationship.

[0162] In an exemplary embodiment of the present application, based on the foregoing scheme, the logic establishing unit 360 is further configured to, if there is a dependency relationship across the command buffers, serially process the commands in different command buffers by using a semaphore mechanism.

[0163] In an exemplary embodiment of the present application, based on the foregoing scheme, the logic establishing unit 360 is further configured to, if there is no dependency relationship across the command buffers, perform the following operations in parallel:

[0164] execute the resource copy command by using the special processing thread;

[0165] execute the graphics processing command by using the graphics processing thread.

[0166] According to a third aspect of the embodiments of the present application, a task processing system 600 is further provided, referring to Figure 6 As shown in the figure, the task processing system 600 includes the task processing apparatus 300 described above, and further includes a graphics application program 610, a central processing unit 620 and a graphics processing unit 630.

[0167] The graphics application program 610 is configured to issue a command stream to the task processing apparatus 300.

[0168] The central processing unit 620 is configured to run the main thread of the graphics application program 610 and the special processing thread scheduled by the task processing apparatus 300.

[0169] The graphics processing unit 630 is configured to run the graphics processing thread scheduled by the task processing apparatus 300.

[0170] It should be noted that although several units of the task processing apparatus 300 are mentioned in the foregoing detailed description, such division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or sub-modules described above can be embodied in one module or unit. Conversely, the features and functions of one module or sub-module described above can be further divided into embodied by multiple modules or sub-modules.

[0171] Furthermore, in the exemplary embodiments of the present application, an electronic device capable of implementing the above task processing method is also provided.

[0172] Those skilled in the art can understand that various aspects of the present application can be implemented as a system, a method or a program product. Therefore, various aspects of the present application can be embodied as a complete hardware embodiment, a complete software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, which can be collectively referred to as "circuitry", "module" or "system" here.

[0173] The electronic device 700 according to such embodiments of the present application will be described below with reference to Figure 7 Figure 7 The electronic device 700 shown is merely an example and should not bring any limitation to the function and use range of the embodiments of the present application.

[0174] As shown in Figure 7 The components of the electronic device 700 can include, but are not limited to, the at least one processing unit 710 described above, the at least one storage unit 720 described above, a bus 730 connecting different system components (including the storage unit 720 and the processing unit 710), and a display unit 740.

[0175] The storage unit stores program code which can be executed by the processing unit 710, so that the processing unit 710 performs the steps according to various exemplary embodiments of the present application described in the "Exemplary Method" section above. For example, the processing unit 710 can perform the steps S110 shown in Figure 1 S110, identify resource copy commands and graphic processing commands in a main thread command stream; S120, assign the resource copy commands to a special processing thread for execution and assign the graphic processing commands in the command stream to a graphic processing thread for execution, wherein the special processing thread is a thread created independently of the main thread and the graphic processing thread; S130, determine the parallel execution of the special processing thread and the graphic processing thread according to the dependency relationship of the resource copy commands and the graphic processing commands.

[0176] ​Storage 720 can include a readable medium, such as a volatile memory 721 (e.g., random access memory (RAM)) and / or a cache 722, and can further include a non-volatile storage 723, e.g., read-only memory (ROM).

[0177] Storage 720 can also include a program / utility 724 having a set of program modules 725, including but not limited to an operating system, one or more application programs, other program modules, and program data, each of which can include implementations of the network environment in whole or in part.

[0178] Bus 730 can represent one or more of several types of bus structures, including a storage bus or bus controller, peripheral bus, graphics bus, processor or local bus using any of a variety of bus architectures.

[0179] Electronic device 700 can also communicate with one or more external devices 770 such as a keyboard or pointing device, using one or more input / output (I / O) devices 750. I / O device 750 can include one or more devices allowing a user to provide input to electronic device 700 and / or one or more devices allowing an output of information from electronic device 700. These devices can include, but are not limited to, a keyboard, a pointing device, a microphone, a display, a speaker, etc. Electronic device 700 can also include one or more communication devices 760, such as a modem, a network interface card (e.g. an Ethernet card), a wireless radio, etc., to enable electronic device 700 to communicate with one or more other devices. Figure 7 As shown, communication devices 760 can enable electronic device 700 to communicate with one or more other devices over a network 780, such as a local area network (LAN), a wide area network (WAN), and / or the Internet, among other examples. Although communication devices 760 are shown within electronic device 700, one or more communication devices 760 can be external to electronic device 700 and / or used in conjunction with electronic device 700 as is the case, for example, in a client-server relationship.

[0180] From the foregoing description, it will be apparent to those skilled in the art that a variety of modifications and changes can be made to the implementations described herein without departing from the scope of the application as understood by those of ordinary skill in the art. Thus, it is intended that the application not be limited to the particular

[0181] In the exemplary embodiments of the present application, a computer readable storage medium is also provided, on which a program product capable of implementing the above-mentioned task processing method of the present application is stored. In some possible embodiments, various aspects of the present application can also be implemented in the form of a program product, which includes program codes for causing a terminal device to perform the steps described in the above-mentioned "Exemplary Method" section according to various exemplary embodiments of the present application when the program product is run on the terminal device.

[0182] Reference Figure 8 As shown, a program product 800 for implementing the above-mentioned task processing method according to the embodiments of the present application is described, which can take the form of a portable compact disc read-only memory (CD-ROM) and include program codes, and can be run on a terminal device, such as a personal computer. However, the program product of the present application is not limited thereto, and in the present application, the readable storage medium can be any tangible medium containing or storing a program, which can be used by or in conjunction with an instruction execution system, apparatus or device.

[0183] The program product can take any combination of one or more readable storage media. The readable storage medium may, for example, be but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0184] The program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, C++, etc., and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of involving a remote computing device, the remote computing device can be connected to the user's computing device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, through the Internet by connecting to an Internet service provider).

[0185] Moreover, the above-described figures are only schematic and are not limiting, of the processes included in the method according to the exemplary embodiments of the present application. It is readily understood by those skilled in the art that the processes depicted in the figures are not meant to imply a particular timing of the processes. In addition, it is readily understood that the processes can be performed simultaneously or in a different order than that shown in the figures.

[0186] Those skilled in the art will readily understand that the example embodiments described herein can be implemented by software and / or by hardware components. As such, the technical solutions according to the embodiments of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, a USB flash disk, a mobile hard disk, etc.) or a network, and includes a number of instructions for enabling a computing device (such as a personal computer, a server, a touch terminal, or a network device, etc.) to perform the methods according to the embodiments of the present application.

[0187] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the present application cover any and all variations of the application that come within the scope of the claims and their equivalents. It is intended that the specification and examples be considered exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0188] It is to be understood that the application is not limited to the precise construction described and shown in the drawings and that various modifications and changes can be made by those skilled in the art without departing from the scope of the application. The scope of the application is limited only by the claims that follow.

Claims

1. A task processing method characterized by, The method comprises: identifying resource copy commands and graphics processing commands in a main thread command stream; allocating the resource copy commands to a dedicated processing thread for execution and allocating graphics processing commands in the command stream to a graphics processing thread for execution, wherein the dedicated processing thread is a thread created independently of the main thread and the graphics processing thread; determining parallel execution of the dedicated processing thread and the graphics processing thread according to a dependency relationship between the resource copy commands and the graphics processing commands.

2. The task processing method according to claim 1, characterized by, The method further comprises: the main thread command stream comprises other commands in addition to the resource copy commands and the graphics processing commands, and determining parallel execution of the main thread, the dedicated processing thread and the graphics processing thread according to a dependency relationship between the resource copy commands, the graphics processing commands and the other commands.

3. The task processing method of claim 1, wherein, After identifying the resource copy commands and the graphics processing commands in the command stream, the task processing method further comprises: storing the resource copy commands and the graphics processing commands separately in different command buffers; allocating the resource copy commands to the dedicated processing thread for execution and allocating the graphics processing commands to the graphics processing thread for execution comprises: in response to a submission command, submitting a command buffer address corresponding to the resource copy commands to the dedicated processing thread and submitting a command buffer address corresponding to the graphics processing commands to the graphics processing thread.

4. The task processing method according to claim 3, characterized by, After storing the resource copy commands and the graphics processing commands separately in different command buffers, the task processing method further comprises: in response to a requirement of an application program, recording a dependency relationship between commands in different command buffers; establishing execution timing logic across the command buffers according to the dependency relationship.

5. The task processing method according to claim 4, characterized by, Establishing execution timing logic across the command buffers according to the dependency relationship comprises: if there is a dependency relationship across the command buffers, serializing the commands in different command buffers by using a semaphore mechanism.

6. The task processing method of claim 5, wherein, The semaphore mechanism comprises: triggering a first semaphore after the dedicated processing thread completes the resource copy commands; waiting for the first semaphore to be released before the graphics processing thread executes the graphics processing commands.

7. The task processing method according to any one of claims 1 to 6, characterized by, The thread created independently of the main thread and the graphics processing thread comprises: dynamically applying thread resources when a resource copy command is first detected; releasing the thread resources when there is no resource copy command to be executed.

8. A task processing apparatus characterized by comprising: The driver program comprises: a command identification unit configured to identify resource copy commands and graphics processing commands in a main thread command stream; a command allocation unit configured to allocate the resource copy commands to a dedicated processing thread for execution and allocate graphics processing commands in the command stream to a graphics processing thread for execution, wherein the dedicated processing thread is a thread created independently of the main thread and the graphics processing thread; a command execution determination unit configured to determine parallel execution of the dedicated processing thread and the graphics processing thread according to a dependency relationship between the resource copy commands and the graphics processing commands.

9. A task processing system characterized by comprising: The task processing apparatus comprises: the task processing apparatus according to claim 8; a graphics application program configured to issue a command stream to the task processing apparatus; a central processing unit configured to run a main thread of the graphics application and a dedicated processing thread scheduled by the task processing device; a graphics processing unit configured to run a graphics processing thread scheduled by the task processing device.

10. An electronic device, comprising: comprising: a processor; and a memory having stored thereon computer readable instructions to be executed by the processor to implement the method of any one of claims 1 to 7.

11. A computer readable storage medium, characterized in that, a computer program stored thereon, the computer program being executed by a processor to implement the method of any one of claims 1 to 7.

Images