WO2023216461A1 - 一种任务处理的方法、装置以及计算机设备 - Google Patents

一种任务处理的方法、装置以及计算机设备 Download PDF

Info

Publication number
WO2023216461A1
WO2023216461A1 PCT/CN2022/114605 CN2022114605W WO2023216461A1 WO 2023216461 A1 WO2023216461 A1 WO 2023216461A1 CN 2022114605 W CN2022114605 W CN 2022114605W WO 2023216461 A1 WO2023216461 A1 WO 2023216461A1
Authority
WO
WIPO (PCT)
Prior art keywords
command
task
hardware
function module
coprocessor
Prior art date
Application number
PCT/CN2022/114605
Other languages
English (en)
French (fr)
Inventor
李建文
王晨辉
严宗宗
官杨杰
Original Assignee
成都登临科技有限公司
上海登临科技有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 成都登临科技有限公司, 上海登临科技有限公司 filed Critical 成都登临科技有限公司
Publication of WO2023216461A1 publication Critical patent/WO2023216461A1/zh

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

Definitions

  • the present application relates to the field of chip technology, specifically, to a task processing method, device and computer equipment.
  • Computer devices usually need to drive hardware function modules through device drivers to execute task commands.
  • the device driver is usually set in the central processor of the computer device, and is used to control the hardware function module to perform corresponding operations based on the received task command, and return the execution results to the user.
  • a central processing unit usually calls a device driver to send hardware operation commands to hardware function modules based on task commands issued by the user.
  • the hardware function module executes the hardware operation command and returns the command execution result to the central processor.
  • the central processing unit usually needs to call the device driver to generate each task command and multiple corresponding hardware operation commands, send each hardware operation command to the hardware function module, and receive the hardware function module to execute the execution of each hardware operation command. As a result, this consumes a lot of CPU resources for task command processing, hardware operation command sending, and execution result reception, resulting in lower device performance.
  • the purpose of the embodiments of the present application is to provide a task processing method, device and computer equipment, so as to reduce the consumption of central processor resources and improve equipment performance when processing tasks through hardware function modules.
  • a task processing method is provided, which is applied to a task processing device in a computer device.
  • the task processing device includes a coprocessor and a hardware function module.
  • the computer device also includes a central processor.
  • the method may include:
  • the coprocessor determines that when it receives the task command sent by the central processor, based on the task command, it calls the device driver subroutine set on the coprocessor and sends the hardware operation command to the hardware function module;
  • the hardware function module executes the received hardware operation command and returns the operation execution result to the coprocessor when it is determined that the command execution is completed;
  • the coprocessor sends command execution results to the central processor based on the received operation execution results.
  • task command processing, hardware operation command transmission, and operation execution results are received and summarized through the coprocessor in the task processing device. Only the central processor and the task processing device are required to transmit task commands and command execution results. , greatly reducing the load on the central processor and improving system performance.
  • the device driver subroutine is obtained by decomposing the device driver program.
  • receiving the task command sent by the central processor may include: when determining that a user interrupt request sent by the central processor is received, obtaining the task command based on the user interrupt request.
  • calling the device driver subroutine set on the coprocessor and sending the hardware operation command to the hardware function module may include: from at least one of the task processing devices In the hardware function module, the hardware function module matching the task command is determined; based on the task command, the device driver subroutine corresponding to the matching hardware function module is called, and at least one hardware operation command is sent to the matching hardware function module.
  • the device driver subroutine set on the coprocessor is called and the hardware operation command is sent to the hardware function module, which may include:
  • the following steps may be used:
  • the device driver subroutine corresponding to the matching hardware function module is called, and at least one hardware operation command is sent to the matching hardware function module, in the following manner:
  • the device driver subroutine sends a task command to the device driver subroutine corresponding to the matching hardware function module.
  • the device driver subroutine generates at least one hardware operation command according to the task command, and sends the generated hardware operation command to the matching hardware function module.
  • each device driver subroutine Based on the task command, generate at least one drive control command, and send each drive control command to the device driver subroutine corresponding to the matching hardware function module, and each device driver subroutine generates each drive control command respectively. corresponding to at least one hardware operation command, and sends the generated hardware operation command to the matching hardware function module.
  • the device driver subroutine corresponding to the matching hardware function module is called, and at least one hardware operation command is sent to the matching hardware function module, which may include: Based on the task command, a task subcommand corresponding to each matching hardware function module is generated; based on each task subcommand, the device driver subroutine corresponding to each matching hardware function module is called, and at least one hardware function module is sent to each matching hardware function module. Operation command.
  • the hardware function module executes the received hardware operation command, and when it is determined that the command execution is completed, returns the operation execution result to the coprocessor, which can be done in the following manner:
  • the hardware function module executes a hardware operation command, it uses an interrupt request to return the operation execution result corresponding to the hardware operation command;
  • the hardware function module After the hardware function module determines that each hardware operation command has been executed, it obtains an operation execution result corresponding to each hardware operation command, and returns the operation execution result in the form of an interrupt request.
  • the coprocessor based on the received operation execution result, sends the command execution result to the central processor, which may include: the coprocessor, when determining that the operation execution result is received, based on the operation execution result, Generate command execution results; use interrupt requests to send the command execution results to the central processor.
  • the central processor may be provided with a device driver subroutine. Both the device driver subroutine in the central processor and the device driver subroutine in the coprocessor may be obtained based on the device driver.
  • the method may also be include:
  • Hardware function module perform the following steps:
  • the hardware operation command is executed, wherein the hardware operation command is sent by the central processor calling a device driver subroutine in the central processor based on a specified type of task command;
  • the command execution result is returned to the central processor in the form of an interrupt request.
  • the method may further include:
  • the coprocessor receives the driver installation instruction containing driver configuration information sent by the central processor, and installs the device driver subroutine based on the driver configuration information contained in the driver installation instruction.
  • the driver installation instruction is when the central processor determines that the driver installation conditions are met. sent;
  • the coprocessor receives the operating system containing the device driver subroutine sent by the central processor, and starts the operating system so that the device driver subroutine starts automatically in the coprocessor.
  • the driver configuration information may be obtained based on firmware files designed for hardware function modules supported by the coprocessor; the driver configuration information may include: a program for running on the coprocessor. Operating system information, and one or more device driver subroutines configured to drive corresponding hardware function modules.
  • a task processing device in a computer device includes a coprocessor and a hardware function module.
  • the computer device may also include a central processor;
  • the coprocessor is configured to determine that when a task command sent by the central processor is received, based on the task command, call the device driver subroutine set on the coprocessor and send a hardware operation command to the hardware function module;
  • the hardware function module is configured to execute the received hardware operation command, and when it is determined that the command execution is completed, return the operation execution result to the coprocessor;
  • the coprocessor is further configured to send a command execution result to the central processor based on the received operation execution result.
  • the coprocessor may be further configured to: when determining that a user interrupt request sent by the central processor is received, obtain a task command based on the user interrupt request.
  • the coprocessor can also be configured to:
  • the device driver subroutine corresponding to the matching hardware function module is called, and at least one hardware operation command is sent to the matching hardware function module.
  • the coprocessor may also be configured to:
  • the hardware function module matching the task command from at least one hardware function module of the task processing device;
  • the coprocessor may also be configured to: if there are multiple matching hardware function modules, generate a task subcommand corresponding to each matching hardware function module based on the task command; based on each task subcommand , calling the device driver subroutine corresponding to each matching hardware function module, and sending at least one hardware operation command to each matching hardware function module respectively.
  • the coprocessor may also be configured to: when determining that the operation execution result is received, generate a command execution result based on the operation execution result; and send the command execution result to the central processor in the form of an interrupt request. .
  • the central processor may be provided with a device driver subroutine.
  • 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 hardware function module can Configured to: execute the hardware operation command when determining to receive a hardware operation command sent by the central processor, wherein the hardware operation command is sent by the central processor calling a device driver subroutine in the central processor based on a specified type of task command. ; when it is determined that the command execution is completed, the command execution result is returned to the central processor in the form of an interrupt request.
  • the coprocessor may be configured to: receive a driver installation instruction containing driver configuration information sent by the central processor, and install the device driver subroutine based on the driver configuration information included in the driver installation instruction.
  • the installation instruction is sent when the central processor determines that the driver installation conditions are met; or, it receives the operating system containing the device driver subroutine sent by the central processor and starts the operating system so that the device driver subroutine starts automatically in the coprocessor. .
  • a computer device may include a central processor and a task processing device;
  • a central processing unit configured to send task commands to the task processing device
  • the task processing device is configured to execute the task command using the task processing method of the above-mentioned first aspect, and return the command execution result to the central processor.
  • the central processor may be configured to: if it is determined that the task command is of a non-specified type, send the task command to the task processing device;
  • the central processing unit may also be configured to: if the task command is determined to be of a specified type, call a device driver subroutine in the central processing unit based on the task command and send a hardware operation command to the hardware function module of the task processing device;
  • the hardware function module can be configured to: execute the hardware operation command when it determines that the hardware operation command sent by the central processor is received; and when it determines that the command execution is completed, use an interrupt request to return the hardware operation command to the central processor. Generated command execution results.
  • the central processing unit may also be configured to: when determining that the driver installation conditions are met, send a driver installation instruction containing driver configuration information to the coprocessor in the task processing device, and the driver configuration information is configured to use Install the device driver subroutine in the coprocessor provided to the task processing device; or send the operating system containing the device driver subroutine to the coprocessor, so that the device driver subroutine can be used in the process of the coprocessor starting the operating system. Self-starting.
  • the driver installation conditions may include any one of the following conditions: device initialization, driver upgrade, and addition of hardware function modules.
  • embodiments of the present application further provide a system-on-a-chip (SOC).
  • SOC system-on-a-chip
  • the system-on-a-chip (SOC) includes a central processor and at least one task processing device connected to the central processor.
  • the task processing device Including a coprocessor and a hardware function module, the system-on-chip is used to execute the task processing method provided by the first aspect.
  • the system-on-chip can be configured in a computer system to perform data processing on the terminal device side or the server side by executing the aforementioned task processing method.
  • Figure 1 is a schematic structural diagram of a computer device 100 provided by an embodiment of the present application.
  • Figure 2 is a flow chart of a task processing method 200 provided by an embodiment of the present application.
  • FIG. 3 is a structural block diagram of a task processing device 300 provided by an embodiment of the present application.
  • 101-central processor 101-central processor
  • 103 301-coprocessor
  • 104 302-hardware function module.
  • Terminal device It can be a mobile terminal, a fixed terminal or a portable terminal, such as a mobile phone, a site, a unit, a device, a multimedia computer, a multimedia tablet, an Internet node, a communicator, a desktop computer, a laptop computer, a notebook computer, a netbook computer, Tablet computers, personal communication system devices, personal navigation devices, personal digital assistants, audio/video players, digital cameras/camcorders, positioning devices, television receivers, radio broadcast receivers, e-book devices, gaming devices, or any combination thereof, Includes accessories and peripherals for these devices or any combination thereof. It is also foreseeable that the terminal device can support any type of user-oriented interface (such as wearable devices), etc.
  • Server It can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, Cloud servers for middleware services, domain name services, security services, and basic cloud computing services such as big data and artificial intelligence platforms.
  • Hardware function modules eg, mouse
  • computer devices eg, computers
  • the device driver provides users with a software interface for using hardware function modules, receives user commands through the software interface, controls the driver hardware function module to execute the user commands, and sends the command execution results to the user through the software interface.
  • a centralized device driver architecture is usually adopted, that is, all device drivers are set in the central processor of the computer device, and the central processor is responsible for processing all transactions during the working process of the hardware function module, including processing user commands and Handle device interrupts.
  • the central processing unit usually calls the device driver to send hardware operation commands to the hardware function module based on the task command issued by the user. After the hardware function module executes the hardware operation command, it triggers a device interrupt to notify the central processor that the command execution is completed.
  • the central processing unit stops other work for interrupt processing, obtains the command execution result of the hardware function module, sends the command execution result to the user, and continues the work before the interruption after completing the interrupt processing.
  • the hardware video encoding and decoding unit (as a hardware function module) in an artificial intelligence accelerator card
  • the hardware video encoding and decoding unit (Video Processing Unit, VPU) can support 256 channels of 1080p 30FPS decoding, and the artificial intelligence accelerator card can It can output 7680 video frames per second.
  • the central processor needs to send 76,800 task commands to the artificial intelligence accelerator card and handle 76,800 device interrupts per second.
  • the task commands that the central processor needs to send and the device interrupts that need to be processed reach 614,400 per second. Obviously, this will put a considerable burden on the central processor, seriously affecting the execution of other tasks on the server (that is, the device where the central processor is located), and may cause system performance degradation due to the overload of the central processor.
  • this application uses a distributed device driver architecture to replace the above-mentioned centralized device driver architecture. That is, the device driver that completely relies on the central processor can be split according to the hardware function modules, and each hardware function module can be divided into Configure the corresponding coprocessor, and distribute the device driver subroutines of some or all hardware function modules to different coprocessors, and process the work process of the hardware function module through the coprocessor containing the device driver subroutine. affairs.
  • Embodiments of the present application provide a task processing method, device and computer equipment, which can reduce the load of the central processor, reduce the consumption of central processor resources, and improve the overall processing capability of the system in scenarios where the throughput of hardware equipment is large. , give full play to the performance of hardware equipment.
  • FIG. 1 is a schematic structural diagram of a computer device 100 provided by an embodiment of the present application.
  • the computer device 100 includes a central processing unit 101 and a task processing device 102 .
  • the computer device 100 can be a server or a terminal device, which is not limited here.
  • Central processing unit 101 is the host CPU of the computer device 100, configured to send task commands to the co-processor 103 in the task processing device 102, and receive command execution results returned by the co-processor 103 based on the task commands.
  • the central processor 101 may also be provided with a device driver subroutine, which calls the device driver subroutine to generate hardware operation commands based on task commands issued by the user, and sends the generated hardware operation commands to the task processing device 102 hardware function module, and receives the command execution result returned by the hardware function module 104.
  • a device driver subroutine which calls the device driver subroutine to generate hardware operation commands based on task commands issued by the user, and sends the generated hardware operation commands to the task processing device 102 hardware function module, and receives the command execution result returned by the hardware function module 104.
  • the hardware operation command is one or more commands generated by the device driver subroutine based on the task command.
  • the central processor can send some task commands (such as complex commands) to the coprocessor, and drive the hardware function module to execute the task command through the coprocessor. It can also directly control the hardware function module to execute some commands (such as simple commands). ).
  • Task processing device 102 includes a coprocessor 103 and a hardware function module 104, which is used to execute task commands or hardware operation commands issued by the central processor 101, and return command execution results to the central processor 101.
  • Each task processing device 102 may include one or more co-processors 103 .
  • Each coprocessor 103 can run one or more device driver subroutines based on the performance of the coprocessor 103 and actual needs.
  • Each device driver subroutine can control one or more hardware function modules 104. Any two device driver subroutines in each task processing device 102 may be the same or different. Any two hardware function modules 104 in each task processing device 102 may be the same or different. Since the device driver subroutine is used to drive the hardware function module 104, the device driver subroutine running in each co-processor 103 in the task processing device 102 is determined by the hardware function module 104 in the task processing device 102. Different coprocessors 103 can run their own device driver subroutines respectively without affecting each other.
  • different device driver subroutines in the same task processing device 102 can control different types of hardware function modules 104 .
  • the types of hardware function modules 104 may be divided according to functions, and there may be one or more hardware function modules 104 of each type.
  • Coprocessor 103 is a processor in the computer device 100 other than the central processor 101, configured to control one or more correspondingly connected hardware function modules 104 through a device driver subroutine that it runs.
  • the coprocessor 103 receives the task command sent by the central processor 101, calls the device driver subroutine running on itself, sends the hardware operation command to the hardware function module 104 based on the task command, and receives the hardware function module 104 to execute the command.
  • Each task processing device 102 may have one or more communication channels.
  • the coprocessor 103 communicates with the central processor 101 through a communication channel.
  • each co-processor 103 usually requires an independent communication channel to communicate with the central processor 101, the number of communication channels in each task processing device 102 is usually not less than the number of co-processors 103.
  • the communication channel may be simplex or duplex.
  • communication channels usually use duplex. Different communication channels are completely independent of each other and can work at the same time without affecting each other.
  • the communication channel may support interrupts, such as bidirectional interrupts, that is, the coprocessor 103 may send an interrupt request to the central processor 101, and the central processor 101 may also send an interrupt request to the coprocessor 103.
  • interrupts such as bidirectional interrupts
  • the coprocessor 103 and the operating system in the central processor 101 may be the same or different.
  • the hardware function module 104 is configured to receive a hardware operation command sent by the driver subroutine in the coprocessor 103 based on a task command of an unspecified type, execute the received hardware operation command, and return the operation execution result to the coprocessor 103, The coprocessor 103 generates a command execution result based on the operation execution result, and returns the command execution result to the central processor 101 .
  • the hardware function module 104 can also receive a hardware operation command sent by the central processor 101 based on a specified type of task command, execute the received hardware operation command, and return the command execution result generated based on the hardware operation command to the central processing unit. Device 101.
  • the specified type can be a simple type.
  • the specified type can be set according to the actual application scenario, and is not limited here.
  • the device driver subroutine in the central processor 101 and the device driver subroutine in the coprocessor 103 are both obtained based on the device driver program.
  • Any device driver subroutine can be the device driver itself, or it can be a subroutine in the device driver that is used to implement some functions.
  • each hardware function module 104 in each task processing device 102 the device driver is decomposed into a plurality of device driver subroutines, and each device driver subroutine is installed to each task processing device 102. in coprocessor 103.
  • the central processor 101 can call the device driver subroutine through the coprocessor 103 to control the corresponding hardware function module 104 to execute the task command.
  • the central processor 101 can directly control the corresponding hardware function module 104 to execute a simple type (ie, a specified type) of task commands through the device driver subroutine that it runs, and can also call the device driver through the coprocessor 103.
  • the subroutine controls the corresponding hardware function module 104 to execute task commands of complex types (ie, non-specified types).
  • the task processing method provided by the embodiment of the present application can be executed by the central processor 101 and the task processing device 102 in the computer device 100 .
  • FIG. 2 a flow chart of a task processing method 200 provided by an embodiment of the present application is shown.
  • the method can be executed by a task processing device, for example, by the task processing device in the computer equipment shown in FIG. 1 .
  • the task processing method will be explained below in conjunction with the architecture shown in Figure 1.
  • the specific implementation process of this method may include:
  • Step 201 When the coprocessor determines that it has received the task command sent by the central processor, based on the task command, it calls the device driver subroutine set on the coprocessor and sends the hardware operation command to the hardware function module.
  • step 201 when performing step 201, the following steps can be used:
  • S2011 The central processor sends a task command to the co-processor in the task processing device.
  • the central processor determines the hardware function module that matches the task command, determines the coprocessor corresponding to the matching hardware function module, and sends the task command to the coprocessor. .
  • Each task processing device includes at least one hardware function module, and the hardware function modules in different task processing devices may be the same or different. Multiple identical hardware function modules may be located in different task processing device modules, or may be located in the same task processing device.
  • Each coprocessor is used to control one or more hardware function modules, that is, each coprocessor has a corresponding relationship with at least one hardware function module.
  • the central processing unit obtains the module identification information contained in the task command, and determines the hardware function module corresponding to the module identification information as the matching hardware function module.
  • the central processor sends task commands to the coprocessor through the communication channel and in the form of interrupt requests.
  • the central processor stores the task command to the set command reading address, and sends the user interrupt request to the coprocessor through the communication channel, so that after the coprocessor receives the user interrupt request, it can read the command from the set address.
  • the command read address reads the task command.
  • the command reading address is set in advance.
  • S2012 The coprocessor receives the task command sent by the central processor.
  • the coprocessor determines that it has received the user interrupt request sent by the central processor, it obtains the task command based on the user interrupt request.
  • the coprocessor calls the device driver subroutine set on the coprocessor and sends hardware operation commands to the hardware function module.
  • any of the following methods can be used:
  • Method 1 If the task command is a non-cyclic command type, the coprocessor determines the hardware function module matching the task command from at least one hardware function module of the task processing device, and based on the task command, calls the above matching hardware function The device driver subroutine corresponding to the module sends at least one hardware operation command to the matching hardware function module.
  • the coprocessor sends a task command to the device driver subroutine corresponding to the matching hardware function module.
  • the device driver subroutine executes the task command, generates at least one hardware operation command, and sends the generated hardware operation command to the matching hardware function module.
  • the coprocessor generates at least one drive control command based on the task command, and sends each drive control command to the device driver subroutine corresponding to the matching hardware function module.
  • Each device driver subroutine generates at least one hardware operation command corresponding to each drive control command, and sends the generated hardware operation command to the matching hardware function module.
  • a task subcommand corresponding to each matching hardware function module is generated based on the task command, and based on each task subcommand, a task corresponding to each matching hardware function module is called.
  • the device driver subroutine sends at least one hardware operation command to each matching hardware function module.
  • the task command may be a relatively complex command, that is, the same hardware function module may be required to perform the same or different combinations of operations multiple times, or multiple different hardware function modules may be required to perform different combinations of operations. Therefore, the coprocessor First, multiple task subcommands are generated based on the task command, and based on each task subcommand, different device driver subroutines are called to drive each hardware function module to perform corresponding operations.
  • Method 2 If the task command is a cyclic command type, based on the task command, the device driver subroutine set on the coprocessor is called cyclically, and the hardware operation command is sent to the hardware function module until it is determined that the command execution is completed.
  • the coprocessor when executing mode 2, can take the following steps:
  • S20131 Determine the hardware function module that matches the task command from at least one hardware function module of the task processing device.
  • S20132 Based on the task command, call the device driver subroutine corresponding to the matching hardware function module, and send at least one hardware operation command to the matching hardware function module.
  • S20133 Receive the operation execution result returned after the matching hardware function module executes at least one hardware operation command.
  • each time the hardware function module completes execution of a hardware operation command uses an interrupt request to return the operation execution result corresponding to the hardware operation command to the coprocessor.
  • the coprocessor receives the operation execution results corresponding to each hardware operation command.
  • the hardware function module determines that each hardware operation command has been executed, it obtains an operation execution result corresponding to each hardware operation command, and returns the operation execution result to the coprocessor in the form of an interrupt request.
  • the coprocessor receives the above-mentioned operation execution result corresponding to each hardware operation command.
  • S20134 Based on the operation execution result, determine whether the task command is completed. If so, execute S20135; otherwise, execute S20132.
  • n is a positive integer.
  • Mode 2 When executing Mode 2, for specific steps, please refer to the specific implementation of Mode 1 above, and will not be described again here.
  • the coprocessor will call a loop program for executing the task command to repeatedly call one or more hardware function modules to repeatedly execute a certain set of operations. .
  • the single-time printing program can only control the printer to print one newspaper, then the loop printing program is run, and the single-time printing program is called 10 times in a loop to print 10 newspapers.
  • the coprocessor can directly or indirectly obtain the device driver subroutine when the driver installation conditions are met.
  • device driver subroutines are available through the central processor.
  • the device driver subroutine can also be loaded into the storage unit corresponding to the coprocessor through other methods.
  • the coprocessor may install the device driver subroutine when it is determined that the driver installation conditions are met. For example, when it is determined that the co-processor meets the driver installation conditions, the central processor may send a driver installation instruction containing the driver configuration information to the co-processor in the task processing device. The coprocessor can receive a driver installation instruction containing driver configuration information sent by the central processor, and install the device driver subroutine based on the driver configuration information included in the driver installation instruction.
  • the driver configuration information is used to install the device driver subroutine.
  • the driver installation instruction is sent by the central processor when it determines that the driver installation conditions are met.
  • Driver installation conditions may include but are not limited to any of the following conditions: device initialization, driver upgrade, and addition of hardware function modules.
  • the driver configuration information may be a firmware (Firmware) file designed for hardware function modules supported by the coprocessor.
  • the driver configuration information may include: information for an operating system (eg, Linux) running on the coprocessor, and one or more device driver subroutines configured to drive corresponding hardware function modules.
  • an operating system eg, Linux
  • device driver subroutines configured to drive corresponding hardware function modules.
  • the central processor determines the hardware function module connected to the co-processor, obtains the driver configuration information corresponding to the hardware function module, and sends the driver configuration information to the co-processor in the task processing device.
  • Informational driver installation instructions for the coprocessor to load the device driver subroutine.
  • the computer device when the computer device is powered off and restarted, it can be deemed to meet the driver installation conditions, and the central processor can send a driver installation instruction containing driver configuration information to the coprocessor in the task processing device.
  • the central processor determines the driver upgrade, obtains (such as downloading and copying, etc.) the driver upgrade file, obtains the driver configuration information based on the driver upgrade file, and sends it to the coprocessor in the task processing device.
  • Driver installation instructions containing driver configuration information.
  • the driver configuration information of the new hardware function module is obtained, and the coprocessor corresponding to the new hardware function module is determined, and the new hardware function module is determined.
  • the outgoing coprocessor sends driver installation instructions containing driver configuration information.
  • the coprocessor may not use the installation process of the above implementation, but directly start the operating system containing the device driver subroutine, thereby realizing the device driver subroutine self-starting in the coprocessor.
  • the central processor can send the operating system containing the device driver subroutine to the co-processor in the task processing device, and the content sent by the central processor can also be provided in the form of a firmware file.
  • the coprocessor can receive the operating system containing the device driver subroutine sent by the central processor, and start the operating system, so that the device driver subroutine can start automatically in the coprocessor.
  • the coprocessor can call the device driver subroutine to send hardware operation commands to the matching hardware function module.
  • Step 202 The hardware function module executes the received hardware operation command, and when it is determined that the command execution is completed, returns the operation execution result to the coprocessor.
  • each time the hardware function module completes execution of a hardware operation command uses an interrupt request to return the operation execution result corresponding to the hardware operation command to the coprocessor.
  • the coprocessor receives the operation execution results corresponding to each hardware operation command.
  • the hardware function module determines that each hardware operation command has been executed, it obtains an operation execution result of each hardware operation command and returns the operation execution result to the coprocessor in the form of an interrupt request.
  • the coprocessor receives the above-mentioned operation execution result corresponding to each hardware operation command.
  • Step 203 Based on the received operation execution result, the coprocessor sends the command execution result to the central processor.
  • the coprocessor may take the following steps:
  • each operation execution result can be analyzed to generate a command execution result.
  • the operation execution result is an operation execution result corresponding to at least one hardware operation command
  • the operation execution result can be used as the command execution result.
  • the coprocessor stores the command execution result to a set result reading address, and uses a communication channel to send a result interrupt request to the central processor. After the central processing unit determines that it has received the result interrupt request, it reads the command execution result from the result read address.
  • the central processing unit can also call the device driver subroutine that it runs, and directly send hardware operation commands to one or more hardware function modules in the task processing device.
  • the central processor calls a device driver subroutine in the central processor based on a task command of a specified type, and sends at least one hardware operation command to at least one hardware function module that matches the task command.
  • the hardware function module determines that it has received the hardware operation command sent by the central processor, it executes the received hardware operation command, and when it determines that the command execution is completed, it returns the command execution result to the central processor in the form of a result interrupt request.
  • the central processor needs to be specifically responsible for controlling the work of the hardware video encoding and decoding unit, and needs to send 76,800 task commands to the artificial intelligence accelerator card per second and process 76,800 Device interruption.
  • the central processor does not need to be specifically responsible for driving and controlling the work of the hardware video encoding and decoding unit.
  • 15,360 task commands are sent to the device per second and 15,360 are processed. Device interruption. In this way, the consumption of CPU resources is greatly reduced.
  • the central processor calls the device driver running on itself based on the task command to generate hardware operation commands, sends the hardware operation commands to the hardware function module, and receives the hardware function module The command execution result returned after executing the hardware operation command.
  • Each task command usually requires the hardware function module to perform a series of hardware operations. Therefore, the central processor usually needs to generate a series of hardware operations for each task command to control the hardware function module. Multiple hardware operation commands for hardware operations.
  • the central processor needs to decompose the task command into multiple task sub-commands and send hardware operations to different hardware function modules based on each task sub-command. command, and receive the command execution result corresponding to each task subcommand returned by the hardware function module.
  • the generation and transmission of a large number of hardware operation commands, as well as the processing of interrupt requests will consume a lot of processing resources of the central processor.
  • the device driver is decomposed into device driver subroutines corresponding to each hardware function module, and each device driver subroutine is distributed on the central processor and corresponding to each hardware function module. on the coprocessor.
  • the central processor only needs to manage some hardware function modules (for example, hardware function modules with low throughput), and only needs to send task commands to the coprocessor and receive the command execution results of the task commands returned by the coprocessor. There is no need to process task commands, transmit hardware operation commands, and receive and summarize operation execution results for all hardware function modules. This can make full use of hardware capabilities, greatly reduce the load on the central processor, and improve system performance.
  • the central processor sends task commands to the co-processor in the form of interrupt requests, and receives the command execution results returned by the co-processor in the form of interrupt requests. The processing of bidirectional interrupts further reduces the consumption of central processor resources.
  • embodiments of the present application also provide a task processing device.
  • FIG 3 is a schematic structural diagram of a task processing device 300 in a computer device provided by an embodiment of the present application.
  • the task processing device 300 includes a coprocessor 301 and a hardware function module 302.
  • the computer device also includes CPU;
  • the coprocessor 301 is used to determine that when a task command sent by the central processor is received, based on the task command, call the device driver subroutine set on the coprocessor 301 and send a hardware operation command to the hardware function module 302;
  • the hardware function module 302 is used to execute the received hardware operation command, and when it is determined that the command execution is completed, return the operation execution result to the coprocessor 301;
  • the coprocessor 301 is also used to send command execution results to the central processor based on the received operation execution results.
  • the coprocessor 301 is also configured to: when determining that a user interrupt request sent by the central processor is received, obtain a task command based on the user interrupt request.
  • the coprocessor 301 is also used to: determine the hardware function module 302 matching the task command from at least one hardware function module 302 of the task processing device 300; based on the task command, call the device driver subroutine corresponding to the matching hardware function module 302, and send at least one hardware operation command to the matching hardware function module 302.
  • the coprocessor 301 is configured to: if the task command is a cyclic command type, determine the hardware function module 302 matching the task command from at least one hardware function module 302 of the task processing device 300; perform the following in a loop: Steps until the execution of the task command is completed: based on the task command, call the device driver subroutine corresponding to the matching hardware function module 302, send at least one hardware operation command to the matching hardware function module 302; receive the matching hardware function module 302 to execute at least one The operation execution result returned after the hardware operation command; based on the operation execution result, it is judged whether the task command is completed.
  • the coprocessor 301 is also used to: if there are multiple matching hardware function modules 302, generate a task subcommand corresponding to each matching hardware function module 302 based on the task command; based on each task subcommand, The device driver subroutine corresponding to each matching hardware function module 302 is called, and at least one hardware operation command is sent to each matching hardware function module 302 respectively.
  • the coprocessor 301 is also configured to: when determining that an operation execution result is received, generate a command execution result based on the operation execution result; and send the command execution result to the central processor in the form of an interrupt request.
  • the central processor is provided with a device driver subroutine.
  • the device driver subroutine in the central processor and the device driver subroutine in the coprocessor 301 are both obtained based on the device driver.
  • the hardware function module 302 Used to: determine to execute the hardware operation command when receiving the hardware operation command sent by the central processor, where the hardware operation command is sent by the central processor calling the device driver subroutine in the central processor based on a specified type of task command; determine When the command execution is completed, the command execution result is returned to the central processor in the form of an interrupt request.
  • the coprocessor 301 is configured to: receive a driver installation instruction containing driver configuration information sent by the central processor, and install the device driver subroutine based on the driver configuration information included in the driver installation instruction, where the driver installation instruction is It is sent when the central processor determines that the driver installation conditions are met; or, it receives the operating system containing the device driver subroutine sent by the central processor, and starts the operating system so that the device driver subroutine starts automatically in the coprocessor 301.
  • inventions of the present application also provide a system-on-a-chip (SOC).
  • SOC system-on-a-chip
  • the system-on-a-chip (SOC) includes a central processor and at least one task processing device connected to the central processor.
  • the task processing device includes a coprocessor and a hardware function module, and the system-on-chip is used to perform the aforementioned task processing method.
  • the system-on-chip can be configured in a computer system or installed in a computer device, and performs data processing on the terminal device side or the server side by executing the aforementioned task processing method.
  • the system on chip adopts the design of distributed drive architecture, for example, the architecture shown in Figure 1 can be used.
  • the central processor, co-processor and hardware function modules in the system-on-chip please refer to the related descriptions of the task processing device, computer equipment, and task processing methods mentioned above, and will not be described again here.
  • embodiments of the present application may be provided as methods, systems, electronic devices, or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines 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, etc.) having computer-usable program code embodied therein.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • This application provides a task processing method, device and computer equipment.
  • the device driver is decomposed into device driver subroutines corresponding to each hardware function module, and each device driver subroutine is distributed in the central On the processor and the coprocessor corresponding to each hardware function module.
  • the central processor only needs to manage some hardware function modules (such as hardware function modules with low throughput), and only needs to send task commands to the coprocessor and receive the command execution results of the task commands returned by the coprocessor. , without the need to process task commands, transmit hardware operation commands, and receive and summarize operation execution results for all hardware function modules. This can fully utilize the hardware capabilities, greatly reduce the load of the central processor, and improve the performance of the system. .
  • the central processor sends task commands to the co-processor in the form of interrupt requests, and receives the command execution results returned by the co-processor in the form of interrupt requests. The processing of bidirectional interrupts further reduces the consumption of central processor resources.
  • the task processing method, apparatus and computer equipment of the present application are reproducible and can be used in a variety of industrial applications.
  • the task processing method, device and computer equipment of this application can be used in the field of chip technology.

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

本申请属于芯片技术领域，公开了一种任务处理的方法、装置以及计算机设备，该方法包括，应用于计算机设备中的任务处理装置，任务处理装置包括协处理器和硬件功能模块，计算机设备中还包含中央处理器，方法包括：协处理器，确定接收到中央处理器发送的任务命令时，基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令；硬件功能模块，执行接收到的硬件操作命令，并在确定命令执行完成时，向协处理器返回操作执行结果；协处理器，基于接收的操作执行结果，向中央处理器发送命令执行结果。这样可以降低中央处理器的资源消耗，提高设备性能。

Description

一种任务处理的方法、装置以及计算机设备
相关申请的交叉引用
本申请要求于2022年05月09日提交中国国家知识产权局的申请号为202210495716.8、名称为“一种任务处理的方法、装置以及计算机设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及芯片技术领域，具体而言，涉及一种任务处理的方法、装置以及计算机设备。
背景技术
计算机设备通常需要通过设备驱动程序驱动硬件功能模块执行任务命令。设备驱动程序通常设置于计算机设备的中央处理器中，用于基于接收的任务命令控制硬件功能模块执行相应的操作，以及将执行结果返回给用户。
在相关技术下，中央处理器通常基于用户下发的任务命令，调用设备驱动程序向硬件功能模块发送硬件操作命令。硬件功能模块执行该硬件操作命令，并将命令执行结果返回至中央处理器。
由于中央处理器通常需要调用设备驱动程序，分别生成每一任务命令，对应的多个硬件操作命令，并将各硬件操作命令发送至硬件功能模块，以及接收硬件功能模块执行各硬件操作命令的执行结果，因此，这会耗费大量的中央处理器资源进行任务命令处理、硬件操作命令发送以及执行结果接收，进而导致设备性能较低。
发明内容
本申请实施例的目的在于提供一种任务处理的方法、装置以及计算机设备，用以在通过硬件功能模块处理任务时，降低中央处理器资源的消耗，提高设备性能。
第一方面，提供一种任务处理的方法，应用于计算机设备中的任务处理装置，任务处理装置包括协处理器和硬件功能模块，计算机设备中还包含中央处理器，方法可以包括：
协处理器，确定接收到中央处理器发送的任务命令时，基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令；
硬件功能模块，执行接收到的硬件操作命令，并在确定命令执行完成时，向协处理器返回操作执行结果；
协处理器，基于接收的操作执行结果，向中央处理器发送命令执行结果。
在上述实现过程中，通过任务处理装置中的协处理器，进行任务命令处理、硬件操作命令传输以及操作执行结果的接收和汇总，仅需要中央处理器与任务处理装置传输任务命令和命令执行结果，极大地降低了中央处理器的负载，提升了系统的性能。
其中，所述设备驱动子程序是对设备驱动程序分解后获得的。
一种实施方式中，接收到中央处理器发送的任务命令，可以包括：确定接收到中央处理器发送的用户中断请求时，基于用户中断请求，获取任务命令。
一种实施方式中，若任务命令为非循环命令类型，基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令，可以包括：从任务处理装置的至少一个硬件功能模块中，确定出任务命令匹配的硬件功能模块；基于任务命令，调用匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令。
一种实施方式中，若任务命令为循环命令类型，基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令，可以包括：
从任务处理装置的至少一个硬件功能模块中，确定出任务命令匹配的硬件功能模块；
循环执行以下步骤，直至任务命令执行完成：
基于任务命令，调用匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令；
接收匹配的硬件功能模块执行至少一个硬件操作命令后返回的操作执行结果；
基于操作执行结果，判断任务命令是否执行完成。
一种实施方式中，从所述任务处理装置的至少一个硬件功能模块中，确定出所述任务命令匹配的硬件功能模块，可以采用以下步骤：
获取所述任务命令中包含的模块标识信息，并将所述模块标识信息对应的硬件功能模块，确定为所述任务命令匹配的硬件功能模块。
一种实施方式中，基于所述任务命令，调用所述匹配的硬件功能模块对应的设备驱动子程序，向所述匹配的硬件功能模块发送至少一个硬件操作命令，可以采用以下方式：
向所述匹配的硬件功能模块对应的设备驱动子程序发送任务命令，该设备驱动子程序根据该任务命令，生成至少一个硬件操作命令，并向所述匹配的硬件功能模块发送生成的硬件操作命令；或者
基于所述任务命令，生成至少一个驱动控制命令，并分别将每一驱动控制命令发送至所述匹配的硬件功能模块对应的设备驱动子程序，每一设备驱动子程序分别生成每一驱动控制命令对应的至少一个硬件操作命令，并向所述匹配的硬件功能模块发送生成的硬件操作命令。
一种实施方式中，若匹配的硬件功能模块为多个，则基于任务命令，调用匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令，可以包括：基于任务命令，生成各匹配的硬件功能模块对应的任务子命令；基于各任务子命令，调用各匹配的硬件功能模块对应的设备驱动子程序，分别向每一匹配的硬件功能模块发送至少一个硬件操作命令。
一种实施方式中，所述硬件功能模块，执行接收到的所述硬件操作命令，并在确定命 令执行完成时，向所述协处理器返回操作执行结果，可以采用以下方式：
所述硬件功能模块每次执行完成一个硬件操作命令后，均采用中断请求的方式，返回该硬件操作命令对应的操作执行结果；或者
所述硬件功能模块确定各硬件操作命令均执行完成后，获得各硬件操作命令对应的一个操作执行结果，并采用中断请求的方式，将该操作执行结果返回。
一种实施方式中，所述协处理器，基于接收的操作执行结果，向中央处理器发送命令执行结果，可以包括：所述协处理器，确定接收到操作执行结果时，基于操作执行结果，生成命令执行结果；采用中断请求的方式，将命令执行结果发送给中央处理器。
一种实施方式中，中央处理器上可以设置有设备驱动子程序，中央处理器中的设备驱动子程序和协处理器中的设备驱动子程序均可以是基于设备驱动程序获得的，方法还可以包括：
硬件功能模块，执行以下步骤：
确定接收到中央处理器发送的硬件操作命令时，执行硬件操作命令，其中，硬件操作命令是中央处理器基于指定类型的任务命令调用中央处理器中的设备驱动子程序发送的；
确定命令执行完成时，采用中断请求的方式，向中央处理器返回命令执行结果。
一种实施方式中，方法还可以包括：
协处理器，接收中央处理器发送的包含驱动配置信息的驱动安装指令，并基于驱动安装指令中包含的驱动配置信息，安装设备驱动子程序，驱动安装指令是中央处理器确定符合驱动安装条件时发送的；
或，协处理器接收中央处理器发送的含有设备驱动子程序的操作系统，并启动操作系统，以使设备驱动子程序在协处理器中自启动。
一种实施方式中，可以基于为针对协处理器支持的硬件功能模块所设计的固件文件得到所述驱动配置信息；所述驱动配置信息中可以包括：用于运行在所述协处理器上的操作系统的信息，以及被配置成用于驱动对应硬件功能模块的一个或多个设备驱动子程序。
第二方面，提供一种计算机设备中的任务处理装置，任务处理装置包括协处理器和硬件功能模块，计算机设备中还可以包含中央处理器；
协处理器，被配置成用于确定接收到中央处理器发送的任务命令时，基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令；
硬件功能模块，被配置成用于执行接收到的硬件操作命令，并在确定命令执行完成时，向协处理器返回操作执行结果；
协处理器，还被配置成用于基于接收的操作执行结果，向中央处理器发送命令执行结果。
一种实施方式中，协处理器还可以被配置成用于：确定接收到中央处理器发送的用户中断请求时，基于用户中断请求，获取任务命令。
一种实施方式中，若任务命令为非循环命令类型，协处理器还可以被配置成用于：
从任务处理装置的至少一个硬件功能模块中，确定出任务命令匹配的硬件功能模块；
基于任务命令，调用匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令。
一种实施方式中，协处理器还可以被配置成用于：
若任务命令为循环命令类型，则从任务处理装置的至少一个硬件功能模块中，确定出任务命令匹配的硬件功能模块；
循环执行以下步骤，直至任务命令执行完成：
基于任务命令，调用匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令；
接收匹配的硬件功能模块执行至少一个硬件操作命令后返回的操作执行结果；
基于操作执行结果，判断任务命令是否执行完成。
一种实施方式中，协处理器还可以被配置成用于：若匹配的硬件功能模块为多个，则基于任务命令，生成各匹配的硬件功能模块对应的任务子命令；基于各任务子命令，调用各匹配的硬件功能模块对应的设备驱动子程序，分别向每一匹配的硬件功能模块发送至少一个硬件操作命令。
一种实施方式中，协处理器还可以被配置成用于：确定接收到操作执行结果时，基于操作执行结果，生成命令执行结果；采用中断请求的方式，将命令执行结果发送给中央处理器。
一种实施方式中，中央处理器上可以设置有设备驱动子程序，中央处理器中的设备驱动子程序和协处理器中的设备驱动子程序均是基于设备驱动程序获得的，硬件功能模块可以被配置成用于：确定接收到中央处理器发送的硬件操作命令时，执行硬件操作命令，其中，硬件操作命令是中央处理器基于指定类型的任务命令调用中央处理器中的设备驱动子程序发送的；确定命令执行完成时，采用中断请求的方式，向中央处理器返回命令执行结果。
一种实施方式中，协处理器可以被配置成用于：接收中央处理器发送的包含驱动配置信息的驱动安装指令，并基于驱动安装指令中包含的驱动配置信息，安装设备驱动子程序，驱动安装指令是中央处理器确定符合驱动安装条件时发送的；或，接收中央处理器发送的含有设备驱动子程序的操作系统，并启动操作系统，以使设备驱动子程序在协处理器中自启动。
第三方面，提供一种计算机设备，计算机设备可以包括中央处理器以及任务处理装置；
中央处理器，被配置成用于向任务处理装置发送任务命令；
任务处理装置，被配置成用于采用如上述第一方面的任务处理方法执行任务命令，并将命令执行结果返回至中央处理器。
一种实施方式中，中央处理器可以被配置成用于：若确定任务命令为非指定类型，则将任务命令发送至任务处理装置；
中央处理器还可以被配置成用于：若确定任务命令为指定类型，则基于任务命令调用中央处理器中的设备驱动子程序，向任务处理装置的硬件功能模块发送硬件操作命令；
硬件功能模块可以被配置成用于：确定接收到中央处理器发送的硬件操作命令时，执行硬件操作命令，并确定命令执行完成时，采用中断请求的方式，向中央处理器返回基于硬件操作命令生成的命令执行结果。
一种实施方式中，中央处理器还可以被配置成用于：确定符合驱动安装条件时，向任务处理装置中的协处理器发送包含驱动配置信息的驱动安装指令，驱动配置信息被配置成用于提供给任务处理装置中的协处理器安装设备驱动子程序；或，向协处理器发送含有设备驱动子程序的操作系统，以使设备驱动子程序能够在协处理器启动操作系统的过程中自启动。
一种实施方式中，驱动安装条件可以包括以下条件中的任意一种：设备初始化、驱动升级以及硬件功能模块增加。
第四方面，本申请实施例还提供一种片上系统(System-on-a-chip，SOC)，该片上系统包括中央处理器以及与中央处理器连接的至少一个任务处理装置，该任务处理装置包括协处理器和硬件功能模块，该片上系统用于执行前述第一方面提供的任务处理的方法。该片上系统可以被配置在计算机系统中，通过执行前述的任务处理的方法，进行终端设备侧或服务器侧的数据处理。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的一种计算机设备100的结构示意图；
图2为本申请实施例提供的一种任务处理的方法200的流程图；
图3为本申请实施例提供的一种任务处理装置300的结构框图。
图中：101-中央处理器；103、301-协处理器；104、302-硬件功能模块。
具体实施方式
下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此 处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
首先对本申请实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。
终端设备：可以是移动终端、固定终端或便携式终端，例如移动手机、站点、单元、设备、多媒体计算机、多媒体平板、互联网节点、通信器、台式计算机、膝上型计算机、笔记本计算机、上网本计算机、平板计算机、个人通信系统设备、个人导航设备、个人数字助理、音频/视频播放器、数码相机/摄像机、定位设备、电视接收器、无线电广播接收器、电子书设备、游戏设备或者其任意组合，包括这些设备的配件和外设或者其任意组合。还可预见到的是，终端设备能够支持任意类型的针对用户的接口(例如可穿戴设备)等。
服务器：可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务以及大数据和人工智能平台等基础云计算服务的云服务器。
下面对本申请实施例的设计思想进行简要介绍：
计算机设备(如，电脑)中的硬件功能模块(如，鼠标)通常需要相应的设备驱动程序才能正常工作。设备驱动程序提供用户使用硬件功能模块的软件接口，并通过该软件接口接收用户命令，以及控制驱动硬件功能模块执行该用户命令，并通过该软件接口将命令执行结果发送给用户。
传统方式中，通常采用集中式的设备驱动架构，即将设备驱动程序全部设置于计算机设备的中央处理器中，并通过中央处理器负责处理硬件功能模块工作过程中的所有事务，包括处理用户命令和处理设备中断。具体地，中央处理器通常基于用户下发的任务命令，调用设备驱动程序向硬件功能模块发送硬件操作命令。硬件功能模块执行该硬件操作命令后，触发设备中断以通知中央处理器命令执行完成。中央处理器停止其它工作进行中断处理，获得硬件功能模块的命令执行结果，并将命令执行结果发送给用户，以及完成中断处理后继续进行中断前的工作。
在硬件设备吞吐量较小的应用场景中采用这种集中式的方式，不会对中央处理器带来较大的负担，但是，在硬件设备吞吐量非常大的应用场景中，每秒会有非常多的用户命令和设备中断需要中央处理器处理，这会耗费大量的中央处理器资源，甚至会占满中央处理器资源，进而导致整个系统卡顿。
在一个实例中，对于一个人工智能加速卡中的硬件视频编解码单元(作为硬件功能模块)，硬件视频编解码单元(Video Processing Unit，VPU)能够支持256路1080p 30FPS解码，人工智能加速卡每秒可输出7680帧视频帧。据统计，由于每一帧视频帧需要发送10个任务命令并处理10个设备中断，因此，中央处理器每秒需要向人工智能加速卡发送76800个任务命令并处理76800个设备中断。在8卡服务器(作为计算机设备)上，中央处理器需要发送的任务命令和处理的设备中断都达到了每秒614400个。显然，这会对中央处理器带来相当大的负担，严重影响服务器(即中央处理器所在的设备)上其他任务的执行，并且可能因为中央处理器负担过重造成系统性能下降。
基于此，本申请采用分布式的设备驱动架构取代上述集中式的设备驱动架构，即可以按照硬件功能模块，将完全依靠中央处理器运行的设备驱动程序进行拆分，并针对各硬件功能模块分别配置相应的协处理器，以及将部分或者全部硬件功能模块的设备驱动子程序，分布到不同的协处理器中，并通过包含设备驱动子程序的协处理器处理硬件功能模块的工作过程中的事务。本申请实施例提供了一种任务处理的方法、装置以及计算机设备，可以在硬件设备吞吐量较大的场景中，降低中央处理器的负载，减少耗费的中央处理器资源，提高系统整体处理能力，充分发挥硬件设备性能。
参阅图1所示，为本申请实施例提供的一种计算机设备100的结构示意图。计算机设备100包括中央处理器101以及任务处理装置102。
可选地，计算机设备100可以为服务器，也可以为终端设备，在此不作限制。
中央处理器101：为计算机设备100的主机CPU，被配置成用于向任务处理装置102中的协处理器103发送任务命令，并接收协处理器103基于任务命令返回的命令执行结果。
可选地，中央处理器101还可以设置有设备驱动子程序，调用上述设备驱动子程序基于用户下发的任务命令生成硬件操作命令，并将生成的硬件操作命令发送至任务处理装置102中的硬件功能模块，并接收该硬件功能模块104返回的命令执行结果。
其中，硬件操作命令是设备驱动子程序基于任务命令生成的一个或多个命令。
这样，中央处理器可以将部分任务命令(如，复杂命令)发送至协处理器，并通过协处理器驱动硬件功能模块执行任务命令，还可以直接控制硬件功能模块执行部分命令(如，简单命令)。
任务处理装置102：包括协处理器103和硬件功能模块104，用于执行中央处理器101下发的任务命令或硬件操作命令，以及向中央处理器101返回命令执行结果。
可选地，计算机设备100中可以包含一个或多个任务处理装置102。每一任务处理装置102中可以包含一个或多个协处理器103。每一协处理器103可以基于协处理器103的性能以及实际需求，运行一个或多个设备驱动子程序。每一设备驱动子程序可以控制一个或多个硬件功能模块104。各任务处理装置102中的任意两个设备驱动子程序可以相同，也可以不同。每一任务处理装置102中的任意两个硬件功能模块104可以相同，也可以不同。 由于设备驱动子程序是用于驱动硬件功能模块104的，因此，任务处理装置102中各协处理器103中运行的设备驱动子程序是由任务处理装置102中的硬件功能模块104决定的。不同协处理器103可分别运行自身的设备驱动子程序，互相之间互不影响。
一种实施方式中，同一任务处理装置102中的不同设备驱动子程序可以控制不同类型的硬件功能模块104。硬件功能模块104的类型可以是根据功能划分的，每一类型的硬件功能模块104可以为一个或多个。
协处理器103：为计算机设备100中除中央处理器101之外的处理器，被配置成用于通过自身运行的设备驱动子程序，控制对应连接的一个或多个硬件功能模块104。
一种实施方式中，协处理器103接收中央处理器101发送的任务命令，并调用自身运行的设备驱动子程序，基于任务命令向硬件功能模块104发送硬件操作命令，以及接收硬件功能模块104执行硬件操作命令后返回的操作执行结果，并基于接收的操作执行结果生成命令执行结果，以及将命令执行结果发送给中央处理器101。
其中，每一任务处理装置102可以有一个或多个通信信道。协处理器103通过通信信道，与中央处理器101进行通信。
由于每一协处理器103通常需要一个独立的通信信道与中央处理器101进行通信，因此，每一任务处理装置102中的通信信道的数量通常不低于协处理器103的数量。
可选地，通信信道可以采用单工或者双工。为提高系统性能，实际应用中，通信信道通常采用双工。不同通信信道互相之间是完全独立的，可以同时工作且互不影响。
可选地，通信信道可以支持中断，如，双向中断，即协处理器103可以向中央处理器101发送中断请求，中央处理器101也可以向协处理器103发送中断请求。协处理器103中的操作系统与中央处理器101中的操作系统可以相同，也可以不同。
硬件功能模块104：用于接收协处理器103中的驱动子程序基于非指定类型的任务命令发送的硬件操作命令后，执行接收的硬件操作命令，并将操作执行结果返回至协处理器103，以通过协处理器103基于操作执行结果生成命令执行结果，并将命令执行结果返回至中央处理器101。
可选地，硬件功能模块104还可以接收中央处理器101基于指定类型的任务命令发送的硬件操作命令后，执行接收的硬件操作命令，并将基于硬件操作命令生成的命令执行结果返回至中央处理器101。
可选地，指定类型可以为简单类型。实际应用中，指定类型可以根据实际应用场景进行设置，在此不作限制。
一种实施方式中，中央处理器101中的设备驱动子程序和协处理器103中的设备驱动子程序均是基于设备驱动程序获得的。任一设备驱动子程序可以为设备驱动程序本身，也可以是设备驱动程序中用于实现部分功能的子程序。
一种实施方式中，根据各任务处理装置102中的各硬件功能模块104，将设备驱动程序 分解为多个设备驱动子程序，并将各设备驱动子程序分别安装至各任务处理装置102的各协处理器103中。中央处理器101可以通过协处理器103调用设备驱动子程序，控制对应的硬件功能模块104执行任务命令。
一种实施方式中，中央处理器101可以通过自身运行的设备驱动子程序，直接控制对应的硬件功能模块104执行简单类型(即指定类型)的任务命令，还可以通过协处理器103调用设备驱动子程序，控制对应的硬件功能模块104执行复杂类型(即非指定类型)的任务命令。
通过计算机设备100中的中央处理器101和任务处理装置102可执行本申请实施例提供的任务处理的方法。
参阅图2所示，为本申请实施例提供的一种任务处理的方法200的流程图，该方法可由任务处理装置执行，例如可由图1所示计算机设备中的任务处理装置执行。下面将结合图1所示的架构，对任务处理的方法进行阐述说明，该方法的具体实施流程可包括：
步骤201：协处理器确定接收到中央处理器发送的任务命令时，基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令。
具体地，执行步骤201时，可以采用以下步骤：
S2011：中央处理器向任务处理装置中的协处理器发送任务命令。
具体地，若计算机设备中有多个任务处理装置，则中央处理器确定任务命令匹配的硬件功能模块，并确定该匹配的硬件功能模块对应的协处理器，以及向该协处理器发送任务命令。
其中，每一任务处理装置中至少包含一个硬件功能模块，不同任务处理装置中的硬件功能模块可以相同，也可以不同。相同的多个硬件功能模块可以分别位于不同的任务处理装置模块中，也可以均位于同一任务处理装置中。每一协处理器用于控制一个或多个硬件功能模块，即每一协处理器与至少一个硬件功能模块具有对应关系。
一种实施方式中，确定任务命令匹配的硬件功能模块时，可以采用以下步骤：
中央处理器获取任务命令中包含的模块标识信息，并将该模块标识信息对应的硬件功能模块，确定为匹配的硬件功能模块。
实际应用中，也可以采用其它方式确定任务命令匹配的硬件功能模块，在此不作限制。
一种实施方式中，向该协处理器发送任务命令时，可以采用以下步骤：
中央处理器通过通信信道，采用中断请求的方式，向该协处理器发送任务命令。
具体地，中央处理器将任务命令存储至设置好的命令读取地址，并通过通信信道向该协处理器发送用户中断请求，以使得协处理器接收到用户中断请求后，可以从该设置好的命令读取地址读取任务命令。
其中，命令读取地址是预先设置好的。
实际应用中，也可以根据实际应用场景采用其它的命令传输方式，在此不作限制。
S2012：协处理器接收中央处理器发送的任务命令。
具体地，协处理器确定接收到中央处理器发送的用户中断请求时，基于用户中断请求，获取任务命令。
S2013：协处理器基于任务命令，调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令。
具体地，执行S2013时，可以采用以下任一方式：
方式1：若任务命令为非循环命令类型，则协处理器从任务处理装置的至少一个硬件功能模块中，确定出任务命令匹配的硬件功能模块，并基于该任务命令，调用上述匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令。
其中，基于该任务命令，调用上述匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令时，可以采用以下方式：
一种实施方式中，协处理器向上述匹配的硬件功能模块对应的设备驱动子程序发送任务命令。设备驱动子程序执行该任务命令，生成至少一个硬件操作命令，并向匹配的硬件功能模块发送生成的硬件操作命令。
一种实施方式中，协处理器基于该任务命令，生成至少一个驱动控制命令，并分别将每一驱动控制命令发送至上述匹配的硬件功能模块对应的设备驱动子程序。每一设备驱动子程序分别生成每一驱动控制命令对应的至少一个硬件操作命令，并向匹配的硬件功能模块发送生成的硬件操作命令。
一种实施方式中，若匹配的硬件功能模块为多个，则基于任务命令，生成各匹配的硬件功能模块对应的任务子命令，并基于各任务子命令，调用各匹配的硬件功能模块对应的设备驱动子程序，分别向每一匹配的硬件功能模块发送至少一个硬件操作命令。
这是由于任务命令可能为较为复杂的命令，即可能需要同一硬件功能模块多次执行相同或不同的操作组合，或者需要多个不同的硬件功能模块分别执行不同的操作组合，因此，协处理器先基于任务命令生成多个任务子命令，并基于各任务子命令调用不同的设备驱动子程序驱动各硬件功能模块执行相应的操作。
可选地，不同的任务子命令可以并行执行或者顺序执行，在此不作限制。
方式2：若任务命令为循环命令类型，则基于任务命令，循环调用协处理器上设置的设备驱动子程序，向硬件功能模块发送硬件操作命令，直至确定命令执行完成。
具体地，执行方式2时，协处理器可以采用以下步骤：
S20131：从任务处理装置的至少一个硬件功能模块中，确定出任务命令匹配的硬件功能模块。
S20132：基于任务命令，调用匹配的硬件功能模块对应的设备驱动子程序，向匹配的硬件功能模块发送至少一个硬件操作命令。
S20133：接收匹配的硬件功能模块执行至少一个硬件操作命令后返回的操作执行结果。
一种实施方式中，硬件功能模块每次执行完成一个硬件操作命令后，均采用中断请求的方式，向协处理器返回该硬件操作命令对应的操作执行结果。协处理器接收到各硬件操作命令分别对应的操作执行结果。
一种实施方式中，硬件功能模块确定各硬件操作命令均执行完成后，获得各硬件操作命令对应的一个操作执行结果，并采用中断请求的方式，将该操作执行结果返回至协处理器。协处理器接收到各硬件操作命令对应的上述一个操作执行结果。
S20134：基于操作执行结果，判断任务命令是否执行完成，若是，则执行S20135，否则，执行S20132。
一种实施方式中，基于任务命令确定需要循环执行n次，则判断是否达到n次，若是，则执行S20135，否则，执行S20132-S20133。其中，n为正整数。
S20135：结束执行任务命令的循环流程。
其中，执行方式2时，具体步骤参见上述方式1的具体实施方式，在此不做赘述。
这是由于任务命令可能为一个需要多次循环执行的命令，则协处理器会调用用于执行任务命令的一个循环程序，以循环多次调用一个或多个硬件功能模块重复执行某一操作集合。
例如，任务命令为打印10张报纸，单次打印程序仅可以控制打印机打印一张报纸，则运行循环打印程序，循环调用10次单次打印程序，以打印10张报纸。
可选地，协处理器可以在符合驱动安装条件时，直接或间接获得设备驱动子程序。例如，可通过中央处理器得到设备驱动子程序。在一些实施例中，如果协处理器的存储能力足够，也可以通过其他方式加载设备驱动子程序至协处理器对应的存储单元。
作为一种实施方式，协处理器可以在确定符合驱动安装条件时，安装设备驱动子程序。示例性地，在确定协处理器符合驱动安装条件时，中央处理器可向任务处理装置中的该协处理器发送包含驱动配置信息的驱动安装指令。协处理器可接收中央处理器发送的包含驱动配置信息的驱动安装指令，并基于该驱动安装指令中包含的驱动配置信息，安装设备驱动子程序。
其中，驱动配置信息用于安装设备驱动子程序。驱动安装指令是中央处理器确定符合驱动安装条件时发送的。
驱动安装条件可以包括但不限于以下条件中的任意一种：设备初始化、驱动升级以及硬件功能模块增加。
可选地，驱动配置信息可以为针对协处理器支持的硬件功能模块所设计的固件(Firmware)文件。驱动配置信息中可以包括：用于运行在协处理器上的操作系统(如，Linux)的信息，以及被配置成用于驱动对应硬件功能模块的一个或多个设备驱动子程序。可选地，更新驱动配置信息时可以只更新Firmware文件中的内容。
示例性地，确定符合驱动安装条件时，中央处理器确定协处理器连接的硬件功能模块， 并获取该硬件功能模块对应的驱动配置信息，以及向任务处理装置中的协处理器发送包含驱动配置信息的驱动安装指令，以供协处理器加载设备驱动子程序。
在一个应用场景下，计算机设备断电重启时可视为符合驱动安装条件，中央处理器可向任务处理装置中的协处理器发送包含驱动配置信息的驱动安装指令。
在另一个应用场景下，中央处理器确定驱动升级，则获取(如，下载以及拷贝等)驱动升级文件，并基于驱动升级文件，获取驱动配置信息，以及向任务处理装置中的协处理器发送包含驱动配置信息的驱动安装指令。
在又一个应用场景下，确定计算机设备增加(即组装)了新的硬件功能模块，则获取新的硬件功能模块的驱动配置信息，并确定新的硬件功能模块对应的协处理器，以及向确定出的协处理器发送包含驱动配置信息的驱动安装指令。
作为另一种实施方式，协处理器也可以不采用上述实施方式的安装过程，而是通过直接启动含有设备驱动子程序的操作系统，以此实现设备驱动子程序在协处理器中自启动。
其中，中央处理器可以向任务处理装置中的协处理器发送含有设备驱动子程序的操作系统，中央处理器发送的内容也可以固件(Firmware)文件的形式提供。协处理器可接收中央处理器发送的含有设备驱动子程序的操作系统，并启动该操作系统，以使设备驱动子程序在协处理器中能够自启动。
当需要执行任务时，协处理器可调用设备驱动子程序向匹配的硬件功能模块发送硬件操作命令。
步骤202：硬件功能模块执行接收到的硬件操作命令，并在确定命令执行完成时，向协处理器返回操作执行结果。
一种实施方式中，硬件功能模块每次执行完成一个硬件操作命令后，均采用中断请求的方式，向协处理器返回该硬件操作命令对应的操作执行结果。协处理器接收到各硬件操作命令分别对应的操作执行结果。
一种实施方式中，硬件功能模块确定各硬件操作命令均执行完成后，获得各硬件操作命令执行的一个操作执行结果，并采用中断请求的方式，将该操作执行结果返回至协处理器。协处理器接收到各硬件操作命令对应的上述一个操作执行结果。
步骤203：协处理器基于接收的操作执行结果，向中央处理器发送命令执行结果。
具体地，执行步骤203时，协处理器可以采用以下步骤：
S2031：确定接收到操作执行结果时，基于操作执行结果，生成命令执行结果。
若操作执行结果为至少一个硬件操作命令分别对应的操作执行结果，则可以分析各操作执行结果，生成命令执行结果。
若操作执行结果为至少一个硬件操作命令对应的一个操作执行结果，则可以将该操作执行结果，作为命令执行结果。
S2032：采用中断请求的方式，将命令执行结果发送给中央处理器。
一种实施方式中，协处理器将命令执行结果存储至设置好的结果读取地址，并采用通信信道，向中央处理器发送结果中断请求。中央处理器确定接收到结果中断请求后，从结果读取地址中读取命令执行结果。
可选地，中央处理器还可以基于任务命令，调用自身运行的设备驱动子程序，直接向任务处理装置中的一个或多个硬件功能模块发送硬件操作命令。
一种实施方式中，中央处理器基于指定类型的任务命令，调用中央处理器中的设备驱动子程序，向任务命令匹配的至少一个硬件功能模块发送分别发送至少一个硬件操作命令。硬件功能模块确定接收到中央处理器发送的硬件操作命令时，执行接收的硬件操作命令，并确定命令执行完成时，采用结果中断请求的方式，向中央处理器返回命令执行结果。
如果采用传统方式对上述支持256路1080p 30FPS解码的硬件进行处理，则中央处理器需要具体负责控制硬件视频编解码单元的工作，每秒需要向人工智能加速卡发送76800个任务命令，处理76800个设备中断。而在采用本申请实施例提供的任务处理方法时，中央处理器不需要具体负责驱动控制硬件视频编解码单元的工作，在一个实验场景下，每秒向设备发送15360个任务命令，处理15360个设备中断。这样，极大地减少了中央处理器资源的消耗。
由于传统方式中，仅在中央处理器中运行设备驱动程序，中央处理器基于任务命令调用自身运行的设备驱动程序生成硬件操作命令，并将硬件操作命令发送至硬件功能模块，以及接收硬件功能模块执行硬件操作命令之后返回的命令执行结果，每一任务命令通常需要硬件功能模块执行一系列的硬件操作，因此，中央处理器通常需要分别针对每一任务命令生成用于控制硬件功能模块执行一系列硬件操作的多个硬件操作命令。再者，如果任务命令是比较复杂的命令(如，循环命令)，则中央处理器需将任务命令分解为多个任务子命令，并分别基于每一任务子命令向不同硬件功能模块发送硬件操作命令，以及接收硬件功能模块返回的每一任务子命令对应的命令执行结果。显然，大量硬件操作命令的生成和传输，以及中断请求处理，会耗费中央处理器大量的处理资源。
而本申请实施例中，根据各硬件功能模块，将设备驱动程序分解为各硬件功能模块分别对应的设备驱动子程序，并将各设备驱动子程序分布在中央处理器以及每一硬件功能模块对应的协处理器上。这样，中央处理器仅需要管理部分硬件功能模块(例如，吞吐量不大的硬件功能模块)，并仅需要向协处理器发送任务命令以及接收协处理器返回的该任务命令的命令执行结果，而不需要针对所有的硬件功能模块进行任务命令处理、硬件操作命令传输以及操作执行结果的接收和汇总，这样可以充分利用硬件能力，极大地降低了中央处理器的负载，提升了系统的性能。再者，中央处理器采用中断请求的方式向协处理发送任务命令，并通过中断请求的方式接收协处理器返回的命令执行结果，双向中断的处理进一步减少了中央处理器资源的消耗。
基于同一发明构思，本申请实施例中还提供了一种任务处理装置。
如图3所示，图3为本申请实施例提供的一种计算机设备中的任务处理装置300的结构示意图，该任务处理装置300包括协处理器301和硬件功能模块302，计算机设备中还包含中央处理器；
协处理器301，用于确定接收到中央处理器发送的任务命令时，基于任务命令，调用协处理器301上设置的设备驱动子程序，向硬件功能模块302发送硬件操作命令；
硬件功能模块302，用于执行接收到的硬件操作命令，并在确定命令执行完成时，向协处理器301返回操作执行结果；
协处理器301，还用于基于接收的操作执行结果，向中央处理器发送命令执行结果。
一种实施方式中，协处理器301还用于：确定接收到中央处理器发送的用户中断请求时，基于用户中断请求，获取任务命令。
一种实施方式中，若任务命令为非循环命令类型，协处理器301还用于：从任务处理装置300的至少一个硬件功能模块302中，确定出任务命令匹配的硬件功能模块302；基于任务命令，调用匹配的硬件功能模块302对应的设备驱动子程序，向匹配的硬件功能模块302发送至少一个硬件操作命令。
一种实施方式中，协处理器301用于：若任务命令为循环命令类型，则从任务处理装置300的至少一个硬件功能模块302中，确定出任务命令匹配的硬件功能模块302；循环执行以下步骤，直至任务命令执行完成：基于任务命令，调用匹配的硬件功能模块302对应的设备驱动子程序，向匹配的硬件功能模块302发送至少一个硬件操作命令；接收匹配的硬件功能模块302执行至少一个硬件操作命令后返回的操作执行结果；基于操作执行结果，判断任务命令是否执行完成。
一种实施方式中，协处理器301还用于：若匹配的硬件功能模块302为多个，则基于任务命令，生成各匹配的硬件功能模块302对应的任务子命令；基于各任务子命令，调用各匹配的硬件功能模块302对应的设备驱动子程序，分别向每一匹配的硬件功能模块302发送至少一个硬件操作命令。
一种实施方式中，协处理器301还用于：确定接收到操作执行结果时，基于操作执行结果，生成命令执行结果；采用中断请求的方式，将命令执行结果发送给中央处理器。
一种实施方式中，中央处理器上设置有设备驱动子程序，中央处理器中的设备驱动子程序和协处理器301中的设备驱动子程序均是基于设备驱动程序获得的，硬件功能模块302用于：确定接收到中央处理器发送的硬件操作命令时，执行硬件操作命令，其中，硬件操作命令是中央处理器基于指定类型的任务命令调用中央处理器中的设备驱动子程序发送的；确定命令执行完成时，采用中断请求的方式，向中央处理器返回命令执行结果。
一种实施方式中，协处理器301用于：接收中央处理器发送的包含驱动配置信息的驱动安装指令，并基于驱动安装指令中包含的驱动配置信息，安装设备驱动子程序，驱动安装指令是中央处理器确定符合驱动安装条件时发送的；或，接收中央处理器发送的含有设 备驱动子程序的操作系统，并启动操作系统，以使设备驱动子程序在协处理器301中自启动。
由于该任务处理装置解决问题的原理以及产生的效果与前述任务处理的方法相似，为了简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容，此处不再赘述。
基于同一发明构思，本申请实施例还提供一种片上系统(System-on-a-chip，SOC)，该片上系统包括中央处理器以及与中央处理器连接的至少一个任务处理装置，该任务处理装置包括协处理器和硬件功能模块，该片上系统用于执行前述的任务处理的方法。该片上系统可以被配置在计算机系统中、设置在计算机设备中，通过执行前述的任务处理的方法，进行终端设备侧或服务器侧的数据处理。在该片上系统中采用了分布式驱动架构的设计，例如可采用图1所示的架构。关于片上系统中对于中央处理器、协处理器和硬件功能模块的其他细节，可参照前述对于任务处理装置、计算机设备、任务处理的方法的相关描述，此处不再赘述。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、电子设备或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
工业实用性
本申请提供了一种任务处理的方法、装置以及计算机设备，根据各硬件功能模块，将设备驱动程序分解为各硬件功能模块分别对应的设备驱动子程序，并将各设备驱动子程序分布在中央处理器以及每一硬件功能模块对应的协处理器上。这样，中央处理器仅需要管理部分硬件功能模块(如，吞吐量不大的硬件功能模块，)，并仅需要向协处理器发送任务命令以及接收协处理器返回的该任务命令的命令执行结果，而不需要针对所有的硬件功能模块进行任务命令处理、硬件操作命令传输以及操作执行结果的接收和汇总，这样可以充分利用硬件能力，极大地降低了中央处理器的负载，提升了系统的性能。再者，中央处理器采用中断请求的方式向协处理发送任务命令，并通过中断请求的方式接收协处理器返回的命令执行结果，双向中断的处理进一步减少了中央处理器资源的消耗。
此外，可以理解的是，本申请的任务处理的方法、装置以及计算机设备是可以重现的，并且可以用在多种工业应用中。例如，本申请的任务处理的方法、装置以及计算机设备可以用于芯片技术领域。

Claims (18)

  1. 一种任务处理的方法，其特征在于，应用于计算机设备中的任务处理装置，所述任务处理装置包括协处理器和硬件功能模块，所述计算机设备中还包含中央处理器，所述方法包括：
    所述协处理器，确定接收到所述中央处理器发送的任务命令时，基于所述任务命令，调用所述协处理器上设置的设备驱动子程序，向所述硬件功能模块发送硬件操作命令；
    所述硬件功能模块，执行接收到的所述硬件操作命令，并在确定命令执行完成时，向所述协处理器返回操作执行结果；
    所述协处理器，基于接收的所述操作执行结果，向所述中央处理器发送命令执行结果。
  2. 根据权利要求1所述的方法，其特征在于，所述接收到所述中央处理器发送的任务命令，包括：
    确定接收到所述中央处理器发送的用户中断请求时，基于所述用户中断请求，获取所述任务命令。
  3. 根据权利要求1所述的方法，其特征在于，若所述任务命令为非循环命令类型，所述基于所述任务命令，调用所述协处理器上设置的设备驱动子程序，向所述硬件功能模块发送硬件操作命令，包括：
    从所述任务处理装置的至少一个硬件功能模块中，确定出所述任务命令匹配的硬件功能模块；
    基于所述任务命令，调用所述匹配的硬件功能模块对应的设备驱动子程序，向所述匹配的硬件功能模块发送至少一个硬件操作命令。
  4. 根据权利要求1所述的方法，其特征在于，若所述任务命令为循环命令类型，所述基于所述任务命令，调用所述协处理器上设置的设备驱动子程序，向所述硬件功能模块发送硬件操作命令，包括：
    从所述任务处理装置的至少一个硬件功能模块中，确定出所述任务命令匹配的硬件功能模块；
    循环执行以下步骤，直至所述任务命令执行完成：
    基于所述任务命令，调用所述匹配的硬件功能模块对应的设备驱动子程序，向所述匹配的硬件功能模块发送至少一个硬件操作命令；
    接收所述匹配的硬件功能模块执行所述至少一个硬件操作命令后返回的操作执行结果；
    基于所述操作执行结果，判断所述任务命令是否执行完成。
  5. 根据权利要求3或4所述的方法，其特征在于，从所述任务处理装置的至少一个硬件功能模块中，确定出所述任务命令匹配的硬件功能模块，采用以下步骤：
    获取所述任务命令中包含的模块标识信息，并将所述模块标识信息对应的硬件功能模 块，确定为所述任务命令匹配的硬件功能模块。
  6. 根据权利要求3至5中任一项所述的方法，其特征在于，基于所述任务命令，调用所述匹配的硬件功能模块对应的设备驱动子程序，向所述匹配的硬件功能模块发送至少一个硬件操作命令，采用以下方式：
    向所述匹配的硬件功能模块对应的设备驱动子程序发送任务命令，该设备驱动子程序执行该任务命令，生成至少一个硬件操作命令，并向所述匹配的硬件功能模块发送生成的硬件操作命令；或者
    基于所述任务命令，生成至少一个驱动控制命令，并分别将每一驱动控制命令发送至所述匹配的硬件功能模块对应的设备驱动子程序，每一设备驱动子程序分别生成每一驱动控制命令对应的至少一个硬件操作命令，并向所述匹配的硬件功能模块发送生成的硬件操作命令。
  7. 根据权利要求3至6中任一项所述的方法，其特征在于，若所述匹配的硬件功能模块为多个，则所述基于所述任务命令，调用所述匹配的硬件功能模块对应的设备驱动子程序，向所述匹配的硬件功能模块发送至少一个硬件操作命令，包括：
    基于所述任务命令，生成各匹配的硬件功能模块对应的任务子命令；
    基于各任务子命令，调用各匹配的硬件功能模块对应的设备驱动子程序，分别向每一匹配的硬件功能模块发送至少一个硬件操作命令。
  8. 根据权利要求1至7中任一项所述的方法，其特征在于，所述硬件功能模块，执行接收到的所述硬件操作命令，并在确定命令执行完成时，向所述协处理器返回操作执行结果，采用以下方式：
    所述硬件功能模块每次执行完成一个硬件操作命令后，均采用中断请求的方式，返回该硬件操作命令对应的操作执行结果；或者
    所述硬件功能模块确定各硬件操作命令均执行完成后，获得各硬件操作命令对应的一个操作执行结果，并采用中断请求的方式，将该操作执行结果返回。
  9. 根据权利要求1至8中任一项所述的方法，其特征在于，所述协处理器，基于接收的所述操作执行结果，向所述中央处理器发送命令执行结果，包括：
    所述协处理器，基于所述操作执行结果，生成所述命令执行结果；
    采用中断请求的方式，将所述命令执行结果发送给所述中央处理器。
  10. 根据权利要求1至9中任一项所述的方法，其特征在于，所述中央处理器上设置有设备驱动子程序，所述中央处理器中的设备驱动子程序和所述协处理器中的设备驱动子程序均是基于设备驱动程序获得的，所述设备驱动子程序是对设备驱动程序分解后获得的，所述方法还包括：
    所述硬件功能模块，执行以下步骤：
    确定接收到所述中央处理器发送的硬件操作命令时，执行所述硬件操作命令，其中， 所述硬件操作命令是所述中央处理器基于指定类型的任务命令调用所述中央处理器中的设备驱动子程序发送的；
    确定命令执行完成时，采用中断请求的方式，向所述中央处理器返回命令执行结果。
  11. 根据权利要求1至10中任一项所述的方法，其特征在于，所述方法还包括：
    所述协处理器，接收所述中央处理器发送的包含驱动配置信息的驱动安装指令，并基于所述驱动安装指令中包含的驱动配置信息，安装设备驱动子程序，所述驱动安装指令是所述中央处理器确定符合驱动安装条件时发送的；
    或，所述协处理器接收所述中央处理器发送的含有设备驱动子程序的操作系统，并启动所述操作系统，以使所述设备驱动子程序在所述协处理器中自启动。
  12. 根据权利要求11所述的方法，其特征在于，所述驱动配置信息是基于针对协处理器支持的硬件功能模块所设计的固件文件得到的；所述驱动配置信息中包括：用于运行在所述协处理器上的操作系统的信息，以及被配置成用于驱动对应硬件功能模块的一个或多个设备驱动子程序。
  13. 一种计算机设备中的任务处理装置，其特征在于，所述任务处理装置包括协处理器和硬件功能模块，所述计算机设备中还包含中央处理器；
    所述协处理器，用于确定接收到所述中央处理器发送的任务命令时，基于所述任务命令，调用所述协处理器上设置的设备驱动子程序，向所述硬件功能模块发送硬件操作命令；
    所述硬件功能模块，用于执行接收到的所述硬件操作命令，并在确定命令执行完成时，向所述协处理器返回操作执行结果；
    所述协处理器，还用于基于接收的所述操作执行结果，向所述中央处理器发送命令执行结果。
  14. 一种计算机设备，其特征在于，包括中央处理器以及任务处理装置；
    所述中央处理器，被配置成用于向所述任务处理装置发送任务命令；
    所述任务处理装置，被配置成用于采用权利要求1至12中任一项所述的方法执行所述任务命令，并将命令执行结果返回至所述中央处理器。
  15. 根据权利要求14所述的计算机设备，其特征在于，所述中央处理器被配置成用于：若确定所述任务命令为非指定类型，则将所述任务命令发送至所述任务处理装置；
    所述中央处理器还被配置成用于：若确定所述任务命令为指定类型，则基于所述任务命令调用所述中央处理器中的设备驱动子程序，向所述任务处理装置中的硬件功能模块发送硬件操作命令；
    所述硬件功能模块被配置成用于：确定接收到所述中央处理器发送的硬件操作命令时，执行所述硬件操作命令，并确定命令执行完成时，采用中断请求的方式，向所述中央处理器返回基于所述硬件操作命令生成的命令执行结果。
  16. 根据权利要求14或15所述的计算机设备，其特征在于，所述中央处理器还被配 置成用于：
    确定符合驱动安装条件时，向所述任务处理装置中的协处理器发送包含驱动配置信息的驱动安装指令，所述驱动配置信息用于提供给所述任务处理装置中的协处理器安装设备驱动子程序；
    或，向所述协处理器发送含有设备驱动子程序的操作系统，以使所述设备驱动子程序在所述协处理器启动所述操作系统的过程中自启动。
  17. 根据权利要求16所述的计算机设备，其特征在于，所述驱动安装条件包括以下条件中的任意一种：设备初始化、驱动升级以及硬件功能模块增加。
  18. 一种片上系统，其特征在于，所述片上系统包括中央处理器以及与所述中央处理器连接的至少一个任务处理装置，所述任务处理装置包括协处理器和硬件功能模块，所述片上系统用于被设置在计算机设备中执行根据权利要求1至12中任一项所述的方法。
PCT/CN2022/114605 2022-05-09 2022-08-24 一种任务处理的方法、装置以及计算机设备 WO2023216461A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210495716.8 2022-05-09
CN202210495716.8A CN114579288B (zh) 2022-05-09 2022-05-09 一种任务处理的方法、装置以及计算机设备

Publications (1)

Publication Number Publication Date
WO2023216461A1 true WO2023216461A1 (zh) 2023-11-16

Family

ID=81767806

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/114605 WO2023216461A1 (zh) 2022-05-09 2022-08-24 一种任务处理的方法、装置以及计算机设备

Country Status (2)

Country Link
CN (1) CN114579288B (zh)
WO (1) WO2023216461A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114579288B (zh) * 2022-05-09 2022-09-02 成都登临科技有限公司 一种任务处理的方法、装置以及计算机设备
CN115586972B (zh) * 2022-11-25 2023-02-28 成都登临科技有限公司 命令生成方法、装置、ai芯片、电子设备及存储介质
CN116800604B (zh) * 2023-08-22 2023-11-07 中国科学院空天信息创新研究院 可配置的激光通信设备控制方法、装置、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101201811A (zh) * 2006-12-11 2008-06-18 边立剑 用于soc的加解密协处理器、其实现方法及编程模型
CN104205042A (zh) * 2012-03-30 2014-12-10 英特尔公司 用于具有通用cpu核心和紧密耦合的加速器的处理核心的上下文切换机制
US20180203713A1 (en) * 2017-01-16 2018-07-19 International Business Machines Corporation Precise error injection for driver testing
CN112631772A (zh) * 2020-12-21 2021-04-09 海光信息技术股份有限公司 密码运算方法、处理器、装置及存储介质
CN114579288A (zh) * 2022-05-09 2022-06-03 成都登临科技有限公司 一种任务处理的方法、装置以及计算机设备

Family Cites Families (13)

* Cited by examiner, † Cited by third party
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
US6832305B2 (en) * 2001-03-14 2004-12-14 Samsung Electronics Co., Ltd. Method and apparatus for executing coprocessor instructions
US7421694B2 (en) * 2003-02-18 2008-09-02 Microsoft Corporation Systems and methods for enhancing performance of a coprocessor
US7444637B2 (en) * 2003-02-18 2008-10-28 Microsoft Corporation Systems and methods for scheduling coprocessor resources in a computing system
US9329840B1 (en) * 2005-12-30 2016-05-03 The Mathworks, Inc. Graphical programming of custom device drivers
CN102098511A (zh) * 2010-12-15 2011-06-15 中兴通讯股份有限公司 一种移动终端及其视频播放的实现方法
JP6379905B2 (ja) * 2014-09-16 2018-08-29 富士通株式会社 制御装置および制御方法
CN104702474B (zh) * 2015-03-11 2018-02-23 华中科技大学 一种基于FPGA的EtherCAT主站装置
CN104866423B (zh) * 2015-05-20 2018-04-20 中国科学院空间应用工程与技术中心 一种软件配置项的测试方法及系统
US10503551B2 (en) * 2017-06-07 2019-12-10 Dell Products L.P. Coordinating FPGA services using cascaded FPGA service managers
CN111400986B (zh) * 2020-02-19 2024-03-19 西安智多晶微电子有限公司 一种集成电路计算设备及计算处理系统
CN114116594A (zh) * 2021-11-05 2022-03-01 中国航空工业集团公司雷华电子技术研究所 一种基于srio总线的多接口兼容扩展系统及通信方法
CN114116015B (zh) * 2022-01-21 2022-06-07 上海登临科技有限公司 用于管理硬件命令队列的方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101201811A (zh) * 2006-12-11 2008-06-18 边立剑 用于soc的加解密协处理器、其实现方法及编程模型
CN104205042A (zh) * 2012-03-30 2014-12-10 英特尔公司 用于具有通用cpu核心和紧密耦合的加速器的处理核心的上下文切换机制
US20180203713A1 (en) * 2017-01-16 2018-07-19 International Business Machines Corporation Precise error injection for driver testing
CN112631772A (zh) * 2020-12-21 2021-04-09 海光信息技术股份有限公司 密码运算方法、处理器、装置及存储介质
CN114579288A (zh) * 2022-05-09 2022-06-03 成都登临科技有限公司 一种任务处理的方法、装置以及计算机设备

Also Published As

Publication number Publication date
CN114579288A (zh) 2022-06-03
CN114579288B (zh) 2022-09-02

Similar Documents

Publication Publication Date Title
WO2023216461A1 (zh) 一种任务处理的方法、装置以及计算机设备
US8631414B2 (en) Distributed resource management in a portable computing device
US7231638B2 (en) Memory sharing in a distributed data processing system using modified address space to create extended address space for copying data
US8806502B2 (en) Batching resource requests in a portable computing device
US5692204A (en) Method and apparatus for computer system power management
US8195968B2 (en) System and method for power reduction by sequestering at least one device or partition in a platform from operating system access
US11093297B2 (en) Workload optimization system
US20030084435A1 (en) Method and system for offloading execution and resources for resource-constrained networked devices
US10402223B1 (en) Scheduling hardware resources for offloading functions in a heterogeneous computing system
WO1993016437A1 (en) A programming model for a coprocessor on a computer system
US20160269479A1 (en) Cloud virtual server scheduling method and apparatus
US20220357990A1 (en) Method for allocating data processing tasks, electronic device, and storage medium
JP2013516711A (ja) 電子デバイスにおける電力を制御するシステムおよび方法
CN111274044B (zh) Gpu虚拟化资源限制处理方法及装置
JP6088531B2 (ja) ローカルサーバーを通じたローカルクライアントアプリケーションのためのイベントサービス
CN114296953B (zh) 一种多云异构系统及任务处理方法
KR20060063643A (ko) 운영 체제의 성능을 향상시키는 방법 및 시스템
CN114820275A (zh) 一种动态定时器及VirtIO GPU性能优化方法
CN109951737B (zh) 视频处理方法、装置、电子设备和计算机可读存储介质
CN114385351A (zh) 云管理平台负载均衡性能优化方法、装置、设备、介质
CN113204426A (zh) 资源池的任务处理方法及相关设备
CN113407331A (zh) 一种任务处理的方法、装置及存储介质
CN111258715A (zh) 多操作系统渲染处理方法及装置
CN110933226B (zh) 应用程序远程托管方法及装置
Tanaka et al. Low latency and resource-aware program composition for large-scale data analysis

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22941402

Country of ref document: EP

Kind code of ref document: A1