Graphics processor, data processing method, electronic device, and storage medium

Abstract

The present disclosure provides a graphics processor, a data processing method, an electronic device and a storage medium, and relates to the technical field of computers. The graphics processor comprises a graphics engine, the graphics engine comprises a graphics engine controller and a micro-copy sub-engine, wherein the graphics engine controller is configured to receive a task command sequence generated by an upper layer driver, and send a data transfer task to the micro-copy sub-engine if it is identified that the task command sequence contains the data transfer task; and the micro-copy sub-engine is configured to process the received data transfer task, and return a task completion signal to the graphics engine controller after completing the data transfer task. The present disclosure embeds the micro-copy sub-engine in the graphics engine, so that the data transfer task can be directly processed by the graphics engine, the call to other engines is reduced, the scheduling complexity in the graphics processor and the synchronization overhead between the engines are reduced, and the performance of the graphics processor is improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and in particular, to a graphics processor, a data processing method, an electronic device and a storage medium. BACKGROUND

[0002] In a graphics processor, a plurality of function engines, such as a graphics engine, a computing engine and a copy engine, are usually integrated for performing different types of tasks, such as graphics rendering, parallel computing and data transfer, respectively. In order to improve the overall processing performance and meet the demand of multi-task cooperative operation, the current graphics processor generally adopts a multi-engine cooperative scheduling mechanism, in which a scheduler distributes tasks to corresponding function engines for processing according to the types of the tasks.

[0003] For example, when rendering a frame of picture, a plurality of data transfer tasks and graphics rendering tasks usually need to be cooperatively executed. The graphics rendering task depends on the data transfer task, for example, the data transfer task is responsible for uploading the required vertex data and texture data for the graphics rendering task to consume to complete the picture output.

[0004] However, when the data transfer task has a small granularity, the data processing by scheduling the copy engine will bring a high scheduling overhead, which may even exceed the processing benefit of the task itself. If the graphics engine is solely relied on to undertake the data transfer and graphics rendering operations, two rendering processes need to be triggered respectively to complete the data loading and picture generation, further increasing the task scheduling and execution cost.

[0005] It should be noted that the information disclosed in the above background section is only used to strengthen the understanding of the background of the present disclosure, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0006] The purpose of the present disclosure is to provide a graphics processor, a data processing method, an electronic device and a storage medium, by embedding a micro-copy sub-engine in a graphics engine, so that the data transfer task can be directly processed by the graphics engine, reducing the invocation of other engines, reducing the scheduling complexity within the graphics processor and the synchronization overhead between engines, and thus improving the performance of the graphics processor.

[0007] According to a first aspect of the present disclosure, a graphics processor is provided, comprising a graphics engine, the graphics engine comprising a graphics engine controller and a micro-copy sub-engine, wherein:

[0008] The graphics engine controller is configured to receive a task command sequence generated by an upper layer driver, and in a case where the task command sequence contains a data transfer task, send the data transfer task to the micro-copy sub-engine.

[0009] The microcopy sub-engine is used to process the received data transfer task and return a task completion signal to the graphics engine controller after completing the data transfer task.

[0010] In one exemplary embodiment of this disclosure, the microcopy sub-engine includes:

[0011] The task control module is used to extract the data transfer task, identify the task type of the data transfer task, and split the data transfer task into read commands and / or write commands according to the task type.

[0012] The command processing module is used to receive read commands and / or write commands sent by the task control module, and process the corresponding target data based on the read commands and / or write commands.

[0013] In one exemplary embodiment of this disclosure, the task type includes a copy task;

[0014] The task control module is used to split the extracted copy task into a first read command and a first write command;

[0015] The command processing module is used to receive the first read command and the first write command, and to copy data according to the first read command and the first write command.

[0016] In one exemplary embodiment of this disclosure, the microcopy sub-engine further includes an internal buffer, the first read command includes a first data size and a first source address, and the first write command includes a first data size and a first destination address;

[0017] The command processing module includes:

[0018] The read command processing module is used to receive the first read command, and split the first read command into multiple first read requests adapted to the memory bus interface according to the first data size, and send each first read request to the memory bus interface so as to write the first target data read from the first source address into the internal buffer through the memory bus interface.

[0019] The write command processing module is used to receive the first write command, split the first write command into multiple first write requests adapted to the memory bus interface according to the first data size, and send each first write request to the memory bus interface so as to write the first target data read from the internal buffer to the first target address through the memory bus interface.

[0020] In one exemplary embodiment of this disclosure, when the write command processing module detects that data exists in the internal buffer, it writes the first target data read from the internal buffer into the storage space corresponding to the first target address through the memory bus interface.

[0021] In one exemplary embodiment of this disclosure, after the read command processing module writes the first target data into the internal buffer, it returns a first completion signal to the task control module; after the write command processing module writes the first target data into the storage space corresponding to the first target address, it returns a second completion signal to the task control module; after receiving the first completion signal and the second completion signal, the task control module returns a copy task completion signal to the graphics engine controller.

[0022] In one exemplary embodiment of this disclosure, the task type includes a fill task;

[0023] The task control module is used to convert the extracted fill task into a second write command;

[0024] The command processing module is used to receive the second write command and fill in the data according to the second write command.

[0025] In one exemplary embodiment of this disclosure, the second write command includes a second data size, a second target address, and padding content;

[0026] The command processing module includes:

[0027] The write command processing module is used to receive the second write command, split the second write command into multiple second write requests adapted to the memory bus interface according to the second data size, and send each second write request to the memory bus interface so as to write the filling content into the storage space corresponding to the second target address through the memory bus interface.

[0028] In one exemplary embodiment of this disclosure, after the write command processing module writes the filling content into the storage space corresponding to the second target address, it returns a third completion signal to the task control module. After receiving the third completion signal, the task control module returns a filling task completion signal to the graphics engine controller.

[0029] In one exemplary embodiment of this disclosure, the task type includes a prefetch task;

[0030] The task control module is used to convert the extracted prefetch task into a second read command;

[0031] The command processing module is used to receive the second read command and perform data prefetching according to the second read command.

[0032] In one exemplary embodiment of this disclosure, the second read command includes a third data size and a second source address;

[0033] The command processing module includes:

[0034] The read command processing module is used to receive the second read command, split the second read command into multiple second read requests adapted to the memory bus interface according to the third data size, and send each second read request to the memory bus interface so as to write the second target data read from the second source address into the target cache through the memory bus interface.

[0035] In one exemplary embodiment of this disclosure, after the read command processing module writes the second target data into the target cache, it returns a fourth completion signal to the task control module. After receiving the fourth completion signal, the task control module returns a prefetch task completion signal to the graphics engine controller.

[0036] In one exemplary embodiment of this disclosure, the microcopy sub-engine further includes:

[0037] A task queue is used to cache the received data transfer tasks so that the task control module can extract the data transfer tasks from the task queue.

[0038] In one exemplary embodiment of this disclosure, the graphics engine further includes:

[0039] A graphics task dispatcher is used to receive graphics tasks sent by the graphics engine controller and send the graphics tasks to the graphics rendering pipeline for rendering processing.

[0040] According to a second aspect of this disclosure, a data processing method is provided, applied to a graphics processor, the graphics processor including a graphics engine, the graphics engine including a graphics engine controller and a microcopy sub-engine, the method comprising:

[0041] The graphics engine controller receives a sequence of task commands generated by the upper-layer driver, and if it is found that the sequence of task commands contains a data transfer task, it sends the data transfer task to the microcopy sub-engine.

[0042] The microcopy sub-engine processes the received data transfer task and returns a task completion signal to the graphics engine controller after completing the data transfer task.

[0043] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0044] A graphics processor; and a storage unit for storing executable instructions of the graphics processor; wherein the graphics processor is configured to perform the above data processing method by executing the executable instructions.

[0045] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a graphics processor, implements the above-described data processing method.

[0046] The exemplary embodiments disclosed herein may have some or all of the following beneficial effects:

[0047] The graphics processor provided in this exemplary embodiment embeds a microcopy sub-engine within the graphics engine, enabling data transfer tasks to be received and processed within the graphics engine itself. Compared to related solutions that rely on a copy engine to complete similar tasks, this allows for localized optimization of the scheduling path, thereby reducing the number of cross-engine calls and lowering the scheduling overhead caused by frequent scheduling. Based on this, data transfer and graphics rendering operations only need to be triggered once, further reducing overall scheduling costs.

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

[0049] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0050] Figure 1 An architecture diagram of a graphics processor according to an embodiment of the present disclosure is shown.

[0051] Figure 2 An architecture diagram of a graphics engine according to an embodiment of this disclosure is shown.

[0052] Figure 3 An architecture diagram of another graphics processor according to an embodiment of this disclosure is shown.

[0053] Figure 4 An architecture diagram of a microcopy sub-engine according to an embodiment of this disclosure is shown.

[0054] Figure 5 A schematic diagram illustrating the principle of a microcopy sub-engine performing data transfer tasks in an embodiment of this disclosure is shown.

[0055] Figure 6 A flowchart illustrating a data processing method according to an embodiment of this disclosure is shown.

[0056] Figure 7 A complete processing flowchart of a microcopy sub-engine performing a data transfer task is shown in an embodiment of this disclosure.

[0057] Figure 8 A schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure is shown.

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

[0059] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more of the specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0060] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0061] It is understandable that a graphics processing unit (GPU) can be a GPU that supports general computing capabilities. In addition to performing traditional graphics rendering tasks, it can also use the parallel computing capabilities of the GPU to compute non-graphics tasks that are highly regular, simple, and numerous.

[0062] refer to Figure 1 The diagram illustrates an architecture of a graphics processor according to an embodiment of this disclosure. Figure 1In this system, the graphics processor includes a graphics engine 110, which embeds a microcopy sub-engine 111. The graphics engine 110 can be used to perform operations such as graphics rendering and graphics task scheduling, while the microcopy sub-engine 111, as an embedded sub-unit of the graphics engine 110, is used to handle data transfer tasks with small granularity and / or high processing frequency.

[0063] For example, a small-granularity data transfer task can refer to a transfer request involving no more than a few hundred bytes to several thousand bytes of data in a single operation. Of course, the specific size of the data granularity can be flexibly adjusted according to the graphics processor's task scheduling strategy, internal bandwidth allocation, and the real-time requirements of the specific application scenario, and this disclosure does not limit this. A high-frequency data transfer task can refer to a task whose triggering frequency exceeds a preset frequency threshold per unit time. For example, triggering more than dozens or even hundreds of data transfer requests per second. Such tasks have high call density and real-time requirements in scenarios such as graphics rendering initialization, resource synchronization, and status parameter updates, and are generally not suitable for execution through the main rendering path or large-scale general-purpose engines to avoid scheduling blockage or resource conflicts.

[0064] By completing data transfer tasks within the graphics engine, the data transfer path in the graphics processing path can be shortened, the scheduling waiting time required for task migration can be reduced, and the necessary data preparation process can be completed without introducing cross-engine scheduling.

[0065] Specifically, the microcopy sub-engine 111 can extract data transfer tasks and identify the task type of the data transfer tasks, and then process the corresponding target data according to the task type of the data transfer tasks. Among them, the data volume of the target data is relatively small, usually hundreds of bytes to thousands of bytes, including but not limited to texture data, vertex data, instruction buffer data or intermediate calculation results required for graphics rendering, which are suitable for the data transfer tasks targeted by the microcopy sub-engine.

[0066] For example, in the exemplary embodiments of this disclosure, the data transfer task types include, but are not limited to, copy tasks, fill tasks, or prefetch tasks, thereby avoiding scheduling such tasks to other functional engines within the graphics processor, such as a dedicated copy engine, for processing. This helps to reduce the scheduling load of the task scheduler within the graphics processor and reduce resource contention and synchronization overhead caused by concurrent processing of multiple engines, enabling tasks to be executed locally in a closed loop, thereby enhancing the controllability and execution efficiency of the task processing process.

[0067] Of course, the graphics processing unit (GPU) may also include other functional engines besides the graphics engine 110, such as a computing engine 120, a copying engine 130, and a ray tracing engine 140, to perform different types of graphics or non-graphics tasks, such as parallel computing, large-scale data transfer, and complex lighting simulation. These functional engines can work together within the GPU, with the scheduler dynamically allocating resources according to the task type to achieve unified scheduling and execution of multiple types of tasks. In addition, the GPU may also include a cache management unit, a storage interface, a task scheduler, and related control modules (not shown in the figure) to support multi-task concurrent processing and efficient data access path management, thereby improving the overall system-level throughput and resource utilization of the GPU. With the synergistic cooperation of the above structures in the GPU, a high-efficiency balance can be achieved between resource utilization and concurrent processing, providing stable computing power support for complex graphics applications.

[0068] It should be noted that, Figure 1 This is merely a schematic diagram of the graphics processor, used to illustrate the basic architectural concept of this disclosure. The specific structure of the graphics processor can be further divided into different sub-modules, task scheduling units, and interface logic, etc., according to actual application requirements, and this disclosure does not limit it in this regard.

[0069] refer to Figure 2 The diagram illustrates an architecture of a graphics engine according to an embodiment of this disclosure. Figure 2 In addition to the embedded microcopy sub-engine 111, the graphics engine 110 also includes a graphics engine controller 112 and a graphics task dispatcher 113.

[0070] The graphics engine controller 112 is used to receive a sequence of task commands generated by the upper-layer driver, that is, to receive various tasks to be processed configured from the graphics processor driver side. For example, the tasks to be processed include, but are not limited to, data handling tasks such as data copying, data filling or data prefetching, as well as graphics tasks related to graphics rendering, which are not limited in this disclosure.

[0071] The graphics engine controller 112 can parse and classify the received task command sequence, and schedule and distribute traffic according to the differentiated paths based on the task type, so as to achieve resource usage optimization under task type awareness. For example, by parsing the task type field in the task command sequence, the queue label when submitting the task queue, or the resource access description information, the type of each task can be determined.

[0072] When the graphics engine controller 112 identifies a data transfer task in the sequence of task commands during the parsing process, it can send the data transfer task to the microcopy sub-engine 111.

[0073] The microcopy sub-engine 111 can process received data transfer tasks. For example, it can identify the task type of the data transfer task, and perform discrimination and scheduling based on the task type to execute the processing corresponding to the task type.

[0074] After completing data processing, the microcopy sub-engine 111 returns a task completion signal to the graphics engine controller 112, thereby forming a closed loop of task processing, which facilitates the subsequent control module to track and manage the task status.

[0075] When the graphics engine controller 112 recognizes a graphics task, it sends the received graphics task to the graphics task dispatcher 113, which then schedules the graphics task to the graphics rendering pipeline 150 to complete the processing of graphics rendering-related processes.

[0076] The division of labor and collaboration among the modules in the graphics engine 110 enables differentiated management and parallel execution of different types of tasks. This avoids unnecessary cross-interference in the task scheduling chain and improves the scheduling flexibility and execution throughput efficiency of the graphics engine in handling multiple task scenarios.

[0077] refer to Figure 3 The diagram illustrates an architecture of another graphics processor according to an embodiment of this disclosure. In this architecture, the microcopy sub-engine 111 includes a task control module and a command processing module. The task control module is used to extract data transfer tasks distributed by the graphics processor scheduling unit, identify the task type of the extracted data transfer tasks, and split the data transfer tasks into read commands and / or write commands according to the task type, thereby achieving standardized encapsulation and scheduling decoupling of the data operation process.

[0078] Specifically, the task control module can generate read / write commands with access instructions and parameter configurations based on the task description fields configured in the data transfer task, such as source address, destination address, and data size. This supports data transfer operations of different task types, such as data copying, data filling, or data prefetching. For example, when a data transfer task contains both a valid source address and a destination address, it is identified as a data copy task; when a data transfer task contains only a destination address and carries a fill value, it is identified as a data fill task; when a task contains only a source address and carries a prefetch flag, it is identified as a data prefetch task. Of course, if the data transfer task is configured with a task type code field, the corresponding task type can be directly determined based on the task type code field; this disclosure does not impose any limitations on this.

[0079] The command processing module receives read and / or write commands from the task control module and processes the corresponding target data based on these commands. Specifically, the command processing module can use read commands to trigger a read operation on the target data in the storage unit and use write commands to control the write process of the target data, thereby achieving efficient transfer of target data between the source address and the target address.

[0080] In this example, the microcopy sub-engine 111 can transform the original data transfer task into a set of standardized command sequences that can be executed quickly, and complete the instruction-level execution process in an efficient and decoupled manner. This improves the graphics processor's response speed and overall concurrent processing capability for small-granularity, high-frequency data transfer requests without relying on the main graphics rendering path, and enhances the processor's adaptability and scalability to heterogeneous task scenarios.

[0081] Further, refer to Figure 4 The diagram illustrates an architecture of a microcopy sub-engine according to an embodiment of this disclosure. Figure 4 As shown, the microcopy sub-engine 111 includes a task queue 1111, a task control module 1112, and a command processing module. The task queue 1111 is used to cache received data transfer tasks, enabling temporary task storage and process decoupling. This avoids resource backpressure on the graphics engine scheduling path caused by instantaneous task backlog, thus ensuring the continuous processing capability and scheduling stability of graphics tasks. The task control module 1112 is used to extract data transfer tasks to be processed from the task queue 1111, identify the task type of the data transfer tasks, and split the data transfer tasks into read commands and / or write commands according to the task type, thereby realizing the instruction-based processing of the data reading and writing process. Next, the command processing module is used to receive the read commands and / or write commands sent by the task control module 1112, and perform corresponding data processing based on the read commands and / or write commands.

[0082] In this embodiment of the present disclosure, in order to achieve efficient collaboration with the underlying storage channel, the command processing module can be further subdivided into a read command processing module 1113 and a write command processing module 1114, which are used to process the command requests corresponding to the read operation and the write operation, respectively.

[0083] Through such Figure 4 As shown in the module division, the microcopy sub-engine 111 can realize the structured decomposition and efficient execution of data transfer tasks, further improving the task response speed and concurrent processing capability of the graphics processor in multi-tasking scenarios.

[0084] Specifically, task queue 1111 is used to cache various data transfer tasks from graphics engine controller 112, such as copy tasks, fill tasks, or prefetch tasks. Setting up task queue 1111 can achieve temporary storage and decoupling buffering of data transfer tasks, thereby avoiding back pressure on the graphics engine resource scheduling path caused by instantaneous task accumulation, and helping to ensure the continuity and responsiveness of graphics tasks.

[0085] The task control module 1112 is used to extract data transfer tasks to be processed from the task queue 1111, and parse them into one or more operation commands according to the specific type of the task, including read commands and / or write commands, thereby realizing the generation of structured instructions for data transfer tasks. Taking a copy task as an example, the task control module 1112 can split it into corresponding read commands and write commands, and send these commands to the read command processing module 1113 and the write command processing module 1114 respectively.

[0086] The read command processing module 1113 is used to receive the read command generated by the task control module 1112, and according to the source address and data size information carried in the command, further split the read command into multiple read requests adapted to the memory bus interface 401, and then read the target data from the specified source address through the memory bus interface 401 and write it into the internal buffer 1115 of the microcopy sub-engine 111.

[0087] The write command processing module 1114 is used to receive the write command generated by the task control module 1112, and according to the target address and write data size configured in the command, split the write command into multiple write requests adapted to the memory bus interface 401, and write the data stored in the internal buffer 1115 to the target address through the memory bus interface 401.

[0088] The internal buffer 1115 provides intermediate buffer storage space between data reading and writing to support decoupling and timing matching of the read and write processes. For example, the read command processing module 1113 writes the target data obtained from the source address into the internal buffer 1115, while the write command processing module 1114 reads the target data from the internal buffer 1115 and writes it to the target address. By setting the internal buffer 1115, processing bottlenecks caused by access latency and bus bandwidth occupation can be effectively alleviated, improving the overall processing efficiency of data transfer tasks and the stability of the graphics processor's data path.

[0089] In addition, by refining the command processing module into a read command processing module 1113 and a write command processing module 1114, not only can parallel processing and functional decoupling of the read and write paths be realized, but the processing throughput efficiency of data transfer tasks in the graphics engine can also be improved, enhancing the concurrent processing capability of the graphics processor for multiple high-frequency, low-load tasks, which helps to improve the flexibility and execution efficiency of the overall graphics task scheduling.

[0090] In one example implementation, the data transfer task type includes a copy task. A copy task refers to a data transfer operation that copies data from a specified source address to a specified target address. This example implementation is suitable for scenarios with a small amount of data but high response speed requirements.

[0091] For example, the task control module can be used to extract copy tasks to be processed from the task queue. To support fine-grained scheduling and execution of copy tasks, the copy task can be split into a first read command and a first write command. The first read command contains parameter information describing the source data location and data volume, indicating the data location and reading range to be read. The first write command contains the target address and corresponding write control field, indicating the storage location and writing range of the copied data. The command processing module receives the first read command and first write command generated by the task control module and performs data copying according to these commands. This enables rapid execution of small-granularity data transfer operations on the graphics engine side, reducing resource scheduling burden and helping to improve the response efficiency and concurrency capabilities of task processing in the graphics processor.

[0092] For example, the first read command includes a first data size and a first source address, while the first write command includes a first data size and a first destination address. The first data size indicates the total length of data to be read from the source address, usually in bytes, and is used to guide the granularity and batch size of data access. The first source address specifies the starting storage location for the data read operation, and the first destination address identifies the write terminal location of the copied data, serving as the address basis for subsequent write operations.

[0093] To improve task execution efficiency and interface adaptability, the command processing module is structurally divided into a read command processing module and a write command processing module. The read command processing module receives the first read command issued by the task control module and performs granular segmentation processing on the first read command according to the first data size. For example, it splits the first read command into multiple first read requests adapted to the memory bus interface. Each read request includes address offset and segment data length parameters to adapt to the system bus's concurrent access mechanism.

[0094] Subsequently, the read command processing module sends each first read request to the memory bus interface, so that the first target data read from the first source address can be written into the internal buffer of the microcopy sub-engine through the memory bus interface, thereby decoupling the local temporary storage of data from the subsequent processing.

[0095] Correspondingly, the write command processing module receives the first write command and, based on the first data size, splits it into multiple first write requests adapted to the memory bus interface. Each first write request includes a mapping between a target address segment and the byte segment of the data to be written. Each first write request is sent to the memory bus interface so that the first target data read from the internal buffer can be written to the storage space corresponding to the first target address, achieving a fast update operation on the target storage area.

[0096] It should be noted that when the write command processing module detects data in the internal buffer, such as the first target data, it can write the first target data read from the internal buffer to the storage space corresponding to the first target address through the memory bus interface.

[0097] Furthermore, to ensure a closed-loop feedback mechanism for task status, the read command processing module can return a first completion signal to the task control module after writing the first target data into its internal buffer. The write command processing module, after writing the first target data into the storage space corresponding to the first target address, returns a second completion signal to the task control module. Upon receiving the first and second completion signals, the task control module determines that the current copy task is complete and then returns a copy task completion signal to the graphics engine controller for reference in subsequent task scheduling.

[0098] In one example implementation, the data transfer task includes a filling task, which is a data initialization operation that writes a set value to a contiguous memory region at a specified target address. It is suitable for scenarios such as buffer initialization, data segment reset, general memory pre-configuration, or construction of basic graphics data structures in graphics processors. It has the characteristics of high trigger frequency and short response cycle, and is especially suitable for task environments that require rapid completion of memory state preparation.

[0099] For example, the task control module can be used to extract a fill task to be processed from the task queue and convert the fill task into a second write command. The second write command includes a starting position parameter to identify the target address to be written, a data content field to specify the fill value, and length information describing the write range. Through the structured configuration of these write parameters, explicit expression of the fill task and orderly control of its execution process can be achieved.

[0100] The command processing module receives the second write command sent by the task control module and performs data filling according to the command. For example, based on the settings in the second write command, it writes the filling content to the memory region indicated by the target address, thereby efficiently completing the fast filling of the specified memory segment. This not only avoids the synchronization delay and scheduling resource contention issues caused by task migration between multiple functional engines, but also improves the efficiency of graphics tasks in preparing the data structures they depend on before execution. Therefore, while ensuring system responsiveness, it enhances the graphics processor's adaptability to multi-task concurrent processing and the flexibility of resource allocation.

[0101] For example, the second write command includes a second data size, a second target address, and padding content. The second data size indicates the length of the target address space covered by this padding operation, the second target address identifies the starting memory location where the padding operation needs to be performed, and the padding content specifies the data value to be written to that memory region. Upon receiving the second write command, the write command processing module can break it down into multiple second write requests adapted to the memory bus interface based on the second data size, thereby enabling the smallest granularity of data access operations at the hardware level.

[0102] Subsequently, the write command processing module can send the split second write requests to the memory bus interface, and write the fill content in batches or segments to the contiguous memory region indicated by the second target address through the memory bus interface. During this process, the write command processing module can use parallel writing, pipeline scheduling, and other methods to improve filling efficiency and reduce processing latency.

[0103] In this example, the microcopy sub-engine can efficiently complete the data filling task of a specified memory region. It is suitable for application scenarios such as initializing buffers, clearing data blocks, or building preset data structures, thereby effectively improving the data preprocessing capability and overall execution efficiency of the graphics processor in a multi-tasking environment.

[0104] After writing the fill content to the storage space corresponding to the second target address, the write command processing module returns a third completion signal to the task control module to indicate that the current fill operation has been successfully completed. Specifically, after writing the fill content to the memory area indicated by the second target address according to the settings in the second write command, the write command processing module generates and sends a third completion signal to complete the task feedback.

[0105] Upon receiving the third completion signal from the write command processing module, the task control module confirms that the fill task has been completed and generates a fill task completion signal to return to the graphics engine controller. This task completion signal can be used to update the task execution status in the graphics engine, supporting the execution of subsequent scheduling logic or the advancement of the task pipeline.

[0106] In this example, the microcopy sub-engine can achieve closed-loop feedback of task status after completing the filling task, which helps to improve the controllability and synchronization of task processing in the graphics processor, and further enhances the system's response efficiency and scheduling stability for high-frequency data transfer tasks.

[0107] In one example implementation, the data transfer task type includes a prefetch task. A prefetch task refers to a pre-fetch operation that proactively loads relevant data from system memory into the target cache area integrated with the graphics processor based on the required data address range before the actual computation or rendering task is triggered. This operation is initiated by the microcopy sub-engine to improve the data access hit rate of subsequent tasks and reduce runtime data loading latency, making it particularly suitable for graphics rendering or massively parallel computing tasks that are sensitive to cache response time.

[0108] For example, the task control module can be used to extract prefetch tasks to be processed from the task queue and convert the prefetch tasks into second read commands. The second read command includes an information field representing the data source address and a range parameter describing the amount of prefetched data, used to guide subsequent data loading operations.

[0109] The command processing module receives the second read command sent by the task control module and performs data prefetching based on the data source location and data length specified in the second read command. This prefetches the target data from system memory into the target cache, preparing it for subsequent data use triggered by graphics or computation tasks. The target cache can refer to on-chip cache (L1 / L2 cache), shared memory, or other data temporary storage areas with fast access capabilities; this disclosure does not limit this definition.

[0110] Through this prefetching mechanism, the graphics processor can complete the cache filling of critical data before task scheduling, reduce the data access latency during the execution phase without interrupting the main task logic flow, help improve the data flow continuity and multi-task processing performance of the overall system, and enhance the stability and response efficiency of the graphics engine under high load conditions.

[0111] For example, the second read command includes a third data size and a second source address. The third data size indicates the length of the data to be loaded in this prefetch operation, and the second source address indicates the starting memory location from which the data will be read.

[0112] At this time, the read command processing module is used to receive the second read command and split the second read command into multiple second read requests adapted to the memory bus interface according to the third data size. This splitting process can ensure that each read request meets the requirements of the underlying hardware bus for data access granularity and bandwidth alignment, thereby improving access efficiency.

[0113] Subsequently, the read command processing module sends each second read request to the memory bus interface, so as to read the second target data of a preset length from the second source address through the memory bus interface, and write the read second target data into the target cache.

[0114] This example enables the preloading of critical data before the actual rendering or computation task begins, thereby reducing access latency during the main task's execution and improving cache hit rate.

[0115] After writing the second target data to the target cache, the read command processing module returns a fourth completion signal to the task control module to notify that the current prefetch operation has been completed. Upon receiving the fourth completion signal, the task control module confirms that the current prefetch task has been completed and generates a prefetch task completion signal, which is sent to the graphics engine controller to update the task status or trigger subsequent task scheduling.

[0116] The microcopy sub-engine not only realizes the structured execution and feedback loop of prefetch data transfer tasks, but also effectively improves the data preparation efficiency and system response performance of the graphics processor in a multi-tasking environment.

[0117] refer to Figure 5 The diagram illustrates the principle of a microcopy sub-engine performing a data transfer task in an embodiment of this disclosure. Before performing the data transfer task, the microcopy sub-engine 111 pre-allocates data space in its integrated internal buffer 1115 for temporary storage of data to be transferred or received, thereby improving the concurrency performance and scheduling flexibility of data transfer.

[0118] The microcopy sub-engine 111 establishes a connection with the system bus through the memory bus interface 401 to complete data interaction operations with the system memory. Specifically, the microcopy sub-engine 111 can read data to be transmitted from the internal buffer 1115 and send it to the downstream channel through the bus, or receive data from the system memory and write it into the buffer.

[0119] To improve the efficiency of the data transfer path, the data being read or to be transmitted is first transferred through the cache 501. The cache 501 serves as a high-speed temporary buffer area, used to store data that will be transmitted through the on-chip network 502 for a short period of time, thereby reducing the pressure on system bandwidth caused by burst data access and improving the overall data throughput performance.

[0120] Subsequently, cache 501 transmits data to memory 503 via on-chip network 502, or reads data from memory 503 and returns it to cache 501, thereby realizing data transfer operations between microcopy sub-engine 111 and system memory. This process completes cross-domain data transfer between different storage areas, effectively improving the system's data access efficiency and resource utilization coordination in tasks such as graphics processing and parallel computing.

[0121] This disclosure also provides a data processing method applied to a graphics processor, specifically, the graphics processor including a graphics engine, which embeds a graphics engine controller and a microcopy sub-engine. (See reference) Figure 6 As shown, the data processing method may include the following steps S610 and S620:

[0122] In step S610, the graphics engine controller receives the task command sequence generated by the upper-layer driver, and if it is found that the task command sequence contains a data transfer task, it sends the data transfer task to the microcopy sub-engine.

[0123] The upper-layer driver is usually a graphics processor driver running in the graphics subsystem of the operating system. It is used to generate corresponding task command sequences based on rendering requests, data loading requests or synchronization instructions submitted by the application layer, and to configure the type, resource access parameters and execution order of each task.

[0124] After assembling and parameterizing the task command sequence, the upper-layer driver sends the task command sequence to the graphics engine controller for the graphics engine to perform task scheduling and resource calls.

[0125] The task command sequence comprises multiple task commands, each corresponding to a graphics task or data transfer task to be executed. Each task command can carry a task type field, a parameter field, and resource access description information to define the task category and execution parameters. For example, the task type field can indicate whether the task belongs to graphics rendering, computation scheduling, or data transfer. The parameter field may include a task identifier, priority, and synchronization dependency information. The resource access description information may include the source memory address, the target memory address, the data length, and cache control flags.

[0126] After receiving the task command sequence, the graphics engine controller can temporarily store the sequence in the command buffer, verifying its integrity and order to ensure the validity of the task data. Subsequently, it reads and parses each task command, identifying commands belonging to the data transfer category based on the task type field. For identified data transfer commands, it extracts their resource access parameters and execution attributes, assembles them into structured data transfer tasks, and finally sends them to the microcopy sub-engine for execution via the internal command bus.

[0127] In step S620, the microcopy sub-engine processes the received data transfer task and returns a task completion signal to the graphics engine controller after completing the data transfer task.

[0128] After receiving a data transfer task, the micro-copy sub-engine can read and verify the key fields of each task. These key fields include the source address, destination address, data length, alignment attributes, and whether it carries padding values ​​or a prefetch flag. Based on this, the task type can be determined: if both a valid source and destination address are present, it is determined to be a data copy task; if only the destination address is present and a padding value is included, it is determined to be a data padding task; if only the source address is present and a prefetch flag is included, it is determined to be a data prefetch task. If the key fields include a type code field, the task type can also be directly determined based on this.

[0129] After completing the task type identification, corresponding read and / or write commands can be generated based on the specific task type.

[0130] For example, for a copy task, a set of read commands to read source data and write commands to write to the target address are generated. For a fill task, write commands to write to the target region with the specified fill value are generated directly; for a prefetch task, only read commands to load data into the internal buffer need to be constructed.

[0131] The process of breaking down data transfer tasks enables the task to be expressed in instructions, which is beneficial for the concurrent scheduling and pipeline execution of subsequent modules.

[0132] During the command execution phase, the corresponding processing path can be initiated based on the specific type of the command. For read commands, the data size can be split into multiple read requests adapted to the bus protocol, and external system memory can be accessed through the memory bus interface within the graphics processor to read data from the specified address into the internal buffer of the microcopy sub-engine, or to move data from memory to the cache. For write commands, the data in the internal buffer or the preset fill value can be written to the target address, realizing data transfer or area filling.

[0133] After the data transfer task is completed, a corresponding task completion signal can be generated and returned to the graphics engine controller, supporting scheduling synchronization and subsequent task triggering.

[0134] This method enables independent and efficient processing of lightweight data transfer tasks within the graphics engine, optimizes the overall resource utilization and task scheduling performance of the graphics processor, and is particularly suitable for rapid data preparation scenarios during intermittent gaps between rendering tasks or in parallel computing processes.

[0135] refer to Figure 7The diagram illustrates a complete processing flowchart of a micro-copy sub-engine performing data transfer tasks in an embodiment of this disclosure. This flowchart enables the classification, processing, and closed-loop control of small-granularity, high-frequency data transfer tasks such as data copying, data filling, and data prefetching. The process includes the following steps S701 to S720:

[0136] Step S701, extract a data transfer task from the task queue: The task control module can extract a data transfer task to be processed from the task queue according to the task execution priority or scheduling strategy.

[0137] Step S702, Identify Task Type: The task control module identifies the task type of the received data transfer task, determining whether it is a copy task, a fill task, or a prefetch task, in order to construct the corresponding processing command. If the task is determined to be a copy task, then steps S703 to S710 and S720 are executed; if the task is determined to be a prefetch task, then steps S711 to S715 and S720 are executed; if the task is determined to be a fill task, then steps S717 to S720 are executed.

[0138] For copying tasks:

[0139] Step S703: The task control module constructs a write command and sends it to the write command processing module, and constructs a read command and sends it to the read command processing module;

[0140] Step S704: The read command processing module splits the read command into fixed-size bus read commands;

[0141] Step S705: Send the split bus read command to the memory bus interface to initiate a read operation;

[0142] Step S706: Receive the data returned from the source address and write it to the internal buffer;

[0143] Step S707: The read command processing module sends a completion signal to the task control module and executes step S720.

[0144] In step S708, the write command processing module retrieves read data from the internal buffer, splits the write command into fixed-size bus write commands, and fills the internal buffer with data.

[0145] Step S709: Send the split bus write command to the memory bus interface to write the read data to the target address according to the bus write command;

[0146] Step S710: The write command processing module sends a completion signal to the task control module and executes step S720.

[0147] It should be noted that steps S704 to S705 (read operation) and steps S708 to S709 (write operation) can be executed in parallel, and steps S707 and S710 can also return completion signals in parallel. There is no dependency on the start time. However, the processing of the write command module depends on the read command module writing to the internal buffer.

[0148] For prefetching tasks:

[0149] Step S711: The task control module constructs a read command and sends it to the read command processing module;

[0150] Step S712: The read command processing module splits the read command into fixed-size bus read commands;

[0151] Step S713: Send the split bus read command to the memory bus interface;

[0152] In step S714, the memory processing system moves the data from memory to the cache;

[0153] Step S715: The read command processing module sends a completion signal to the task control module and executes step S720.

[0154] For fill tasks:

[0155] Step S716: The task control module constructs a write command and sends it to the write command processing module;

[0156] In step S717, the write command processing module splits the write command into fixed-size bus write commands and fills the data with fill content, such as filling the data area of ​​each sub-command with fill value;

[0157] Step S718: Send the split bus write command to the memory bus interface;

[0158] Step S719: The write command processing module generates a completion signal and sends it to the task control module, and then executes step S720.

[0159] In step S720, after receiving the completion signal, the task control module generates and returns a task completion signal to the graphics front-end control module.

[0160] Through the above steps, the microcopy sub-engine can achieve unified reception, classification and processing, command construction and execution status feedback for different types of data transfer tasks. It has the advantages of clear structure, high processing efficiency and closed-loop scheduling, and is particularly suitable for coprocessing scenarios in graphics processors for high-frequency tasks with small data volumes.

[0161] The data processing method implemented in the example embodiments of this disclosure enables data transfer tasks to be received and processed within the graphics engine by embedding a micro-copy sub-engine within the graphics engine, without having to call other functional engines such as the copy engine. This shortens the task scheduling path, reduces the synchronization and coordination overhead between multiple engines, and improves the execution efficiency of target data processing and the utilization rate of system resources.

[0162] Exemplary embodiments of this disclosure also provide a computer-readable storage medium having a program product stored thereon capable of implementing the methods described above in this specification. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when run on an electronic device, causes the electronic device to perform the steps described in the "Exemplary Methods" section of this specification according to the various exemplary embodiments of this disclosure. This program product may be a portable compact disc read-only memory (CD-ROM) including program code and may run on an electronic device, such as a personal computer. However, the program product of this disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

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

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

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

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

[0167] Exemplary embodiments of this disclosure also provide an electronic device capable of implementing the above-described method. Referring below... Figure 8 To describe an electronic device 800 according to such an exemplary embodiment of the present disclosure. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0168] like Figure 8 As shown, the electronic device 800 can be represented as a general-purpose computing device. The components of the electronic device 800 may include, but are not limited to: at least one graphics processor 810, at least one storage unit 820, a bus 830 connecting different system components (including the storage unit 820 and the graphics processor 810), and a display unit 840.

[0169] The storage unit 820 stores program code that can be executed by the graphics processor 810, causing the graphics processor 810 to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of this disclosure. For example, the graphics processor 810 can execute... Figure 6 and Figure 7 The methods and steps in the text.

[0170] Storage unit 820 may include readable media in the form of volatile storage units, such as random access memory (RAM) 821 and / or cache memory (Cache) 822, and may further include read-only memory (ROM) 823.

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

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

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

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

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

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

[0177] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0178] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A graphics processor, characterized in that, The graphics processor includes a graphics engine, which includes a graphics engine controller and a microcopy sub-engine, wherein: The graphics engine controller is configured to receive a sequence of task commands generated by the upper-layer driver, and, if it is identified that the sequence of task commands contains a data transfer task, send the data transfer task to the microcopy sub-engine. The microcopy sub-engine is used to process the received data transfer task and return a task completion signal to the graphics engine controller after completing the data transfer task.

2. The graphics processor according to claim 1, characterized in that, The microcopy sub-engine includes: The task control module is used to extract the data transfer task, identify the task type of the data transfer task, and split the data transfer task into read commands and / or write commands according to the task type. The command processing module is used to receive read commands and / or write commands sent by the task control module, and process the corresponding target data based on the read commands and / or write commands.

3. The graphics processor according to claim 2, characterized in that, The task type includes copy tasks; The task control module is used to split the extracted copy task into a first read command and a first write command; The command processing module is used to receive the first read command and the first write command, and to copy data according to the first read command and the first write command.

4. The graphics processor according to claim 3, characterized in that, The microcopy sub-engine also includes an internal buffer, the first read command includes a first data size and a first source address, and the first write command includes a first data size and a first destination address; The command processing module includes: The read command processing module is used to receive the first read command, and split the first read command into multiple first read requests adapted to the memory bus interface according to the first data size, and send each first read request to the memory bus interface so as to write the first target data read from the first source address into the internal buffer through the memory bus interface. The write command processing module is used to receive the first write command, split the first write command into multiple first write requests adapted to the memory bus interface according to the first data size, and send each first write request to the memory bus interface so as to write the first target data read from the internal buffer into the storage space corresponding to the first target address through the memory bus interface.

5. The graphics processor according to claim 4, characterized in that, When the write command processing module detects that there is data in the internal buffer, it writes the first target data read from the internal buffer into the storage space corresponding to the first target address through the memory bus interface.

6. The graphics processor according to claim 4, characterized in that, After writing the first target data into the internal buffer, the read command processing module returns a first completion signal to the task control module; after writing the first target data into the storage space corresponding to the first target address, the write command processing module returns a second completion signal to the task control module. After receiving the first and second completion signals, the task control module returns a copy task completion signal to the graphics engine controller.

7. The graphics processor according to claim 2, characterized in that, The task types include filler tasks; The task control module is used to convert the extracted fill task into a second write command; The command processing module is used to receive the second write command and fill in the data according to the second write command.

8. The graphics processor according to claim 7, characterized in that, The second write command includes a second data size, a second target address, and padding content; The command processing module includes: The write command processing module is used to receive the second write command, split the second write command into multiple second write requests adapted to the memory bus interface according to the second data size, and send each second write request to the memory bus interface so as to write the filling content into the storage space corresponding to the second target address through the memory bus interface.

9. The graphics processor according to claim 8, characterized in that, After writing the fill content into the storage space corresponding to the second target address, the write command processing module returns a third completion signal to the task control module. After receiving the third completion signal, the task control module returns a fill task completion signal to the graphics engine controller.

10. The graphics processor according to claim 2, characterized in that, The task types include prefetching tasks; The task control module is used to convert the extracted prefetch task into a second read command; The command processing module is used to receive the second read command and perform data prefetching according to the second read command.

11. The graphics processor according to claim 10, characterized in that, The second read command includes a third data size and a second source address; The command processing module includes: The read command processing module is used to receive the second read command, split the second read command into multiple second read requests adapted to the memory bus interface according to the third data size, and send each second read request to the memory bus interface so as to write the second target data read from the second source address into the target cache through the memory bus interface.

12. The graphics processor according to claim 11, characterized in that, After writing the second target data into the target cache, the read command processing module returns a fourth completion signal to the task control module. Upon receiving the fourth completion signal, the task control module returns a prefetch task completion signal to the graphics engine controller.

13. The graphics processor according to claim 2, characterized in that, The microcopy sub-engine also includes: A task queue is used to cache the received data transfer tasks so that the task control module can extract the data transfer tasks from the task queue.

14. The graphics processor according to claim 1, characterized in that, The graphics engine also includes: A graphics task dispatcher is used to receive graphics tasks sent by the graphics engine controller and send the graphics tasks to the graphics rendering pipeline for rendering processing.

15. A data processing method, characterized in that, Applied to a graphics processing unit, the graphics processing unit including a graphics engine, the graphics engine including a graphics engine controller and a microcopy sub-engine, the method includes: The graphics engine controller receives a sequence of task commands generated by the upper-layer driver, and if it is found that the sequence of task commands contains a data transfer task, it sends the data transfer task to the microcopy sub-engine. The microcopy sub-engine processes the received data transfer task and returns a task completion signal to the graphics engine controller after completing the data transfer task.

16. An electronic device, characterized in that, include: Graphics processor; as well as A storage unit for storing the executable instructions of the graphics processor; The graphics processor is configured to perform the data processing method of claim 15 by executing the executable instructions.

17. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the graphics processor, it implements the data processing method of claim 15.

Images