Task processing method and device, supernode server, electronic equipment and medium

Abstract

The application discloses a task processing method and device, a supernode server, electronic equipment and a medium, relates to the technical field of processors, converts a data flow graph into a task descriptor set, and stores the task descriptor set to a task descriptor pool. When a to-be-processed task is detected, a target data feature of the to-be-processed task is extracted; according to a feature mapping table, a target task template matched by the target data feature is determined, and a target task descriptor corresponding to the target task template is screened out from the task descriptor pool. The corresponding heterogeneous device is called according to the target task descriptor to process the to-be-processed task. When the to-be-processed task is completed, the next task is determined according to a task dependency table until all tasks are completed. By converting the data flow graph into a task descriptor set that can be directly executed by hardware, the hardware analysis logic of the data trigger controller of the supernode can be accurately matched based on the task descriptor, the hardware low-delay characteristic is retained, and the development threshold is reduced.

Description

Technical Field

[0001] This application relates to the field of processor technology, and more particularly to task processing methods, apparatus, supernode servers, electronic devices, and media. Background Technology

[0002] With the explosive development of data-intensive applications such as real-time monitoring of industrial IoT, environmental perception of intelligent driving, and cloud-based artificial intelligence (AI) inference, the supernode architecture, as the core form of a new multi-core processor system, achieves efficient data flow at the hardware level by leveraging the deep aggregation characteristics of "core-cachate-communication".

[0003] However, the current programming model of supernode architecture has significant bottlenecks. On the one hand, traditional instruction-based programming requires developers to manually manage core allocation, cache scheduling, and cross-core communication, resulting in high code development complexity and low efficiency in adapting to heterogeneous supernode cores. On the other hand, data triggering, as a core capability of supernode hardware, lacks a matching programming layer support, and the low-latency characteristics of the hardware cannot be fully utilized, creating a contradiction between hardware overcapacity and insufficient software model adaptation.

[0004] It is evident that how to retain the low latency characteristics of hardware while lowering the development threshold is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides a task processing method, apparatus, supernode server, electronic device, and medium to at least address the problems of high development thresholds, excessive hardware capabilities, and insufficient software model adaptation in related technologies.

[0006] This application provides a task processing method, including: The data flow graph is converted into a task descriptor set, and the task descriptor set is stored in the task descriptor pool; wherein, the task descriptors contained in the task descriptor set are hardware executable description languages ​​triggered by data; Upon detecting a task to be processed, extract the target data features of the task to be processed; Based on the feature mapping table, the target task template matching the target data features is determined, and the target task descriptor corresponding to the target task template is selected from the task descriptor pool; the feature mapping table records the mapping relationship between the data features of each task and the task template. The corresponding heterogeneous device is invoked to process the task to be processed based on the target task descriptor; Once the pending tasks are completed, the next task is determined according to the task dependency table and designated as the pending task. The operation steps for extracting the target data features of the pending task are then returned until all tasks included in the task dependency table are completed. The task dependency table records the execution order of each task.

[0007] This application also provides a task processing apparatus, including a conversion unit, an extraction unit, a determination unit, a processing unit, and an execution unit; The conversion unit is used to convert the data flow graph into a task descriptor set and store the task descriptor set in the task descriptor pool; wherein, the task descriptors contained in the task descriptor set are hardware executable description languages ​​triggered by data; The extraction unit is used to extract the target data features of the task to be processed when the task to be processed is detected. The determining unit is used to determine the target task template that matches the target data features based on the feature mapping table, and to filter the target task descriptor corresponding to the target task template from the task descriptor pool; wherein, the feature mapping table records the mapping relationship between the data features of each task and the task template; The processing unit is used to call the corresponding heterogeneous device to process the task to be processed according to the target task descriptor; As a unit, it is used to determine the next task according to the task dependency table after completing the task to be processed, and to take the next task as the task to be processed. It then returns the operation steps for extracting the target data features of the task to be processed, until all tasks included in the task dependency table are completed. The task dependency table records the execution order of each task.

[0008] This application also provides a supernode server, including multiple compute nodes, a control node, and a task descriptor pool; wherein each compute node contains multiple heterogeneous devices; The task descriptor pool stores the set of task descriptors obtained by transforming the data flow graph. The task descriptors in the set are hardware executable description languages ​​triggered by data. The control node is connected to multiple computing nodes and is used to execute the steps of any of the above task processing methods based on the task descriptor set.

[0009] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described task processing methods.

[0010] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described task processing methods.

[0011] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described task processing methods.

[0012] This application converts a data flow graph into a task descriptor set and stores the task descriptor set in a task descriptor pool. The task descriptors in the task descriptor set are hardware-executable description languages ​​triggered by data. Upon detecting a task to be processed, the target data features of the task are extracted. Based on a feature mapping table, the target task template matching the target data features is determined, and the target task descriptor corresponding to the target task template is selected from the task descriptor pool. The feature mapping table records the mapping relationship between the data features of each task and the task template. The corresponding heterogeneous device is invoked to process the task based on the target task descriptor. Upon completing a task, the next task is determined according to a task dependency table and designated as the task to be processed. The process of extracting the target data features of the task to be processed is repeated until all tasks in the task dependency table are completed. The task dependency table records the execution order of each task. This technical solution converts the data flow graph into a set of task descriptors that can be directly executed by the hardware. Based on these task descriptors, the hardware parsing logic of the supernode's data trigger controller can be accurately matched, achieving zero-intermediate transfer from software description to hardware execution. This solves the problem of decoupling between the traditional programming model and the supernode hardware, fully preserving the low-latency characteristics of hardware data triggering. Furthermore, the implementation process requires no complex code development, lowering the development threshold. Attached Figure Description

[0013] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a task processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for selecting heterogeneous devices provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0016] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0017] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] Dataflow programming models, such as TensorFlow and Apache Flink, support "task node-edge" dataflow descriptions. However, they have two major limitations: First, they are designed for general-purpose computing architectures and are not adapted to the "shared cache-heterogeneous core" hardware characteristics of supernodes, making it impossible to directly utilize the local storage and data of supernodes to trigger hardware logic. Second, task scheduling relies on the software runtime, requiring forwarding through the operating system kernel layer. It cannot skip intermediate steps to directly drive supernode hardware execution, resulting in increased data processing latency and failing to meet the low-latency requirements of supernode architectures.

[0019] Currently, hardware-triggered programming in the embedded field, such as trigger logic based on Field-Programmable Gate Arrays (FPGAs), can achieve hardware-level task initiation, but developers need to write the trigger logic using hardware description languages ​​(Verilog / VHDL), making the development threshold extremely high. Furthermore, it lacks a standardized "data-task" mapping mechanism; each application requires its own trigger logic design, making it non-reusable and severely limiting its flexibility in adapting to multi-scenario data processing on supernodes, such as video frame decoding and sensor batch sampling.

[0020] Current programming development for supernode architectures suffers from three core limitations, all with significant adaptation defects: First, traditional imperative programming requires developers to manually manage core allocation, cache scheduling, and cross-core communication, resulting in low development efficiency. Furthermore, software scheduling latency is high, failing to match the low-latency characteristics of supernode hardware. This manifests as an inability to automatically identify the heterogeneous core capabilities of supernodes, leading to core utilization rates below 60%. Additionally, data must undergo multiple layers of forwarding before reaching the core, wasting the "zero-copy" advantage of the supernode's shared cache. Second, while general dataflow programming models such as TensorFlow and Apache Flink support "task node-edge" dataflow descriptions, they are decoupled from supernode hardware, failing to utilize the hardware-level data triggering logic of supernodes. Task execution relies on the software runtime, resulting in high latency. When adapting to supernodes, not only must data arrive and wait for software scheduling, rendering hardware triggering capabilities idle, but it also cannot adapt to the supernode's core private cache L1-shared cache L2-local storage hierarchical caching architecture, causing increased data access latency. Third, hardware-triggered programming solutions, such as FPGA-based triggering logic, rely on hardware description languages ​​such as Verilog / VHDL, which have extremely high development barriers and lack a standardized "data-task" mapping mechanism. They are inflexible and cannot handle multiple types of tasks such as AI inference and data filtering in batches when adapting to supernodes. Furthermore, because the triggering logic is strongly bound to the hardware, the code needs to be refactored when the number or type of supernode cores is adjusted, making it difficult to meet the flexible expansion requirements of the supernode architecture.

[0021] Therefore, embodiments of this application provide a task processing method, apparatus, electronic device, and storage medium. By converting a data flow graph into a set of task descriptors that can be directly executed by hardware, the hardware parsing logic of the supernode's data trigger controller can be accurately matched based on the task descriptors, achieving zero-intermediate transfer from software description to hardware execution. This solves the problem of decoupling between traditional programming models and supernode hardware, and fully preserves the low-latency characteristics of hardware data triggering. Furthermore, the implementation process does not require complex code development, lowering the development threshold.

[0022] Figure 1 A flowchart of a task processing method provided in this application embodiment includes: S101: Convert the data flow graph into a task descriptor set and store the task descriptor set in the task descriptor pool.

[0023] The task descriptor set contains task descriptors that are hardware executable description languages ​​triggered by data.

[0024] This application adopts a three-layer abstraction-to-hardware mapping programming architecture, including a three-level programming abstraction of "data flow graph (top layer), task template (middle layer), and task descriptor (bottom layer)". The task descriptor can adopt a 32-byte fixed-length binary structure to accurately match the hardware parsing logic of the supernode data trigger controller, realizing zero transfer from software description to hardware execution and solving the problem of decoupling between traditional programming models and supernode hardware.

[0025] For top-level data flow graphs, in practical applications, programmers can use a graph structure to describe the entire application's processing flow. The graph structure includes task nodes and edges. A task node represents a processing task, such as feature extraction, filtering, classification, or aggregation. Edges represent data flow channels, where data flows from the output of one node to the input of another.

[0026] In this embodiment, a compiler can be used to compile the data flow graph to obtain a task descriptor set. The task descriptor set contains the task descriptor corresponding to each task node.

[0027] The mid-level task template is a static description carrier corresponding to the task node, used to define the core elements required for task execution, which may include: input data format, output data format, computation logic, quality of service (QoS) constraints, and required resources.

[0028] The computational logic can be described using assembly languages ​​such as OpenCL, and after compilation, it is bound to a specific type of core on the supernode. QoS constraints can include latency limits, throughput requirements, etc. Required resources can include core type, memory size, accelerator type, etc. The core type can be the type of heterogeneous device contained in the supernode. A heterogeneous device can be regarded as a heterogeneous core, which can be simply referred to as a core. Heterogeneous cores can include Application-Specific Integrated Circuits (ASICs), Neural Processing Units (NPUs), Tensor Processing Units (TPUs), Graphics Processing Units (GPUs), Data Processing Units (DPUs), etc.

[0029] Task templates need to be compiled by the compiler into task descriptors that can be directly executed by the supernode hardware, and then stored in the task template library of the supernode.

[0030] The task template library is stored in the shared memory area of ​​the supernode, and the address can be fixed between 0x0002_0000 and 0x0002_FFFF. The task template library can contain basic templates such as general-purpose central processing units (CPUs), streaming processing (ASICs), AI computing (NPUs, TPUs, GPUs, etc.), and communication transmission (DPUs, etc.).

[0031] Each template type is associated with a mapping relationship of "input / output format, core type, and QoS constraints". For example, the AI ​​computing template is bound to an NPU core, the input format supports red-green-blue (RGB) / blue-green-red (BGR) images, and the QoS latency limit is ≤500μs.

[0032] Task descriptors are mapped to hardware. Task descriptors are the core bridge connecting the programming model and hardware execution. They are binary structures that the data trigger controller can directly parse.

[0033] In this embodiment, a compiler can be used to parse the data flow graph and extract task node information for each task node; the task node information may include task type, input / output format, and task scheduling requirements. Task scheduling requirements may include QoS constraints.

[0034] At runtime, the application adaptation layer requests a shared cache address to obtain information about the shared cache addresses allocated by the application adaptation layer to each task node in the data flow graph. The shared cache address may include the input data base address (Input BaseAddr), the output data base address (Output Base Addr), and task parameter pointers (Param Pointer), etc.

[0035] The task node information and its corresponding shared cache address information of each task node are populated with fields according to the task descriptor format to obtain the task descriptor for each task node. The task descriptors of all task nodes are used as the task descriptor set of the data flow graph.

[0036] For example, the compiler can read the defect detection tasks (such as TaskNodes) defined on the application side and extract the task type, input / output format, and QoS constraints. At runtime, it requests a shared cache address from the application adaptation layer to obtain the shared cache address information. It then fills in fields such as Task ID, Task Type, Trigger Mode, and Status Flag according to the specified format. The Task ID can be automatically generated; the Task Type matches the core type; the Trigger Mode can be configured according to application requirements; and the Status Flag is initialized to 0x01, indicating that the task is not started (Idle).

[0037] S102: If a task to be processed is detected, extract the target data features of the task to be processed.

[0038] In this embodiment of the application, after the task descriptor set is stored in the task descriptor pool, the subsequent task processing flow is mainly executed by the data trigger controller. Based on the operations required to be executed by the data trigger controller, different functional modules can be divided, including a data monitoring module, a feature parsing module, a task triggering module, and a status management module.

[0039] The feature parsing module establishes a mapping between data features and task templates. Data features encompass key information such as task type, input / output format, and QoS constraints, providing a basis for template matching upon data arrival. Data features may also contain other types of information, which are not limited here.

[0040] After the data monitoring module detects the task to be processed, the feature parsing module extracts data features, such as the task type being video frames and the QoS being high priority.

[0041] In this embodiment of the application, the task to be processed carries data to be processed. In order to ensure the integrity and correctness of the data to be processed, the task to be processed can be verified before extracting the target data features of the task to be processed.

[0042] If the pending task fails the verification, a data retransmission request is sent to the source device of the pending task, and the pending task is stored in the set cache partition.

[0043] If a retransmitted task is obtained, the retransmitted task is verified; until the task passes the verification, the target data features are extracted from the verified task.

[0044] S103: Based on the feature mapping table, determine the target task template that matches the target data features, and filter the target task descriptor corresponding to the target task template from the task descriptor pool.

[0045] The feature mapping table records the mapping relationship between the data features of each task and the task template.

[0046] The feature parsing module queries the mapping relationship between data features and task templates, determines the address of the corresponding task descriptor in the task descriptor pool, and filters the target task descriptor from the task descriptor pool based on the address.

[0047] In this embodiment, task templates can be dynamically expanded, allowing developers to upload custom templates via a programming interface (add_template). The compiler automatically verifies the compatibility of the template with the supernode hardware, such as the existence of the core type. After successful verification, the template is written to the task template library, enabling flexible expansion of general and custom templates.

[0048] S104: Call the corresponding heterogeneous device to process the task to be processed according to the target task descriptor.

[0049] The target task descriptor records the heterogeneous device executing the task and the triggering mode.

[0050] The data trigger controller can parse the target task descriptor, determine the heterogeneous device that will execute the target task, and write the task parameters of the target task into the registers of the heterogeneous device.

[0051] When the target task meets the task start conditions corresponding to the trigger mode, a start signal is sent to the heterogeneous device, so that the heterogeneous device can process the task to be processed based on the task parameters recorded in the registers, and update the status flag recorded in the target task descriptor according to the processing result. The target task descriptor records the trigger mode of the target task.

[0052] In practical applications, the task triggering module of the data trigger controller reads the target task descriptor, parses out the target core group ID, and writes parameters such as Input Base Addr and Output Base Addr into the target core's configuration register. Trigger conditions are configured according to the trigger mode. Upon meeting the trigger conditions, a start signal is sent to the target core, and the Status Flag is updated to 0x02, indicating that the task is running. After the target core completes execution, the Status Flag is updated to 0x04 via a hardware interrupt, indicating that the task is completed. If a timeout occurs, the Status Flag is updated to 0x08, indicating that the task encountered an error. The data trigger controller then performs subsequent operations based on the latest status flags, such as triggering downstream tasks or initiating retransmissions.

[0053] S105: If the pending task is completed, determine the next task according to the task dependency table, and treat the next task as the pending task. Return to the operation steps for extracting the target data features of the pending task, until all tasks included in the task dependency table are completed.

[0054] The task dependency table records the execution order of each task.

[0055] In this embodiment of the application, when deploying the data flow graph, the node dependency relationship can be transformed into a task dependency table at runtime and written into the task triggering module of the data triggering controller; at the same time, the mapping relationship between data features and task templates can be sent to the feature parsing module to complete the hardware-level triggering logic configuration and prepare for automatic triggering after subsequent data arrives.

[0056] The task dependency table is a hardware data structure stored in the data trigger controller, used to manage the execution order and triggering relationship between tasks. The structure of the task dependency table is shown in Table 1 below.

[0057] Table 1 Task Dependency Table .

[0058] In Table 1, the Task ID represents the unique identifier of the current task, which is consistent with the Task ID in the task descriptor. The Upstream Task ID List represents an array of IDs of all upstream tasks that the current task depends on. The array length is fixed, such as a maximum of 4 upstream dependencies.

[0059] In Table 1, NULL in the upstream task ID list indicates no dependency (starting task).

[0060] In Table 1, the dependency status indicates the satisfaction status of the dependency relationship. 0x01 indicates that all dependencies are satisfied (READY), 0x02 indicates that the dependency is waiting (WAITING), 0x04 indicates that the dependency is blocked (BLOCKED), and 0x08 indicates that the satisfaction status of each dependency is represented bitwise (SATISFIED_MASK).

[0061] In Table 1, the trigger condition mask represents the combination of dependency conditions required to trigger this task. 0x01 indicates immediate triggering, 0x02 indicates data full triggering, 0x04 indicates triggering after a preset time threshold, 0x08 indicates dependency triggering, and 0x0A indicates a combination of dependency triggering and data full triggering.

[0062] In Table 1, the downstream task queue pointers are used to point to downstream tasks in the shared cache.

[0063] The process of task triggering and status update: The heterogeneous core completes the task (0x0101), and the hardware interrupt sets the status flag of task 0x0101 to task completion (COMPLETED).

[0064] The data trigger controller performs the following operations: It queries the task dependency table to confirm which tasks depend on 0x0101. It finds task 0x0102 and updates its dependency status, for example, marking the information corresponding to [0x0101] in the upstream task ID list as satisfied, updating the dependency status to WAITING, and checking if all dependencies are satisfied. Trigger condition check: The trigger condition mask for task 0x0102 is 0x0A. If the dependency is satisfied and the data is also satisfied, the status of 0x0102 is changed to READY. The task trigger module detects that 0x0102 is READY and begins execution.

[0065] In this embodiment, a multi-mode data triggering and dynamic adaptation mechanism is adopted. The designed basic triggering modes can include four basic triggering modes: immediate triggering, data full triggering, time triggering, and dependency triggering. These four basic triggering modes can be combined using "OR / AND" methods. Hardware-level configuration is achieved through the triggering mode field of the task descriptor, and the triggering mode can be dynamically adjusted according to data characteristics. For example, when sensor data is missing, it automatically switches from "data full triggering" to "time triggering," solving the current deficiency of poor flexibility in hardware triggering programming.

[0066] As can be seen from the above technical solution, the data flow graph is converted into a task descriptor set, and the task descriptor set is stored in a task descriptor pool. The task descriptors in the task descriptor set are hardware-executable description languages ​​triggered by data. When a task to be processed is detected, the target data features of the task to be processed are extracted. Based on the feature mapping table, the target task template matching the target data features is determined, and the target task descriptor corresponding to the target task template is selected from the task descriptor pool. The feature mapping table records the mapping relationship between the data features of each task and the task template. The corresponding heterogeneous device is invoked to process the task to be processed according to the target task descriptor. When a task to be processed is completed, the next task is determined according to the task dependency table, and the next task is designated as the task to be processed. The steps for extracting the target data features of the task to be processed are returned, until all tasks in the task dependency table are completed. The task dependency table records the execution order of each task. This technical solution converts the data flow graph into a set of task descriptors that can be directly executed by the hardware. Based on these task descriptors, the hardware parsing logic of the supernode's data trigger controller can be accurately matched, achieving zero-intermediate transfer from software description to hardware execution. This solves the problem of decoupling between the traditional programming model and the supernode hardware, fully preserving the low-latency characteristics of hardware data triggering. Furthermore, the implementation process requires no complex code development, lowering the development threshold.

[0067] In this embodiment of the application, the task descriptor may contain multiple fields, and the corresponding information needs to be filled into the fields according to the format of the task descriptor to obtain the task descriptor.

[0068] Each task node has its corresponding task descriptor. Taking any one of the task nodes, namely the target task node, as an example, we will introduce the process of filling in the fields of its task descriptor.

[0069] In the specific implementation, the task type, task scheduling requirements, and shared cache address information of the target task node can be filled into the corresponding fields of the task descriptor.

[0070] Following the format requirements of the identifier field in the task descriptor, generate the task identifier for the target task node and fill it into the identifier field of the task descriptor. Based on the task type and input / output format of the target task node, determine the heterogeneous devices that match the target task node and fill the device identifiers of the matching heterogeneous devices into the device group field of the task descriptor. Fill the task start conditions of the target task node into the trigger mode field of the task descriptor and initialize the status flag field of the task descriptor to the task not started state.

[0071] Filling the task initiation conditions of the target task node into the trigger mode field of the task descriptor can include filling the corresponding mode value of the task initiation condition into the trigger mode field of the task descriptor when the task initiation condition of the target task node is a single condition; or filling the combined mode value into the trigger mode field of the task descriptor when the task initiation conditions of the target task node are combined conditions, based on the combination relationship of the combined conditions and the mode values ​​of the included task initiation conditions.

[0072] Filling the target task node's task type, task scheduling requirements, and shared cache address information into the corresponding fields of the task descriptor can include filling the target task node's task type into the type field of the task descriptor; filling the target task node's task scheduling requirements into the priority field of the task descriptor; and filling the target task node's shared cache address information into the address field of the task descriptor.

[0073] The shared cache address information can include the starting address of the input data, the storage address of the output data, and a pointer to the address of the task configuration parameters in the shared cache. Therefore, in practical applications, the starting address of the input data contained in the shared cache address information can be filled into the input data base address field of the task descriptor; the number of bytes of the input data contained in the shared cache address information can be filled into the input data length field of the task descriptor. The storage address of the output data contained in the shared cache address information can be filled into the output data base address field of the task descriptor; the number of pre-allocated bytes of the output data contained in the shared cache address information can be filled into the output data length field of the task descriptor. The pointer to the address of the task configuration parameters in the shared cache contained in the shared cache address information can be filled into the task parameter pointer field of the task descriptor.

[0074] Table 2 below is a list of information for each field of a task descriptor provided in an embodiment of this application.

[0075] Table 2. List of fields for a task descriptor .

[0076] The field names in Table 2 include Task ID, Task Type, QoS Priority, Input Base Address, Output Base Address, Input Data Length, Output Data Length, Target Core Group ID, Trigger Mode, Status Flag, Param Pointer, Timeout Threshold, and Extension.

[0077] Table 2 shows the Task ID (0-15 bits). Format: 16-bit unsigned integer, range 0~65535. Generated by the compiler as "Application ID + Task Sequence Number", where the Application ID occupies 8 bits and the Task Sequence Number occupies 8 bits. Function: Uniquely identifies each task within a supernode, avoiding task confusion. The data trigger controller's state management module tracks the task lifecycle (waiting / executing / completing / abnormal) through the Task ID; the Task ID is carried during frame transmission, and the receiving end can match retransmission requests with the original task using the Task ID.

[0078] Task Type (16-23 bits). Format: 8-bit enumeration value, which corresponds one-to-one with the heterogeneous core type of the supernode. Table 3 below shows the list of possible values ​​for the task type.

[0079] Table 3. List of possible values ​​for task type .

[0080] Input Base Address (32-63 bits), Output Base Address (64-95 bits). Format: 32-bit physical address, belonging to the internal address space of the supernode shared cache, not a virtual address, dynamically allocated by the application adaptation layer. Function: When heterogeneous cores execute tasks, they directly read data from the Input Base Address and write the results to the Output Base Address, achieving zero-copy. The address must match the supernode cache address mapping table. For example, the shared cache address range of core group 0x02 is 0x1000_0000~0x10FF_FFFF, and the base address must be within this range. If the data length exceeds a single page cache (e.g., 4KB), the hardware automatically reads continuously by address, without software fragmentation. Constraint: The address must be aligned to 64 bytes (the smallest access unit of the supernode cache). If it is not aligned, the hardware automatically rounds up to avoid a decrease in access efficiency.

[0081] Trigger Mode (144-151bit), format: 8-bit enumeration value, linked with the trigger strategy of the data monitoring module, as shown in Table 4 below, which is a list of trigger mode values.

[0082] Table 4. List of possible trigger modes .

[0083] The trigger mode is a key field in the task descriptor, parsed and executed by the task triggering module of the data trigger controller. It defines the actual conditions for task initiation, ensuring that the task is not executed immediately after the task descriptor is issued, but rather triggered only when specific conditions are met. The task triggering module configures the hardware triggering logic based on the trigger mode to ensure that the task starts when data is ready, resources are available, or dependent conditions are met, thereby avoiding problems such as incomplete data or resource conflicts. Its purpose is to ensure the effectiveness of task execution and adapt to diverse data flow characteristics, such as whole-frame arrivals, batch arrivals, or scenarios dependent on upstream results.

[0084] In this embodiment, four basic triggering modes can be used, and these four basic triggering modes can also be combined and extended. The lower 4 bits of the 8-bit array represent the mode type, and the higher 4 bits represent the mode parameters, such as timeout time, threshold percentage, etc. The four basic triggering modes include Immediate Trigger, Data-full Trigger, Time Trigger, and Dependency Trigger.

[0085] Immediate Trigger, mode value: 00000001 (0x01), start condition: execution begins immediately after the task descriptor is sent to the target core group; it does not wait for data to fill, does not wait for time, and does not depend on other tasks. Hardware judgment logic: After receiving the immediate trigger mode, the task triggering module directly writes a start signal to the start register of the target core group; at the same time, it sets the task status flag to Running. Applicable scenarios: high-priority control instructions; computational tasks with small data volume and low latency requirements.

[0086] Data-full Trigger, mode value: 00000010 (0x02), trigger condition: the amount of data in the input data buffer is greater than or equal to the input data length specified in the task descriptor; or reaches a certain percentage of the input data length, such as 80%, specified by the high 4 bits of the parameter. Hardware judgment logic: the data monitoring module counts the effective bytes in the input buffer in real time; when the threshold is reached, a trigger signal is sent to the task triggering module; the task triggering module checks the idle status of the core group, and if idle, it starts immediately. Applicable scenarios: video frame / image block processing, where a whole frame of data must arrive; batch sensor data acquisition, such as 1024 sampling points as a batch.

[0087] Time Trigger, mode value: 00000100 (0x04). Trigger condition: Triggered after a preset time threshold has elapsed since the first data is written to the input buffer; the time threshold is specified by the timeout threshold in the task descriptor or the high 4 bits of the Trigger Mode parameter. Hardware judgment logic: The data monitoring module starts a hardware timer when it detects the arrival of the first data block; when the timer reaches the timeout threshold, the task is triggered even if the data volume has not reached the input data length; the task starts by reading the currently arrived data (partial data execution). Applicable scenarios: Sensor data processing with high real-time requirements; avoiding long waiting times caused by incomplete data arrival.

[0088] Dependency Trigger, mode value: 00001000 (0x08). Trigger condition: The specified upstream task (identified by Task ID) has completed execution and its status is Completed. Optionally, the input buffer data volume of this task meets the requirements. Hardware judgment logic: The task triggering module maintains a task dependency table, recording dependent TaskIDs and their statuses; when the dependent task status changes to Completed, the triggering module checks the resource and data conditions of this task; if the conditions are met, execution is initiated. Applicable scenarios: Pipeline tasks, such as frame decoding → feature extraction → object detection; multi-stage computations requiring guaranteed data processing order.

[0089] In this embodiment, the four triggering modes described above can also be combined based on business requirements. The high 4 bits can be used to represent combined conditions, such as: Data-full OR Timeout trigger, mode value: 00010110 (0x12), where the high 4 bits 0001 represent an "OR" relationship, and the low 4 bits 0110 represent data-full + timeout trigger. Triggering condition: The data-full threshold is reached or the timeout period is reached; either condition is met to trigger the trigger.

[0090] For example: Dependency AND Data-full is triggered when the dependency is complete and the data is full. The mode value is 00101001 (0x29). The high 4 bits 0010 represent the AND relationship, and the low 4 bits 1001 represent the dependency plus the data being full. Triggering condition: It is triggered only when the upstream task is completed and the input data is full.

[0091] Status Flag (152-159 bits), format: 8-bit status bits, each bit represents a status, supports multiple statuses to be marked at the same time, as shown in Table 5 below.

[0092] Table 5 List of Status Flags .

[0093] Function: The hardware provides real-time feedback on the task status through the Status Flag, and the data triggers the controller's exception handling module to perform retransmission, degradation, or alarm operations accordingly.

[0094] The task parameter pointer (160-191 bits) is a 32-bit physical address pointing to the starting address of the task configuration parameters in the shared cache. Its function is to store dynamic parameters required for task execution, avoiding hardcoding parameters into the task descriptor and improving flexibility.

[0095] For example, in AI inference tasks, the Param Pointer points to the offset address of the model weights in the shared cache, such as 0x1001_2000. The kernel reads the weight data at this address during execution, supporting the loading of different model parameters for the same task template.

[0096] After generating the task descriptors, before using the task descriptors of all task nodes as the task descriptor set of the data flow graph, the task descriptors can be validated to ensure their correctness.

[0097] In the embodiments of this application, it can be determined whether the content of each field in the task descriptor of each task node meets the field format requirements.

[0098] If all fields in the task descriptor of each task node meet the field format requirements, determine whether the task type contained in the task descriptor of each task node matches the heterogeneous device type.

[0099] If the task type contained in the task descriptor of each task node matches the heterogeneous device type, it means that the task descriptor field is valid. At this time, the operation of treating the task descriptors of all task nodes as the task descriptor set of the data flow graph can be performed.

[0100] In this embodiment, the compiler verifies the validity of the fields and stores the verified task descriptors in the task descriptor pool of the supernode. The task descriptor pool shares a dedicated area in the cache, with fixed addresses of 0x0001_0000-0x0001_FFFF.

[0101] When data triggers the controller to execute tasks, there may be abnormal scenarios, such as task execution timeout exceptions or data verification failure exceptions.

[0102] In response to task execution timeout exceptions, if the execution time of the target task exceeds the timeout threshold recorded in the target task descriptor, a task interruption signal is sent to the heterogeneous device so that the heterogeneous device can suspend processing the target task.

[0103] In the event of a task timeout, multiple retries can be performed until the maximum number of retries is reached, at which point the retries process ends. To reduce the probability of task timeouts during each retry, the trigger mode can be automatically adjusted.

[0104] In practical implementation, if the number of retries for the target task is less than the retry limit recorded in the target task descriptor, the trigger mode recorded in the target task descriptor can be adjusted. If the target task meets the task startup conditions corresponding to the trigger mode, a startup signal is resent to the heterogeneous device.

[0105] Each time a start signal is resent to a heterogeneous device, the retry count is incremented by one; if the retry count of the target task is greater than or equal to the retry limit recorded in the target task descriptor, an alarm signal is sent and the target task is migrated to a backup device.

[0106] For example, when the task execution time exceeds the timeout threshold carried in the task descriptor, the status management module of the data trigger controller immediately triggers, sending a "task interruption signal" to the target core group to suspend the current task execution and prevent core resources from being occupied. The data trigger controller reads the number of retry attempts carried in the task descriptor (default 3). If the retry limit has not been reached, the task trigger module reissues the task descriptor and automatically adjusts the trigger mode, such as changing the original trigger mode "data full trigger" to "data full or timeout trigger" to avoid timeouts again. If the number of retry attempts is exhausted, an alarm signal is sent to the runtime system, and the runtime automatically migrates the task to an idle backup core group within the supernode to ensure that the task is not interrupted.

[0107] In response to data verification failures, the data monitoring module, when counting input data, immediately marks the erroneous data block if it detects a data verification error, such as a failed Cyclic Redundancy Check (CRC), and sends a "data retransmission request" to the data source. The data retransmission request can be a control frame based on the dedicated communication protocol of the supernode interconnection layer.

[0108] In this embodiment, by marking erroneous data blocks, a data cache isolation mechanism is triggered, isolating the erroneous data blocks to a dedicated cache partition to prevent contamination of normal data. After the retransmitted data arrives, the input data volume is recalculated, and the task is started normally when the triggering conditions are met, ensuring that data integrity does not affect task execution.

[0109] When determining the target task template, an approach of prioritizing exact matching and using compatible matching as a fallback can be adopted.

[0110] In practical implementation, it can be determined whether there are data features in the feature mapping table that are completely consistent with the target data features.

[0111] If there is a data feature in the feature mapping table that is completely consistent with the target data feature, it means that there is a task template that precisely matches the target data feature. In this case, the task template corresponding to the data feature can be used as the target task template.

[0112] If there is no data feature in the feature mapping table that is completely consistent with the target data feature, the target task template that matches the target data feature can be determined from the feature mapping table according to the compatibility matching rule, and the task parameters corresponding to the target data feature can be adjusted.

[0113] The compatibility matching rules include a compatibility order, which can include data format, heterogeneous device types, task scheduling requirements, and resource requirements.

[0114] In this embodiment, a target task template matching the target data features can be determined from the feature mapping table according to the compatibility order included in the compatibility matching rules. Task parameters that are incompatible with the target data features are adjusted according to the data features corresponding to the target task template. When no exact matching template is available, a compatible template is automatically selected and parameters are adjusted to ensure that the task is executable and hardware resources are not wasted.

[0115] In practical applications, task modules that match the data format can be selected first. If no task module matches the data format, task modules that match the heterogeneous device type can be selected. If no task module matches the heterogeneous device type, task modules that match the task scheduling requirements can be selected. If no task module matches the task scheduling requirements, task modules that match the resource requirements can be selected.

[0116] If the data format of the target task template is incompatible with that of the target data features, a format conversion subtask needs to be inserted into the target task template to ensure the normal processing of the target task.

[0117] If the target task template is incompatible with the heterogeneous device types of the target data characteristics, the heterogeneous device types corresponding to the target data characteristics need to be adjusted. If the task scheduling requirements of the target task template are incompatible with those of the target data characteristics, the task scheduling requirements corresponding to the target data characteristics need to be adjusted. If the resources corresponding to the target task template do not meet the resource requirements of the target data characteristics, a data compression subtask and / or a data sharding processing task should be initiated.

[0118] When matching task templates, the feature parsing module of the data trigger controller adopts a two-level strategy of "precise matching first → compatible matching as a fallback".

[0119] Level 1: Exact Matching. This prioritizes finding task templates that perfectly match the data characteristics. Matching dimensions can include input / output data format, core type, QoS constraints, and resource requirements. QoS constraints can include latency, throughput, and priority; resource requirements can include memory size and accelerator type. If a perfectly matching task template is found, the corresponding task descriptor is directly selected.

[0120] Level 2: Compatibility Matching. If no exact matching task template is found, the compatibility matching process is initiated, selecting the closest compatible template in the following order: Data Format Compatibility: Select a template that supports format conversion. Core Type Compatibility: Select the template with the closest performance (e.g., NPU → GPU → General-Purpose CPU, adapting based on computing power degradation). QoS Restriction Compatibility: Select a task template with the same or more lenient QoS constraints (e.g., latency ≤500μs → latency ≤1ms). Resource Degradation Compatibility: Select a template requiring fewer resources (e.g., halved memory requirements).

[0121] Taking video / images as an example, common color encoding formats include color spaces that separate luminance information (Y) and chrominance / color difference information (U, V), with a downsampling ratio of 420, namely YUV420, and the YUV420 half-plane format (NV12). When selecting a template that supports format conversion, such as RGB→BGR or YUV420→NV12, RGB→BGR means that if the data format is RGB but there is no task template that exactly matches it, then a task module with the data format of RGB can be selected. YUV420→NV12 means that if the data format is YUV420 but there is no task template that exactly matches it, then a task module with the data format of NV12 can be selected.

[0122] When a compatible template is selected, the system will automatically adjust the parameters to ensure that the task can be executed and that hardware resources are used efficiently.

[0123] The adjustment mechanism is as follows: Templates matching the data format are prioritized; format conversions are avoided unless absolutely necessary to prevent introducing additional latency. Core type adaptation is implemented, with performance degradation based on computing power. If the NPU is unavailable, GPU execution is used, and the system automatically adjusts task parameters and enables GPU-optimized kernels. QoS adaptation relaxes latency requirements, such as from ≤400μs to ≤500μs. The system improves priority and optimizes scheduling to approximate the original latency requirements as closely as possible.

[0124] If the input / output data format does not match the template, the system automatically inserts a format conversion subtask. The conversion logic is implemented by the template's built-in format converter.

[0125] For example: the template requires RGB input, but the actual data is YUV420 → an automatic "YUV420 to RGB" subtask is inserted. The conversion subtask is automatically scheduled by the data trigger controller after the data arrives, ensuring format compatibility before triggering the main task.

[0126] Core type downgrade or upgrade: If the required core type is unavailable, the system will automatically select the available core with the closest performance.

[0127] Taking downgrade as an example, the task template is bound to the NPU, but the NPU is currently busy. In this case, it is adjusted to automatically bind to the streaming core, which slightly reduces the performance but ensures that the task can be executed.

[0128] Taking the upgrade as an example, the task template is bound to the CPU, but if the current system has an idle NPU and the task can be accelerated, it will be automatically upgraded to the NPU to improve performance.

[0129] The core type selection strategy can be configured to support "performance priority" or "energy efficiency priority" modes.

[0130] Dynamic QoS parameter adaptation: If the QoS constraints of the template are not completely consistent with the actual requirements, the system will adjust according to the following rules.

[0131] Higher latency requirements: Automatically increase task priority, allocate more bandwidth and better cores.

[0132] Higher throughput requirements: Automatically enable pipeline or batch processing mode to improve concurrency.

[0133] When resources are insufficient: Automatically activate the degradation mode, such as reducing processing precision and batch size, to ensure that tasks are not interrupted.

[0134] Flexible resource allocation: If the template lacks sufficient resources (such as memory and cache), the system performs operations such as memory compression or data fragmentation. Memory compression: Automatically enables a data compression subtask to reduce memory usage. Data fragmentation: Processes large amounts of data in fragments, triggering tasks in batches.

[0135] The feature parsing module of the data trigger controller automatically selects the optimal task template through a two-level strategy of "precise matching first → compatibility matching as a fallback". It then uses the task descriptor corresponding to the optimal task template to execute the target task, eliminating the need for developers to manually adapt the core type and solving the problems of low efficiency and low core utilization in traditional programming development.

[0136] In this embodiment, a programming model similar to the Python interface of the open-source framework (TensorFlow) used for machine learning and deep learning can be designed using a high-level programming language (Python), allowing users to define the entire data processing flow with just a few lines of code. Pseudocode examples are used to illustrate the usage of the data flow and task mapping programming model.

[0137] In the specific implementation, a data flow graph can be constructed based on user-defined processing nodes; the data flow graph is then compiled to obtain a task dependency table and a feature mapping table. Each processing node includes the functional requirements of the processing task, input / output formats, heterogeneous device types, and quality of service constraints; the input / output formats include the data formats of the input data and the output data.

[0138] To receive user input data, a data source can be defined. The user can be a developer.

[0139] For example, declare an external data source (DataSource) through a programming interface, named camera_stream, with a data format of YUV420 and a priority of 7. The data source is defined as follows: camera_stream=DataSource("camera", format="YUV420", priority=7).

[0140] Upon detecting an external data source declared by the user through the programming interface, the external data source is converted into a data source description frame. This data source description frame includes the data format, data channel identifier (data channel ID), and priority. The data source description frame is written as a pending task to the data source configuration register so that the data trigger controller can detect the pending task when reading the data source configuration register.

[0141] This statement will be converted by the runtime system into hardware-recognizable data source description information, which will be used by the data monitoring module to perform real-time monitoring and priority scheduling of the input data stream.

[0142] When a user calls DataSource("camera", format="YUV420", priority=7), the runtime system converts the parameters into a data source description frame, writes it to the data source configuration register of the data trigger controller through the application adaptation layer, and the data monitoring module reads the register in real time to obtain information such as the format and priority of the data source, so as to achieve accurate monitoring of the target data stream.

[0143] Users can define processing nodes according to their actual processing needs. Taking the processing flow of video frame decoding, object detection, and result output as an example, users can define a frame decoding node (frame_decode), an object detection node (object_detection), and a result output node (result_output).

[0144] The frame decoding node (frame_decode) receives video data from the camera stream and outputs video frame data converted to RGB format. QoS constraints: end-to-end latency must not exceed 500 microseconds. Its format is as follows: frame_decode=TaskNode("frame_decode", input=camera_stream, output_format="RGB", "core_type":"gpu", # Specifies the core type at the template level. "logic":"opencl_kernel.cl"# Computation logic file, qos={"latency": 500us}).

[0145] The runtime system will automatically match the frame decoding task template from the task template library based on the input data format, output data format and QoS requirements, and generate the corresponding task descriptor.

[0146] The object detection node (object_detection) takes the following inputs: RGB video frames output from the frame_decode node; algorithm model: specifies the use of a lightweight model (YOLOv5-lite); QoS constraint: processing throughput is no less than 30 frames / second. Its format is as follows: object_detect=TaskNode("object_detection", input=frame_decode, "core_type":"npu", # Specifies the core type at the template level. "logic":"opencl_kernel.cl"# Computation logic file, model="yolov5-lite", qos={"throughput":30fps}).

[0147] The runtime system matches the AI ​​inference task template based on the model type and QoS requirements, and binds it to the NPU acceleration core group within the supernode.

[0148] The result output node (result_output) takes the following inputs: the detection results output by the object_detection node (such as target coordinates, category, confidence score, etc.); and outputs the result sent to an external system via a network interface. QoS constraints: transmission priority is 5. Its format is as follows: result_output=TaskNode("result_output", input=object_detect, output_sink="network", "core_type":"dpu", # Specifies the core type at the template level. qos={"priority":5}).

[0149] Users define the three data processing nodes in sequence. Each node describes the functional requirements, inputs and outputs, core type, and quality of service (QoS) constraints of a processing task.

[0150] After defining the processing nodes, a data flow graph can be built based on them. Taking the three processing nodes in the example above, adding them to a data flow graph forms a complete data processing chain. Its format is as follows: graph = DataflowGraph(); graph.add_nodes([frame_decode, object_detect, result_output].

[0151] The data flow graph is compiled into a task dependency table and a data channel mapping table at runtime, which are used by the data trigger controller to automatically manage task scheduling and data transmission paths at runtime.

[0152] When deploying to the supernode, the data flow graph is first deployed to the hardware system through the runtime environment: the compiler converts the data flow graph into a set of hardware-executable task descriptors and loads them into the supernode's task descriptor pool. During the deployment phase, the compiler parses the user data flow graph, maps each Task Node to a task template in the supernode's task library, generates hardware-recognizable task descriptors, and performs static optimizations, including merging pipelined tasks, pre-allocating cache space, and binding tasks to different priority queues based on QoS constraints.

[0153] During runtime, the system loads task mapping information into the feature mapping table of the feature parsing module and works in conjunction with the data triggering controller to continuously monitor the data stream status and dynamically adjust QoS parameters, task core bindings, and data stream branches. The data monitoring module listens to data sources such as camera_stream. When data reaches a threshold or priority condition, the feature parsing module matches the corresponding task template based on the features. The task triggering module then distributes the task to the target core group based on the task descriptor, configuring the shared cache core to start the processing flow. The processing results are written to the output buffer and can trigger downstream tasks, forming a highly efficient pipeline execution.

[0154] Taking the three processing nodes mentioned above as examples, when camera_stream receives data input, the data monitoring module identifies that it meets the triggering conditions and then sends a signal to the feature parsing module. The feature parsing module matches the frame_decode task template based on data features (such as YUV420 format and priority 7), and the task triggering module generates a task descriptor accordingly and sends it for execution. After the frame_decode task is completed, the output data is written to the shared buffer. The data monitoring module detects that the output buffer is ready and automatically triggers the object_detection task. After this task is completed, the result_output task is further triggered, sending the result over the network. The data triggering controller dynamically schedules tasks based on QoS parameters (such as latency, throughput, and priority) in the task descriptor, ensuring that high-priority and low-latency tasks have priority access to computing resources and communication bandwidth.

[0155] In this embodiment, users only need to describe "how the data flows and what processing is done," without needing to worry about underlying scheduling, communication, cache consistency, etc. The data-triggered controller directly drives hardware execution, bypassing the operating system and traditional task scheduler, fully leveraging the low-latency characteristics of supernodes. The same set of data flow descriptions can run on supernode clusters of different sizes, and the compiler automatically adapts to hardware resources at runtime, exhibiting good portability and scalability.

[0156] Task templates can be bound to different core types, and each core type corresponds to heterogeneous devices. In this embodiment, in addition to executing tasks based on the heterogeneous devices corresponding to the core types bound to the task templates, the feature parsing module can also dynamically select the optimal heterogeneous device for executing tasks based on core load and capabilities. The heterogeneous device executing the task can be a single heterogeneous device or a combination of heterogeneous devices.

[0157] Figure 2 A flowchart of a method for selecting heterogeneous devices provided in this application embodiment, the method including: S201: Construct a resource status table based on the real-time status of all available computing resources in the system.

[0158] The real-time status recorded in the resource status table can include any or any combination of load rate, queue status, performance metrics, and health status. In addition, the resource status table can also contain other types of information, which are not limited here.

[0159] The data-triggered controller internally maintains a resource status table that continuously tracks the real-time status of all heterogeneous computing devices available in the system. This resource status table can monitor the following key metrics.

[0160] Load factor: The average utilization of each heterogeneous device or group of heterogeneous devices within the most recent time window (e.g., 1 millisecond), reflecting the current workload.

[0161] Queue status: The ratio of the number of pending tasks on each heterogeneous device to the total queue capacity, indicating the task backlog.

[0162] Performance metrics include average latency, throughput, and power efficiency data for the most recently processed tasks.

[0163] Health status: Operating parameters of heterogeneous equipment, such as temperature, number of errors, voltage frequency, etc.

[0164] These monitoring data are updated with nanosecond-level precision, providing real-time support for dynamic decision-making.

[0165] S202: Filter out compatible devices based on the task type of the task to be processed.

[0166] When the feature parsing module needs to select heterogeneous devices to execute a specific task, it follows this decision-making process: First, compatibility screening: the system filters all heterogeneous devices capable of executing the task based on the task type. Then, multi-dimensional scoring is performed to determine the comprehensive score of each heterogeneous device. Finally, the heterogeneous device with the highest comprehensive score is selected to execute the task.

[0167] S203: Perform a comprehensive evaluation of the real-time status of each compatible device in the resource status table to determine the comprehensive score of each compatible device.

[0168] For each compatible device, the system calculates a comprehensive score based on the currently configured strategy. The system can perform a weighted summation of various indicators to obtain the comprehensive score.

[0169] The scoring considers the following dimensions. Latency optimization: For tasks with strict latency requirements, priority is given to heterogeneous devices with the lowest estimated latency. Estimated latency is calculated based on the current load of the heterogeneous devices.

[0170] Load balancing: To avoid overloading of individual heterogeneous devices, prioritize heterogeneous devices with lower current loads to ensure overall system load balancing.

[0171] Energy efficiency optimization: In battery-powered or high-temperature environments, prioritize heterogeneous devices with higher energy efficiency ratios to reduce power consumption and heat dissipation pressure.

[0172] Data locality: If a heterogeneous device has recently processed similar or adjacent data, selecting that heterogeneous device can reduce data transfer costs.

[0173] Reliability considerations: Based on historical success rates, prioritize heterogeneous equipment with low failure rates and high stability.

[0174] The weights of various indicators can be dynamically adjusted in different scenarios. For example, when the overall system latency is close to the service quality (QoS) limit, the latency optimization weight is increased; when heterogeneous devices overheat or have insufficient power, the energy efficiency optimization weight is increased; and when the load on some heterogeneous devices remains high, the load balancing weight is increased.

[0175] S204: Select the compatible device with the highest overall score as the heterogeneous device corresponding to the target task descriptor.

[0176] Select the heterogeneous device with the highest overall score as the execution target. If there is a tie, prioritize the heterogeneous device type that best matches the task characteristics.

[0177] The heterogeneous device selection mechanism based on real-time system status enables the feature parsing module to dynamically select the most suitable heterogeneous device for execution for each task. This mechanism achieves optimal combination and scheduling of hardware resources through multi-dimensional monitoring and real-time decision-making.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0179] Figure 3 A schematic diagram of a task processing device provided in an embodiment of this application includes a conversion unit 31, an extraction unit 32, a determination unit 33, a processing unit 34, and an execution unit 35; The conversion unit 31 is used to convert the data flow graph into a task descriptor set and store the task descriptor set in the task descriptor pool; wherein the task descriptors contained in the task descriptor set are hardware executable description languages ​​triggered by data. Extraction unit 32 is used to extract target data features of the task to be processed when the task to be processed is detected; The determining unit 33 is used to determine the target task template that matches the target data features based on the feature mapping table, and to filter the target task descriptor corresponding to the target task template from the task descriptor pool; wherein, the feature mapping table records the mapping relationship between the data features of each task and the task template; Processing unit 34 is used to call the corresponding heterogeneous device to process the task to be processed according to the target task descriptor; Unit 35 is used to determine the next task according to the task dependency table after completing the task to be processed, and to take the next task as the task to be processed, and return the operation steps for extracting the target data features of the task to be processed, until all tasks included in the task dependency table are completed; wherein, the task dependency table records the execution order of each task.

[0180] In some embodiments, the processing unit includes a parsing subunit and a startup subunit; The parsing subunit is used to parse the target task descriptor, determine the heterogeneous device that executes the target task, and write the task parameters of the target task into the registers of the heterogeneous device. The startup subunit is used to send a startup signal to the heterogeneous device when the target task meets the task startup conditions corresponding to the trigger mode, so that the heterogeneous device can process the task to be processed based on the task parameters recorded in the register, and update the status flag recorded in the target task descriptor according to the processing result; wherein, the target task descriptor records the trigger mode of the target task.

[0181] In some embodiments, it further includes an interrupt unit, a mode adjustment unit, and a retransmission unit; The interrupt unit is used to send a task interrupt signal to the heterogeneous device when the execution time of the target task exceeds the timeout threshold recorded in the target task descriptor, so that the heterogeneous device can suspend the processing of the target task. The mode adjustment unit is used to adjust the trigger mode recorded in the target task descriptor when the number of retries for the target task is less than the maximum retry value recorded in the target task descriptor. The retransmission unit is used to resend the start signal to the heterogeneous device when the target task meets the task start conditions corresponding to the trigger mode.

[0182] In some embodiments, it further includes an accumulation unit and an alarm unit; The accumulator unit increments the retry count by one each time a start signal is resent to a heterogeneous device. The alarm unit is used to send an alarm signal and migrate the target task to a backup device if the number of retries for the target task is greater than or equal to the retry limit recorded in the target task descriptor.

[0183] In some embodiments, the determining unit includes a judging subunit, a first determining subunit, and an adjusting subunit; The judgment sub-unit is used to determine whether there are data features in the feature mapping table that are completely consistent with the target data features; The first is a sub-unit used to take the task template corresponding to the data feature as the target task template when there is a data feature in the feature mapping table that is completely consistent with the target data feature. The adjustment subunit is used to determine the target task template that matches the target data feature from the feature mapping table according to the compatibility matching rules when there is no data feature in the feature mapping table that is completely consistent with the target data feature, and to adjust the task parameters corresponding to the target data feature.

[0184] In some embodiments, the adjustment subunit is used to determine a target task template that matches the target data features from the feature mapping table according to the compatibility order included in the compatibility matching rules; wherein the compatibility order includes data format, heterogeneous device type, task scheduling requirements and resource requirements; and to adjust task parameters that are incompatible with the target data features and the target task template according to the data features corresponding to the target task template.

[0185] In some embodiments, the adjustment subunit is used to insert a format conversion subtask into the target task template when the data formats of the target task template and the target data features are incompatible. If the target task template and the target data features are incompatible with the heterogeneous device type, adjust the heterogeneous device type corresponding to the target data features; If the task scheduling requirements of the target task template and the target data features are incompatible, adjust the task scheduling requirements corresponding to the target data features. If the resources corresponding to the target task template do not meet the resource requirements of the target data characteristics, start the data compression subtask and / or the data sharding processing task.

[0186] In some embodiments, a verification unit and a transmission unit are also included; The verification unit is used to verify the task to be processed when the task to be processed is detected. The sending unit is used to send a data retransmission request to the source device of the task to be processed if the verification of the task to be processed fails, and to store the task to be processed in the set cache partition. The verification unit is also used to verify the retransmitted task when it is obtained; until the task passes the verification, the extraction unit is triggered to perform the operation steps of extracting the target data features of the task.

[0187] In some embodiments, the conversion unit includes an extraction subunit, an acquisition subunit, a filling subunit, and a second subunit; The extraction sub-unit is used to parse the data flow graph and extract the task node information of each task node; the task node information includes task type, input / output format and task scheduling requirements. The acquisition sub-unit is used to obtain the shared cache address information allocated by the application adaptation layer to each task node in the data flow graph; The filling sub-unit is used to fill the fields of the task node information and its corresponding shared cache address information of each task node according to the format of the task descriptor, so as to obtain the task descriptor corresponding to each task node. The second, as a sub-unit, is used to treat the task descriptors of all task nodes as the task descriptor set of the data flow graph.

[0188] In some embodiments, the filling subunit is used to fill the target task node's task type, task scheduling requirements, and shared cache address information into the corresponding fields of the task descriptor; Generate the task identifier of the target task node according to the format requirements of the identifier field in the task descriptor, and fill the task identifier into the identifier field of the task descriptor; where the target task node is any one of the task nodes. Based on the task type and input / output format of the target task node, determine the heterogeneous devices that match the target task node, and fill the device identifier of the heterogeneous devices that match the target task node into the device group field of the task descriptor. Fill the task start conditions of the target task node into the trigger mode field of the task descriptor, and initialize the status flag field of the task descriptor to the task not started state.

[0189] In some embodiments, the filling subunit is used to fill the mode value corresponding to the task start condition into the trigger mode field of the task descriptor when the task start condition of the target task node is a single condition. When the task initiation condition of the target task node is a combination condition, a combination mode value is constructed based on the combination relationship of the combination conditions and the mode value of the included task initiation conditions, and the combination mode value is filled into the trigger mode field of the task descriptor.

[0190] In some embodiments, the filling sub-unit is used to fill the task type of the target task node into the type field of the task descriptor; Fill in the task scheduling requirements of the target task node into the priority field of the task descriptor; Fill in the shared cache address information of the target task node into the address field of the task descriptor.

[0191] In some embodiments, the filling subunit is used to fill the starting address of the input data contained in the shared cache address information into the input data base address field of the task descriptor; and to fill the number of bytes of the input data contained in the shared cache address information into the input data length field of the task descriptor; Fill the storage address of the output data contained in the shared cache address information into the output data base address field of the task descriptor; fill the number of pre-allocated bytes of the output data contained in the shared cache address information into the output data length field of the task descriptor; Fill the task parameter pointer field of the task descriptor with the pointer to the address of the task configuration parameter in the shared cache, which is included in the shared cache address information.

[0192] In some embodiments, the system further includes a format determination unit and a type determination unit; The format judgment unit is used to determine whether the content of each field in the task descriptor of each task node meets the field format requirements. The type determination unit is used to determine whether the task type contained in the task descriptor of each task node matches the heterogeneous device type, provided that the content of each field in the task descriptor of each task node meets the field format requirements; if the task type contained in the task descriptor of each task node matches the heterogeneous device type, the second sub-unit is triggered to perform the operation of treating the task descriptors of all task nodes as a task descriptor set of the data flow graph.

[0193] In some embodiments, a flow graph construction unit and a compilation unit are also included; The flow graph construction unit is used to construct a data flow graph based on user-defined processing nodes; each processing node includes the functional requirements of the processing task, input and output formats, heterogeneous device types, and quality of service constraints. The compilation unit is used to compile the data flow graph to obtain the task dependency table and feature mapping table.

[0194] In some embodiments, a conversion unit and a writing unit are also included; The conversion unit is used to convert an external data source into a data source description frame when an external data source declared by the user through a programming interface is detected; wherein the data source description frame includes data format, data channel identifier and priority; The write unit is used to write the data source description frame as a task to be processed into the data source configuration register, so that the task to be processed can be detected when the data trigger controller reads the data source configuration register.

[0195] In some embodiments, before calling the corresponding heterogeneous device to process the task to be processed according to the target task descriptor, the system further includes a status table construction unit, a filtering unit, an evaluation unit, and a device determination unit. The status table construction unit is used to construct a resource status table based on the real-time status of all available computing resources in the system; the resource status table contains any or any combination of load rate, queue status, performance indicators and health status; The filtering unit is used to filter out compatible devices based on the task type of the task to be processed; The evaluation unit is used to comprehensively evaluate the real-time status of each compatible device in the resource status table and determine the comprehensive score of each compatible device. The device determination unit is used to identify the compatible device with the highest overall score as the heterogeneous device corresponding to the target task descriptor.

[0196] For a description of the features in the embodiment corresponding to the task processing device, please refer to the relevant description in the embodiment corresponding to the task processing method, which will not be repeated here.

[0197] As can be seen from the above technical solution, the data flow graph is converted into a task descriptor set, and the task descriptor set is stored in a task descriptor pool. The task descriptors in the task descriptor set are hardware-executable description languages ​​triggered by data. When a task to be processed is detected, the target data features of the task to be processed are extracted. Based on the feature mapping table, the target task template matching the target data features is determined, and the target task descriptor corresponding to the target task template is selected from the task descriptor pool. The feature mapping table records the mapping relationship between the data features of each task and the task template. The corresponding heterogeneous device is invoked to process the task to be processed according to the target task descriptor. When a task to be processed is completed, the next task is determined according to the task dependency table, and the next task is designated as the task to be processed. The steps for extracting the target data features of the task to be processed are returned, until all tasks in the task dependency table are completed. The task dependency table records the execution order of each task. This technical solution converts the data flow graph into a set of task descriptors that can be directly executed by the hardware. Based on these task descriptors, the hardware parsing logic of the supernode's data trigger controller can be accurately matched, achieving zero-intermediate transfer from software description to hardware execution. This solves the problem of decoupling between the traditional programming model and the supernode hardware, fully preserving the low-latency characteristics of hardware data triggering. Furthermore, the implementation process requires no complex code development, lowering the development threshold.

[0198] Embodiments of this application also provide a supernode server, including multiple compute nodes, a control node, and a task descriptor pool; wherein each compute node includes multiple heterogeneous devices; The task descriptor pool stores the set of task descriptors obtained by transforming the data flow graph. The task descriptors in the set are hardware executable description languages ​​triggered by data. The control node is connected to multiple computing nodes and is used to execute the steps of any of the above task processing methods based on the task descriptor set.

[0199] The control node includes a data-triggered controller, which invokes heterogeneous devices in the computing node to process tasks in a data-triggered mode.

[0200] A supernode server consists of a control node, a task descriptor pool, and multiple compute nodes. These compute nodes are tightly connected via an efficient interconnect protocol. The supernode server possesses unified memory addressing capabilities across physical nodes and logically presents itself as a single computing system to upper-layer software and users. The efficient interconnect protocol may include a memory-coherent interconnect protocol bus, which refers to a high-speed interconnect protocol capable of achieving cache coherency and supporting memory sharing across multiple devices. This may include, but is not limited to, the Compute Express Link (CXL) bus and the Cache Coherent Interconnect for Accelerators (CCIX) bus.

[0201] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described task processing method embodiments.

[0202] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described task processing method embodiments at runtime.

[0203] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0204] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described task processing method embodiments.

[0205] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described task processing method embodiments.

[0206] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0207] The foregoing has provided a detailed description of a task processing method, apparatus, supernode server, electronic device, computer-readable storage medium, and computer program product provided by this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A task processing method, characterized in that, include: The data flow graph is converted into a task descriptor set, and the task descriptor set is stored in the task descriptor pool; wherein, the task descriptors contained in the task descriptor set are hardware executable description languages ​​triggered by data; Upon detecting a task to be processed, extract the target data features of the task to be processed; Based on the feature mapping table, the target task template matching the target data features is determined, and the target task descriptor corresponding to the target task template is filtered from the task descriptor pool; wherein, the feature mapping table records the mapping relationship between the data features of each task and the task template; The corresponding heterogeneous device is invoked to process the task to be processed according to the target task descriptor; Upon completion of the pending task, the next task is determined according to the task dependency table and designated as the pending task. The operation steps for extracting the target data features of the pending task are then returned until all tasks included in the task dependency table are completed. The task dependency table records the execution order of each task.

2. The task processing method according to claim 1, characterized in that, According to the target task descriptor, the corresponding heterogeneous device is invoked to process the task to be processed, including: The target task descriptor is parsed to determine the heterogeneous device that executes the target task, and the task parameters of the target task are written into the register of the heterogeneous device. When the target task meets the task start conditions corresponding to the trigger mode, a start signal is sent to the heterogeneous device so that the heterogeneous device can process the task to be processed based on the task parameters recorded in the register, and update the status flag recorded in the target task descriptor according to the processing result; wherein, the target task descriptor records the trigger mode of the target task.

3. The task processing method according to claim 1, characterized in that, After invoking the corresponding heterogeneous device to process the task according to the target task descriptor, the process further includes: If the execution time of the target task exceeds the timeout threshold recorded in the target task descriptor, a task interruption signal is sent to the heterogeneous device so that the heterogeneous device can suspend processing the target task. If the number of retries for the target task is less than the maximum retry value recorded in the target task descriptor, adjust the trigger mode recorded in the target task descriptor. If the target task meets the task start conditions corresponding to the trigger mode, a start signal is resent to the heterogeneous device.

4. The task processing method according to claim 3, characterized in that, Also includes: Each time a startup signal is resent to the heterogeneous device, the retry count is incremented by one; If the number of retries for the target task is greater than or equal to the retry limit recorded in the target task descriptor, an alarm signal is sent and the target task is migrated to a backup device.

5. The task processing method according to claim 1, characterized in that, Based on the feature mapping table, the target task template matching the target data features is determined, including: Determine whether there exists a data feature in the feature mapping table that is completely consistent with the target data feature; If a data feature that is completely identical to the target data feature exists in the feature mapping table, the task template corresponding to the data feature shall be used as the target task template. If no data feature completely matches the target data feature exists in the feature mapping table, a target task template matching the target data feature is determined from the feature mapping table according to the compatibility matching rule, and the task parameters corresponding to the target data feature are adjusted.

6. The task processing method according to claim 5, characterized in that, According to the compatibility matching rules, a target task template matching the target data features is determined from the feature mapping table, and the task parameters corresponding to the target data features are adjusted, including: According to the compatibility order included in the compatibility matching rules, a target task template that matches the target data features is determined from the feature mapping table; wherein, the compatibility order includes data format, heterogeneous device type, task scheduling requirements, and resource requirements; Adjust task parameters that are incompatible with the target data features according to the data features corresponding to the target task template.

7. The task processing method according to claim 6, characterized in that, Adjusting task parameters that are incompatible with the target data features and the target task template according to the data features corresponding to the target task template, including: If the data format of the target task template is incompatible with that of the target data feature, a format conversion subtask is inserted into the target task template. If the target task template is incompatible with the heterogeneous device type of the target data feature, adjust the heterogeneous device type corresponding to the target data feature; If the target task template is incompatible with the task scheduling requirements of the target data feature, adjust the task scheduling requirements corresponding to the target data feature. If the resources corresponding to the target task template do not meet the resource requirements of the target data characteristics, start the data compression subtask and / or the data fragmentation processing task.

8. The task processing method according to claim 1, characterized in that, Before extracting the target data features of the task to be processed, the process also includes: If a task to be processed is detected, the task to be processed is verified. If the pending task fails the verification, a data retransmission request is sent to the source device of the pending task, and the pending task is stored in the set cache partition. If a retransmission task is obtained, the retransmission task is verified. Once the task to be processed passes the verification, the operation step of extracting the target data features of the task to be processed is executed.

9. The task processing method according to claim 1, characterized in that, Convert the data flow graph into a set of task descriptors, including: The data flow graph is parsed to extract task node information for each task node; wherein, the task node information includes task type, input / output format, and task scheduling requirements; Obtain the shared cache address information allocated by the application adaptation layer to each task node in the data flow graph; Fill in the fields of each task node with its task node information and its corresponding shared cache address information according to the format of the task descriptor to obtain the task descriptor corresponding to each task node. The task descriptors of all task nodes are used as the task descriptor set of the data flow graph.

10. The task processing method according to claim 9, characterized in that, The task node information and its corresponding shared cache address information of each task node are populated with fields according to the task descriptor format to obtain the task descriptor corresponding to each task node, including: Fill in the task type, task scheduling requirements, and shared cache address information of the target task node into the corresponding fields of the task descriptor; According to the format requirements of the identifier field in the task descriptor, generate the task identifier of the target task node and fill the task identifier into the identifier field of the task descriptor; wherein, the target task node is any one of the task nodes; Based on the task type and input / output format of the target task node, determine the heterogeneous device that matches the target task node, and fill the device identifier of the heterogeneous device that matches the target task node into the device group field of the task descriptor; Fill the task start conditions of the target task node into the trigger mode field of the task descriptor, and initialize the status flag field of the task descriptor to the task not started state.

11. The task processing method according to claim 10, characterized in that, Fill the task initiation conditions of the target task node into the trigger mode field of the task descriptor, including: If the task initiation condition of the target task node is a single condition, fill the mode value corresponding to the task initiation condition into the trigger mode field of the task descriptor; When the task initiation condition of the target task node is a combination condition, a combination mode value is constructed based on the combination relationship of the combination conditions and the mode value of the included task initiation conditions, and the combination mode value is filled into the trigger mode field of the task descriptor.

12. The task processing method according to claim 10, characterized in that, Fill the target task node's task type, task scheduling requirements, and shared cache address information into the corresponding fields of the task descriptor, including: Fill the task type of the target task node into the type field of the task descriptor; Fill the task scheduling requirements of the target task node into the priority field of the task descriptor; Fill the shared cache address information of the target task node into the address field of the task descriptor.

13. The task processing method according to claim 12, characterized in that, Fill the shared cache address information of the target task node into the address field of the task descriptor, including: Fill the starting address of the input data contained in the shared cache address information into the input data base address field of the task descriptor; fill the number of bytes of the input data contained in the shared cache address information into the input data length field of the task descriptor; Fill the storage address of the output data contained in the shared cache address information into the output data base address field of the task descriptor; fill the number of pre-allocated bytes of the output data contained in the shared cache address information into the output data length field of the task descriptor; The pointer to the address of the task configuration parameter in the shared cache, contained in the shared cache address information, is filled into the task parameter pointer field of the task descriptor.

14. The task processing method according to claim 9, characterized in that, Before including the task descriptors of all task nodes as the task descriptor set of the data flow graph, the following is also included: Determine whether the content of each field in the task descriptor of each task node meets the field format requirements; If all fields in the task descriptor of each task node meet the field format requirements, determine whether the task type contained in the task descriptor of each task node matches the heterogeneous device type. If the task type contained in the task descriptor of each task node matches the heterogeneous device type, perform the operation of using the task descriptors of all task nodes as the task descriptor set of the data flow graph.

15. The task processing method according to claim 1, characterized in that, Before converting the data flow graph into a task descriptor set, the following steps are also included: Based on the user-defined processing nodes, a data flow diagram is constructed; each processing node includes the functional requirements of the processing task, input and output formats, heterogeneous device types, and service quality constraints. The data flow graph is compiled to obtain a task dependency table and a feature mapping table.

16. The task processing method according to claim 1, characterized in that, Before extracting the target data features of the task to be processed when a task to be processed is detected, the method further includes: Upon detecting an external data source declared by the user through a programming interface, the external data source is converted into a data source description frame; wherein, the data source description frame includes data format, data channel identifier, and priority; The data source description frame is written as a task to be processed into the data source configuration register so that the data trigger controller can detect the task to be processed when reading the data source configuration register.

17. The task processing method according to claim 1, characterized in that, Before invoking the corresponding heterogeneous device to process the task according to the target task descriptor, the method further includes: Based on the real-time status of all available computing resources in the system, a resource status table is constructed; wherein, the resource status table includes any or any combination of load rate, queue status, performance indicators and health status; Based on the task type of the task to be processed, compatible devices are selected; The real-time status of each compatible device in the resource status table is comprehensively evaluated to determine the overall score of each compatible device; The compatible device with the highest overall score is selected as the heterogeneous device corresponding to the target task descriptor.

18. A task processing device, characterized in that, It includes a conversion unit, an extraction unit, a determination unit, a processing unit, and an application unit; The conversion unit is used to convert the data flow graph into a task descriptor set and store the task descriptor set in the task descriptor pool; wherein the task descriptors contained in the task descriptor set are hardware executable description languages ​​triggered by data; The extraction unit is used to extract the target data features of the task to be processed when the task to be processed is detected. The determining unit is used to determine the target task template matched by the target data features based on the feature mapping table, and to filter the target task descriptor corresponding to the target task template from the task descriptor pool; wherein, the feature mapping table records the mapping relationship between the data features of each task and the task template; The processing unit is configured to call the corresponding heterogeneous device to process the task to be processed according to the target task descriptor; The unit is used to determine the next task according to the task dependency table after completing the task to be processed, and to take the next task as the task to be processed, and return the operation steps of extracting the target data features of the task to be processed, until all tasks included in the task dependency table are completed; wherein, the task dependency table records the execution order of each task.

19. A supernode server, characterized in that, It includes multiple computing nodes, control nodes, and a task descriptor pool; wherein each computing node contains multiple heterogeneous devices; The task descriptor pool is used to store the task descriptor set obtained by converting the data flow graph. The task descriptor set contains task descriptors that are hardware executable description languages ​​triggered by data. The control node is connected to multiple computing nodes and is used to execute the steps of the task processing method as described in any one of claims 1 to 17 based on the task descriptor set.

20. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the task processing method as described in any one of claims 1 to 17.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the task processing method as described in any one of claims 1 to 17.

Images