Ordered storage operations in multiprocessor system

Abstract

Embodiments of the present disclosure relate to ordered storage operations in a multiprocessor system. Various embodiments include techniques for performing memory storage operations in a computing system. A memory management unit (MMU) receives various types of storage operations from a processor, including an out-of-order storage operation, a weakly ordered storage operation, and a strongly ordered storage operation. The MMU performs a translation of the virtual address to the physical address for the storage operation and forwards the translated storage operation for execution. The MMU may perform translation and forwarding of out-of-order and weakly ordered storage operations at any time. In contrast, when any previous ordered storage operation is suspended, the MMU may delay translation and forwarding of the strongly ordered storage operation. In this manner, the MMU may enforce ordering of weakly ordered storage operations to be translated and performed prior to subsequent strongly ordered storage operations. These techniques allow the processor to continue performing other operations when an ordered store operation in the MMU is suspended.

Description

Technical Field

[0001] Various embodiments relate generally to computer system architecture and, more particularly, to ordered memory operations in multi-processor systems. Background Art

[0002] A computing system typically includes one or more processing units (such as a central processing unit (CPU) and / or a graphics processing unit (GPU)), one or more memory systems, and one or more networks, among other things. The processing unit executes a user-mode software application that submits and initiates a computing task to be executed on one or more computing engines included in the processing unit. In operation, the processing unit loads data from one or more memory systems, performs various arithmetic and logical operations on the data, and stores the data back to the one or more memory systems. One way in which the processing unit can communicate with the memory system is through a network interface card (NIC). The NIC provides an interface between the processing unit and the memory system through various network interface protocols including Ethernet, Peripheral Component Interconnect Express (PCIe), and / or the like.

[0003] Modern GPUs frequently communicate with NICs for purposes such as sharing data, synchronizing computational stages, and initiating new work for the GPU, NIC, or other devices in the system. Therefore, computational workloads in computing systems with many GPUs, CPUs, NICs, and / or other devices can benefit when the GPU and NIC communicate efficiently. Additionally or alternatively, the GPU can communicate with the NIC by invoking an API call to a communication library. In response to the API call, functions included in the communication library execute to perform the communication task specified by the API call.

[0004] Given the parallel architecture of GPUs and CPUs, the memory model of a computing system does not provide any guarantees regarding ordering between writes to different addresses from the same thread or different threads. In many cases, the CPU and / or GPU may be a relaxed memory model processing unit, where thread instructions may be executed out of order. Thus, when a first thread executes, for example, ten consecutive memory operations, the tenth memory operation may be completed while one or more of the first nine memory operations remain outstanding. Therefore, when a previous memory operation needs to be completed and / or made visible in memory, a thread performs a memory synchronization operation, such as a memory barrier, a memory fence, or the like. The process of submitting work to the NIC or creating work internally in the GPU may consist of multiple memory synchronization operations. Furthermore, these multiple memory synchronization operations are serialized relative to each other to ensure visibility of the previous memory operation corresponding to one memory synchronization operation before executing a subsequent memory synchronization operation.

[0005] One problem with this technique for transferring data between threads is that memory synchronization operations can take a significant amount of time to complete. As mentioned above, performing two or three memory synchronization operations can consume thousands to tens of thousands of processor clock cycles, corresponding to multiple microseconds of latency. Furthermore, the thread issuing the memory synchronization operation can be blocked from performing further work until the memory synchronization operation completes. Consequently, these memory synchronization operations can significantly degrade processor performance.

[0006] As stated above, what is needed in the art are more efficient techniques for performing storage operations in computing systems. Summary of the Invention

[0007] Various embodiments of the present disclosure describe a computer-implemented method for performing a storage operation in a computing system. The method includes receiving a first storage operation from a first processor. The method further includes determining that the first storage operation comprises an ordered storage operation of a first type. The method further includes delaying, if necessary, execution of the first storage operation until confirmation is received from the first processor that data from a second storage operation comprising an ordered storage operation of a second type is visible in memory. In some examples, the method may choose not to delay PCIe inbound ordered stores. Using this method, the first processor continues to execute operations while the first storage operation is pending.

[0008] Other embodiments include, but are not limited to, systems that implement one or more aspects of the disclosed technology, and one or more computer-readable media including instructions for performing one or more aspects of the disclosed technology, and methods for performing one or more aspects of the disclosed technology.

[0009] At least one technical advantage of the disclosed technology over the prior art is that, through the disclosed technique of using ordered store operations, threads can eliminate memory synchronization operations and still maintain the desired ordering between individual store operations relative to any physical global memory aperture, such as the system (e.g., CPU-attached) memory aperture, peer device memory aperture, local device memory aperture, etc. The memory system maintains proper ordering in an efficient manner, and the MMU only inserts wait cycles when needed to see the ordered store operations. By doing so, strongly ordered store operations can maintain the cumulative ordering of previously ordered store operations within the system scope, with higher performance and less processing overhead compared to traditional techniques that employ memory synchronization operations. These advantages represent one or more technical improvements over prior art approaches. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to understand the relevant features of the various embodiments described above in more detail, the inventive concepts briefly summarized above may be described in more detail with reference to various embodiments (some of which are illustrated in the accompanying drawings). However, it should be noted that the drawings illustrate only typical embodiments of the inventive concepts and are therefore not to be construed as limiting the scope in any way, and that other equally effective embodiments may exist.

[0011] Figure 1 is a block diagram of a computing system configured to implement one or more aspects of various embodiments;

[0012] Figure 2 is included in Figure 1 A block diagram of a parallel processing unit (PPU) in an accelerator processing subsystem according to various embodiments;

[0013] Figure 3 is included in Figure 2 A block diagram of a general processing cluster (GPC) in a parallel processing unit (PPU) according to various embodiments;

[0014] Figure 4 yes Figure 3 a block diagram of a memory management unit (MMU) according to various embodiments;

[0015] Figure 5 is shown by Figure 3 A block diagram of storage operations according to various embodiments performed by an SM;

[0016] Figure 6 is Figure 3 A sequence diagram of ordered storage operations according to various embodiments performed by an SM;

[0017] Figure 7 is Figure 3 A sequence diagram of ordered storage operations according to various other embodiments performed by the SM; and

[0018] Figures 8A to 8C shows the process for Figure 3 Flowchart of method steps of a SM performing a storage operation according to various embodiments. DETAILED DESCRIPTION

[0019] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of various embodiments. However, it will be apparent to one skilled in the art that the present invention can be practiced without one or more of these specific details.

[0020] System Overview

[0021] Figure 1 1 is a block diagram of a computing system 100 configured to implement one or more aspects of various embodiments. As shown, computing system 100 includes, but is not limited to, a central processing unit (CPU) 102 and a system memory 104, which is coupled to an accelerator processing subsystem 112 via a memory bridge 105 and a communication path 113. Memory bridge 105 is further coupled to an I / O (input / output) bridge 107 via a communication path 106, and I / O bridge 107 is coupled to a switch 116.

[0022] In operation, I / O bridge 107 is configured to receive user input information from input device 108, such as a keyboard or mouse, and forward the input information to CPU 102 via communication path 106 and memory bridge 105 for processing. In some examples, input device 108 is used to verify the identity of one or more users so that authorized users are allowed access to computing system 100 and unauthorized users are denied access to computing system 100. Switch 116 is configured to provide connections between I / O bridge 107 and other components of computing system 100, such as network adapter 118 and various add-in cards 120 and 121. In some examples, network adapter 118 acts as a primary input device or a dedicated input device to receive input data for processing by the disclosed technology.

[0023] As also shown, the I / O bridge 107 is coupled to a system disk 114, which can be configured to store content, applications, and data for use by the CPU 102 and the accelerator processing subsystem 112. Generally, the system disk 114 provides non-volatile storage for applications and data and can include a fixed or removable hard drive, a flash memory device, and a CD-ROM (Compact Disc - Read Only Memory), DVD-ROM (Digital Versatile Disc - ROM), Blu-ray, HD-DVD (High Definition DVD), or other magnetic, optical, or solid-state storage device. Finally, although not explicitly shown, other components such as a universal serial bus or other port connection, an optical disc drive, a digital versatile disc drive, a film recording device, and the like can also be connected to the I / O bridge 107.

[0024] In various embodiments, memory bridge 105 may be a northbridge chip, and I / O bridge 107 may be a southbridge chip. Furthermore, communication paths 106 and 113, as well as other communication paths within computing system 100, may be implemented using any technically suitable protocol, including but not limited to Peripheral Component Interconnect Express (PCIe), HyperTransport, or any other bus or point-to-point communication protocol known in the art.

[0025] In some embodiments, the accelerator processing subsystem 112 includes a graphics subsystem that delivers pixels to the display device 110, which may be any conventional cathode ray tube, liquid crystal display, light emitting diode display, etc. In such embodiments, the accelerator processing subsystem 112 incorporates circuitry optimized for graphics and video processing, including, for example, video output circuitry. Figure 2 As described in more detail in , such circuits may be combined across one or more accelerators included in the accelerator processing subsystem 112. An accelerator includes any one or more processing units that can execute instructions, such as a central processing unit (CPU), Figures 2 to 4 Parallel processing units (PPUs), graphics processing units (GPUs), direct memory access (DMA) units, intelligence processing units (IPUs), neural processing units (NPUs), tensor processing units (TPUs), neural network processors (NNPs), data processing units (DPUs), vision processing units (VPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or the like.

[0026] In some embodiments, the accelerator processing subsystem 112 includes two processors, referred to herein as a primary processor (typically a CPU) and a secondary processor. Typically, the primary processor is a CPU and the secondary processor is a GPU. Additionally or alternatively, each of the primary and secondary processors can be any one or more of the accelerator types disclosed herein, in any technically feasible combination. The secondary processor receives secure commands from the primary processor via an unprotected communication path. The secondary processor accesses memory and / or other storage systems, such as system memory 104, Compute Express Link (CXL) memory expander, memory-managed disk storage, on-chip memory, and / or the like. The secondary processor accesses this memory and / or other storage systems via an unsecured connection. The primary and secondary processors can communicate with each other via a GPU-to-GPU communication channel, such as Nvidia Link (NVLink). In addition, the primary and secondary processors can communicate with each other via a network adapter 118. Generally, the distinction between an unsecured communication path and a secure communication path depends on the application. A particular application typically considers communications within a die or package to be secure. Transmitting unencrypted data over standard communication channels such as PCIe is considered insecure.

[0027] In some embodiments, the accelerator processing subsystem 112 incorporates circuitry optimized for general-purpose and / or computational processing. Similarly, such circuitry may be combined across one or more accelerators included in the accelerator processing subsystem 112, which are configured to perform such general-purpose and / or computational operations. In other embodiments, one or more accelerators included in the accelerator processing subsystem 112 may be configured to perform graphics processing, general-purpose processing, and computational processing operations. System memory 104 includes at least one device driver 103 configured to manage processing operations of one or more accelerators in the accelerator processing subsystem 112.

[0028] In various embodiments, the accelerator processing subsystem 112 may be configured to Figure 1 The accelerator processing subsystem 112 may be integrated with one or more other elements of the CPU 102 to form a single system. For example, the accelerator processing subsystem 112 may be integrated with the CPU 102 and other connected circuits on a single chip to form a system on a chip (SoC).

[0029] It should be understood that the system shown herein is illustrative and that variations and modifications are possible. The connection topology (including the number and arrangement of bridges, the number of CPUs 102, and the number of accelerator processing subsystems 112) can be modified as needed. For example, in some embodiments, the system memory 104 can be directly connected to the CPU 102, rather than being connected to the CPU 102 through the memory bridge 105, and other devices will communicate with the system memory 104 via the memory bridge 105 and the CPU 102. In other alternative topologies, the accelerator processing subsystem 112 can be connected to the I / O bridge 107 or directly to the CPU 102, rather than being connected to the memory bridge 105. In still other embodiments, the I / O bridge 107 and the memory bridge 105 can be integrated into a single chip, rather than existing as one or more discrete devices. Finally, in some embodiments, Figure 1 One or more of the components shown may not be present. For example, switch 116 may be eliminated, and network adapter 118 and add-in cards 120 , 121 may be connected directly to I / O bridge 107 .

[0030] Figure 2 yes Figure 1 1 is a block diagram of a parallel processing unit (PPU) 202 according to various embodiments included in the accelerator processing subsystem 112 of FIG. Figure 2 While one PPU 202 is depicted, as described above, the accelerator processing subsystem 112 may include any number of PPUs 202. Figure 2 PPU 202 is Figure 1 The accelerator processing subsystem 112 is one example of an accelerator included in the accelerator. Alternative accelerators include, but are not limited to, a CPU, a GPU, a DMA unit, an IPU, an NPU, a TPU, an NNP, a DPU, a VPU, an ASIC, an FPGA, and / or the like. Figures 2 to 4 The techniques disclosed in

[15] regarding the PPU 202 are equally applicable to any type of accelerator included in the accelerator processing subsystem 112, in any combination. As shown, the PPU 202 is coupled to a local parallel processing (PP) memory 204. The PPU 202 and the PP memory 204 may be implemented using one or more integrated circuit devices, such as a programmable processor, an application-specific integrated circuit (ASIC), or a memory device, or in any other technically feasible manner.

[0031] In some embodiments, PPU 202 includes a graphics processing unit (GPU) that can be configured to implement a graphics rendering pipeline to perform various operations related to generating pixel data based on graphics data provided by CPU 102 and / or system memory 104. When processing graphics data, PP memory 204 can be used as graphics memory to store one or more conventional frame buffers (and, if desired, one or more other rendering targets). PP memory 204 can be used to, among other things, store and update pixel data and transmit the final pixel data, or display frame, to display device 110 for display. In some embodiments, PPU 202 can also be configured for general processing and computational operations.

[0032] In operation, CPU 102 is the main processor of computing system 100, controlling and coordinating the operations of other system components. In particular, CPU 102 issues commands that control the operation of PPU 202. In some embodiments, CPU 102 writes a command stream for PPU 202 into a data structure ( Figure 1 or Figure 2 102 and PPU 202). In some embodiments, the data structure may be located in system memory 104, PP memory 204, or another storage location accessible to both CPU 102 and PPU 202. Additionally or alternatively, a processor and / or accelerator other than CPU 102 may write one or more command streams from PPU 202 to the data structure. A pointer to the data structure is written to a push buffer to initiate processing of the command stream in the data structure. PPU 202 reads the command stream from the push buffer and then executes the commands asynchronously with respect to the operation of CPU 102. In embodiments where multiple push buffers are generated, the application may specify an execution priority for each push buffer via device driver 103 to control the scheduling of different push buffers.

[0033] As also shown, PPU 202 includes an I / O (input / output) unit 205, which communicates with the rest of computing system 100 via communication path 113 and memory bridge 105. I / O unit 205 generates data packets (or other signals) for transmission on communication path 113, and also receives all incoming data packets (or other signals) from communication path 113, directing the incoming data packets to the corresponding components of PPU 202. For example, commands related to processing tasks may be directed to host interface 206, while commands related to memory operations (e.g., reading from or writing to PP memory 204) may be directed to crossbar unit 210. Host interface 206 reads each push buffer and sends the command stream stored in the push buffer to front end 212.

[0034] As above combined Figure 1 As described above, the connection between PPU 202 and the rest of computing system 100 can vary. In some embodiments, accelerator processing subsystem 112 (which includes at least one PPU 202) is implemented as an add-in card that can be inserted into an expansion slot of computing system 100. In other embodiments, PPU 202 can be integrated on a single chip using a bus bridge, such as memory bridge 105 or I / O bridge 107. Likewise, in other embodiments, some or all elements of PPU 202 can be included with CPU 102 in a single integrated circuit or system on a chip (SoC).

[0035] In operation, the front end 212 sends processing tasks received from the host interface 206 to a work distribution unit (not shown) within the task / work unit 207. The work distribution unit receives pointers to processing tasks, which are encoded as task metadata (TMD) and stored in memory. The pointer to the TMD is included in a command stream, which is stored as a push buffer and received by the front end 212 from the host interface 206. The processing tasks that can be encoded as TMDs include indexes associated with the data to be processed, as well as state parameters and commands that define how to process the data. For example, the state parameters and commands can define the program to be executed on the data. The task / work unit 207 receives tasks from the front end 212 and ensures that the GPC 208 is configured to a valid state before initiating the processing tasks specified by each TMD. A priority can be assigned to each TMD, which is used to schedule the execution of the processing tasks. Processing tasks can also be received from the processing cluster array 230. Optionally, the TMD may include a parameter that controls whether the TMD is added to the head or tail of a list of processing tasks (or a list of pointers to processing tasks), thereby providing another level of control over execution priority.

[0036] PPU 202 advantageously implements a highly parallel processing architecture based on a processing cluster array 230, which includes a collection of C general processing clusters (GPCs) 208, where C ≥ 1. Each GPC 208 is capable of executing a large number (e.g., hundreds or thousands) of threads simultaneously, where each thread is an instance of a program. In various applications, different GPCs 208 can be assigned to process different types of programs or perform different types of computations. The assignment of GPCs 208 can vary depending on the workload generated by each type of program or computation.

[0037] The memory interface 214 includes a set of D partition units 215, where D ≥ 1. Each partition unit 215 is coupled to one or more dynamic random access memories (DRAMs) 220 residing within the PP memory 204. In one embodiment, the number of partition units 215 is equal to the number of DRAMs 220, with each partition unit 215 coupled to a different DRAM 220. In other embodiments, the number of partition units 215 may be different than the number of DRAMs 220. Those skilled in the art will recognize that the DRAMs 220 may be replaced with any other technically suitable memory device. In operation, various render targets (such as texture maps and frame buffers) may be stored across the DRAMs 220, allowing the partition units 215 to write portions of each render target in parallel, thereby efficiently utilizing the available bandwidth of the PP memory 204.

[0038] A given GPC 208 can process data to be written to any DRAM 220 in PP memory 204. A crossbar unit 210 is configured to route the output of each GPC 208 to the input of any partition unit 215 or any other GPC 208 for further processing. The GPCs 208 communicate with the memory interface 214 via the crossbar unit 210 to read from or write to the various DRAMs 220. In one embodiment, the crossbar unit 210 is connected to the I / O unit 205 in addition to being connected to the PP memory 204 via the memory interface 214, thereby enabling processing cores in different GPCs 208 to communicate with the system memory 104 or other memory that is not local to the PPU 202. Figure 2 In some embodiments, the crossbar unit 210 is directly connected to the I / O unit 205. In various embodiments, the crossbar unit 210 can separate the traffic flow between the GPCs 208 and the partition units 215 using virtual channels.

[0039] Likewise, the GPCs 208 can be programmed to perform processing tasks associated with various applications, including, but not limited to, linear and nonlinear data transformations, filtering of video and / or audio data, modeling operations (e.g., applying physical laws to determine the position, velocity, and other properties of an object), image rendering operations (e.g., tessellation shading programs, vertex shading programs, geometry shading programs, and / or pixel / fragment shading programs), general-purpose compute operations, etc. In operation, the PPU 202 is configured to transfer data from the system memory 104 and / or the PP memory 204 to one or more on-chip memory units, process the data, and write the resulting data back to the system memory 104 and / or the PP memory 204. The resulting data can then be accessed by other system components (including the CPU 102, another PPU 202 in the accelerator processing subsystem 112, or another accelerator processing subsystem 112 in the computing system 100).

[0040] As described above, any number of PPUs 202 may be included in the accelerator processing subsystem 112. For example, multiple PPUs 202 may be provided on a single add-in card, or multiple add-in cards may be connected to the communication path 113, or one or more PPUs 202 may be integrated into a bridge chip. The PPUs 202 in a multi-PPU system may be identical to or different from one another. For example, different PPUs 202 may have different numbers of processing cores and / or different amounts of PP memories 204. In implementations where multiple PPUs 202 are present, the PPUs may operate in parallel to process data at a higher throughput than would be possible with a single PPU 202. Systems including one or more PPUs 202 may be implemented in a variety of configurations and form factors, including but not limited to desktops, laptops, handheld personal computers or other handheld devices, servers, workstations, gaming consoles, embedded systems, and / or the like.

[0041] Figure 3 yes Figure 2208 includes a general processing cluster (GPC) 208. In operation, the GPC 208 can be configured to execute a large number of threads in parallel to perform graphics, general processing and / or computing operations. As used herein, a "thread" refers to an instance of a specific program executed on a specific input data set. In some embodiments, a single instruction multiple data (SIMD) instruction issuance technology is used to support the parallel execution of a large number of threads without providing multiple independent instruction units. In other embodiments, a single instruction multiple thread (SIMT) technology is used to support the parallel execution of a large number of generally synchronized threads using a general instruction unit configured to issue instructions to a group of processing engines in the GPC 208. Unlike a SIMD execution architecture (in which all processing engines generally execute the same instruction), SIMT execution allows different threads to more easily follow different execution paths through a given program. It should be appreciated by those skilled in the art that a SIMD processing architecture represents a functional subset of a SIMT processing architecture.

[0042] The operation of GPC 208 is controlled via pipeline manager 305, which distributes processing tasks received from work distribution units (not shown) within task / work units 207 to one or more streaming multiprocessors (SMs) 310. Pipeline manager 305 can also be configured to control work distribution crossbar 330 by specifying the destination of processed data output by SM 310.

[0043] In one embodiment, the GPC 208 includes a set of M SMs 310, where M ≥ 1. In addition, each SM 310 includes a set of function execution units (not shown), such as execution units and load-store units. The processing operations specific to any function execution unit can be pipelined, allowing new instructions to be issued for execution before the previous instructions have completed execution. Any combination of function execution units in a given SM 310 can be provided. In various embodiments, the function execution units can be configured to support a variety of different operations, including integer and floating-point arithmetic (e.g., addition and multiplication), comparison operations, Boolean operations (e.g., AND, OR, XOR), bit shifts, and calculations of various algebraic functions (e.g., planar interpolation and trigonometric functions, exponential functions, logarithmic functions, etc.). Advantageously, the same function execution unit can be configured to perform different operations.

[0044] In operation, each SM 310 is configured to process one or more thread groups. As used herein, a "thread group" or "warp" refers to a group of threads that concurrently execute the same program on different input data, with a thread in the group assigned to a different execution unit in the SM 310. A thread group may include fewer threads than the number of execution units in the SM 310, in which case some execution units may be idle during cycles while the thread group is being processed. A thread group may also include more threads than the number of execution units in the SM 310, in which case processing may occur in consecutive clock cycles. Since each SM 310 can support up to G thread groups simultaneously, up to G*M thread groups may be executing in a GPC 208 at any given time.

[0045] In addition, multiple related thread groups can be active (in different stages of execution) simultaneously in an SM 310. This collection of thread groups is referred to herein as a "cooperative thread array" ("CTA") or "thread array." The size of a particular CTA is equal to m*k, where k is the number of concurrently executing threads in the thread group, which is typically an integer multiple of the number of execution units in the SM 310, and m is the number of concurrently active thread groups within the SM 310. In various embodiments, software applications written in the Compute Unified Device Architecture (CUDA) programming language describe the behavior and operations of threads executing on the GPC 208, including any of the behaviors and operations described above. A given processing task can be specified in a CUDA program so that the SM 310 can be configured to perform and / or manage general-purpose computing operations.

[0046] although Figure 3 Not shown, but each SM 310 includes a level 1 (L1) cache, or uses space in a corresponding L1 cache external to the SM 310 to support load and store operations, etc., performed by the execution units. Each SM 310 also has access to a level 2 (L2) cache (not shown) that is shared between all GPCs 208 in the PPU 202. The L2 cache can be used to transfer data between threads. Finally, the SM 310 also has access to off-chip "global" memory, which can include PP memory 204 and / or system memory 104. It should be understood that any memory external to the PPU 202 can be used as global memory. In addition, as Figure 3As shown, a level 1.5 (L1.5) cache 335 may be included in GPC 208 and is configured to receive and store data requested from memory by SM 310 via memory interface 214. Such data may include, but is not limited to, instructions, uniform data, and constant data. In embodiments having multiple SMs 310 within GPC 208, SMs 310 may advantageously share common instructions and data cached in L1.5 cache 335.

[0047] Each GPC 208 may have an associated memory management unit (MMU) 320 that is configured to map virtual addresses to physical addresses. In various embodiments, the MMU 320 may reside within the GPC 208 or the memory interface 214. The MMU 320 includes a set of page table entries (PTEs) for mapping virtual addresses to physical addresses of tiles or memory pages, and optionally to cache line indices. The MMU 320 may include a translation lookaside buffer (TLB) or a cache resident within the SM 310, one or more L1 caches, or the GPC 208.

[0048] In graphics and compute applications, GPC 208 may be configured such that each SM 310 is coupled to a texture unit 315 for performing texture mapping operations, such as determining texture sample locations, reading texture data, and filtering texture data.

[0049] In operation, each SM 310 sends a processed task to the work distribution crossbar 330 so that the processed task can be provided to another GPC 208 for further processing, or the processed task can be stored in an L2 cache (not shown), parallel processing memory 204, or system memory 104 via the crossbar unit 210. In addition, a pre-raster operation (preROP) unit 325 is configured to receive data from the SM 310, direct the data to one or more raster operation (ROP) units within the partition unit 215, perform optimization of color blending, organize pixel color data, and perform address translation.

[0050] It should be understood that the core architecture described herein is illustrative and that variations and modifications are possible. In addition, any number of processing units, such as SM 310, texture unit 315, or preROP unit 325, may be included in GPC 208. Figure 2As described above, the PPU 202 may include any number of GPCs 208 that are configured to be functionally similar to one another so that execution behavior does not depend on which GPC 208 receives a particular processing task. Furthermore, each GPC 208 operates independently of the other GPCs 208 in the PPU 202 to execute tasks of one or more application programs. In view of the foregoing, one of ordinary skill in the art will appreciate that Figures 1 to 3 The architecture described in this document in no way limits the scope of the various embodiments of the present disclosure.

[0051] Note that, as used herein, reference to shared memory may include any one or more technically feasible memories, including but not limited to local memory shared by one or more SMs 310 or memory accessible via memory interface 214, such as cache memory, parallel processing memory 204, or system memory 104. Note also that, as used herein, reference to cache memory may include any one or more technically feasible memories, including but not limited to L1 cache, L1.5 cache, and L2 cache.

[0052] Ordered storage operations

[0053] Various embodiments include techniques for performing ordered store operations from GPC clients in a multiprocessor system. In some examples, the techniques perform ordered store operations from a GPC 208 to initiate work to a NIC in a multiprocessor system. The NIC may operate by maintaining a circular work queue, where each entry in the queue is referred to as a work queue entry (WQE). The circular work queue may be stored in any memory system, such as system memory 104, PP memory 204, or the like. Each WQE includes a work descriptor that informs the NIC what work to perform on the corresponding message data.

[0054] In some examples, one or more GPCs 208 support a GPC direct asynchronous programming model that enables direct transfer of GPC-computed data from the local memory of one GPC 208 (in one node) to the local memory of another GPC 208 (in the same node or in another node). Direct data transfers can be performed over a device that provides network connectivity (such as a NIC) and a communication bus (such as PCIe). GPC direct asynchronous data transfers enable an efficient producer-consumer programming model in which a producer (such as a GPC 208) can directly ring the doorbell of a consumer (such as a NIC) without the involvement of the CPU 102.

[0055] The producer-consumer programming sequence can proceed as follows. The CPU 102 generates a direct memory access (DMA) descriptor, such as a WQE, and stores the DMA descriptor in memory for execution by the NIC. The CPU 102 dispatches a compute task to the GPC 208 and / or initiates a compute task. The GPC 208 executes the compute task defined by the DMA descriptor and stores the result of the compute task in a buffer in local memory. The GPC 208 updates the location and / or address of the output buffer in the DMA descriptor for access by the NIC. The GPC 208 issues a series of one or more register writes to the NIC via the PCIe interface, thereby indicating that the data buffer in memory is ready to be consumed. The series of one or more register writes to the NIC constitutes a doorbell. In response, the NIC initiates a DMA sequence to read the buffer from the GPC memory via the PCIe interface. Once the CPU 102 initiates the compute task to the GPC 208, the programming sequence no longer requires the CPU 102's participation. Instead, CPU 102 may be free to continue processing other computing tasks, or may enter an idle or gated power state.

[0056] Using conventional techniques, a first thread executing on a local processor typically transfers message data from a local memory area via a NIC to a second thread executing on a remote host. The first thread stores the message data in memory, either by directly executing instructions or by issuing API calls to a communications library. The first thread stores the work queue (WQE) in any memory visible to the NIC. The first thread performs a memory synchronization operation to ensure that the message data and WQE are visible in memory. The first thread stores a doorbell record in memory, where the doorbell record includes an updated tail pointer for the circular work queue after storing the WQE. The first thread performs a memory synchronization operation to ensure that the doorbell record is visible in memory. The first thread writes a doorbell to the NIC, indicating to the NIC that the message data, WQE, and doorbell record can be reliably accessed. The first thread performs a memory synchronization operation to ensure that this doorbell write precedes any subsequent doorbell writes. The NIC and / or the second thread can now access the message data, WQE, and doorbell record. While any of the three memory synchronization operations is pending, the first thread is blocked from performing any further work.

[0057] In a specific example, after issuing a series of memory operations, a first thread stores a work queue entry (WQE) in memory, where a WQE is a work descriptor that informs the NIC what work needs to be done on data. The first thread issues a memory synchronization operation, such as a memory barrier or a memory fence. This memory barrier ensures that the data from the ten memory operations and the associated WQEs are visible in memory. The first thread generates and stores a notification record, referred to herein as a doorbell record, describing the data from the ten memory operations, such as the location of the data in memory and the total size of the data. If the NIC does not support reliable doorbells, the first thread stores the doorbell record. Due to resource constraints, a NIC that does not support reliable doorbells may not be able to guarantee that all in-flight doorbells will be received and processed. Therefore, the first thread stores the doorbell record in memory as a pointer to the doorbell to ensure that the NIC receives and processes every doorbell generated by the first thread. The first thread issues a second memory synchronization operation to ensure that the doorbell record is visible in memory. The first thread then generates and sends a notification, referred to herein as a doorbell press or doorbell write, to the NIC to notify it that the data and doorbell record are visible in memory. The first thread issues a third memory sync operation to ensure that the current doorbell write precedes the subsequent doorbell write. The third memory sync operation can be used by a special class of NICs that distinguish between even-numbered doorbells and odd-numbered doorbells. When the current doorbell write is detected, the second thread can reliably access the data through the NIC.

[0058] In contrast, using the disclosed techniques, threads executing in a computing system have an ordered view of memory. This ordered view of memory is distinct from the standard program memory view, in which writes to different addresses are not ordered without memory synchronization operations. From a programmer's perspective, this ordered view provides a mechanism for executing global memory store operations with embedded, hardware-enforced synchronization. The data of any store operation executed in the ordered view is visible to any external observer through subsequent strongly ordered store operations in the same view without the need to perform additional memory synchronization operations. Using these techniques, threads executing on the SM maintain the ordering of store operations until the store operation is issued to the MMU 320 and the memory system. The MMU 320, in turn, ensures that store operations remain ordered relative to previously ordered store operations executed by the thread, as intended by the programmer. Based on the final aperture of the translated physical address, the MMU 320 performs additional synchronization operations, if necessary, to ensure that ordering is maintained without the assistance of software techniques or instructions (such as memory synchronization operations).

[0059] The disclosed ordered storage operations can be categorized into two main types: weakly ordered storage operations and strongly ordered storage operations. Beyond the basic same-thread-same-address ordering provided by the GPU memory model, weakly ordered storage operations do not enforce strict ordering among themselves. Like strongly ordered storage operations, weakly ordered storage operations are also part of an ordered view. In some examples, weakly ordered storage operations execute with higher performance than strongly ordered storage operations. On the other hand, strongly ordered storage operations enforce strict ordering with respect to any other previously ordered storage operations (including weakly ordered and strongly ordered storage operations). Strongly ordered storage operations further ensure that previously ordered storage operations are visible within the relevant scope. For example, SM-wide visibility specifies that data from an ordered storage operation is visible to threads within SM 310. System-wide visibility specifies that data from an ordered storage operation is visible to all components of computing system 100, and so on. An ordered view includes both weakly and strongly ordered storage operations. Weakly ordered storage operations offer better performance, despite having weaker ordering guarantees. Strongly ordered storage operations provide stricter storage guarantees at slightly lower performance.

[0060] By using weakly-ordered and strongly-ordered store operations, the NIC communication sequence described above can be simplified as follows. A first thread executing on a local processor performs a first weakly-ordered store operation to store message data from a local memory area to a second thread executing on a remote host via the NIC. The first thread stores the message data in memory, either by directly executing instructions or by issuing API calls to a communications library. The first thread performs a second weakly-ordered store operation to store the WQE in any memory visible to the NIC. The first thread performs a first strongly-ordered store operation to store the doorbell record in memory, where the first strongly-ordered store operation ensures that the message data and WQE are visible in system-wide memory. The first thread performs a second strongly-ordered store operation to write the doorbell to the NIC, indicating to the NIC that the message data, WQE, and doorbell record can be reliably accessed. The second strongly-ordered store operation ensures that the message data, WQE, and doorbell record are visible in system-wide memory. The NIC and / or the second thread can now access the message data, WQE, and doorbell record. Because the first thread does not perform any memory synchronization operations, the first thread is not blocked from performing any other work.

[0061] Figure 4 yes Figure 34. Block diagram of a memory management unit (MMU) 320 according to various embodiments. The MMU 320 includes, but is not limited to, input store operations 410, a pre-translation ordering module 420, a translation lookaside buffer (TLB) 430, a post-translation ordering module 440, and output store operations 450.

[0062] In operation, SM 310 sends an input store operation 410 to MMU 320. In some examples, input store operation 410 may be temporarily stored in a buffer, first-in-first-out (FIFO) memory, queue, etc., awaiting address translation. Input store operation 410 includes a virtual address that identifies the location in the virtual address space where the data included in the store operation will be stored. To store the data in physical memory, MMU 320 performs an address translation from the virtual address included in the input store operation to a corresponding physical address that identifies the location in physical memory where the data included in the store operation will be stored. After address translation, MMU 320 generates output store operation 450, which includes a physical address that identifies the location in physical memory where the data included in the output store operation will be stored. MMU 320 transmits output store operation 450 to memory interface 214 along path 470. Additionally or alternatively, MMU 320 transmits output store operation 450 to a network interface card, a network fabric, a communication bus, etc. The data included in the output store operation 450 may be stored in the system memory 104, in the PP memory 204 of the PPU 202 including the SM 310 that generated the store operation, in the PP memory 204 in a different PPU 202, in memory of a different computing system 100, and / or in other similar locations.

[0063] Input storage operations 410 may be unordered storage operations 412, weakly ordered storage operations 414, or strongly ordered storage operations 416, or any combination thereof. As shown, input storage operations 410 include four unordered storage operations: U1 412(1), U2 412(2), U3 412(3), and U4 412(4). Input storage operations 410 also include two weakly ordered storage operations: WO1 414(1) and WO2 414(2), and two strongly ordered storage operations: SO1 416(1) and SO2 416(2).

[0064] The MMU 320 receives the out-of-order store operation 412 and the weakly-ordered store operation 414 and routes them to the TLB 430 along a path 460. The TLB 430 includes entries that store virtual address to physical address translations of recent store operations and / or expected store operations. If the TLB 430 includes an entry for the virtual address included in the input store operation 410, the MMU 320 generates an output store operation 450 that includes the corresponding physical address stored in the entry. The MMU 320 can generate the output store operation 450 from the entry in the TLB 430 with relatively low latency. If the TLB 430 does not include an entry for the virtual address included in the input store operation 410, the MMU 320 can query one or more other TLBs to see if another TLB, such as a TLB for a different SM 310, includes the required entry. If the other TLB includes the required entry, the MMU 320 may receive the entry from the other TLB and store it in the local TLB 430. The MMU 320 may generate an output store operation 450 from the entry in the other TLB, but with higher latency relative to generating an output store operation 450 from the entry in the local TLB 430.

[0065] If no TLB contains the required entry, the MMU 320 may perform a page table lookup by accessing one or more page tables, which include entries that map pages of virtual memory to pages of physical memory. Based on the data included in the one or more page table entries, the MMU 320 generates a virtual-to-physical address translation for the virtual address included in the input store operation 410. The MMU 320 stores the virtual-to-physical address translation as an entry in the TLB 430. The MMU 320 may generate the output store operation 450 based on the virtual-to-physical address translation determined by the page table lookup, but with a higher latency than generating the output store operation 450 based on an entry in the local TLB 430 or an entry in another TLB. Therefore, because any given virtual-to-physical address translation may be stored in the TLB 430, stored in another TLB, or generated from an entry in a page table, the MMU 320 may translate the addresses of the out-of-order store operation 412 and the weakly-ordered store operation 414 in any order. After translation, MMU 320 generates output store operations 450, which include out-of-order store operations 452 and weakly-ordered store operations 454, and transmits output store operations 450 to memory interface 214 along path 470. MMU 320 may store output store operations 450 in a buffer, FIFO memory, queue, and / or the like.

[0066] To enforce address translation ordering for certain input store operations 410, the MMU 320 also receives a strongly-ordered store operation 416. The MMU 320 routes the strongly-ordered store operation 416 to the pre-translation ordering module 420 along path 462. The pre-translation ordering module 420 delays the translation of the virtual address of the received strongly-ordered store operation 416 into a physical address until the translation of the pending weakly-ordered store operation 414 is completed. To this end, the pre-translation ordering module 420 includes a translation counter 422 that counts the number of weakly-ordered store operations 414 received by the MMU 320 since the most recent strongly-ordered store operation 416 was received. When the MMU 320 receives a weakly-ordered store operation 414, the translation counter 422 is incremented. When the MMU 320 completes the translation of the virtual address of the weakly-ordered store operation 414 into a physical address, the translation counter 422 is decremented. When the translation counter 422 reaches a value of zero, all pending virtual address to physical address translations for the pending weakly ordered store operations 414 are complete. In response to the completion of the pending weakly ordered store operations 414, the pre-translation ordering module 420 sends the strongly ordered store operations 416 to the TLB 430 along path 464. The MMU 320 performs virtual address to physical address translation for the strongly ordered store operations 416, similar to the process described herein for the out-of-order store operations 412 and the weakly ordered store operations 414. After the address translation, the MMU 320 sends the strongly ordered store operations 416 to the post-translation ordering module 440 along path 472.

[0067] In some examples, the MMU 320 may receive the second strongly-ordered store operation 416 while the first strongly-ordered store operation 416 is pending in the pre-translation ordering module 420. In this case, the MMU 320 holds the second strongly-ordered store operation 416 in the input store operations 410 until the pre-translation ordering module 420 completes processing the first strongly-ordered store operation 416 and sends the first strongly-ordered store operation 416 to the TLB 430 for translation.

[0068] In some examples, the MMU 320 classifies ordered memory operations into different groups based on the different ordering protocols employed by different destinations. The destination of a memory operation is also referred to as an aperture. For example, the MMU 320 may classify ordered memory operations into two different groups: a first group for ordered memory operations directed to a PCIe bus aperture, referred to as PCIe-bound memory operations, and a second group for ordered memory operations directed to apertures other than the PCIe bus, referred to as non-PCIe-bound memory operations.

[0069] To enforce the transmission ordering of the translated non-PCIe output storage operations 450, the MMU 320 includes a post-translation ordering module 440. The post-translation ordering module 440 receives translated strongly-ordered storage operations 442 from the TLB 430 along path 472. The post-translation ordering module 440 can store multiple translated strongly-ordered storage operations 442 in a buffer, a first-in-first-out (FIFO) memory, a queue, and / or the like. As shown, the post-translation ordering module 440 stores two translated strongly-ordered storage operations: SO1 442(1) and SO2 442(2). The post-translation ordering module 440 includes an acknowledgment counter 444 that counts the number of pending acknowledgments for certain output storage operations 450, such as weakly-ordered storage operations 454 and strongly-ordered storage operations 456. The acknowledgment counter 444 increments when the MMU 320 generates a weakly-ordered storage operation 454 or a strongly-ordered storage operation 456. When the memory interface 214 and / or other interface or communication bus confirms that the data of the weakly ordered storage operation 454 or the strongly ordered storage operation 456 is visible in the memory of the relevant scope, the confirmation counter 444 is decremented. When the confirmation counter 444 reaches a value of zero, all previously sent weakly ordered storage operations 454 and strongly ordered storage operations 456 are visible in the global memory. In response, the post-translation ordering module 440 generates a strongly ordered storage operation 456 based on the corresponding translated strongly ordered storage operation 442. The strongly ordered storage operation 456 includes a physical address that identifies the location in physical memory where the data contained in the strongly ordered storage operation 456 will be stored. The post-translation ordering module 440 transmits the strongly ordered storage operation 456 as an output storage operation 450 along the path 474 to the memory interface 214. After processing the first translated strongly ordered storage operation 442 (1), the post-translation ordering module 440 can process the second translated strongly ordered storage operation 442 (2).

[0070] As shown, the order of the output storage operations 450 can be different from the order of the corresponding input storage operations 410. For example, weakly ordered storage operations do not necessarily maintain order with respect to each other. Thus, although weakly ordered storage operation WO2 414(2) is ranked sixth in the input storage operations 410, weakly ordered storage operation WO2 454(2) is ranked first in the output storage operations 450. Weakly ordered storage operation WO1 414(1) is ranked second in the input storage operations 410, but weakly ordered storage operation WO1 454(1) is ranked fourth in the output storage operations 450.

[0071] Strongly-ordered store operations maintain order with respect to each other. Thus, because strongly-ordered store operation SO1 416(1) precedes strongly-ordered store operation SO2 416(2) in input store operations 410, strongly-ordered store operation SO1 456(1) also precedes strongly-ordered store operation SO2 456(2) in output store operations 450. Furthermore, each strongly-ordered store operation ensures that the previous weakly-ordered store operation is transmitted and acknowledged before the strongly-ordered store operation is transmitted. Thus, in input store operations 410, because weakly-ordered store operation WO1 414(1) precedes strongly-ordered store operation SO1 416(1), weakly-ordered store operation WO1 454(1) also precedes strongly-ordered store operation SO1 456(1). Similarly, because the weakly-ordered store operation WO2 414(2) precedes the strongly-ordered store operation SO2 416(2) in the input store operations 410, the weakly-ordered store operation WO2 454(2) also precedes the strongly-ordered store operation SO2 456(2).

[0072] Unordered store operations do not necessarily preserve order with respect to each other, whether they are weakly or strongly ordered. Thus, in input store operation 410, unordered store operation U1 412(1) precedes unordered store operation U2 412(2), but in output store operation 450, unordered store operation U2 452(2) precedes unordered store operation U1 452(1). Similarly, in input store operation 410, unordered store operation U2 412(2) precedes weakly ordered store operation WO2 414(2), but in output store operation 450, weakly ordered store operation WO2 454(2) precedes unordered store operation U2 452(2). Likewise, in the input store operation 410, the out-of-order store operation U4 412(4) precedes the strongly-ordered store operation SO2 416(2), but in the output store operation 450, the strongly-ordered store operation SO2 456(2) precedes the out-of-order store operation U4 452(4).

[0073] The MMU 320 relies on the PCIe ordering mechanism to enforce the ordering of outgoing memory operations directed to the PCIe bus. Memory operations directed to the PCIe bus are posted memory operations. For posted memory operations, the PCIe bus does not return an acknowledgment when the memory operation completes, and the data included in the memory operation is visible at the destination. Furthermore, PCIe semantics enforce ordering of consecutive memory operations to any address in the PCIe bus address space. Apertures other than the PCIe bus, such as the PP memory 204 of the local PPU 202, the PP memory 204 of a peer PPU 202, system memory 104, and / or the like, support non-posted memory operations. For non-posted memory operations, the MMU 320 receives an acknowledgment when the memory operation completes, and the data included in the memory operation is visible at the destination. However, for non-posted memory operations, ordering between consecutive memory operations to different addresses in these apertures is not guaranteed. Thus, in some examples, when an ordered store operation to an interface that supports posted store operations (such as a PCIe interface) is followed by an ordered store operation to an interface that does not support posted store operations, the MMU 320 performs an aperture switch I / O flush operation. This aperture switch I / O flush operation ensures that the data from the ordered store operation to an interface that supports posted store operations is visible in memory before processing any ordered store operations to any interface that supports non-posted store operations. This aperture switch I / O flush operation essentially inserts or issues a dummy read operation on the PCIe bus, which is, by definition, non-posted. According to PCIe ordering rules, non-posted operations push the previous posted operation. Thus, the dummy read response from the aperture switch I / O flush operation ensures that the previous posted store operation is already visible in memory. In response to receiving a read operation response to the dummy read operation indicating that the data associated with the posted operation is visible in memory, the non-posted operation is allowed to proceed.

[0074] To enforce the described ordering of ordered memory operations, the MMU 320 awaits acknowledgments for memory operations directed to non-PCIe apertures and sends memory operations directed to PCIe apertures in the original order in which they were received. The MMU 320 forces strongly-ordered memory operations directed to non-PCIe apertures to await acknowledgments from both previously strongly-ordered and previously weakly-ordered memory operations. The MMU 320 may store and retain, or delay, these strongly-ordered memory operations in a buffer, FIFO memory, queue, and / or the like included in the post-translation ordering module 440. In some examples, strongly-ordered memory operations to non-PCIe apertures may also flush previously ordered memory operations to PCIe apertures. In these examples, the MMU 320 performs a flush operation that only flushes previously ordered memory operations directed to PCIe apertures. This flush operation does not flush out-of-order memory operations. This flush operation also does not flush previously ordered memory operations directed to non-PCIe apertures.

[0075] Due to the memory operation ordering behavior of the PCIe bus, the MMU 320 can send a continuous stream of strongly ordered memory operations to the PCIe aperture. To ensure that these PCIe ordered write operations arrive at the PCIe bus in the order in which they were originally received, the MMU 320 transmits the ordered memory operations included in the set of ordered memory operations via the same fixed path through the memory system. The fixed path for this set of ordered memory operations is determined by a special fixed path address map, called a fixed path AMAP. With fixed path AMAP, input / output ports and L2 cache memory slices in the memory system are selected based on an identifier of the TLB 430 associated with the original requesting SM 310 and / or an identifier of the SM 310 of the original requesting SM 310. In contrast, with standard AMAP, input / output ports and L2 cache memory slices in the memory system are selected based on the address included in the memory operation. Therefore, ordered memory operations using standard AMAP will not be limited to traveling on a single fixed path.

[0076] When transferred through the L2 cache memory slice, these fixed path memory operations are marked as non-cacheable by the MMU 320. The MMU 320 marks the fixed path memory operations as non-cacheable because the fixed path memory operations are transferred to a different L2 cache memory than expected by standard AMAP. Therefore, the fixed path memory operations should not be cached in the L2 cache. This fixed path allows ordered memory operations directed to the PCIe aperture to be streamed one by one (back-to-back) to the PCIe subsystem, thereby forming an efficient sorting mechanism. The MMU 320 can use this PCIe sorting mechanism to communicate with PCIe attached network interfaces and / or other PCIe attached input / output devices. The MMU 320 can transfer memory operations one by one without stopping the SM 310 or the MMU 320, while ensuring the sorting of ordered memory operations transferred to the PCIe aperture.

[0077] In some examples, MMU 320 can handle the two stages of sorting separately, i.e., pre-translation sorting and post-translation sorting, as described herein. Additionally or optionally, MMU 320 can implement a unified sorting controller that handles the two stages of sorting together. In such an example, MMU 320 does not enforce pre-translation delays for the execution of strongly ordered storage operations. As an alternative, MMU 320 enforces the sorting of storage operations in the post-translation stage. It should be noted that MMU 320 can complete the address translation of the strongly ordered storage operation before completing the address translation of the previous weakly ordered storage operation. However, MMU 320 ensures that the data of the weakly ordered storage operation is visible at the destination before the data of the subsequent strongly ordered storage operation is visible at the destination.

[0078] Figure 5 It is shown by Figure 3310 stores the first message data in the memory 520(0) by performing a weakly ordered store operation. The SM 310 stores the first message data in the memory by directly executing an instruction or by issuing an API call to the communication library. The SM 310 stores the first work queue entry (WQE) in the memory 522(0) by performing a weakly ordered store operation. The SM 310 stores the first WQE in any memory visible to the memory interface 214. The WQEs are stored in a circular work queue, where each entry in the queue is a work queue entry (WQE). The circular work queue can be stored in any memory system such as system memory, PP memory, etc. The first WQE includes a work descriptor that informs the memory interface 214 what work will be performed on the first message data. Because the store operations on the first message data and the first WQE are performed as weakly ordered store operations, the MMU 320 can process the two weakly ordered store operations in any order.

[0079] SM 310 stores a first doorbell (DB) record in memory 524(0) by performing a strongly ordered store operation. After storing the first WQE, the first doorbell record includes an updated tail pointer for the circular work queue. Because the store operation on the first doorbell record is performed as a strongly ordered store operation, MMU 320 saves the store operation of the first doorbell record until the first message data and the first WQE are visible in memory. Once the first doorbell record and the first WQE are visible in memory, MMU 320 can process the strongly ordered store operation of the first doorbell record. SM 310 stores the first doorbell (DB) in memory 526(0) by performing a strongly ordered store operation. The first doorbell indicates that the first message data, the first WQE, and the first doorbell record can be reliably accessed. Because the store operation of the first doorbell is performed as a strongly ordered store operation, MMU 320 saves the store operation of the first doorbell until the first message data, the first WQE, and the first doorbell record are visible in memory. Once the first message data, the first WQE, and the first doorbell record are visible in memory, the MMU 320 may process strongly ordered store operations for the first doorbell.

[0080] The SM 310 stores the second message data in the memory 520(1) by performing a weakly ordered store operation. The SM 310 stores the second message data in the memory by directly executing an instruction or by issuing an API call to the communication library. The SM 310 stores a second work queue entry (WQE) in the memory 522(1) by performing a weakly ordered store operation. The SM 310 stores the second WQE in any memory visible to the memory interface 214. The second WQE includes a work descriptor that informs the memory interface 214 what work will be performed on the second message data. Because the store operations on the first message data, the first WQE, the second message data, and the second WQE are performed as weakly ordered store operations, the MMU 320 can process these four weakly ordered store operations in any order.

[0081] The SM 310 stores the second doorbell (DB) record in the memory 524 (1) by performing a strongly ordered store operation. After storing the second WQE, the second doorbell record includes an updated tail pointer for the circular work queue. Because the store operation on the second doorbell record is performed as a strongly ordered store operation, the MMU 320 saves the store operation on the second doorbell record until the second message data and the second WQE are visible in the memory. Once the second doorbell record and the second WQE are visible in the memory, the MMU 320 can process the strongly ordered store operation on the second doorbell record. The SM 310 stores the second doorbell (DB) in the memory 526 (1) by performing a strongly ordered store operation. The second doorbell indicates that the second message data, the second WQE, and the second doorbell record can be reliably accessed. Because the store operation on the second doorbell is performed as a strongly ordered store operation, the MMU 320 saves the store operation on the second doorbell until the first doorbell, the second message data, the second WQE, and the second doorbell record are visible in the memory. Once the first doorbell, the second message data, the second WQE, and the second doorbell record are visible in memory, the MMU 320 can process the strongly ordered store operation for the second doorbell. In this way, the MMU 320 can ensure the desired ordering of weakly ordered store operations and strongly ordered store operations without requiring the SM 310 to perform any memory synchronization operations.

[0082] Figure 6 is Figure 36 shows a sequence diagram of ordered storage operations performed by SM 310 according to various embodiments. As shown, SM 310 performs four ordered storage operations. The first ordered storage operation stores write data (store WDAT 620). The second ordered storage operation stores a work queue entry corresponding to the write data (store WQE 622). SM 310 performs the first and second ordered storage operations as weakly ordered storage operations. The third ordered storage operation stores a doorbell record (store DB rec 624). The fourth ordered storage operation stores a doorbell corresponding to the doorbell record (store DB 626). SM 310 performs the third and fourth ordered storage operations as strongly ordered storage operations.

[0083] Because the first and second ordered store operations are weakly ordered store operations, the MMU 320 can process these two ordered store operations in any order. After address translation, the MMU 320 determines that the first and second ordered store operations point to equivalent memory apertures. Therefore, the MMU 320 sends the first ordered store operation (store WDAT 630) and the second ordered store operation (store WQE 632) to the local L2 cache memory 610. When the MMU 320 receives the third ordered store operation, i.e., the strongly ordered store operation, the MMU 320 completes the address translation and then waits to receive an acknowledgment that the data of the first and second ordered store operations are visible in the memory (ack WDAT 640) and an acknowledgment that the data of the second ordered store operation are visible in the memory (ack WQE 642).

[0084] Upon receiving these two acknowledgments, the MMU 320 processes the third ordered store operation. The MMU 320 determines that the third ordered store operation is destined for the PCIe aperture. The MMU 320 determines that the fourth ordered store operation is also destined for the PCIe aperture. Therefore, the MMU 320 can send the third and fourth ordered store operations in sequence, and the PCIe bus can maintain the order of the third and fourth ordered store operations. Therefore, the MMU 320 sends the third ordered store operation (store DB rec 650) and the fourth ordered store operation (store DB 652) to the system L2 cache memory 612. In some examples, because the PCIe bus maintains ordering, and because the third ordered store operation (store DB rec 650) and the fourth ordered store operation (store DB 652) are destined for the PCIe bus, the MMU 320 does not need to wait for an acknowledgment of the third ordered store operation before sending the fourth ordered store operation, because both the third and fourth ordered store operations are destined for the PCIe bus. The system L2 cache memory 612 forwards the third ordered store operation (store DB rec 660) and the fourth ordered store operation (store DB 662) to the network interface 614. The network interface 614 forwards the third ordered store operation and the fourth ordered store operation to the PCIe bus. The network interface 614 generates an acknowledgment (ack DB rec 670) that the data of the third ordered store operation has been forwarded to the PCIe bus and an acknowledgment (ack DB 672) that the data of the fourth ordered store operation has been forwarded to the PCIe bus. The network interface 614 sends an acknowledgment (ack DB rec 670) for the third ordered store operation and an acknowledgment (ack DB 672) for the fourth ordered store operation to the system L2 cache memory 612. The system L2 cache memory 612 forwards the acknowledgment (ack DB rec 680) for the third ordered store operation and an acknowledgment (ack DB 682) for the fourth ordered store operation to the MMU 320.

[0085] Figure 7 is Figure 37. A sequence diagram of ordered storage operations performed by SM 310 according to various other embodiments is shown. As shown, SM 310 performs four ordered storage operations. The first ordered storage operation stores write data (store WDAT 720). The second ordered storage operation stores a work queue entry corresponding to the write data (store WQE 722). SM 310 performs the first and second ordered storage operations as weakly ordered storage operations. The third ordered storage operation stores a doorbell record (store DB rec 724). The fourth ordered storage operation stores a doorbell corresponding to the doorbell record (store DB 726). SM 310 performs the third and fourth ordered storage operations as strongly ordered storage operations.

[0086] Because the first and second ordered store operations are weakly ordered store operations, the MMU 320 can process these two ordered store operations in any order. After address translation, the MMU 320 determines that the first and second ordered store operations point to the PCIe aperture. After address translation, the MMU 320 determines that the third and fourth ordered store operations also point to the PCIe aperture. Therefore, the MMU 320 can send the four ordered store operations in sequence, and the PCIe bus can maintain the order of the four ordered store operations. Therefore, the MMU 320 sends the first ordered store operation (store WDAT 730), the second ordered store operation (store WQE 732), the third ordered store operation (store DB rec 734), and the fourth ordered store operation (store DB 736) to the system L2 cache memory 612. The system L2 cache memory 612 forwards the first ordered store operation (store WDAT 740), the second ordered store operation (store WQE 742), the third ordered store operation (store DB rec 744), and the fourth ordered store operation (store DB 746) to the network interface 614. The network interface 614 forwards the four ordered store operations to the PCIe bus in sequence. The network interface 614 generates an acknowledgment that the data of the first ordered store operation has been forwarded to the PCIe bus (ack WDAT 750), an acknowledgment that the data of the second ordered store operation has been forwarded to the PCIe bus (ack WQE 752), an acknowledgment that the data of the third ordered store operation has been forwarded to the PCIe bus (ack DB rec 754), and an acknowledgment that the data of the fourth ordered store operation has been forwarded to the PCIe bus (ack DB 756). The network interface 614 sends an acknowledgment of the first ordered storage operation (ackWDAT 750), an acknowledgment of the second ordered storage operation (ack WQE 752), an acknowledgment of the third ordered storage operation (ack DBrec 754), and an acknowledgment of the fourth ordered storage operation (ack DB 756) to the system L2 cache memory 612. The system L2 cache memory 612, in turn, forwards the acknowledgment of the first ordered storage operation (ack WDAT 760), an acknowledgment of the second ordered storage operation (ack WQE 762), an acknowledgment of the third ordered storage operation (ack DB rec 764), and an acknowledgment of the fourth ordered storage operation (ack DB 766) to the MMU 320. In some examples, the MMU 320 does not need to wait for any of these acknowledgments before sending the ordered storage operation.

[0087] Figures 8A to 8C Describes the process used to Figure 3Flowchart of method steps for broadcast operations according to various embodiments performed by SM 310 of FIG. Additionally or alternatively, the method steps may be performed by one or more alternative accelerators, including but not limited to CPU, GPU, DMA unit, IPU, NPU, TPU, NNP, DPU, VPU, ASIC, FPGA and / or the like, in any combination. Although combined Figures 1 to 7 Although the method steps are described with respect to a system, one of ordinary skill in the art will understand that any system configured to perform the method steps in any order is within the scope of the present disclosure.

[0088] As shown, method 800 begins at step 802, where a memory management unit, such as MMU 320 included in SM 310, receives a storage operation from SM 310. SM 310 performs the storage operation to store data at a storage location specified by a virtual address. The storage operation can be an out-of-order storage operation, a weakly-ordered storage operation, or a strongly-ordered storage operation.

[0089] At step 804, the memory management unit determines whether the storage operation is a strongly-ordered storage operation. If the storage operation is not a strongly-ordered storage operation, then the storage operation is either an unordered storage operation or a weakly-ordered storage operation. The memory management unit can process unordered storage operations and weakly-ordered storage operations in any order.

[0090] If the store operation is not a strongly ordered store operation, the method continues to step 806, where the memory management unit translates the address included in the store operation via a translation lookaside buffer. In doing so, when the store operation is completed, the memory management unit translates the virtual address included in the store operation into the physical address of the location of the corresponding data in physical memory. The memory management unit may perform the virtual address to physical address translation by accessing entries in a translation lookaside buffer local to the memory management unit. Additionally or alternatively, the memory management unit may perform the virtual address to physical address translation by accessing a translation lookaside buffer associated with another memory management unit. In either case, the entries in the translation lookaside buffer include entries storing virtual address to physical address translations for recent store operations and / or anticipated store operations. If no translation lookaside buffer contains the required entries, the memory management unit may perform a page table lookup by accessing one or more page tables. The one or more page tables include entries that map pages of virtual memory to pages of physical memory. Based on data included in entries of one or more page tables, the memory management unit generates a virtual address to physical address translation for a virtual address included in a memory operation.

[0091] At step 808, the memory management unit forwards the storage operation to the network interface. The memory management unit may forward the storage operation to different destinations based on the aperture associated with the physical address accessed by the storage operation. Method 800 then terminates. Alternatively, method 800 continues to step 802 above to process additional storage operations.

[0092] Returning to step 804, if the storage operation is a strongly ordered storage operation, method 800 continues to step 810, wherein the memory management unit stores the strongly ordered storage operation in a pre-translation buffer, awaiting the translation of the previously ordered storage operation. The pre-translation sorting module delays the translation of the virtual address of the received strongly ordered storage operation to the physical address until the translation of the pending weakly ordered storage operation is completed. To this end, the pre-translation sorting module includes a translation counter that counts the number of weakly ordered storage operations received by the memory management unit since the most recent strongly ordered storage operation was received. When the memory management unit receives a weakly ordered storage operation or a strongly ordered storage operation, the translation counter increments. When the memory management unit completes the translation of the virtual address of the weakly ordered storage operation to the physical address, the translation counter decrements. When the translation counter reaches zero, the translation of all pending virtual addresses for the pending weakly ordered storage operations to the physical address is completed.

[0093] At step 812, the memory management unit translates the address included in the strongly-ordered store operation via the translation lookaside buffer. In doing so, the memory management unit translates the virtual address included in the strongly-ordered store operation into a physical address corresponding to the location in physical memory where the data resides when the strongly-ordered store operation completes. As described in conjunction with step 806, the memory management unit may perform the virtual address to physical address translation.

[0094] At step 814, the memory management unit determines whether the current strongly-ordered store operation is directed to a PCIe aperture. More generally, the memory management unit determines whether the strongly-ordered store operation is directed to an aperture that supports post-style operations. In this case, the memory management unit can utilize the ordering enforced by the aperture that supports post-style operations. If the current strongly-ordered store operation is not directed to a PCIe aperture, the method 800 continues to step 816.

[0095] At step 816, the memory management unit cannot rely on the ordering enforced by the aperture. The memory management unit determines whether one or more previously ordered memory operations were sent to a non-PCIe aperture. More generally, the memory management unit determines whether a previously ordered memory operation was sent to an aperture that does not support posted operations. If no previously ordered memory operations were transmitted to a non-PCIe aperture, the method 800 continues to step 818.

[0096] At step 818, the memory management unit has determined that the current strongly ordered memory operation is directed to a non-PCIe aperture and that no previously ordered memory operations were sent to a non-PCIe aperture. The memory management unit then determines whether one or more previously ordered memory operations were sent to a PCIe aperture. If the previously ordered memory operation was sent to a PCIe aperture, the method 800 continues to step 820.

[0097] At step 820, the memory management unit has determined that the current strongly ordered store operation is directed to a non-PCIe aperture, no previous ordered store operation was sent to a non-PCIe aperture, and at least one previous ordered store operation was sent to a PCIe aperture. In this case, the system has switched from transmitting ordered operations to the PCIe interface to transmitting ordered operations to the non-PCIe interface. In this case, the memory management unit sends an aperture switch I / O flush operation to the PCIe interface. This aperture switch I / O flush operation ensures that data from ordered store operations directed to interfaces that support posted store operations is visible in memory before processing ordered store operations directed to any interface that does not support posted store operations. This aperture switch I / O flush operation essentially inserts or issues a dummy read operation on the PCIe bus, which is, by definition, non-posted. According to PCIe ordering rules, non-posted operations push previous posted operations. Therefore, the dummy read response from the aperture switch I / O flush operation ensures that the previous posted store operation is visible in memory.

[0098] In step 824, the memory management unit stores the strongly ordered store operations in the post-translation buffer, awaiting confirmation that the data of the previously ordered store operations is visible in the memory and / or confirmation that the pending aperture switch I / O refresh operation is complete. The post-translation ordering module receives the translated strongly ordered store operations from the translation back buffer. The post-translation ordering module can store multiple translated strongly ordered store operations in a buffer, a first-in-first-out (FIFO) memory, a queue, and / or the like. The post-translation ordering module includes an acknowledgement counter that counts the number of pending acknowledgements for weakly ordered store operations and strongly ordered store operations. When the memory management unit generates a weakly ordered store operation or a strongly ordered store operation, the acknowledgement counter increments. When the network interface and / or other interface or communication bus confirms that the data of the weakly ordered store operation or the strongly ordered store operation is visible in the memory, the acknowledgement counter decrements. When the acknowledgement counter reaches zero, the virtual address to physical address translations of all pending weakly ordered store operations and strongly ordered store operations are displayed in the memory. In some examples, such as when processing PCIe memory operations, the MMU 320 may skip pushing strongly-ordered memory operations to the post-translation buffer when the pending (post-translation) acknowledge counter value is zero and / or the like. If a pending aperture switch I / O flush operation is pending, the memory management unit waits for a read operation response to the virtual read operation that indicates that data associated with the posted operation is visible in memory.

[0099] In step 826, the memory management unit increments the pending acknowledgement counter. The pending acknowledgement counter maintains a count of ordered storage operations that have been issued but not yet acknowledged. Therefore, when those acknowledgements are received, the memory management unit then decrements the pending acknowledgement counter.

[0100] At step 828, the memory management unit forwards the strongly-ordered store operation to the network interface. The memory management unit may forward the strongly-ordered store operation to different destinations based on the aperture associated with the physical address accessed by the store operation. Method 800 then terminates. Alternatively, method 800 continues to step 802 above to process additional store operations.

[0101] Returning to step 818, if no previous ordered store operation was transmitted to the PCIe aperture, method 800 continues to step 826 as described above. In this case, no ordered store operation was transmitted to any aperture before the current strongly ordered store operation. The memory management unit increments the pending acknowledgement counter and forwards the current strongly ordered store operation.

[0102] Returning to step 816, if one or more previously ordered store operations were sent to a non-PCIe aperture, method 800 continues to step 824 described above. In this case, one or more ordered store operations have been transmitted to the non-PCIe aperture before the current strongly ordered store operation. The memory management unit saves the current strongly ordered operation and waits for confirmation that the data from those previously ordered store operations is visible in memory. The memory management unit increments the pending confirmation counter and forwards the current strongly ordered store operation.

[0103] Returning to step 814, if the current strongly-ordered store operation is directed to a PCIe aperture, method 800 continues to step 822. At step 822, the memory management unit can rely on the ordering enforced by the aperture, but the memory management unit must first determine whether one or more ordered transactions are pending in the non-PCIe aperture. Therefore, at step 822, the memory management unit determines whether one or more previously ordered store operations were sent to a non-PCIe aperture. More generally, the memory management unit determines whether a previously ordered store operation was sent to an aperture that does not support posted operations. If no previously ordered store operation was transmitted to a non-PCIe aperture, method 800 continues to step 826 as described above. In this case, the memory management unit increments the pending acknowledgement counter and forwards the current strongly-ordered store operation.

[0104] If, at step 822, one or more previously ordered memory operations were sent to a non-PCIe aperture, the method 800 continues to the above-described step 824. In this case, the memory management unit saves the current strongly ordered operation and waits for confirmation that the data from those previously ordered memory operations is visible in memory. The memory management unit increments the pending confirmation counter and forwards the current strongly ordered memory operation.

[0105] In summary, various embodiments include techniques for executing ordered store operations from GPU clients in a multi-processor system. In some examples, the techniques execute ordered store operations from a GPC 208 to initiate work to a NIC in a multi-processor system. The NIC can operate by maintaining a circular work queue, where each entry in the queue is referred to as a work queue entry (WQE). The circular work queue can be stored in any memory system such as system memory, PP memory, and the like. Each WQE includes a work descriptor that informs the NIC what work to perform on the corresponding message data.

[0106] Utilizing the disclosed techniques, threads executing in a computing system have an ordered view of memory. This ordered view of memory is a memory view that differs from a standard program memory view, in which writes to different addresses are unordered without memory synchronization operations. From a programmer's perspective, this ordered view provides a mechanism for executing global memory store operations with embedded, hardware-enforced synchronization. The data of any store operation executed within the ordered view is visible to any external observer via subsequent strongly ordered store operations within the same view without the need to perform additional memory synchronization operations. Utilizing these techniques, threads executing on an SM maintain the order of store operations until the store operation is issued to the MMU 320 and the memory system. The MMU 320, in turn, ensures that store operations remain ordered relative to previously ordered store operations executed by the thread, as intended by the programmer. The MMU 320 performs additional synchronization operations as needed to ensure that ordering is maintained without the assistance of software techniques or instructions, such as memory synchronization operations.

[0107] The disclosed ordered storage operations can be divided into two main types: weakly ordered storage operations and strongly ordered storage operations. Weakly ordered storage operations do not enforce strict ordering between them, beyond the basic same-thread same-address ordering provided by the GPU memory model. On the other hand, strongly ordered storage operations enforce strict ordering relative to any other previous ordered storage operations (including weakly ordered storage operations and strongly ordered storage operations). Strongly ordered storage operations further ensure that previous ordered storage operations are visible system-wide. The ordered view includes weakly ordered storage operations and strongly ordered storage operations. Weakly ordered storage operations provide better performance, although their ordering guarantees are weaker. Strongly ordered storage operations provide stricter ordering guarantees at slightly lower performance.

[0108] In some examples, ordered storage operations are used in conjunction with implicit hardware-enforced ordering. In this regard, storage operations directed to the PCIe bus are post-type storage operations, in which the PCIe bus does not return an acknowledgment when the storage operation is completed, and the data contained in the storage operation is visible at the destination. In addition, PCIe semantics can enforce policies so that consecutive storage operations to any address in the PCIe bus address space remain ordered. Specifically, the PCIe bus includes an RO bit that indicates that the memory operation is subject to loose ordering. If the loose ordering bit is disabled (RO=0), the memory operation does not obey the loose ordering, indicating that the memory operation is strongly ordered. In this case, PCIe ordering forces all memory storage operations to any address issued before the strongly ordered memory operation to be pushed to the PCIe bus. If the loose ordering bit is activated (RO=1), the memory operation will follow the loose ordering. In this case, the memory storage operation issued before the memory operation with loose ordering may or may not be pushed to the PCIe bus. As used herein, if an SM issues a strongly ordered store operation directed to the PCIe bus, the store operation is transmitted on the PCIe bus as a memory store operation with RO = 0. Thus, PCIe ordering forces all memory store operations on the PCIe bus to be pushed before memory store operations with RO = 0.

[0109] At least one technical advantage of the disclosed technology over the prior art is that, by using the disclosed techniques for ordered store operations, threads can eliminate memory synchronization operations and still maintain desired ordering between individual store operations relative to any physical global memory aperture, such as system (e.g., CPU-attached) memory aperture, peer device memory aperture, local device memory aperture, and / or the like. The memory system maintains proper ordering in an efficient manner, with the MMU inserting wait cycles only when needed to see ordered store operations. By doing so, strongly ordered store operations can maintain the cumulative ordering of previously ordered store operations system-wide, with higher performance and less processing overhead than conventional techniques employing memory synchronization operations. These advantages represent one or more technical improvements over prior art approaches.

[0110] Any and all combinations of any claim elements recited in any claim and / or any elements described in this application, in any manner, are within the scope of this disclosure and protection.

[0111] The description of the various embodiments has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

[0112] Aspects of the present embodiments may be embodied as systems, methods, or computer program products. Thus, aspects of the present disclosure may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which are collectively referred to herein as "modules" or "systems." Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable media containing computer-readable program code.

[0113] Any combination of one or more computer-readable media can be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium includes, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment, or any suitable combination thereof. More specific examples (non-exhaustive enumeration) of computer-readable storage media can include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this document, a computer-readable storage medium can be any tangible medium that can include or store a program for use by or in conjunction with an instruction execution system, device or device.

[0114] Aspects of the present disclosure are described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram, and the combination of boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that the instructions executed by the processor of the computer or other programmable data processing device enable the function / action specified in one or more boxes of the flowchart and / or block diagram to be implemented. Such processors can be, but are not limited to, general-purpose processors, special-purpose processors, application-specific processors, or field programmable gate arrays.

[0115] The flowcharts and block diagrams in the figures illustrate the possible architectures, functions and operations of the systems, methods and computer program products according to the various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, segment or portion of a code, and the code includes one or more executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative embodiments, the functions indicated in the box may not occur in the order indicated in the figure. For example, two boxes shown in succession can actually be executed roughly at the same time, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, can be implemented by a system based on dedicated hardware that performs a specified function or action or a combination of dedicated hardware and computer instructions.

[0116] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof, as determined by the claims that follow.

Claims

1. A computer-implemented method for performing a memory storage operation, the method comprising: receiving a first store operation from a first processor; determining that the first storage operation comprises a first type of ordered storage operation; as well as maintaining an ordering of the first memory operation relative to a second memory operation, the second memory operation comprising an ordered memory operation of a second type, Wherein when the first storage operation is suspended, the first processor continues to execute operations.

2. The computer-implemented method of claim 1 , wherein maintaining the ordering of the first storage operation with respect to the second storage operation comprises: Execution of the first memory operation is delayed until confirmation is received that data of a second memory operation comprising an ordered memory operation of a second type is visible in memory.

3. The computer-implemented method of claim 2, wherein: The ordered storage operations of the first type include first strongly-ordered storage operations; and The ordered storage operations of the second type include second strongly-ordered storage operations.

4. The computer-implemented method of claim 1 , wherein: The ordered storage operations of the first type include strongly ordered storage operations; and The ordered storage operations of the second type include weakly ordered storage operations.

5. The computer-implemented method of claim 1 , further comprising: receiving a confirmation that data from the second storage operation is visible in the memory; as well as The first storage operation is performed.

6. The computer-implemented method of claim 1 , wherein: said first type of said ordered storage operation comprises a first weakly ordered storage operation; said second type of ordered storage operations comprising second weakly ordered storage operations; and Execution of the first storage operation is not delayed due to the suspension of the second storage operation.

7. The computer-implemented method of claim 1 , further comprising: receiving a third storage operation from the first processor before receiving the first storage operation; as well as determining that the third storage operation comprises an out-of-order storage operation, The execution of the first storage operation will not be further delayed due to the suspension of the third storage operation.

8. The computer-implemented method of claim 1 , further comprising: The translation of the first virtual address of the first storage operation into a physical address is delayed until the translation of the second virtual address of the second storage operation into a physical address is completed.

9. The computer-implemented method of claim 8, further comprising: determining that translation of the second virtual address to a physical address of the second storage operation has been completed; as well as A translation of the first virtual address of the first storage operation into a physical address is performed.

10. The computer-implemented method of claim 9, wherein performing translation of the first virtual address to a physical address of the first storage operation comprises: A physical address associated with the first store operation is accessed from an entry included in a first translation buffer associated with the first processor.

11. The computer-implemented method of claim 9 , wherein performing translation of the first virtual address to a physical address of the first storage operation comprises: A physical address associated with the first memory operation is generated based on an entry in a page table, wherein the entry in the page table corresponds to a virtual address associated with the first memory operation.

12. The computer-implemented method of claim 8, further comprising: receiving a third storage operation from the first processor before receiving the first storage operation; as well as determining that the third storage operation comprises an out-of-order storage operation, The translation of the first virtual address of the first storage operation into a physical address is not further delayed by the translation of the third virtual address of the third storage operation into a physical address.

13. The computer-implemented method of claim 1 , further comprising: receiving a third store operation from the first processor; determining that the third storage operation comprises an ordered storage operation and that the third storage operation is directed to a first interface that does not support non-posted storage operations; as well as The third store operation is performed without delaying the third store operation to receive confirmation that data from the first store operation is visible in memory.

14. The computer-implemented method of claim 13, wherein the first storage operation is directed to the first interface that does not support non-posted storage operations.

15. The computer-implemented method of claim 13, wherein the first interface comprises a Peripheral Component Interconnect Express (PCIe) interface.

16. The computer-implemented method of claim 1 , wherein the first storage operation is directed to a first interface that does not support non-posted storage operations, and the method further comprises: receiving a third store operation from the first processor; Ensure that previously issued ordered store operations are visible in memory; as well as The third store operation is performed without delaying receiving confirmation that the data of the first store operation is visible in memory.

17. The computer-implemented method of claim 1, wherein delaying performing the first memory operation preserves ordering between the first memory operation and the second memory operation with respect to a physical memory aperture.

18. The computer-implemented method of claim 17, wherein the physical memory aperture comprises at least one of a system memory aperture, a peer memory aperture, or a video memory aperture.

19. The computer-implemented method of claim 1, wherein the second storage operation is directed to a first interface that does not support non-posted storage operations and the first storage operation is directed to a second interface that supports non-posted storage operations.

20. The computer-implemented method of claim 1 , wherein: The first storage operation is directed to a first aperture supporting non-drop-in storage operations; as well as The second store operation is directed to a second aperture that does not support non-posted store operations; and The method further comprises: delaying the first storage operation by inserting an aperture switch input / output refresh operation on the second aperture, wherein the aperture switch input / output refresh operation comprises a dummy read operation; receiving the read operation response to the dummy read operation, the read operation response indicating that data associated with the second storage operation is visible in memory; and In response to receiving the read operation response, allowing the first storage operation to proceed.

21. A system comprising: a first processor, wherein the first processor: generating a first storage operation; as well as A memory management unit, the memory management unit: receiving the first store operation from the first processor, determining that the first storage operation comprises a first type of ordered storage operation, and delaying execution of the first memory operation until receiving confirmation that the second memory operation comprises an ordered memory operation of a second type, Wherein when the first storage operation is suspended, the first processor continues to execute operations.

Images