CN114579288A - Task processing method and device and computer equipment - Google Patents
Task processing method and device and computer equipment Download PDFInfo
- Publication number
- CN114579288A CN114579288A CN202210495716.8A CN202210495716A CN114579288A CN 114579288 A CN114579288 A CN 114579288A CN 202210495716 A CN202210495716 A CN 202210495716A CN 114579288 A CN114579288 A CN 114579288A
- Authority
- CN
- China
- Prior art keywords
- command
- task
- hardware
- coprocessor
- processing unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Advance Control (AREA)
Abstract
The application belongs to the technical field of chips, and discloses a task processing method, a task processing device and computer equipment, wherein the method comprises the following steps of applying the task processing device in the computer equipment, wherein the task processing device comprises a coprocessor and a hardware function module, the computer equipment also comprises a central processing unit, and the method comprises the following steps: the coprocessor calls a device driving subprogram arranged on the coprocessor and sends a hardware operation command to the hardware function module based on the task command when the task command sent by the central processing unit is determined to be received; the hardware function module executes the received hardware operation command and returns an operation execution result to the coprocessor when the command execution is determined to be finished; and the coprocessor is used for sending a command execution result to the central processing unit based on the received operation execution result. Therefore, the resource consumption of the central processing unit can be reduced, and the performance of the equipment can be improved.
Description
Technical Field
The present application relates to the field of chip technologies, and in particular, to a method and an apparatus for task processing, and a computer device.
Background
Computer devices typically require the execution of task commands by device drivers driving hardware functional modules. The device driver is usually disposed in a central processing unit of the computer device, and is configured to control the hardware functional module to perform a corresponding operation based on the received task command, and return an execution result to the user.
In the prior art, a central processing unit generally calls a device driver to send a hardware operation command to a hardware function module based on a task command issued by a user. The hardware function module executes the hardware operation command and returns the command execution result to the central processing unit.
Since the central processing unit generally needs to call the device driver, generate each task command, generate a plurality of corresponding hardware operation commands, send each hardware operation command to the hardware function module, and receive the execution result of each hardware operation command executed by the hardware function module, a large amount of central processing unit resources are consumed for task command processing, hardware operation command sending, and execution result receiving, and thus the device performance is low.
Disclosure of Invention
An object of the embodiments of the present application is to provide a method and an apparatus for task processing, and a computer device, so as to reduce consumption of central processing unit resources and improve device performance when a task is processed by a hardware function module.
In a first aspect, a method for processing a task is provided, which is applied to a task processing apparatus in a computer device, where the task processing apparatus includes a coprocessor and a hardware function module, the computer device further includes a central processing unit, and the method includes:
the coprocessor calls a device driving subprogram arranged on the coprocessor and sends a hardware operation command to the hardware function module based on the task command when the task command sent by the central processing unit is determined to be received;
the hardware function module executes the received hardware operation command and returns an operation execution result to the coprocessor when the command execution is determined to be completed;
and the coprocessor is used for sending a command execution result to the central processing unit based on the received operation execution result.
In the implementation process, the coprocessor in the task processing device is used for processing the task command, transmitting the hardware operation command and receiving and summarizing the operation execution result, and the central processing unit and the task processing device are only required to transmit the task command and the command execution result, so that the load of the central processing unit is greatly reduced, and the performance of the system is improved.
In one embodiment, receiving a task command sent by a central processing unit includes: and when determining that a user interrupt request sent by the central processing unit is received, acquiring a task command based on the user interrupt request.
In one embodiment, if the task command is a non-cyclic command type, based on the task command, invoking a device driver subroutine set on the coprocessor, and sending a hardware operation command to the hardware function module, the method includes: determining a hardware functional module matched with the task command from at least one hardware functional module of the task processing device; and based on the task command, calling a device driver subprogram corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module.
In one embodiment, if the task command is a circular command type, based on the task command, invoking a device driver subroutine configured on the coprocessor, and sending a hardware operation command to the hardware function module, the method includes:
determining a hardware functional module matched with the task command from at least one hardware functional module of the task processing device;
circularly executing the following steps until the execution of the task command is completed:
based on the task command, calling a device driver subprogram corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module;
receiving an operation execution result returned after the matched hardware function module executes at least one hardware operation command;
and judging whether the execution of the task command is completed or not based on the operation execution result.
In one embodiment, if there are a plurality of matched hardware functional modules, based on a task command, invoking a device driver subroutine corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module, the method includes: generating task subcommands corresponding to the matched hardware functional modules based on the task commands; and calling the device driving subprogram corresponding to each matched hardware functional module based on each task subcommand, and respectively sending at least one hardware operation command to each matched hardware functional module.
In one embodiment, sending the command execution result to a central processor based on the received operation execution result comprises: when the operation execution result is determined to be received, generating a command execution result based on the operation execution result; and sending the command execution result to the central processing unit by adopting an interrupt request mode.
In one embodiment, the central processing unit is provided with a device driver subroutine, and the device driver subroutine in the central processing unit and the device driver subroutine in the coprocessor are both obtained based on the device driver, and the method further includes:
a hardware functional module for executing the following steps:
when determining that a hardware operation command sent by a central processing unit is received, executing the hardware operation command, wherein the hardware operation command is sent by the central processing unit calling a device driving subprogram in the central processing unit based on a task command of a specified type;
and when the command execution is determined to be completed, returning a command execution result to the central processing unit in an interrupt request mode.
In one embodiment, the method further comprises:
the coprocessor receives a drive installation instruction which is sent by the central processing unit and contains drive configuration information, and installs an equipment drive subprogram based on the drive configuration information contained in the drive installation instruction, wherein the drive installation instruction is sent when the central processing unit determines that the drive installation condition is met;
or the coprocessor receives the operating system containing the device driver subprogram sent by the central processing unit and starts the operating system, so that the device driver subprogram is self-started in the coprocessor.
In a second aspect, a task processing device in a computer device is provided, where the task processing device includes a coprocessor and a hardware functional module, and the computer device further includes a central processing unit;
the coprocessor is used for calling a device driving subprogram arranged on the coprocessor and sending a hardware operation command to the hardware functional module based on the task command when the task command sent by the central processing unit is determined to be received;
the hardware function module is used for executing the received hardware operation command and returning an operation execution result to the coprocessor when the command execution is determined to be finished;
the coprocessor is also used for sending a command execution result to the central processing unit based on the received operation execution result.
In one embodiment, the coprocessor is further configured to: and when determining that a user interrupt request sent by the central processing unit is received, acquiring a task command based on the user interrupt request.
In one embodiment, if the task command is a non-cyclic command type, the coprocessor is further configured to:
determining a hardware functional module matched with the task command from at least one hardware functional module of the task processing device;
and based on the task command, calling a device driver subprogram corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module.
In one embodiment, the coprocessor is further configured to:
if the task command is of a cyclic command type, determining a hardware function module matched with the task command from at least one hardware function module of the task processing device;
circularly executing the following steps until the execution of the task command is completed:
based on the task command, calling a device driver subprogram corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module;
receiving an operation execution result returned after the matched hardware function module executes at least one hardware operation command;
and judging whether the execution of the task command is completed or not based on the operation execution result.
In one embodiment, the coprocessor is further configured to: if the number of the matched hardware functional modules is multiple, generating task subcommands corresponding to the matched hardware functional modules based on the task command; and calling the device driving subprogram corresponding to each matched hardware functional module based on each task subcommand, and respectively sending at least one hardware operation command to each matched hardware functional module.
In one embodiment, the coprocessor is further configured to: when the operation execution result is determined to be received, generating a command execution result based on the operation execution result; and sending the command execution result to the central processing unit by adopting an interrupt request mode.
In one embodiment, the central processing unit is provided with a device driver subroutine, the device driver subroutine in the central processing unit and the device driver subroutine in the coprocessor are both obtained based on the device driver, and the hardware functional module is configured to: when determining that a hardware operation command sent by a central processing unit is received, executing the hardware operation command, wherein the hardware operation command is sent by the central processing unit calling a device driving subprogram in the central processing unit based on a task command of a specified type; and when the command execution is determined to be completed, returning a command execution result to the central processing unit in an interrupt request mode.
In one embodiment, the coprocessor is configured to: receiving a drive installation instruction which is sent by a central processing unit and contains drive configuration information, and installing an equipment drive subprogram based on the drive configuration information contained in the drive installation instruction, wherein the drive installation instruction is sent when the central processing unit determines that the drive installation condition is met; or receiving an operating system containing the device driver subprogram sent by the central processing unit, and starting the operating system so as to enable the device driver subprogram to be self-started in the coprocessor.
In a third aspect, a computer device is provided, which includes a central processing unit and a task processing apparatus;
the central processing unit is used for sending a task command to the task processing device;
and the task processing device is used for executing the task command by adopting the task processing method of the first aspect and returning the command execution result to the central processing unit.
In one embodiment, the central processor is configured to: if the task command is determined to be of the non-specified type, the task command is sent to a task processing device;
the central processing unit is further configured to: if the task command is determined to be of the designated type, calling a device driving subprogram in the central processing unit based on the task command, and sending a hardware operation command to a hardware function module of the task processing device;
the hardware functional module is used for: and when determining that the hardware operation command sent by the central processing unit is received, executing the hardware operation command, and when determining that the command execution is completed, returning a command execution result generated based on the hardware operation command to the central processing unit in an interrupt request mode.
In one embodiment, the central processor is further configured to: when the condition that the installation of the driver is met is determined, a driver installation instruction containing driver configuration information is sent to a coprocessor in the task processing device, and the driver configuration information is used for providing a driver subprogram of coprocessor installation equipment in the task processing device; or sending the operating system containing the device driver subprogram to the coprocessor, so that the device driver subprogram can be self-started in the process of starting the operating system by the coprocessor.
In one embodiment, the drive mounting condition includes any one of the following conditions: equipment initialization, driver upgrade and hardware functional module addition.
Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.
Fig. 1 is a schematic structural diagram of a computer device 100 according to an embodiment of the present application;
FIG. 2 is a flowchart of a method 200 for task processing according to an embodiment of the present disclosure;
fig. 3 is a block diagram of a task processing device 300 according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.
It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not construed as indicating or implying relative importance.
First, some terms referred to in the embodiments of the present application will be described to facilitate understanding by those skilled in the art.
The terminal equipment: may be a mobile terminal, a fixed terminal, or a portable terminal such as a mobile handset, station, unit, device, multimedia computer, multimedia tablet, internet node, communicator, desktop computer, laptop computer, notebook computer, netbook computer, tablet computer, personal communication system device, personal navigation device, personal digital assistant, audio/video player, digital camera/camcorder, positioning device, television receiver, radio broadcast receiver, electronic book device, gaming device, or any combination thereof, including the accessories and peripherals of these devices, or any combination thereof. It is also contemplated that the terminal device can support any type of interface to the user (e.g., wearable device), and the like.
A server: the cloud server can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing basic cloud computing services such as cloud service, a cloud database, cloud computing, cloud functions, cloud storage, network service, cloud communication, middleware service, domain name service, security service, big data and artificial intelligence platform and the like.
The following briefly introduces the design concept of the embodiments of the present application:
hardware functional modules (e.g., a mouse) in a computer device (e.g., a computer) usually require a corresponding device driver to operate properly. The device driver provides a software interface for a user to use the hardware function module, receives a user command through the software interface, controls the drive hardware function module to execute the user command, and sends a command execution result to the user through the software interface.
In a conventional manner, a centralized device driver architecture is usually adopted, that is, a device driver is completely installed in a central processing unit of a computer device, and the central processing unit is responsible for processing all transactions in a working process of a hardware function module, including processing a user command and processing a device interrupt. Specifically, the central processing unit generally calls the device driver to send a hardware operation command to the hardware function module based on a task command issued by the user. After the hardware function module executes the hardware operation command, the hardware function module triggers the device interrupt to inform the central processing unit of the completion of the command execution. The central processing unit stops other works to carry out interrupt processing, obtains a command execution result of the hardware function module, sends the command execution result to a user, and continues to carry out work before interrupt processing after the interrupt processing is finished.
However, in an application scenario with a very large hardware device throughput, a very large number of user commands and device interrupts are generated per second and need to be processed by the central processing unit, which consumes a large amount of central processing unit resources and even occupies the central processing unit resources, thereby causing the whole system to be stuck.
In one example, for a hardware Video codec Unit (as a hardware functional module) in an artificial intelligence accelerator card, the hardware Video codec Unit (VPU) can support 256-way 1080p 30FPS decoding, and the artificial intelligence accelerator card can output 7680 frames of Video frames per second. Statistically, since 10 task commands and handling 10 device interrupts are required to be sent per frame of video, the central processor needs to send 76800 task commands and handle 76800 device interrupts to the artificial intelligence accelerator card every second. On an 8-card server (as a computer device), task commands which need to be sent by a central processing unit and device interrupts which need to be processed reach 614400 per second. Obviously, this places a considerable burden on the central processing unit, severely affects the execution of other tasks on the server (i.e., the device on which the central processing unit resides), and may cause system performance degradation due to the central processing unit being overburdened.
Based on this, the distributed device driver architecture is adopted to replace the centralized device driver architecture, that is, the device driver completely running by the central processing unit can be split according to the hardware function modules, corresponding coprocessors are respectively configured for each hardware function module, and the device driver subprograms of part or all of the hardware function modules are distributed to different coprocessors, and the coprocessors containing the device driver subprograms process the transactions in the working process of the hardware function modules. The embodiment of the application provides a task processing method and device and computer equipment, and can reduce the load of a central processing unit, reduce the consumed central processing unit resources, improve the overall processing capacity of a system and fully exert the performance of hardware equipment in a scene with high throughput of the hardware equipment.
Fig. 1 is a schematic structural diagram of a computer device 100 according to an embodiment of the present disclosure. The computer apparatus 100 includes a central processor 101 and a task processing device 102.
Optionally, the computer device 100 may be a server or a terminal device, and is not limited herein.
The central processing unit 101: which is a host CPU of the computer apparatus 100, for sending a task command to the coprocessor 103 in the task processing device 102 and receiving a command execution result returned by the coprocessor 103 based on the task command.
Optionally, the central processing unit 101 may further be provided with a device driver subprogram, and the device driver subprogram is invoked to generate a hardware operation command based on a task command issued by a user, send the generated hardware operation command to a hardware function module in the task processing device 102, and receive a command execution result returned by the hardware function module 104.
Wherein the hardware operation command is one or more commands generated by the device driver subprogram based on the task command.
In this way, the central processing unit can send part of task commands (e.g. complex commands) to the coprocessor, drive the hardware functional modules to execute the task commands through the coprocessor, and can also directly control the hardware functional modules to execute part of the commands (e.g. simple commands).
The task processing device 102: the coprocessor 103 and the hardware function module 104 are used for executing a task command or a hardware operation command issued by the central processing unit 101 and returning a command execution result to the central processing unit 101.
Among other things, one or more task processing devices 102 may be included in the computer apparatus 100. One or more coprocessors 103 may be included in each task processing device 102. Each coprocessor 103 may run one or more device driver subroutines based on the performance of coprocessor 103 and the actual requirements. Each device driver subroutine may control one or more hardware functional modules 104. Any two device driver subroutines in each task processing device 102 may be the same or different. Any two hardware functional modules 104 in each task processing device 102 may be the same or different. Since the device driver subroutine is for driving the hardware functional module 104, the device driver subroutine executed by each coprocessor 103 in the task processing apparatus 102 is determined by the hardware functional module 104 in the task processing apparatus 102. Different coprocessors 103 can run their own device driver subroutines respectively without mutual influence.
In one embodiment, different device driver subroutines within the same task processing device 102 may control different types of hardware functional modules 104. The types of the hardware functional modules 104 may be divided according to functions, and each type of the hardware functional modules 104 may be one or more.
The coprocessor 103: a processor in the computer device 100, except for the central processing unit 101, is used for controlling one or more hardware functional modules 104 correspondingly connected through a device driver subroutine executed by the processor.
In one embodiment, the coprocessor 103 receives a task command sent by the central processing unit 101, invokes a device driver subroutine running by itself, sends a hardware operation command to the hardware function module 104 based on the task command, receives an operation execution result returned after the hardware function module 104 executes the hardware operation command, generates a command execution result based on the received operation execution result, and sends the command execution result to the central processing unit 101.
There may be one or more communication channels for each task processing device 102. Coprocessor 103 communicates with central processor 101 over a communication channel.
Since each coprocessor 103 typically requires a separate communication channel to communicate with the central processor 101, the number of communication channels in each task processing device 102 is typically not lower than the number of coprocessors 103.
Alternatively, the communication channel may be simplex or duplex. In order to improve the system performance, in practical applications, the communication channel usually adopts duplexing. The different communication channels are completely independent of each other, can work simultaneously and do not affect each other.
The communication channel may support interrupts, such as bidirectional interrupts, that is, coprocessor 103 may send an interrupt request to central processor 101, and central processor 101 may also send an interrupt request to coprocessor 103. The operating system in coprocessor 103 may be the same as or different from the operating system in central processor 101.
Hardware functional module 104: and the coprocessor 103 is used for receiving a hardware operation command sent by a driver subprogram in the coprocessor 103 based on a task command of a non-specified type, executing the received hardware operation command, returning an operation execution result to the coprocessor 103, generating a command execution result based on the operation execution result through the coprocessor 103, and returning the command execution result to the central processing unit 101.
Optionally, the hardware functional module 104 may further receive a hardware operation command sent by the central processing unit 101 based on the task command of the specified type, execute the received hardware operation command, and return a command execution result generated based on the hardware operation command to the central processing unit 101.
Alternatively, the specified type may be a simple type. In practical applications, the specified type may be set according to practical application scenarios, and is not limited herein.
In one embodiment, the device driver subroutines in central processor 101 and coprocessor 103 are both obtained based on the device driver. Any device driver subprogram may be the device driver itself, or may be a subprogram for implementing part of the functions in the device driver.
In one embodiment, the device driver is divided into a plurality of device driver subroutines according to the hardware functional modules 104 in the task processing devices 102, and each device driver subroutine is installed in each coprocessor 103 of each task processing device 102. The central processing unit 101 may invoke the device driver subroutine through the coprocessor 103, and control the corresponding hardware functional module 104 to execute the task command.
In one embodiment, the central processing unit 101 may directly control the corresponding hardware functional module 104 to execute a task command of a simple type (i.e., a specified type) through a device driver subroutine executed by the central processing unit, and may also control the corresponding hardware functional module 104 to execute a task command of a complex type (i.e., a non-specified type) through the coprocessor 103 calling the device driver subroutine.
The method for processing the task provided by the embodiment of the application can be executed by the central processing unit 101 and the task processing device 102 in the computer device 100.
Referring to fig. 2, a flowchart of a method 200 for task processing according to an embodiment of the present application is shown, where the method may be performed by a task processing device, for example, the task processing device in the computer device shown in fig. 1. In the following, a method for processing tasks will be described with reference to the architecture shown in fig. 1, where the method may be implemented in a specific flow including:
step 201: and when the coprocessor determines to receive a task command sent by the central processing unit, calling a device driving subprogram set on the coprocessor based on the task command, and sending a hardware operation command to the hardware function module.
Specifically, when step 201 is executed, the following steps may be adopted:
s2011: the central processing unit sends a task command to the coprocessor in the task processing device.
Specifically, if there are multiple task processing devices in the computer device, the central processing unit determines a hardware function module matched with the task command, determines a coprocessor corresponding to the matched hardware function module, and sends the task command to the coprocessor.
Each task processing device at least comprises a hardware functional module, and the hardware functional modules in different task processing devices can be the same or different. The same hardware functional modules may be located in different task processing device modules, or may be located in the same task processing device. Each coprocessor is used for controlling one or more hardware functional modules, namely each coprocessor and at least one hardware functional module have a corresponding relation.
In one embodiment, when determining the hardware functional module matched with the task command, the following steps may be adopted:
and the central processing unit acquires the module identification information contained in the task command and determines the hardware functional module corresponding to the module identification information as a matched hardware functional module.
In practical applications, the hardware functional module that matches the task command may also be determined in other manners, which is not limited herein.
In one embodiment, when sending a task command to the coprocessor, the following steps may be adopted:
the central processor sends a task command to the coprocessor by adopting an interrupt request mode through a communication channel.
Specifically, the central processing unit stores the task command to a set command reading address, and sends a user interrupt request to the coprocessor through the communication channel, so that the coprocessor can read the task command from the set command reading address after receiving the user interrupt request.
Wherein, the command reading address is preset.
In practical applications, other command transmission modes may be adopted according to practical application scenarios, and are not limited herein.
S2012: the coprocessor receives a task command sent by the central processing unit.
Specifically, when determining that a user interrupt request sent by the central processing unit is received, the coprocessor acquires a task command based on the user interrupt request.
S2013: the coprocessor calls a device driver subprogram set on the coprocessor and sends a hardware operation command to the hardware functional module based on the task command.
Specifically, when S2013 is executed, any one of the following manners may be adopted:
mode 1: if the task command is a non-cyclic command type, the coprocessor determines a hardware function module matched with the task command from at least one hardware function module of the task processing device, calls a device driver subprogram corresponding to the matched hardware function module based on the task command, and sends at least one hardware operation command to the matched hardware function module.
Based on the task command, calling the device driver subprogram corresponding to the matched hardware functional module, and when sending at least one hardware operation command to the matched hardware functional module, adopting the following mode:
in one embodiment, the coprocessor sends a task command to the device driver subroutine corresponding to the matched hardware functional module. The device driver subprogram executes the task command, generates at least one hardware operation command, and sends the generated hardware operation command to the matched hardware functional module.
In one embodiment, the coprocessor generates at least one driving control command based on the task command, and sends each driving control command to the device driving subprogram corresponding to the matched hardware functional module. And each device driver subprogram respectively generates at least one hardware operation command corresponding to each drive control command and sends the generated hardware operation command to the matched hardware functional module.
In one embodiment, if there are a plurality of matched hardware function modules, based on the task command, a task sub-command corresponding to each matched hardware function module is generated, and based on each task sub-command, a device driver sub-program corresponding to each matched hardware function module is called, and at least one hardware operation command is sent to each matched hardware function module.
The task command may be a relatively complex command, that is, the same hardware function module may be required to execute the same or different operation combinations for multiple times, or a plurality of different hardware function modules are required to execute different operation combinations, respectively.
Alternatively, the different task subcommands may be executed in parallel or sequentially, and are not limited herein.
Mode 2: if the task command is of a circular command type, circularly calling a device driving subprogram set on the coprocessor based on the task command, and sending a hardware operation command to the hardware function module until the command execution is determined to be completed.
Specifically, in the implementation of the method 2, the coprocessor may adopt the following steps:
s20131: and determining the hardware functional module matched with the task command from at least one hardware functional module of the task processing device.
S20132: and based on the task command, calling a device driver subprogram corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module.
S20133: and receiving an operation execution result returned after the matched hardware functional module executes at least one hardware operation command.
In one embodiment, after a hardware functional module completes a hardware operation command each time, an interrupt request is adopted to return an operation execution result corresponding to the hardware operation command to a coprocessor. And the coprocessor receives operation execution results corresponding to the hardware operation commands respectively.
In one embodiment, after determining that each hardware operation command is executed, the hardware function module obtains an operation execution result corresponding to each hardware operation command, and returns the operation execution result to the coprocessor by using an interrupt request. And the coprocessor receives the execution result of the operation corresponding to each hardware operation command.
S20134: and judging whether the execution of the task command is finished or not based on the operation execution result, if so, executing S20135, and otherwise, executing S20132.
In one embodiment, if it is determined that the loop execution is required to be performed n times based on the task command, it is determined whether the loop execution is required to be performed n times, if so, S20135 is performed, and otherwise, S20132-S20133 are performed. Wherein n is a positive integer.
S20135: and ending the circulation flow of the task command.
When the method 2 is executed, the specific steps refer to the specific implementation of the method 1, which is not described herein again.
This is because the task command may be a command that requires multiple cycles of execution, and the coprocessor may call a loop program for executing the task command to loop one or more hardware functional modules multiple times to repeatedly execute a certain set of operations.
For example, if the job command is to print 10 newspapers, and the single-pass printing program can control the printer to print only one newspaper, then the loop printing program is run, and 10 times of the single-pass printing program are called in a loop to print 10 newspapers.
Optionally, the coprocessor may directly or indirectly obtain the device driver subprogram when the driver installation condition is met. The device driver subroutines may be available, for example, via a central processor. In some embodiments, if the storage capacity of the coprocessor is sufficient, the device driver subroutine may be loaded to the storage location corresponding to the coprocessor in other ways.
As an embodiment, the coprocessor may install the device driver subroutine when it is determined that the driver installation condition is satisfied. For example, upon determining that the coprocessor meets the driver installation condition, the central processor may send a driver installation instruction containing driver configuration information to the coprocessor in the task processing device. The coprocessor can receive a drive installation instruction which is sent by the central processing unit and contains drive configuration information, and install the device drive subprogram based on the drive configuration information contained in the drive installation instruction.
Wherein the driver configuration information is used to install the device driver sub-program. The drive installation instruction is sent when the central processing unit determines that the drive installation condition is met.
The drive mounting condition may include, but is not limited to, any one of the following conditions: equipment initialization, driver upgrade and hardware functional module addition.
Alternatively, the driver configuration information may be a Firmware file designed for hardware functional modules supported by the coprocessor. The drive configuration information may include: information for an operating system (e.g., Linux) running on the coprocessor, and one or more device driver subroutines for driving the corresponding hardware functional modules. Alternatively, only the content in the Firmware file may be updated when the drive configuration information is updated.
Illustratively, when determining that the driver installation condition is met, the central processing unit determines a hardware function module connected to the coprocessor, acquires driver configuration information corresponding to the hardware function module, and sends a driver installation instruction including the driver configuration information to the coprocessor in the task processing device, so that the coprocessor loads a device driver subroutine.
In an application scenario, when the computer device is powered off and restarted, the computer device can be regarded as conforming to the driver installation condition, and the central processing unit can send a driver installation instruction containing driver configuration information to the coprocessor in the task processing device.
In another application scenario, the central processing unit determines the driver upgrade, acquires (e.g., downloads and copies) a driver upgrade file, acquires driver configuration information based on the driver upgrade file, and sends a driver installation instruction including the driver configuration information to the coprocessor in the task processing device.
In another application scenario, if it is determined that a new hardware functional module is added (i.e., assembled) to the computer device, the driver configuration information of the new hardware functional module is obtained, a coprocessor corresponding to the new hardware functional module is determined, and a driver installation instruction including the driver configuration information is sent to the determined coprocessor.
As another embodiment, the coprocessor may also directly start the operating system including the device driver subprogram, instead of using the installation process in the above embodiment, so as to implement that the device driver subprogram is self-started in the coprocessor.
The central processing unit may send an operating system including a device driver subroutine to the coprocessor in the task processing apparatus, and the content sent by the central processing unit may also be provided in the form of a Firmware file. The coprocessor can receive an operating system containing the device driver subprogram sent by the central processing unit and start the operating system, so that the device driver subprogram can be self-started in the coprocessor.
When the task needs to be executed, the coprocessor can call the device driver subprogram to send a hardware operation command to the matched hardware functional module.
Step 202: and the hardware functional module executes the received hardware operation command and returns an operation execution result to the coprocessor when the command execution is determined to be completed.
In one embodiment, after a hardware functional module completes one hardware operation command each time, an operation execution result corresponding to the hardware operation command is returned to the coprocessor in an interrupt request manner. And the coprocessor receives operation execution results corresponding to the hardware operation commands respectively.
In one embodiment, after determining that each hardware operation command is executed, the hardware function module obtains an operation execution result executed by each hardware operation command, and returns the operation execution result to the coprocessor by using an interrupt request. And the coprocessor receives the execution result of the operation corresponding to each hardware operation command.
Step 203: the coprocessor sends a command execution result to the central processing unit based on the received operation execution result.
Specifically, when step 203 is executed, the coprocessor may adopt the following steps:
s2031: and when the operation execution result is determined to be received, generating a command execution result based on the operation execution result.
If the operation execution result is the operation execution result corresponding to at least one hardware operation command, each operation execution result can be analyzed to generate a command execution result.
If the operation execution result is an operation execution result corresponding to at least one hardware operation command, the operation execution result may be used as a command execution result.
S2032: and sending the command execution result to the central processing unit by adopting an interrupt request mode.
In one embodiment, the coprocessor stores the command execution result to a set result reading address and sends a result interrupt request to the central processing unit using a communication channel. And after determining that the result interrupt request is received, the central processing unit reads the command execution result from the result reading address.
Furthermore, the central processing unit can also call a device driver subprogram operated by the central processing unit based on the task command, and directly send a hardware operation command to one or more hardware functional modules in the task processing device.
In one embodiment, the central processing unit calls a device driver subroutine in the central processing unit based on a task command of a specified type, and sends at least one hardware operation command to at least one hardware function module matched with the task command respectively. And the hardware function module executes the received hardware operation command when determining that the hardware operation command sent by the central processing unit is received, and returns a command execution result to the central processing unit in a result interrupt request mode when determining that the command execution is finished.
If the hardware supporting 256 paths of 1080p 30FPS decoding is processed in a traditional mode, the central processing unit needs to be specifically responsible for controlling the work of a hardware video coding and decoding unit, 76800 task commands need to be sent to the artificial intelligence accelerator card every second, and 76800 device interrupts are processed. When the task processing method provided by the embodiment of the application is adopted, the central processing unit does not need to be particularly responsible for driving and controlling the work of the hardware video coding and decoding unit, and in an experimental scene, 15360 task commands are sent to the equipment every second to process 15360 equipment interrupts. Thus, the consumption of the resources of the central processing unit is greatly reduced.
In the conventional method, only a device driver is run in a central processing unit, the central processing unit calls the device driver running by the central processing unit based on a task command to generate a hardware operation command, sends the hardware operation command to a hardware function module, and receives a command execution result returned after the hardware function module executes the hardware operation command, each task command usually requires the hardware function module to execute a series of hardware operations, and therefore the central processing unit usually needs to generate a plurality of hardware operation commands for controlling the hardware function module to execute a series of hardware operations respectively for each task command. Furthermore, if the task command is a relatively complex command (e.g., a cyclic command), the central processing unit needs to decompose the task command into a plurality of task subcommands, and send a hardware operation command to different hardware functional modules based on each task subcommand, and receive a command execution result corresponding to each task subcommand returned by the hardware functional modules. Obviously, the generation and transmission of a large number of hardware operation commands, and the processing of interrupt requests, consume a large amount of processing resources of the central processing unit.
In the embodiment of the present application, the device driver is decomposed into device driver subroutines corresponding to the hardware function modules according to the hardware function modules, and the device driver subroutines are distributed on the central processing unit and the coprocessor corresponding to each hardware function module. Therefore, the central processing unit only needs to manage part of the hardware function modules (such as the hardware function modules with low throughput), and only needs to send the task command to the coprocessor and receive the command execution result of the task command returned by the coprocessor, and does not need to perform task command processing, hardware operation command transmission and operation execution result receiving and summarizing on all the hardware function modules, so that the hardware capability can be fully utilized, the load of the central processing unit is greatly reduced, and the performance of the system is improved. Moreover, the central processing unit sends a task command to the coprocessor in an interrupt request mode and receives a command execution result returned by the coprocessor in an interrupt request mode, and the consumption of central processing unit resources is further reduced by the bidirectional interrupt processing.
Based on the same inventive concept, the embodiment of the application also provides a task processing device.
As shown in fig. 3, fig. 3 is a schematic structural diagram of a task processing apparatus 300 in a computer device according to an embodiment of the present disclosure, where the task processing apparatus 300 includes a coprocessor 301 and a hardware functional module 302, and the computer device further includes a central processing unit;
the coprocessor 301 is configured to call a device driver subroutine set in the coprocessor 301 based on a task command when determining that the task command sent by the central processing unit is received, and send a hardware operation command to the hardware function module 302;
a hardware function module 302, configured to execute the received hardware operation command, and return an operation execution result to the coprocessor 301 when it is determined that the command execution is completed;
the coprocessor 301 is further configured to send a command execution result to the central processor based on the received operation execution result.
In one embodiment, coprocessor 301 is further configured to: and when determining that a user interrupt request sent by the central processing unit is received, acquiring a task command based on the user interrupt request.
In one embodiment, if the task command is a non-cyclic command type, the coprocessor 301 is further configured to: determining a hardware functional module 302 matched with the task command from at least one hardware functional module 302 of the task processing device 300; based on the task command, the device driver subroutine corresponding to the matched hardware functional module 302 is called, and at least one hardware operation command is sent to the matched hardware functional module 302.
In one embodiment, coprocessor 301 is configured to: if the task command is a cyclic command type, determining a hardware functional module 302 matched with the task command from at least one hardware functional module 302 of the task processing device 300; circularly executing the following steps until the execution of the task command is completed: based on the task command, calling a device driver subroutine corresponding to the matched hardware functional module 302, and sending at least one hardware operation command to the matched hardware functional module 302; receiving an operation execution result returned after the matched hardware functional module 302 executes at least one hardware operation command; and judging whether the execution of the task command is completed or not based on the operation execution result.
In one embodiment, coprocessor 301 is further configured to: if a plurality of matched hardware functional modules 302 are provided, generating a task subcommand corresponding to each matched hardware functional module 302 based on the task command; based on each task subcommand, a device driver subroutine corresponding to each matched hardware functional module 302 is called, and at least one hardware operation command is sent to each matched hardware functional module 302.
In one embodiment, coprocessor 301 is further configured to: when the operation execution result is determined to be received, generating a command execution result based on the operation execution result; and sending the command execution result to the central processing unit by adopting an interrupt request mode.
In one embodiment, the central processing unit is provided with a device driver subroutine, the device driver subroutine in the central processing unit and the device driver subroutine in the coprocessor 301 are both obtained based on the device driver, and the hardware function module 302 is configured to: when determining that a hardware operation command sent by a central processing unit is received, executing the hardware operation command, wherein the hardware operation command is sent by the central processing unit calling a device driving subprogram in the central processing unit based on a task command of a specified type; and when the command execution is determined to be completed, returning a command execution result to the central processing unit in an interrupt request mode.
In one embodiment, coprocessor 301 is configured to: receiving a drive installation instruction which is sent by a central processing unit and contains drive configuration information, and installing an equipment drive subprogram based on the drive configuration information contained in the drive installation instruction, wherein the drive installation instruction is sent when the central processing unit determines that a drive installation condition is met; or, the operating system containing the device driver subprogram sent by the central processing unit is received, and the operating system is started, so that the device driver subprogram is self-started in the coprocessor 301.
Since the principle of solving the problem and the resulting effect of the task processing device are similar to those of the task processing method, for the sake of brief description, no mention is made in the device embodiment, and reference may be made to the corresponding contents in the method embodiment, which is not described herein again.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, electronic device, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (13)
1. A method for processing tasks, which is applied to a task processing device in a computer device, wherein the task processing device comprises a coprocessor and a hardware functional module, the computer device further comprises a central processing unit, and the method comprises the following steps:
the coprocessor calls a device driver subprogram set on the coprocessor and sends a hardware operation command to the hardware functional module based on the task command when determining that the task command sent by the central processing unit is received;
the hardware function module executes the received hardware operation command and returns an operation execution result to the coprocessor when the command execution is determined to be completed;
and the coprocessor is used for sending a command execution result to the central processing unit based on the received operation execution result.
2. The method of claim 1, wherein said receiving a task command sent by said central processor comprises:
and when the user interrupt request sent by the central processing unit is determined to be received, acquiring the task command based on the user interrupt request.
3. The method of claim 1, wherein if the task command is a non-cyclic command type, the invoking a device driver subroutine set on the coprocessor based on the task command to send a hardware operation command to the hardware function module comprises:
determining a hardware functional module matched with the task command from at least one hardware functional module of the task processing device;
and calling a device driving subprogram corresponding to the matched hardware functional module based on the task command, and sending at least one hardware operation command to the matched hardware functional module.
4. The method of claim 1, wherein if the task command is a cyclic command type, the invoking a device driver subroutine set on the coprocessor based on the task command to send a hardware operation command to the hardware function module comprises:
determining a hardware functional module matched with the task command from at least one hardware functional module of the task processing device;
circularly executing the following steps until the task command execution is completed:
based on the task command, calling a device driver subprogram corresponding to the matched hardware functional module, and sending at least one hardware operation command to the matched hardware functional module;
receiving an operation execution result returned after the matched hardware function module executes the at least one hardware operation command;
and judging whether the task command is executed completely or not based on the operation execution result.
5. The method according to claim 3 or 4, wherein if there are a plurality of matched hardware functional modules, the invoking a device driver subroutine corresponding to the matched hardware functional module based on the task command, and sending at least one hardware operation command to the matched hardware functional module includes:
generating task subcommands corresponding to the matched hardware functional modules based on the task commands;
and calling the device driving subprogram corresponding to each matched hardware functional module based on each task subcommand, and respectively sending at least one hardware operation command to each matched hardware functional module.
6. The method of any of claims 1-4, wherein said sending a command execution result to the central processor based on the received operation execution result comprises:
generating the command execution result based on the operation execution result;
and sending the command execution result to the central processing unit by adopting an interrupt request mode.
7. The method of any of claims 1-4, wherein a device driver subroutine is provided on the central processor, the device driver subroutine in the central processor and the device driver subroutine in the coprocessor are both obtained based on the device driver, the method further comprising: the hardware functional module executes the following steps:
when determining that a hardware operation command sent by the central processing unit is received, executing the hardware operation command, wherein the hardware operation command is sent by the central processing unit calling a device driver subprogram in the central processing unit based on a task command of a specified type;
and when the command execution is determined to be completed, returning a command execution result to the central processing unit in an interrupt request mode.
8. The method of any one of claims 1-4, further comprising:
the coprocessor receives a drive installation instruction which is sent by the central processing unit and contains drive configuration information, and installs an equipment drive subprogram based on the drive configuration information contained in the drive installation instruction, wherein the drive installation instruction is sent when the central processing unit determines that a drive installation condition is met;
or the coprocessor receives an operating system which is sent by the central processing unit and contains the device driver subprogram, and starts the operating system, so that the device driver subprogram is self-started in the coprocessor.
9. A task processing device in computer equipment is characterized in that the task processing device comprises a coprocessor and a hardware functional module, and the computer equipment also comprises a central processing unit;
the coprocessor is used for calling a device driver subprogram set on the coprocessor and sending a hardware operation command to the hardware function module based on the task command when the task command sent by the central processing unit is determined to be received;
the hardware function module is used for executing the received hardware operation command and returning an operation execution result to the coprocessor when the command execution is determined to be completed;
the coprocessor is also used for sending a command execution result to the central processing unit based on the received operation execution result.
10. A computer device is characterized by comprising a central processing unit and a task processing device;
the central processing unit is used for sending a task command to the task processing device;
the task processing device is used for executing the task command by adopting the method of any one of claims 1 to 8 and returning the execution result of the command to the central processing unit.
11. The computer device of claim 10, wherein the central processor is to: if the task command is determined to be of a non-specified type, sending the task command to the task processing device;
the central processing unit is further configured to: if the task command is determined to be of the specified type, calling a device driving subprogram in the central processing unit based on the task command, and sending a hardware operation command to a hardware function module in the task processing device;
the hardware functional module is used for: and when the hardware operation command sent by the central processing unit is determined to be received, executing the hardware operation command, and when the command execution is determined to be completed, returning a command execution result generated based on the hardware operation command to the central processing unit in an interrupt request mode.
12. The computer device of claim 10 or 11, wherein the central processor is further configured to:
when determining that the installation condition of the driver is met, sending a driver installation instruction containing driver configuration information to a coprocessor in the task processing device, wherein the driver configuration information is used for providing a driver subprogram of coprocessor installation equipment in the task processing device;
or sending an operating system containing a device driver subprogram to the coprocessor to enable the device driver subprogram to be self-started in the process that the coprocessor starts the operating system.
13. The computer apparatus of claim 12, wherein the drive mounting condition includes any one of the following conditions: equipment initialization, driver upgrade and hardware functional module addition.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210495716.8A CN114579288B (en) | 2022-05-09 | 2022-05-09 | Task processing method and device and computer equipment |
| PCT/CN2022/114605 WO2023216461A1 (en) | 2022-05-09 | 2022-08-24 | Task processing method and apparatus, and computer device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210495716.8A CN114579288B (en) | 2022-05-09 | 2022-05-09 | Task processing method and device and computer equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114579288A true CN114579288A (en) | 2022-06-03 |
| CN114579288B CN114579288B (en) | 2022-09-02 |
Family
ID=81767806
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210495716.8A Active CN114579288B (en) | 2022-05-09 | 2022-05-09 | Task processing method and device and computer equipment |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN114579288B (en) |
| WO (1) | WO2023216461A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115586972A (en) * | 2022-11-25 | 2023-01-10 | 成都登临科技有限公司 | Command generation method and device, AI chip, electronic device and storage medium |
| CN116800604A (en) * | 2023-08-22 | 2023-09-22 | 中国科学院空天信息创新研究院 | Configurable laser communication equipment control method, device, equipment and medium |
| WO2023216461A1 (en) * | 2022-05-09 | 2023-11-16 | 成都登临科技有限公司 | Task processing method and apparatus, and computer device |
Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020133689A1 (en) * | 2001-03-14 | 2002-09-19 | Park Sang Hyun | Method and apparatus for executing coprocessor instructions |
| US6539438B1 (en) * | 1999-01-15 | 2003-03-25 | Quickflex Inc. | Reconfigurable computing system and method and apparatus employing same |
| US20040187135A1 (en) * | 2003-02-18 | 2004-09-23 | Microsoft Corporation. | Systems and methods for scheduling coprocessor resources in a computing system |
| CN101840355A (en) * | 2003-02-18 | 2010-09-22 | 微软公司 | Be used to strengthen the system and method for performance of coprocessor |
| CN102098511A (en) * | 2010-12-15 | 2011-06-15 | 中兴通讯股份有限公司 | Mobile terminal and video playing realization method thereof |
| CN104702474A (en) * | 2015-03-11 | 2015-06-10 | 华中科技大学 | FPGA (Field Programmable Gate Array)-based EtherCAT (Ethernet Control Automation Technology) main station device |
| CN104866423A (en) * | 2015-05-20 | 2015-08-26 | 中国科学院空间应用工程与技术中心 | Software configuration item test method and system |
| US20160077799A1 (en) * | 2014-09-16 | 2016-03-17 | Fujitsu Limited | Control device and control method |
| US9329840B1 (en) * | 2005-12-30 | 2016-05-03 | The Mathworks, Inc. | Graphical programming of custom device drivers |
| US20180357098A1 (en) * | 2017-06-07 | 2018-12-13 | Dell Products L.P. | Coordinating fpga services using cascaded fpga service managers |
| CN111400986A (en) * | 2020-02-19 | 2020-07-10 | 西安智多晶微电子有限公司 | Integrated circuit computing device and computing processing system |
| CN114116015A (en) * | 2022-01-21 | 2022-03-01 | 上海登临科技有限公司 | Method and system for managing hardware command queue |
| CN114116594A (en) * | 2021-11-05 | 2022-03-01 | 中国航空工业集团公司雷华电子技术研究所 | Multi-interface compatible extension system based on SRIO bus and communication method |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101201811B (en) * | 2006-12-11 | 2010-05-12 | 边立剑 | Encryption-decryption coprocessor for SOC |
| US9396020B2 (en) * | 2012-03-30 | 2016-07-19 | Intel Corporation | Context switching mechanism for a processing core having a general purpose CPU core and a tightly coupled accelerator |
| US10552190B2 (en) * | 2017-01-16 | 2020-02-04 | International Business Machines Corporation | Precise error injection for driver testing |
| CN112631772A (en) * | 2020-12-21 | 2021-04-09 | 海光信息技术股份有限公司 | Cryptographic operation method, processor, device and storage medium |
| CN114579288B (en) * | 2022-05-09 | 2022-09-02 | 成都登临科技有限公司 | Task processing method and device and computer equipment |
-
2022
- 2022-05-09 CN CN202210495716.8A patent/CN114579288B/en active Active
- 2022-08-24 WO PCT/CN2022/114605 patent/WO2023216461A1/en unknown
Patent Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6539438B1 (en) * | 1999-01-15 | 2003-03-25 | Quickflex Inc. | Reconfigurable computing system and method and apparatus employing same |
| US20020133689A1 (en) * | 2001-03-14 | 2002-09-19 | Park Sang Hyun | Method and apparatus for executing coprocessor instructions |
| US20040187135A1 (en) * | 2003-02-18 | 2004-09-23 | Microsoft Corporation. | Systems and methods for scheduling coprocessor resources in a computing system |
| CN101840355A (en) * | 2003-02-18 | 2010-09-22 | 微软公司 | Be used to strengthen the system and method for performance of coprocessor |
| US9329840B1 (en) * | 2005-12-30 | 2016-05-03 | The Mathworks, Inc. | Graphical programming of custom device drivers |
| CN102098511A (en) * | 2010-12-15 | 2011-06-15 | 中兴通讯股份有限公司 | Mobile terminal and video playing realization method thereof |
| US20160077799A1 (en) * | 2014-09-16 | 2016-03-17 | Fujitsu Limited | Control device and control method |
| CN104702474A (en) * | 2015-03-11 | 2015-06-10 | 华中科技大学 | FPGA (Field Programmable Gate Array)-based EtherCAT (Ethernet Control Automation Technology) main station device |
| CN104866423A (en) * | 2015-05-20 | 2015-08-26 | 中国科学院空间应用工程与技术中心 | Software configuration item test method and system |
| US20180357098A1 (en) * | 2017-06-07 | 2018-12-13 | Dell Products L.P. | Coordinating fpga services using cascaded fpga service managers |
| CN111400986A (en) * | 2020-02-19 | 2020-07-10 | 西安智多晶微电子有限公司 | Integrated circuit computing device and computing processing system |
| CN114116594A (en) * | 2021-11-05 | 2022-03-01 | 中国航空工业集团公司雷华电子技术研究所 | Multi-interface compatible extension system based on SRIO bus and communication method |
| CN114116015A (en) * | 2022-01-21 | 2022-03-01 | 上海登临科技有限公司 | Method and system for managing hardware command queue |
Non-Patent Citations (3)
| Title |
|---|
| ARNALDO S. R. OLIVEIRA等: "The ARPA-MT Embedded SMT Processor and Its RTOS Hardware Accelerator", 《IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS》 * |
| 李宝伟等: "新一代智能变电站SV直采和GOOSE共口传输方案研究", 《电力系统保护与控制》 * |
| 毕壹双: "基于CAPI技术的DeepFM算法FPGA异构加速研究", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023216461A1 (en) * | 2022-05-09 | 2023-11-16 | 成都登临科技有限公司 | Task processing method and apparatus, and computer device |
| CN115586972A (en) * | 2022-11-25 | 2023-01-10 | 成都登临科技有限公司 | Command generation method and device, AI chip, electronic device and storage medium |
| CN115586972B (en) * | 2022-11-25 | 2023-02-28 | 成都登临科技有限公司 | Command generation method and device, AI chip, electronic device and storage medium |
| CN116800604A (en) * | 2023-08-22 | 2023-09-22 | 中国科学院空天信息创新研究院 | Configurable laser communication equipment control method, device, equipment and medium |
| CN116800604B (en) * | 2023-08-22 | 2023-11-07 | 中国科学院空天信息创新研究院 | Configurable laser communication equipment control method, device, equipment and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114579288B (en) | 2022-09-02 |
| WO2023216461A1 (en) | 2023-11-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114579288B (en) | Task processing method and device and computer equipment | |
| US7231638B2 (en) | Memory sharing in a distributed data processing system using modified address space to create extended address space for copying data | |
| JP5496683B2 (en) | Customization method and computer system | |
| US20050251806A1 (en) | Enhancement of real-time operating system functionality using a hypervisor | |
| US6631515B1 (en) | Method and apparatus to reduce code size and runtime in a Java environment | |
| CN111400000A (en) | Network request processing method, device, equipment and storage medium | |
| CN110659131B (en) | Task processing method, electronic device, computer equipment and storage medium | |
| CN114637536A (en) | Task processing method, computing coprocessor, chip and computer equipment | |
| CN112688915A (en) | Cross-protocol communication method, device and server | |
| CN111427557A (en) | Application microservice method and device, electronic equipment and readable storage medium | |
| CN111274044B (en) | GPU (graphics processing unit) virtualized resource limitation processing method and device | |
| CN110659104B (en) | Service monitoring method and related equipment | |
| CN110221877B (en) | Application program running method and device, electronic equipment and storage medium | |
| KR20060063643A (en) | Improving operating system performance | |
| CN115904761A (en) | System on chip, vehicle and video processing unit virtualization method | |
| WO2019228346A1 (en) | Method and apparatus for executing task by scheduling device | |
| CN114385351A (en) | Cloud management platform load balancing performance optimization method, device, equipment and medium | |
| CN111475226B (en) | Electronic device, micro-service calling method, and computer-readable storage medium | |
| CN113986466A (en) | Cloud computing-oriented GPU virtualization system and method | |
| CN113407331A (en) | Task processing method and device and storage medium | |
| CN114301970A (en) | Service calling method and device, electronic equipment and storage medium | |
| CN115552369A (en) | Compiling method, compiling device, compiling system, storage medium and electronic device | |
| CN114936098B (en) | Data transfer method, device, back-end equipment and storage medium | |
| CN111917620B (en) | MCU service processing method, device, electronic equipment and storage medium | |
| CN110933226B (en) | Application program remote hosting method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |