UNIVERSAL CORE-TO-ACCELERATER COMMUNICATION ARCHITECTURE

Abstract

Methods and devices relating to a universal core-to-accelerator communication architecture for improved performance and / or programmability are described. In one embodiment, a sending agent is coupled to a processor core, and a receiving agent is coupled to a hardware accelerator device. The memory stores data corresponding to a request from the processor core. The sending agent and the receiving agent maintain a communication channel to enable communication between the processor core and the hardware accelerator device in response to the request. Further embodiments are also disclosed and claimed.

Description

TECHNICAL AREA

[0001] The present disclosure relates generally to the field of computer processors. In particular, one embodiment relates to a universal core-to-accelerator communication architecture for improved performance and / or programmability. STATE OF THE ART

[0002] Some on-chip accelerators can communicate using a combination of techniques, including memory-mapped input / output or MMIO read / write operations, device direct memory (DMA) read / write operations, and / or interrupt / query operations. Such approaches can cause several inefficiencies during communication, such as slow MMIO write speeds, overhead for shared queue management (e.g., due to batch size during dynamic requests and / or head / tail updates), reordered execution and quality of service (QoS) issues, cache row bouncing (where a cache row is unnecessarily moved across multiple caches), and so on.

[0003] Therefore, on-chip accelerators would operate more efficiently if such communication problems were adequately addressed. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The detailed description is provided with reference to the accompanying figures. In the figures, the leftmost digit(s) of a reference number identify the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical elements. Fig. Figure 1 presents a comparative block diagram of communication models according to some embodiments. Fig. Figure 2 shows a block diagram of a core-to-accelerator communication architecture according to one embodiment. Fig. 3A and Fig. Figure 3B presents block diagrams of a hardware architecture for a core-to-accelerator communication architecture according to some embodiments. Fig. 4A and Fig. 4B represents flowcharts according to some embodiments. Fig. Figure 5 presents an exemplary Pseudocode 500 for implementing a core-to-accelerator communication architecture according to one embodiment. Fig. Figure 6A is a block diagram illustrating both an exemplary pre-ordered pipeline and an exemplary reordered output / execution pipeline with register renaming according to embodiments. Fig. Figure 6B is a block diagram illustrating both an embodiment of an order-preserving architecture kernel and an exemplary order-changing output / execution architecture kernel with register renaming, which is to be included in a processor according to embodiments. Fig. Figure 7 shows a block diagram of a system-on-chip or SOC package according to one embodiment. Fig. Figure 8 is a block diagram of a processing system according to one embodiment. Fig. Figure 9 is a block diagram of an embodiment of a processor with one or more processor cores according to some embodiments. Fig. Figure 10 is a block diagram of a graphics processor according to one embodiment. DETAILED DESCRIPTION

[0005] The following description sets forth numerous specific details to provide a comprehensive understanding of the various embodiments. However, several embodiments can be implemented without these specific details. In other cases, known methods, procedures, components, and circuits have not been described in detail to avoid obscuring the particular embodiments. Furthermore, different aspects of embodiments can be implemented using various means, such as integrated semiconductor circuits (“hardware”), computer-readable instructions organized into one or more programs (“software”), or any combination of hardware and software.For the purposes of this disclosure, any reference to “logic” shall mean either hardware (such as logic circuit arrangement or more generally circuit arrangement or circuit), software, firmware or any combination thereof.

[0006] As mentioned above, some on-chip accelerators (such as Data Streaming Accelerator (DSA), Intel® Analytics Accelerator (IAX), and Dynamic Load Balancer (DLB), provided by Intel® Corporation of Santa Clara, California) communicate through a combination of techniques, including memory-mapped I / O or MMIO read / write operations, device direct memory (DMA) read / write operations, and / or interrupt / mwait / query operations. As discussed here, "mwait" generally refers to a cue that allows a processor to halt instruction execution and enter an implementation-dependent optimized state until a class of events occurs that is used to wake the processor based on a memory location.Such approaches can cause several inefficiencies during communication, such as slow MMIO write speed, overhead for shared queue management (e.g., due to batch size on dynamic requests), problems with reordered execution and quality of service (QoS), cache line bouncing, etc.

[0007] Furthermore, a relatively recently introduced accelerator interface architecture, or AIA instruction set, from Intel Corporation (including, for example, MOVDIR64B and ENQCMD instructions) aims to improve MMIO write speeds. While AIA supports efficient job distribution, synchronization, and signaling for accelerators, this instruction set does not appear to address all higher-level software overhead issues, such as queue management and / or dynamic request stacking, QoS, and reordered requests. Additionally, even experienced programmers may find it challenging to tune and develop highly efficient drivers and applications to fully utilize hardware accelerators. There is also no universal communication architecture or implementation for accelerator communication.Different hardware accelerators and drivers can be implemented differently depending on the hardware and software developers. The lack of a universal communication solution for accelerators leads to duplicated implementation efforts and unexpected errors.

[0008] To this end, some embodiments provide a universal core for accelerator communication architecture for improved performance and / or programmability. One embodiment provides a hardware-based approach to unify and simplify driver and application development for leveraging hardware accelerators. The simplified software can free up a significant amount of central processing unit (CPU) or processor cycles for other valuable work.

[0009] In contrast, a combination of established low-level communication techniques can be used for core-to-accelerator communication. These can include MMIO read / write operations using a direct memory or DMA read / write operation by the accelerator, and interrupt / query / mwait-based result queries. However, a driver or application still needs to be designed to use these low-level methods to communicate efficiently with an accelerator. Even with such techniques, direct memories can be highly ordered with respect to other direct memories at the same address. Because direct memory targets the limited MMIO addresses from the accelerator to submit jobs, these MMIO writes could be serialized and slow down the processor core backend. Furthermore, batching can be used for optimization to reduce such overhead.Batch production can require high-level application involvement to balance latency and throughput. As a result, these issues complicate driver and application design and programming efforts.

[0010] Furthermore, some existing software-based communication solutions can consume a significant number of CPU cycles. For example, a driver that controls an on-chip accelerator can consume over thirty CPU cycles just to offload a single request. Reducing this CPU overhead creates an opportunity to accelerate sub-100-cycle tasks, such as memory allocation, data serialization / deserialization, and so on.

[0011] In some implementations, a core-to-accelerator communication architecture (sometimes called "ACRE") uses a hardware-based approach to unify and simplify the core-to-accelerator communication interface. ACRE includes a send agent and a receive agent. These agents are responsible for establishing one or more communication channels between a core and an accelerator and exchanging all necessary messages between the core and the accelerator without software intervention. Accordingly, ACRE can offload the software management of the communication channel(s) to the hardware agents, thereby removing software overhead and complexity from the CPU core.

[0012] In one embodiment, ACRE creates and maintains one or more core-to-accelerator communication channels in hardware. Some advantages include: (1) exposing fewer low-level hardware specifications to software, unifying the interface, and reducing programming overhead; (2) reducing core pipeline overhead, freeing up more cycles for other useful tasks; and / or (3) additional features, such as QoS or dynamic stacking, can be implemented in hardware by monitoring hardware events.

[0013] To utilize an on-chip accelerator, applications can choose to use user-space drivers to send job descriptors (e.g., 64 bytes) to the accelerator's input buffer either through a shared descriptor ring buffer or directly via MMIO. If a shared ring buffer is used, a batch descriptor or "doorbell" is written to the accelerator via MMIO to notify the batch of job descriptors. The accelerator DMA then reads the individual job descriptors from the ring buffer. For result querying, software can check a flag bit in a completion record written by the accelerator after job completion (e.g., using a DSA driver). Software can then read the results from the completion record and perform post-processing if necessary.To work with the driver, upper-level applications must be modified to correctly call the application programming interface(s) (API(s)). For example, a driver might provide three APIs, including: `Enqueue_op()`, which queues a job into a shared ring buffer; `Perform_ops()`, which enqueues a batch descriptor via MMIO into an accelerator describing previously enqueued jobs; and `Completed_ops()`, which checks completed results from the accelerator. It is up to the application to call each of the APIs in pipeline mode to achieve an optimal throughput-latency trade-off.

[0014] In such communication methods, software maintains the communication channels in shared memory and sends batch descriptors to accelerators using MMIO writes (i.e., using direct stores like MOVDIR64B or regular stores to write to the accelerator port's MMIO address). It is up to the driver and application developer to decide when and how to batch requests and how to maintain the ring buffer (or another data structure if more efficient). There are two problems with such a method. These problems could prevent many computing systems from using hardware accelerators.

[0015] First, driver and application maintenance overhead is high. It is generally not easy to develop highly efficient drivers and rewrite applications to use those drivers, and to maintain both drivers and applications across different hardware generations. The complexity of software development stems primarily from three aspects: (1) The asynchronous communication model requires software to asynchronously check results and submit jobs. This necessitates careful software pipeline design to overlap CPU processing with accelerator processing. (2) Even with an AIA instruction, software must dynamically evaluate the batch size to strike a balance between throughput and latency. Smaller batch sizes might result in larger volumes of serialized MMIO writes, but larger batches might introduce additional queue latency in the software queue. This requires software to make dynamic decisions based on platform performance insights that are not readily available. (3) In a multi-tenant environment where software sends jobs using ENQCMD instructions, a retry signal is returned to the software, and the software must make intelligent QoS decisions about when and how often to retry. Generally, a multi-tenant system allows multiple users to share a single hardware accelerator or device. A tenant can be a single user or a group of users, such as a customer organization, who share access to and permissions for the hardware accelerator or device. For example, a tenant might include a virtual machine (VM), a container, and / or a software application. One goal of ACRE is to offload these complexities to one or more hardware agents to provide a cleaner and simpler software interface.

[0016] Secondly, a software communication channel requires significant CPU cycles that could be used for other valuable work. For example, a minimal implementation (with very poor system throughput) might cost approximately eight CPU cycles per request sent, but a full implementation could cost more than 40 CPU cycles.

[0017] Fig. Figure 1 presents a comparative block diagram of communication models according to some embodiments. As shown on the left side of Figure 1, the diagram is a comparative representation of communication models according to some embodiments. Fig. As shown in Figure 1(A), some existing communication models can include software modification and maintenance tasks, including a software or SW pipeline application 102, a highly tuned user-space driver 104 running on a processor core and / or accelerator (ACC) 106 hardware (HW). In one embodiment (see, for example, the right side of Figure 1(A)), the software modification and maintenance tasks can be performed by a software or SW pipeline application 102, a highly tuned user-space driver 104, running on a processor core and / or accelerator (ACC) 106 hardware (HW). Fig. 1 (B)), the proposed ACRE enables an application with minimal change 110, a thin driver 112 with channels that are efficiently managed in hardware using an ACRE circuit arrangement 114 that can be tuned or optimized (e.g. by a CPU vendor).

[0018] One embodiment proposes a hardware agent to address the aforementioned problems. In addition to eliminating software overhead, development efforts for software implementation are reduced by using on-chip hardware accelerators, which, for example, expose fewer hardware specification details to software. Generally, a hardware-based approach makes software more robust against hardware failures, thereby ensuring, for example, low software maintenance across different products.

[0019] In one embodiment, the ACRE logic includes an intellectual property or IP hardware block plus software co-design to offload the following communication tasks to software: (1) management of shared ring buffers; (2) a dynamic batch algorithm and MMIO write operation of the batch descriptor; (3) a notification-based result query procedure with cache line prefetching and demotion; and / or (4) a QoS algorithm in a multi-tenant environment.

[0020] Fig. Figure 2 shows a block diagram of a core-to-accelerator communication architecture 200 according to one embodiment. One or more operations of the core-to-accelerator communication architecture (here sometimes also referred to as "ACRE") can be performed by the ACRE circuit arrangement 114.

[0021] In particular, the ACRE circuit arrangement 114 may be able to overcome the problems of existing software-based communication models by providing one or more transmitting agents (where two transmitting agents 202-1 and 202-2 in Fig. 2 (for simplicity) and a receiving agent 204. These agents can be used to establish communication channels between one or more processor cores (e.g., cores 206-1 and / or 206-2) and one or more accelerators 208. These agents (instead of software) would manage the communication channels, thereby reducing the software overhead of queue maintenance. In at least one embodiment, an agent dynamically stacks requests by detecting streaming workload(s) to find a trade-off between latency and throughput. The agent can demote and / or prefetch cache lines between a core's local cache (such as a level 1 (L1) cache or a level 2 (L2) cache) and a last-level cache (LLC) 210 shared between cores 206-1 / 206-2 to reduce cache line bouncing overhead. In one embodiment, the receiving agent 204 (e.g.Perform rate limiting tasks for QoS in multi-tenant environments (using monitoring logic). As described in... Fig. As shown in Figure 2, the sending agents 202-1 / 202-2 and the receiving agent 204 can communicate via shared memory (LLC 210) and direct MMIO memory 214. While an LLC 210 can be used as shared memory to communicate between the agents, other types of storage devices (or a combination of storage devices) can also be used that the sending agent(s) and the receiving agent(s) can access to share data; therefore, embodiments are not limited to the use of an LLC.

[0022] In one embodiment, ACRE includes two hardware components: the sending agent(s) on the sender side (e.g., a processor core) and the receiving agent on the receiver side (e.g., an accelerator). The sending agent can act as a proxy for the sender to communicate with the receiving agent by creating a ring-based communication channel in memory. The receiving agent acts as a proxy for a receiver, buffering incoming requests in its internal buffer. It also helps maintain tenant QoS and track completion results. In at least one embodiment of some accelerator designs (such as DSA, provided by Intel Corporation in Santa Clara, California), a job descriptor-based communication model can be followed, where each acceleration job or task is described by a job descriptor (e.g., 64 bytes in size).These job descriptors are either routed through the communication channel(s) or through the shared ring buffer in memory (as shown, for example, in LLC 210) for reading by an accelerator (e.g., using a direct memory access or DMA operation 212 or a direct MMIO operation 214 directed to the receive agent).

[0023] Fig. 3A and Fig. Figure 3B presents block diagrams of a hardware architecture for a core-to-accelerator communication architecture according to some embodiments. One or more operations of the core-to-accelerator communication architecture (here sometimes referred to as "ACRE") can be performed by the ACRE circuit arrangement 114.

[0024] Referring to Fig. 3A and Fig. 3B The high-level workflow of an ACRE circuit arrangement for sending a batch of acceleration job requests can be described as follows. First, software (e.g., via a processor core) sends a request 302 by writing the job descriptor to the internal registers of the send agent (304) (labeled as descriptor register 306). The send agent 304 then uses loosely ordered memory to store the descriptor in the shared ring buffer 346 in memory 318. After accumulating a selected number of job descriptors (e.g., determined by comparing the number of stored job descriptors with a threshold), the sending agent 304 writes a batch descriptor to the MMIO queue 314 of the receiving agent 312 (e.g., using an MMIO write operation). This MMIO write operation can be performed either using a regular write operation or an AIA command.This MMIO write operation serves as a notification to the receive agent 312 that the batch of descriptors is ready. The send agent 304 can use the result query logic 342 to query the result of the acceleration job. The send agent can write descriptors to the write combination buffer (WC buffer 343) instead of writing directly to memory to improve performance. The send agent 304 can also read data from memory 318 using the load queue 345 of a CPU core.

[0025] If the batch descriptor is accepted, it is buffered in the receiving agent's incoming request buffer 314 for further processing by an accelerator 316. In some embodiments, the receiving agent 312 may reject the batch descriptor due to a rate limit violation. Subsequently, the accelerator 316 reads the batch descriptor from the receiving agent 312 and reads individual job descriptors from memory 318 using the DMA engine 320. Alternatively, the sending agent can write the individual job descriptor directly to the receiving agent 310 without using the shared ring buffer stored in memory 318. The sending agent 330 can use a hardware-based batching algorithm to determine at runtime which method is appropriate, for example, to decide whether or not to stack operations.The mechanism can be compatible with any accelerator and could also operate for accelerator-to-accelerator communication, thus enabling a universal communication interface. The receiving agent can use occupancy monitoring logic (350) together with the occupancy table (352) to monitor the occupancy of an inbound queue (e.g., in the inbound request buffer (314)) for each tenant on the platform. By monitoring occupancy, an algorithm can be designed based on occupancy to implement a QoS feature, such as rate limiting. For example, if a tenant has high queue occupancy, the receiving agent can reject that tenant's request more frequently to allocate more resources to other tenants.As discussed further below, the algorithm sets a threshold based on the occupancy, and if the number of requests from a PASID exceeds the threshold, a retry signal is sent. In one embodiment, requests from the PASID that exceed a certain threshold (as determined in Operation 458, discussed below) are returned with a "retry signal" at Operation 460. Otherwise, the descriptor is buffered in the hardware buffer so that the accelerator can pick it up later at Operation 462.

[0026] Fig. Figure 4A represents a flowchart of a method 400 for sending agent operations according to one embodiment. Fig. Figure 4B presents a flowchart of a method 450 for receiving agent operations according to one embodiment. One or more operations of methods 400 and / or 450 can be performed by the components of the Fig. 3A and Fig. 3B will be carried out.

[0027] In one embodiment, the send agent is a relatively small hardware circuit arrangement located near a processor core. The send agent can reuse the core's memory execution units, such as the page miss handler, the load memory queue, and the write combination or WC buffer, to access memory. The send agent may include the control logic and several internal registers for managing the communication channel between the sender and receiver. It may also include registers used by the core to directly write job descriptors or read results from an agent. Among the internal registers are the descriptor registers, 8x8-byte registers used by software to write a job descriptor in one embodiment. Each job descriptor is a 64-byte cache line that, in one embodiment, consists of the description of the acceleration job.For examples of a job descriptor format, one could refer to the job descriptor format of the DSA.

[0028] Referring to Fig. 3A-4B, during operation 402, the kernel writes a job descriptor to a register of the send agent (such as descriptor register 306). During operation 404, a batching algorithm is invoked (e.g., by batching and send logic 330). In one mode, the send agent automatically detects whether batch processing is required and how large the batch processing should be. Although batching is usually preferable in a streaming workload, it could introduce longer queue latency for requests that enter the queue earlier. A simple, heuristic-based algorithm implemented in the send agent can be described as follows: The send agent starts with a target batch size of 1. In each time window (e.g.,Within a 1-millisecond (ms) window, one of the following conditions can cause the stack size to double: 1) the number of requests per second exceeds a threshold, and 2) an excessive number of "repeat" signals are sent by the receiving agent. Condition 1 implies that the software is a streaming workload. Stacking typically reduces uncore pressure and promotes throughput in streaming cases. Condition 2 indicates that the receiving agent cannot accept any more requests for some reason (e.g., high pressure, QoS reason, etc.). Stacking and buffering requests in the shared ring buffer can reduce pressure on the receiving agent. The stack size is halved if neither condition occurs during the time window. Other algorithms based on hardware performance monitoring counters may also be used in some implementations.Furthermore, CPU providers could implement a proprietary algorithm and send it to the customer without disclosing the proprietary algorithm to the software.

[0029] Operation 406 determines whether the stack size is 1. If so, a MIMO write operation 310 writes a single descriptor to the receiving agent's incoming request buffer 314 during operation 408. If the stack size is not 1, operation 412 writes the descriptors 322 to the shared ring buffer in memory 318. Operation 414 determines whether the stack size has reached a threshold, and if so, operation 416 writes the stack descriptors to the receiving agent's incoming buffer 314 via MIMO. If the stack size has not been reached during operation 414, operation 415 increments the stack size, and operation 400 resumes during operation 412. If the batch size is reached at operation 414, operation 416 is performed to write the batch descriptor to the receiving agent, and procedure 400 continues with operation 418.Operation 418 resets the flag and waits for the next request from software. After Operation 418, the 400 procedure is resumed with Operation 402.

[0030] In some embodiments, the software first checks an empty flag from flag register 332 to determine if the descriptor registers 306 are ready to be written to. The software then uses move instructions (e.g., MOV) to populate the (e.g., eight) descriptor registers and resets the empty flag (which can be done before operation 402, e.g., assuming the kernel has already checked availability before entering operation 402; otherwise, the software waits until availability is confirmed before proceeding with operation 402). The send agent then uses weakly ordered memory to write the descriptor to the head of the ring buffer allocated in memory. After the write, the queue header register is incremented by one to indicate the occupancy of the queue entry. As a circular ring, the head can skip if the value is greater than the queue depth.Once a selected number of requests are queued (in operation 414), the sending agent writes a batch descriptor to the receiving agent's MMIO port via MMIO (in operation 416). This MMIO write operation is performed using direct memory, such as MOVDIR or ENQCMD instructions, or using regular MMIO writes. The sending agent can also maintain a completion bitmap in its internal register 334. The bitmap can reside in a coherent domain and monitor requirement-for-ownership (RFO) signals sent during the operation of a coherence protocol. Each change to the bitmap indicates that new results have been written to memory by the accelerator. In one embodiment, the result is wrapped in a 32-byte completion (CR) record.The send agent retrieves the completion data set for future use by at least one core in advance into a local cache 336 and stores the CR addresses in its internal result buffer registers 338 and writes the first available CR address to the result register 340. If buffer 338 is empty, result register 340 is set to zero (NULL pointer).

[0031] Referring to Fig. 3B and Fig. 4B, the receive agent 312 on the accelerator side contains a hardware input request buffer 314 for buffering incoming requests received during operation 452. This hardware input request buffer is distinct from the shared ring data structure in memory 318. Incoming requests sent by the send agent 310 are temporarily buffered in this internal buffer before being retrieved by the accelerator 316. If the incoming request is a batch job descriptor, the accelerator DMA engine 320 reads the individual job descriptors from the shared ring structure in memory 318. The receive agent is responsible for two tasks. First, the receive agent monitors the queue occupancy (e.g.,The occupancy monitoring logic 350 monitors the occupancy (as shown in Table 352) of the incoming request buffer 314 and records the traffic from each Process Address Space Identifier (PASID) at Operation 454. This can be used to enable the QoS feature at Operation 456. Requests from the PASID that exceed a certain threshold (as determined at Operation 458) are returned with a "retry signal" at Operation 460. Otherwise, the descriptor is buffered in the hardware buffer so that the accelerator can receive it later at Operation 462. Secondly, once the accelerator has finished processing each job and writing it to the completion record, it notifies the receiving agent of the completion, and the receiving agent updates a completion bitmap 344 in memory 318 to notify the sending agent of the job completion via the bitmap register 334.Since the bitmap is also stored in bitmap register 334 in the send agent, the operation of a coherence protocol updates the contents of bitmap register 334 and thus notifies the send agent. The send agent then retrieves the completion records in advance from the local cache 336 and buffers the address of the completion record in its internal register (e.g., buffer 338, where the address is first buffered in buffer 338 and the header of buffer 338 is written to register 340) so that the software can later accept the result.

[0032] Furthermore, the receiving agent uses a queue allocation of the internal buffer (e.g., buffer 314) to manage QoS for different processes. An internal allocation table 352, which maps each PASID to a queue entry count, is used to track the number of requests originating from each process. An additional counter for the total number of jobs can be used to track the total number of jobs queued in the incoming request buffer 314. A user-defined ratio can be used to manage the relationship between these two counters. If the number of requests originating from a particular PASID exceeds the ratio threshold, a new request with a "retry signal" is returned during operation 460.Otherwise, the request is buffered in the internal buffer of the receiving agent and later selected by the accelerator at operation 462.

[0033] Regarding a notification-based results query flow (e.g., performed by results query logic 342 of Fig. 3A), notifies the accelerator 316 as soon as a job has finished, the accelerator informs the receive agent 312 of the completion, and the receive agent writes a completion bitmap 344 to indicate which entry is being made in the ring buffer 346. This bitmap 344 is pinned in a coherence domain in the send agent's local register file (e.g., bitmap register 334), so that the send agent receives an RFO signal upon update. As discussed here, a "coherence domain" generally refers to the data in the register being coherent with the cached data. This can encompass CPU cache and internal registers of the agent and / or core. The send agent then retrieves bitmap 344 and checks which entries have completed. The sending agent retrieves the completion record of the completed request in advance and buffers the address of the completion record in the internal buffer (e.g., 338 in). Fig. 3A) of the sending agent. The completion record can be stored at any location in memory. In at least one embodiment, each request carries a pointer to a memory location to act as the completion record. The accelerator writes the completion record, and the CPU or software must ultimately read the record. The completion record is the result of the request completed by the accelerator. The software retrieves the address of the completion record from the internal register (e.g., register 340) of the sending agent.

[0034] In one embodiment, the send agent 304 must context-switch between several context values, including queue management values ​​(e.g., Tail, Head 348), completion record addresses in Res. Buffer 338 waiting for core consumption, and Bitmap Register 334 for tracking completion requests. During a context switch, the values ​​in the descriptor register 306 must be flushed to memory. Register values ​​related to the context must be saved to memory for future reloading (e.g., using an XSAVE operation / instruction to save extended processor states).

[0035] Fig. Figure 5 presents an exemplary Pseudocode 500 for implementing a core-to-accelerator communication architecture according to one embodiment. The Pseudocode 500 follows some of the features referenced in Fig. 4A and Fig. 4B discussed operations. As in Fig. As shown in Figure 5, a channel identifier (ID) `chanID` is initialized first. A driver can implement the `sendJob()` and `checkResult()` APIs. The application only calls these two APIs to communicate with an accelerator. In `sendJob()`, the software only needs to write a single job descriptor to the send agent's internal register (line 6). For `checkResult()`, the software only needs to read the result from the agent's internal register (line 11). The application calls `Preprocess()` and `Postprocess()` before and after `sendJob` and `checkResult` in loops for streaming workloads. Both the driver and the application are relatively simple and easy to maintain. Queue management, batching, and QoS-related work can all be handled by ACRE hardware, simplifying software maintenance and development overhead and also reducing CPU cycles spent on software implementation.

[0036] In some implementations, ACRE could improve system throughput by a factor of three to seven compared to a system without ACRE. Dynamic instruction counting can also be significantly reduced due to the much simpler software interface.

[0037] Accordingly, at least one embodiment provides a hardware-based approach to implement a universal core-to-accelerator communication channel. A send agent and a receive agent are proposed to create and maintain a communication channel through a shared ring buffer and direct MMIO memory operations. The proposed hardware architecture unifies interfaces between the core and various accelerators, and potentially between accelerators themselves. Initial evaluation results show significant CPU cycle savings and a greatly reduced programming effort.

[0038] Additionally, some embodiments can be applied in data processing systems that include one or more processors (where, for example, the one or more processors may include one or more processor cores), such as those described with reference to Fig. 1 ff. were discussed, including, for example, a desktop computer, a workstation, a computer server, a server blade, or a mobile computing device. A mobile computing device can include a smartphone, tablet, UMPC (Ultra-Mobile Personal Computer), laptop computer, an Ultrabook™ computing device, wearable devices (such as a smartwatch, smart ring, smart bracelet, or smart glasses), etc. Exemplary core architectures, processors, and computer architectures are discussed.

[0039] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general-purpose, pre-order core intended for general-purpose computing; 2) a high-performance, universal, re-order core intended for general-purpose computing; 3) a specialized core primarily intended for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU (central processing unit) comprising one or more pre-order, general-purpose cores intended for general-purpose computing and / or one or more re-ordered general-purpose cores intended for general-purpose computing; and 2) a coprocessor comprising one or more specialized cores primarily intended for graphics and / or scientific (throughput) computing.Such different processors lead to different computer system architectures, which may include: 1) the coprocessor on a chip separate from the CPU; 2) the coprocessor on a separate die in the same package as a CPU; 3) the coprocessor on the same die as a CPU (in this case, such a coprocessor is sometimes referred to as special logic, such as integrated graphics and / or scientific (throughput) logic, or as special cores); and 4) a system-on-a-chip that may include, on the same die, the CPU described (sometimes referred to as the application core(s) or application processor(s)), the coprocessor described above, and additional functionalities. Exemplary core architectures are described below, followed by descriptions of exemplary processors and computer architectures. Exemplary Core Architectures

[0040] Fig. Figure 6A is a block diagram illustrating both an exemplary pre-ordered pipeline and an exemplary reordered output / execution pipeline with register renaming according to embodiments. Fig. Figure 6B is a block diagram illustrating both an embodiment of an order-preserving architecture kernel and an exemplary order-changing output / execution architecture kernel with register renaming, which is to be included in a processor according to embodiments. The boxes with solid lines in Fig. Figures 6A-B illustrate the pre-order pipeline and the pre-order kernel, while the optional addition of the dashed-line boxes illustrates the reordered output / execution pipeline with register renaming and the kernel. Assuming that the pre-order aspect is a subset of the reordered aspect, the reordered aspect is described.

[0041] In Fig. 6A comprises a processor pipeline 600, a retrieval stage 602, a length decoding stage 604, a decoding stage 606, an allocation stage 608, a renaming stage 610, a scheduling stage (also known as distribution or output) 612, a register read / memory read stage 614, an execution stage 616, a write-back / memory write stage 618, an exception handling stage 622, and a transfer stage 624.

[0042] Fig. Figure 6B shows processor core 690, comprising a front-end unit 630, coupled with an execution engine unit 650, and both are coupled with a memory unit 670. Core 690 can be a reduced instruction set (RISC) core, a complex instruction set (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, core 690 can be a special-purpose core, such as, for example, a network or communications core, a compression engine, a coprocessor core, a general-purpose graphics processing unit (GPGPU) core, a graphics core, or similar.

[0043] The front-end unit 630 comprises a branch prediction unit 632, coupled with an instruction cache unit 634, which is coupled with an instruction translation lookaside buffer (TLB) 636, which is coupled with an instruction retrieval unit 638, which is coupled with a decoding unit 640. The decoding unit 640 (or decoder) can decode instructions and produce as an output one or more microoperations, microcode input points, microinstructions, other instructions, or other control signals that are decoded from, otherwise reflect, or are derived from the original instructions. The decoding unit 640 can be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROMs), etc.In one embodiment, the core 690 comprises a microcode ROM or other medium that stores microcode for certain macro instructions (e.g., in the decoding unit 640 or elsewhere within the front-end unit 630). The decoding unit 640 is coupled to a renaming / mapping unit 652 in the execution engine unit 650.

[0044] The execution engine unit 650 comprises the rename / map unit 652, coupled with a retract unit 654 and a set of one or more flow control units 656. The flow control unit(s) 656 represent any number of different flow controls, including reservation stations, central instruction window, etc. The flow control unit(s) 656 is / are coupled with the physical register file unit(s) 658. Each of the physical register file units 658 represents one or more physical register files, several of which store one or more different data types, such as scalar integers, scalar floating-point numbers, packed integers, packed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc.In one embodiment, the physical register file unit(s) 658 comprises a vector register unit, a write mask register unit, and a scalar register unit. These register units can provide architectural vector registers, vector mask registers, and universal registers. The physical register file unit(s) 658 is / are overlapped by the retraction unit 654 to represent various ways in which register renaming and reordered execution can be implemented (e.g., using a reorder buffer and a retraction register file; using a future file, a history buffer, and a retraction register file; using a register mapping and a collection of registers, etc.). The retraction unit 654 and the physical register file unit(s) 658 are / are coupled to the execution cluster(s) 660.The execution clusters 660 comprise a set of one or more execution units 662 and a set of one or more memory access units 664. The execution units 662 can perform various operations (e.g., shifts, addition, subtraction, multiplication) on different types of data (e.g., scalar floating-point data, packed integer data, packed floating-point data, vector integer, vector floating-point). While some embodiments may include a number of execution units specifically designated for particular functions or sets of functions, other embodiments may include only one execution unit or multiple execution units, all of which perform all functions. The flow control unit(s) 656, the physical register file unit(s) 658, and the...The execution clusters 660 are shown as potentially multiple because certain embodiments generate separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating-point / packed integer / packed floating-point / vector integer / vector floating-point pipeline, and / or a memory access pipeline, each having its own flow control unit, physical register file unit(s), and / or execution cluster(s) – and in the case of a separate memory access pipeline, certain embodiments are implemented where only the execution cluster of that pipeline has the memory access unit(s) 664). It is also understood that when separate pipelines are used, one or more of these pipelines may be change-order output / execution pipelines, and the rest may be order-preserving pipelines.

[0045] The set of memory access units 664 is coupled to the memory unit 670, which comprises a data TLB unit 672, coupled to a data cache unit 674, which in turn is coupled to a level 2 (L2) cache unit 676. In an exemplary embodiment, the memory access units 664 can comprise a load unit, an address storage unit, and a data storage unit, each of which is coupled to the data TLB unit 672 in the memory unit 670. The instruction cache unit 634 is further coupled to a level 2 (L2) cache unit 676 in the memory unit 670. The L2 cache unit 676 is coupled to one or more other cache levels and finally to main memory.

[0046] For example, the exemplary core architecture for reordered output / execution with register renaming can implement pipeline 600 as follows: 1) the instruction retrieval unit 638 performs the retrieval and length decoding stages 602 and 604; 2) the decoding unit 640 performs the decoding stage 606; 3) the renaming / mapping unit 652 performs the mapping stage 608 and the renaming stage 610; 4) the flow control unit(s) 656 performs or performs5) the physical register file unit(s) 658 and the storage unit 670 perform the register read / memory read stage 614; the execution cluster 660 performs the execution stage 616; 6) the storage unit 670 and the physical register file unit(s) 658 perform the write back / memory write stage 618; 6) different units may be involved in the exception handling stage 622; and 8) the retract unit 654 and the physical register file unit(s) 658 perform the transfer stage 624.

[0047] The Kernel 690 can support one or more instruction sets (e.g., the x86 instruction set (with some extensions added in newer versions); the MIPS instruction set from MIPS Technologies of Sunnyvale, CA; the ARM instruction set (with optional additional extensions, such as NEON) from ARM Holdings of Sunnyvale, CA), including the instruction(s) described here. In one embodiment, the Kernel 690 includes logic to support an instruction set extension with packed data (e.g., AVX1, AVX2), thereby enabling operations used by many multimedia applications to be performed with packed data.

[0048] Fig. Figure 7 shows a block diagram of a SOC component according to one embodiment. As in Fig. As illustrated in Figure 7, the SOC 702 comprises one or more CPU cores (CPU: central processing unit) 720, one or more GPU cores (GPU: graphics processing unit) 730, an input / output or I / O interface 740, and a memory controller 742. Various components of the SOC package 702 can be coupled by a circuit or bus, as discussed herein with reference to the other figures. The SOC package 702 can also comprise more or fewer components, such as those discussed herein with reference to the other figures. Furthermore, each component of the SOC package 702 can include one or more other components, as discussed herein with reference to the other figures. In one embodiment, the SOC package 702 (and its components) is provided on one or more integrated circuit (IC) dies, which are, for example, B. are encapsulated in a single semiconductor device.

[0049] As in Fig. As illustrated in Figure 7, the SOC package 702 is coupled to a memory 760 via the memory controller 742. In one embodiment, the memory 760 (or part thereof) can be integrated on the SOC package 702.

[0050] The I / O interface 740 can be coupled, for example, via a circuit and / or a bus, such as those discussed here with reference to the other figures, to one or more I / O devices 770. The I / O device(s) 770 can include a keyboard and / or a mouse and / or a touch panel and / or a display and / or an image / video recording device (such as a camera or camcorder / video recorder) and / or a touchscreen and / or a speaker or the like.

[0051] Fig. Figure 8 is a block diagram of a processing system 800 according to one embodiment. In various embodiments, the system 800 comprises one or more processors 802 and one or more graphics processors 808 and can be a single-processor desktop system, a multi-processor workstation system, or a server system with a large number of processors 802 or processor cores 807. In one embodiment, the system 800 is a processing platform integrated into an integrated system-on-a-chip (SoC) circuit for use in mobile, handheld, or embedded devices.

[0052] An embodiment of the System 800 may include or be integrated with a server-based gaming platform, a gaming console (including a gaming and media console), a mobile gaming console, a handheld gaming console, or an online gaming console. In some embodiments, the System 800 is a mobile phone, a smartphone, a tablet data processing device, or a mobile internet device. The Data Processing System 800 may also include, couple with, or be integrated with a wearable device, such as a wearable smartwatch device, smart glasses device, augmented reality device, or virtual reality device. In some embodiments, the Data Processing System 800 is a television or set-top box device with one or more Processors 802 and a graphical interface generated by one or more Graphics Processors 808.

[0053] In some embodiments, the one or more processors 802 each comprise one or more processor cores 807 for processing instructions that, when executed, perform operations for the system and user software. In some embodiments, each of the one or more processor cores 807 is configured to process a specific instruction set 809. In some embodiments, the instruction set 809 can support complex instruction set (CISC), reduced instruction set (RISC), or very long instruction word (VLIW) computations. Multiple processor cores 807 can each process a different instruction set 809, which may include instructions to support the emulation of other instruction sets. The processor core 807 can also include other processing devices, such as a digital signal processor (DSP).

[0054] In some embodiments, the 802 processor includes a cache memory 804. Depending on the architecture, the 802 processor may have a single internal cache or multiple levels of internal caches. In some embodiments, the cache memory is shared among different components of the 802 processor. In some embodiments, the 802 processor also uses an external cache (e.g., a Level 3 (L3) cache or a Low Level Cache (LLC)) (not shown), which can be shared among 807 processor cores using known cache coherence techniques. A register file 806 is also included in the 802 processor, which may contain different types of registers for storing different types of data (e.g., integer registers, floating-point registers, status registers, and an instruction pointer register).Some registers may be universal registers, while other registers may be specific to the design of the 802 processor.

[0055] In some embodiments, the processor 802 is coupled to a processor bus 810 to transmit communication signals, such as address, data, or control signals, between the processor 802 and other components in the system 800. In one embodiment, the system 800 uses an exemplary "hub" system architecture, including a memory control hub 816 and an input / output (I / O) control hub 830. A memory control hub 816 enables communication between a memory device and other components of the system 800, while an I / O control hub (ICH, I / O Controller Hub) 830 provides connections to I / O devices via a local I / O bus. In one embodiment, the logic of the memory control hub 816 is integrated within the processor.

[0056] The memory device 820 can be a DRAM (dynamic random-access memory) device, an SRAM (static random-access memory) device, a flash memory device, a phase-change memory device, or any other memory device with suitable performance to serve as process memory. In one embodiment, the memory device 820 can act as system memory for the system 800 to store data 822 and instructions 821 for use when the one or more processors 802 are executing an application or process. The memory control hub 816 is also coupled to an optional external graphics processor 812, which can communicate with the one or more graphics processors 808 in the processors 802 to perform graphics and media operations.

[0057] In some embodiments, the ICH 830 enables peripheral devices to connect the storage device 820 and the processor 802 via a high-speed I / O bus. The I / O peripheral devices include, among others, an audio controller 846, a firmware interface 828, a wireless transceiver 826 (e.g., WLAN, Bluetooth), a data storage device 824 (e.g., hard disk drive, flash memory, etc.), and a legacy I / O controller 840 for coupling legacy devices (e.g., Personal System 2 (PS / 2)) to the system. One or more USB (Universal Serial Bus) controllers 842 connect input devices, such as keyboard and mouse combinations 844. A network controller 834 may also be coupled to the ICH 830. In some embodiments, a high-performance network controller (not shown) is coupled to the processor bus 810.It is understood that the depicted System 800 is exemplary and not limiting, since other types of data processing systems, designed differently, can also be used. For example, the I / O control hub 830 can be integrated within one or more processors 802, or the memory control hub 816 and the I / O control hub 830 can be integrated into a discrete external graphics processor, such as the external graphics processor 812.

[0058] Fig. Figure 9 is a block diagram of an embodiment of a processor 900, comprising one or more processor cores 902A to 902N, an integrated memory controller 914, and an integrated graphics processor 908. Those elements from Fig. 9, which have the same reference symbols (or names) as the elements of any other figure here, may operate or function in any similar manner to, but are not limited to, those described elsewhere herein. The processor 900 may include additional cores up to and including the additional core 902N, represented by the dashed boxes. Each of the processor cores 902A to 902N includes one or more internal cache units 904A to 904N. In some embodiments, each processor core also has access to one or more shared cache units 906.

[0059] The internal cache units 904A to 904N and shared cache units 906 constitute a cache memory hierarchy within the 900 processor. The cache memory hierarchy can include at least one level of instruction and data cache within each processor core and one or more levels of shared cache at the middle level, such as a Level 2 (L2), Level 3 (L3), Level 4 (L4), or other cache levels, with the highest cache level in front of external memory being classified as LLC. In some embodiments, cache coherence logic maintains coherence between the different cache units 906 and 904A to 904N.

[0060] In some embodiments, the processor 900 may also include a set of one or more bus control units 916 and a system agent core 910. The one or more bus control units 916 manage a set of peripheral buses, such as one or more peripheral component interconnect buses (e.g., PCI, PCI Express). The system agent core 910 provides management functionality for the various processor components. In some embodiments, the system agent core 910 includes one or more integrated memory controllers 914 to manage access to various external storage devices (not shown).

[0061] In some embodiments, one or more of the processor cores 902A to 902N include support for simultaneous multithreading. In such an embodiment, the system agent core 910 includes components for coordinating and operating the cores 902A to 902N during multithreaded processing. The system agent core 910 may additionally include a power control unit (PCU) containing logic and components for regulating the power state of the processor cores 902A to 902N and the graphics processor 908.

[0062] In some embodiments, the processor 900 additionally includes a graphics processor 908 for performing graphics processing operations. In some embodiments, the graphics processor 908 is coupled to the set of shared cache units 906 and the system agent core 910, which includes one or more integrated memory controllers 914. In some embodiments, a display controller 911 is coupled to the graphics processor 908 to drive a graphics processor output to one or more coupled displays. In some embodiments, the display controller 911 may be a separate module coupled to the graphics processor via at least one connection, or it may be integrated into the graphics processor 908 or the system agent core 910.

[0063] In some embodiments, a ring-based interconnection unit 912 is used to couple the internal components of the processor 900. However, an alternative interconnection unit can be used, such as a point-to-point connection, a switched connection, or other techniques, including techniques well known in the prior art. In some embodiments, the graphics processor 908 is coupled to the ring interconnection 912 via an I / O connection 913.

[0064] The exemplary I / O connection 913 represents at least one of several variants of I / O interconnections, including a component-based I / O interconnection, that enables communication between different processor components and an embedded high-performance memory module 918, such as an eDRAM module (or embedded DRAM). In some embodiments, each of the processor cores 902 to 902N and the graphics processor 908 use embedded memory modules 918 as a shared last-level cache.

[0065] In some embodiments, the processor cores 902A to 902N are homogeneous cores executing the same instruction set architecture. In another embodiment, the processor cores 902A to 902N are heterogeneous with respect to the instruction set architecture (ISA), wherein one or more processor cores 902A to 902N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment, the processor cores 902A to 902N are heterogeneous with respect to the microarchitecture, wherein one or more cores with a relatively higher power consumption are coupled with one or more power cores with a lower power consumption. Furthermore, the 900 processor can be implemented on one or more chips or as an integrated SoC circuit with the illustrated components in addition to other components.

[0066] Fig. Figure 10 is a block diagram of a graphics processing unit (GPU) 1000, which may be a discrete graphics processing unit or a GPU integrated with multiple processing cores. In some embodiments, the GPU communicates with registers on the GPU and with instructions placed in processor memory via a memory-mapped I / O interface. In some embodiments, the GPU 1000 includes a memory interface 1014 for accessing memory. The memory interface 1014 may be an interface to local memory, one or more internal caches, one or more shared external caches, and / or system memory.

[0067] In some embodiments, the graphics processor 1000 also includes a display controller 1002 for controlling display output data to a display device 1020. The display controller 1002 includes hardware for one or more overlay layers for displaying and composing multiple layers of video or user interface elements. In some embodiments, the graphics processor 1000 includes a video codec engine 1006 for encoding, decoding, or transcoding media to, from, or between one or more media coding formats, including, but not limited to, MPEG (Moving Picture Experts Group) formats such as MPEG-2, AVC (Advanced Video Coding) formats such as H.264 / MPEG-4-AVC, SMTP (Society of Motion Picture & Television Engineers) formats such as M / VC-1, and JPEG (Joint Photographic Experts Group) formats such as JPEG and Motion JPEG (MJPEG).

[0068] In some embodiments, the graphics processor 1000 includes a block image transfer engine (BLIT) 1004 for performing two-dimensional (2D) rasterizing operations, including, for example, bit boundary block transfers. However, in one embodiment, 3D graphics operations are performed using one or more components of the graphics processing engine (GPE) 1010. In some embodiments, the graphics processing engine 1010 is a computational engine for performing graphics operations, including three-dimensional (3D) graphics operations and media operations.

[0069] In some embodiments, the GPE 1010 includes a 3D pipeline 1012 for performing 3D operations, such as rendering three-dimensional images and scenes using processing functions that act on 3D primitive shapes (e.g., rectangle, triangle, etc.). The 3D pipeline 1012 includes programmable and fixed functional elements that perform various tasks within the element and / or generate execution threads to a 3D / media subsystem 1015. Although the 3D pipeline 1012 can be used to perform media operations, one embodiment of the GPE 1010 also includes a media pipeline 1016, which is specifically used to perform media operations such as video post-processing and image enhancement.

[0070] In some embodiments, the media pipeline 1016 includes fixed-function or programmable logic units to perform one or more specialized media operations, such as video decoding acceleration, video unnesting, and video encoding acceleration, instead of or on behalf of the video codec engine 1006. In some embodiments, the media pipeline 1016 additionally includes a thread generation unit to create threads for execution on the 3D / media subsystem 1015. The generated threads perform computations for the media operations on one or more graphics execution units contained in the 3D / media subsystem 1015.

[0071] In some embodiments, the 3D / Media subsystem 1015 includes logic for executing threads generated by the 3D pipeline 1012 and the media pipeline 1016. In one embodiment, the pipelines send thread execution requests to the 3D / Media subsystem 1015, which includes thread allocation logic for arbitrating and distributing the various requests to available thread execution resources. The execution resources include an array of graphics execution units for processing the 3D and media threads. In some embodiments, the 3D / Media subsystem 1015 includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory, comprising registers and addressable memory, for sharing data between threads and for storing output data.

[0072] This description presents numerous specific details to provide a more comprehensive understanding. However, it is obvious to those skilled in the art that the embodiments described herein can be implemented without one or more of these specific details. In other cases, well-known features have been omitted so as not to obscure the details of the present embodiments.

[0073] The following examples relate to further embodiments. Example 1 includes a setup comprising: a sending agent coupled to a processor core; a receiving agent coupled to a hardware accelerator device; and a memory for storing data corresponding to a request from the processor core, wherein the sending agent and the receiving agent are to maintain a communication channel to enable communication between the processor core and the hardware accelerator device in response to the request. Example 2 includes the setup of Example 1, wherein the memory is to store a ring buffer that is to be shared by the sending agent and the receiving agent. Example 3 includes the setup of Example 2, wherein the ring buffer is to provide the communication channel.Example 4 includes the setup of Example 1, where one of the sending agents and one of the receiving agents are to create the communication channel. Example 5 includes the setup of Example 1, where the memory includes a last-level cache (LLC). Example 6 includes the setup of Example 1, where the receiving agent is to buffer incoming requests from the processor core in a buffer. Example 7 includes the setup of Example 6, where the buffer is to be accessed via a memory-mapped input / output or MMIO load operation, or an MMIO store operation. Example 8 includes the setup of Example 1, where the request corresponds to a job to be executed by the hardware accelerator device. Example 9 includes the setup of Example 8, where a job descriptor corresponding to the job is to be communicated over the communication channel.Example 10 includes the setup of Example 9, where the job descriptor is to be communicated to the hardware accelerator device via a direct memory access (DMA) operation. Example 11 includes the setup of Example 1, where the receive agent is to use occupancy data to manage quality of service (QoS) for different processes. Example 12 includes the setup of Example 11, where the occupancy data is to be stored in a table that maps each process address space identifier (PASID) to a corresponding queue entry count. Example 13 includes the setup of Example 1, where the completion of requests is to be signaled by a completion bitmap. Example 14 includes the setup of Example 13, where the completion bitmap is to be stored in memory or a register.Example 15 includes the setup of Example 13, where the closing bitmap is located in a coherent domain.

[0074] Example 16 includes one or more non-volatile, computer-readable media comprising one or more instructions which, when executed on a processor, configure the processor to perform one or more operations to: a sending agent coupled to a processor core and a receiving agent coupled to a hardware accelerator device to maintain a communication channel to enable communication between the processor core and the hardware accelerator device in response to a request from the processor core; and memory to store data corresponding to the request from the processor core.Example 17 includes the one or more computer-readable media from Example 16, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the memory to store a ring buffer shared by the sending agent and the receiving agent. Example 18 includes the one or more computer-readable media of Example 17, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the ring buffer to provide the communication channel.Example 19 includes the one or more computer-readable media from Example 16, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause one of the sending agent and the receiving agent to create the communication channel. Example 20 includes the one or more computer-readable media from Example 16, wherein the memory comprises a last-level cache (LLC). Example 21 includes the one or more computer-readable media from Example 16, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the receiving agent to buffer incoming requests from the processor core into a buffer.Example 22 includes the one or more computer-readable media from Example 21, which further includes one or more instructions that, when executed on the one or more processors, configure the processors to perform one or more operations to cause the buffer to be accessed via a memory-mapped input / output or MMIO load operation, or an MMIO store operation. Example 23 includes the one or more computer-readable media from Example 16, wherein the requirement is a job to be performed by the hardware accelerator device.Example 24 includes the one or more computer-readable media from Example 16, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the receiving agent to use occupancy data to regulate quality of service (QoS) for different processes. Example 25 includes the one or more computer-readable media from Example 16, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the completion of the request to be signaled by a completion bitmap.

[0075] Example 26 includes a method comprising: a sending agent coupled to a processor core and a receiving agent coupled to a hardware accelerator device, maintaining a communication channel to enable communication between the processor core and the hardware accelerator device in response to a request from the processor core; and storing data corresponding to the request from the processor core in memory. Example 27 includes the method of Example 26, further comprising causing memory to store a ring buffer to be shared by the sending agent and the receiving agent. Example 28 includes the method of Example 27, further comprising causing the ring buffer to provide the communication channel.Example 29 includes the procedure of Example 26, further comprising causing one of the sending agents and the receiving agent to create the communication channel. Example 30 includes the procedure of Example 26, wherein the memory comprises a last-level cache (LLC).

[0076] Example 31 includes a device comprising means for carrying out a procedure according to one of the preceding examples. Example 32 includes a machine-readable storage device containing machine-readable instructions for implementing a procedure according to one of the preceding examples or for realizing a device according to one of the preceding examples.

[0077] In various embodiments, one or more operations that refer to Fig. 1 ff. were discussed, are carried out by one or more components (here interchangeably referred to as "logic"), which are discussed with reference to any one of the figures.

[0078] In various embodiments, the operations discussed here can be performed, for example, with reference to Fig. 1 ff, may be implemented as hardware (e.g., logic circuit arrangement), software, firmware, or combinations thereof, which may be provided, for example, as a computer program product, including one or more tangible (e.g., non-volatile) machine-readable or computer-readable media on which instructions (or software procedures) are stored that are used to program a computer to perform a process discussed herein. The machine-readable medium may include a storage device, such as those discussed with reference to the figures.

[0079] Additionally, such computer-readable media can be downloaded as a computer program product, whereby the program can be transmitted from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by means of data signals provided in a carrier wave or other propagation medium over a communication link (e.g., a bus, a modem, or a network connection).

[0080] A reference in this document to "an embodiment" means that a specific feature, structure, and / or characteristic described in connection with the embodiment may be included in at least one implementation. The presence of the phrase "in an embodiment" at various points in the specification may or may not refer to the same embodiment as a whole.

[0081] The terms "coupled" and "connected," along with their derivatives, may also be used in the description and claims. In some embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact with each other. However, "coupled" may also mean that two or more elements may not be in direct contact with each other but can still cooperate or interact with each other.

[0082] It is therefore understood that, although embodiments have been described in a language specific to structural features and / or methodological actions, the claimed subject matter may not be limited to the specific features or actions described. Rather, the specific features and actions are disclosed as examples of how to implement the claimed subject matter.

Claims

[1] Facility comprising the following: a transmitting agent coupled with a processor core; a receiving agent coupled with a hardware accelerator device; and a memory for storing data that meets a request from the processor core, where the sending agent and the receiving agent are to maintain a communication channel to enable communication between the processor core and the hardware accelerator device in response to the request. [2] Device according to claim 1, wherein the memory is to store a ring buffer which is to be shared by the sending agent and the receiving agent. [3] Device according to one of claims 1 to 2, wherein the ring buffer is to provide the communication channel. [4] Device according to one of claims 1 to 3, wherein one of the transmitting agent and the receiving agent is to generate the communication channel. [5] Device according to any one of claims 1 to 4, wherein the memory comprises a last-level cache (LLC). [6] Device according to any one of claims 1 to 5, wherein the receiving agent is to buffer incoming requests from the processor core in a buffer. [7] Device according to one of claims 1 to 6, wherein the buffer is accessed via a memory-assigned input / output or MMIO load operation or an MMIO store operation. [8] Device according to any one of claims 1 to 7, wherein the requirement corresponds to a job to be performed by the hardware accelerator device. [9] Device according to any one of claims 1 to 8, wherein a job descriptor corresponding to the job is to be communicated via the communication channel. [10] Device according to any one of claims 1 to 9, wherein the job descriptor is to be communicated to the hardware accelerator device via a direct memory access or DMA operation. [11] Device according to any one of claims 1 to 10, wherein the receiving agent is to use occupancy data to regulate quality of service (QoS) for different processes. [12] Device according to any one of claims 1 to 11, wherein the occupancy data are to be stored in a table which assigns each process address space identifier (PASID) to a corresponding queue entry count. [13] Device according to any one of claims 1 to 12, wherein the completion of the requirements is to be signaled by a completion bitmap. [14] Device according to any one of claims 1 to 13, wherein the termination bitmap is to be stored in the memory or a register. [15] Device according to any one of claims 1 to 14, wherein the termination bitmap is located in a coherent domain. [16] Non-volatile computer-readable medium or media comprising one or more instructions which, when executed on a processor, configure the processor to perform one or more operations to: a sending agent coupled to a processor core and a receiving agent coupled to a hardware accelerator device, maintaining a communication channel to enable communication between the processor core and the hardware accelerator device in response to a request from the processor core; and Memory for storing data that meets the requirements of the processor core. [17] Computer-readable medium or computer-readable media according to claim 16, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the memory to store a ring buffer which is shared by the sending agent and the receiving agent. [18] Computer-readable medium or computer-readable media according to any one of claims 16 to 17, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the ring buffer to provide the communication channel. [19] Computer-readable medium or computer-readable media according to any one of claims 16 to 18, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause one of the transmitting agent and the receiving agent to create the communication channel. [20] Computer-readable medium or computer-readable media according to any one of claims 16 to 19, wherein the memory comprises a last-level cache (LLC). [21] Computer-readable medium or computer-readable media according to any one of claims 16 to 20, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the receiving agent to buffer incoming requests from the processor core in a buffer. [22] Computer-readable medium or computer-readable media according to any one of claims 16 to 21, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the buffer to be accessed via a memory-assigned input / output or MMIO load operation or an MMIO store operation. [23] Computer-readable medium or computer-readable media according to any one of claims 16 to 22, wherein the requirement corresponds to a job to be performed by the hardware accelerator device. [24] Computer-readable medium or computer-readable media according to any one of claims 16 to 23, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the receiving agent to use occupancy data to regulate quality of service (QoS) for different processes. [25] Computer-readable medium or computer-readable media according to any one of claims 16 to 24, further comprising one or more instructions which, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the completion of the request to be signaled by a completion bitmap. [26] Method comprising the following: a sending agent coupled to a processor core and a receiving agent coupled to a hardware accelerator device, maintaining a communication channel to enable communication between the processor core and the hardware accelerator device in response to a request from the processor core; and Storing data that meets the requirements of the processor core in memory. [27] Method according to claim 26, further comprising causing the memory to store a ring buffer which is to be shared by the sending agent and the receiving agent. [28] Method according to any one of claims 26 to 27, further comprising causing the ring buffer to provide the communication channel. [29] Method according to any one of claims 26 to 28, further comprising causing one of the sending agent and the receiving agent to generate the communication channel. [30] Method according to any one of claims 26 to 29, wherein the memory comprises a last-level cache (LLC).

Images