Barrier-free and fenceless shared memory synchronization

Abstract

When communicating through shared memory, a producer thread generates a value that is written into a location in shared memory. The value is read from the shared memory by a consumer thread. The challenge is to ensure that the consumer thread reads the location only after the value has been written and thus synchronized. When the producer thread writes the memory location, a flag stored in the memory location at the same time as the value is toggled. The consumer thread tracks information to determine whether the flag stored in the location indicates whether the value has been written to the location by the producer. The flag is read and written at the same time as the location in memory is read and written, thereby eliminating the need for a memory fence. After all consumer threads have read the value, the location can be reused to write one or more additional values and toggle the flag at the same time.

Description

[0001] CLAIM

[0002] This application claims priority to U.S. Patent Application No. 16 / 818,845, filed March 13, 2020, entitled “BARRIERLESS AND FENCELESS SHARED MEMORY SYNCHRONIZATION,” the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure relates to shared memory synchronization, and more particularly to barrierless and fenceless shared memory synchronization. BACKGROUND

[0004] A conventional approach to facilitating shared memory communication is to use barrier synchronization. A “barrier” is a routine executed by producer threads and consumer threads that suspends each thread until all other threads also reach the barrier. In addition, the barrier ensures that all previously initiated memory writes have completed, which is accomplished using a memory fence. The barrier ensures that a consumer thread does not access a memory location until the memory location contains the expected data written by a producer thread. A drawback of the conventional approach is twofold. First, the cost of executing the barrier synchronization routine is high and involves multiple trips to memory. Second, if threads reach the barrier at different times, some threads will have to wait and be idle, which can increase the total computation time.

[0005] While some variations of the conventional synchronization approach can not use explicit barrier synchronization routines, these variations still use memory fences. An example of such a variation is a semaphore. For these variations, synchronization is achieved by using one or more synchronization variables. After writing data to memory, a producer thread executes a memory fence to ensure that the data is committed to memory. The producer thread then updates the synchronization variable. A consumer thread polls (e.g., reads) the synchronization variable until the synchronization variable changes state, and then proceeds to read data from memory. A drawback of these approaches is the cost of the fence and the additional memory trips. For example, implementing the memory fence requires one memory trip. The cost of the communication change in the synchronization variable requires an additional memory trip. However, reading the data typically requires another additional memory trip. These issues and / or other issues related to the prior art need to be addressed. SUMMARY

[0006] When communicating through shared memory, a producer thread generates a value that is written into a location in shared memory. The value is read from the shared memory by a consumer thread. The challenge is to ensure that the consumer thread reads the location only after the value has been written and thus synchronized. When the producer thread writes the memory location, a flag stored in the memory location is toggled along with the value. The consumer thread tracks information to determine whether the flag stored in the location indicates whether the value has been written to the location by the producer. The flag is read and written simultaneously with the value read and written to the location in memory, thereby eliminating the need for a memory fence. After the consumer thread reads the value, the location can be reused to write an additional value while toggling the flag.

[0007] The present disclosure relates to a method, computer readable medium, and system for shared memory synchronization. In one embodiment, a method includes executing a thread group by a multi-threaded parallel processor to process an input according to an instruction sequence, generating a first value by a first thread in the thread group, and writing the first value to a first location of a shared memory while updating a first flag stored at the first location. In one embodiment, the first flag toggles from a first state to a second state, where the first flag is initialized to the second state when execution of the instruction sequence begins. In another embodiment, the first flag toggles from the second state to the first state, where the first flag is initialized to the first state when execution of the instruction sequence begins.

[0008] In one embodiment, the method further includes determining, by a third thread, that the first flag has changed from the first state to the second state, reading, by the third thread, the first value from the first location, then updating a second flag stored at a second location of the shared memory, the flag to be written by a second thread in the thread group, and processing, by the third thread, the first value to produce an output. In one embodiment, determining that the first flag has changed from the first state to the second state includes reading, by the third thread, the first flag and the first value from the first location simultaneously. In one embodiment, determining that the first flag has changed from the first state to the second state further includes comparing the first flag to a valid state.

[0009] In one embodiment, the first flag is stored in a location within the first location that replaces a bit of the first value. In one embodiment, the location corresponds to a least significant bit of the first value.

[0010] In one embodiment, the first value and the first flag are encoded as one of a single 16-bit, 32-bit, 64-bit, or 128-bit word.

[0011] In one embodiment, at least one additional value is associated with the first flag, further including writing the at least one additional value to the first storage location simultaneously when the first value is written to the first storage location.

[0012] In one embodiment, execution of the instruction sequence includes performing one or more operations using a neural network.

[0013] In one embodiment, the method further includes writing, by the third thread, the output to the third location while updating a third flag stored at the third location in the shared memory from a first state to a second state. In one embodiment, the method further includes determining, by a fourth thread, that the third flag has changed from the first state to the second state, processing the output of the fourth thread to produce a fourth value, and updating a first flag stored at the first location from the second state to the first state while writing the fourth value to the first location.

[0014] In one embodiment, a system includes a multi-core parallel processor coupled to a shared memory and configured to execute a thread group to process an input according to an instruction sequence, generate a first value by a first thread in the thread group, and write the first value to a first location in the shared memory while updating a first flag stored at the first location from a first state to a second state, wherein the first flag is initialized to the second state when execution of the instruction sequence begins.

[0015] In one embodiment, a non-transitory computer readable medium stores computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of: executing a thread group to process an input according to an instruction sequence, generating a first value by a first thread in the thread group, and writing the first value to a first location of a shared memory while updating a first flag stored at the first location from a first state to a second state, wherein the first flag is initialized to the second state when execution of the instruction sequence begins. BRIEF DESCRIPTION OF DRAWINGS

[0016] FIG. 1A A block diagram of a multi-threaded shared memory communication system is shown in accordance with one embodiment.

[0017] FIG. 1B A schematic diagram of an example shared memory data format is shown in accordance with one embodiment.

[0018] FIG. 1C A block diagram of another example multi-threaded shared memory communication system is shown in accordance with one embodiment.

[0019] FIG. 1D A conceptual diagram of shared memory communication using a circular buffer is shown in accordance with one embodiment.

[0020] FIG. 2A A flowchart of a method for synchronizing shared memory communication is shown in accordance with one embodiment.

[0021] FIG. 2BAnother flowchart of a method for synchronizing shared memory communication according to one embodiment is shown.

[0022] FIG. 3 A parallel processing unit according to one embodiment is shown.

[0023] FIG. 4A An embodiment is shown. FIG. 3 A general-purpose processing cluster within a parallel processing unit.

[0024] FIG. 4B An embodiment is shown. FIG. 3 The memory partitioning unit of the parallel processing unit.

[0025] FIG. 5A An embodiment is shown. FIG. 4A Streaming multiprocessors.

[0026] FIG. 5B The use according to one embodiment is shown. FIG. 3 A conceptual diagram of the processing system implemented by the PPU.

[0027] FIG. 5C An exemplary system is shown that can implement various architectures and / or functions of various previous embodiments. Detailed Implementation

[0028] During multithreaded processing, data is transferred from producer threads to consumer threads via shared memory. In the context described below, shared memory can be accessed (read and / or written) by different threads executing within a parallel processor. When communicating using shared memory, the producer thread processes a set of inputs and generates a first value to be written to a first location in the shared memory. The consumer thread reads the first value from the shared memory and processes it to generate a second value to be written to a second location in the shared memory, and so on. The challenge is to ensure that a second thread reads a memory location only after the value generated by the first thread has been written to that memory location. Barriers and fences can be avoided by including a flag in each memory location where a value is written and writing a data packet containing the flag and the value in the same transaction (e.g., simultaneously). When a memory location is written, the flag is updated to indicate that a valid value has been written to the memory location. Unlike prior art, where the flag is not updated to a predetermined value to indicate that a memory location has been written, all flags are initialized to the same state (true or false), and the state of the flag is toggled each time a memory location is written.

[0029] When a consumer thread reads a value from a memory location, the value is read simultaneously with a flag stored in the same location. To ensure the read value is valid, the memory location is polled (read) until a flag indicating a valid value is found. The value read along with the flag can then be used in processing, eliminating the need for an additional round trip to memory to retrieve the value after synchronization. Each thread maintains state information indicating the flag state of a memory location that has been written to and is therefore valid, or that needs to be written to and is therefore invalid. In one embodiment, a memory location may be written to by a single producer thread and read by one or more consumer threads. In one embodiment, a memory location can be overwritten with a new value without reinitializing the flag. However, before overwriting a memory location with a new value, it must be ensured that the previous value stored in the memory location is no longer needed, i.e., all consumer threads have already read it.

[0030] FIG. 1A A multi-threaded shared memory communication system 100 according to one embodiment is illustrated. Although the shared memory system 100 is described in the context of processing units, one or more of units 110 and 115 can be implemented as a program, custom circuitry, or a combination of custom circuitry and programs. For example, units 110 and / or 115 can be implemented by a GPU (Graphics Processing Unit), a CPU (Central Processing Unit), or any other type of processor. In one embodiment, units 110 and 115 implement components of a neural network. In one embodiment, the neural network is a recurrent neural network (RNN). Furthermore, those skilled in the art will understand that any system performing the operation of a shared memory system is within the scope and spirit of the embodiments of the present invention.

[0031] Unit 110 is a multi-threaded parallel processing unit configured to receive input and process the input according to a first instruction executed by a first set of threads to produce a first value. In one embodiment, unit 110 is... FIG. 4A The programmable streaming multiprocessor (SM) 440 is shown. In one embodiment, the first instruction is a sequence of program instructions, wherein the program further includes at least a second instruction and a third instruction. A first group of threads simultaneously writes a first value to memory locations 101 and 102, while simultaneously switching (e.g., updating) a first flag stored in memory locations 101 and 102 of shared memory 105 from a first state to a second state. When execution of the first instruction begins, the first flag is initialized to the first state. Alternatively, the first flag is initialized to the second state, and when the first value is written, the first flag is switched from the second state to the first state. In one embodiment, shared memory 105 includes FIG. 5A The L2 cache is 460.

[0032] Unit 115 is a multi-threaded parallel processing unit configured to read a first value from a flag stored at the same memory location as the first value at the same time as the flag, and to process the first value to produce a second value according to a second instruction executed by a second thread when the flag indicates that the first value is valid. The first value can be written to memory locations 101 and 102 at different times. Thus, some of the second threads can read the first value from location 101 and start processing while other second threads are still waiting for the data to be written to location 102. In contrast, when a single conventional barrier is used to synchronize the first threads with the second threads, no second thread can start processing until all first threads have written the value to memory.

[0033] Each thread in the second set of threads polls (e.g., reads, as indicated by the dashed arrows in FIG. 1A the second flag stored at the respective memory location to detect a change from a first state to a second state, indicating that the second value has been written to the memory location. In contrast to the prior art, in which the first state or the second state indicates valid data, while the other state indicates invalid data, neither the first state nor the second state always indicates that the memory location stores valid data. In other words, the interpretation of the flag state depends on the context, so that for one transaction (e.g., a read or a write), the first state indicates that the memory location contains valid data, while for another transaction, the first state indicates that the same memory location contains invalid data, as further described herein.

[0034] When the particular flag polled by a thread indicates that the value is valid (e.g., the flag changes with the value written), the synchronization between the producer thread and the consumer thread is complete for the shared memory location, and the consumer thread can use the value read at the same time as the flag for computation. When each of the threads in the second set of threads completes processing, the thread writes the thread portion of the second value to memory location 111 or 112 at the same time as the second flag stored in memory location 111 or 112, respectively, is switched from the first state to the second state. The second value can be processed again and / or can be sent as output from unit 115.

[0035] More illustrative information will now be set forth in relation to various optional architectures and features that can implement the above framework, as per the desire of the user. It should be noted that the following information is set forth in relation to the particular architectures and features set forth in the description for purposes of exemplification and that the information set forth is not intended to limit or restrict the scope or applicability of the framework set forth. Any of the features set forth can be selectively incorporated into any of the other features set forth, or used in conjunction with any of the other features set forth, without limitation.

[0036] FIG. 1BA diagram illustrating an example shared memory format is shown. A data packet 106 is stored by a thread in a memory location of a shared memory and includes at least one value and a single flag associated with the at least one value. Each of the at least one value can be represented in fixed point, floating point, or any other viable format. In one embodiment, all bits of a value produced by a thread are stored without reducing precision, and a single bit is dedicated to the flag. In another embodiment, the flag is stored in a least significant bit (lsb) position of one of the values, thereby reducing the precision of the one value. When the values are represented in floating point format, the lsb position can be an lsb of a mantissa. Any other values stored in the data packet 106 are stored at full precision.

[0037] A data packet 107 is stored by a thread in a memory location of a shared memory and includes two values and a single flag associated with the two values. Each value can be represented in fixed point, floating point, or any other viable format. In one embodiment, all bits of the two values produced by a thread are stored without reducing precision, and a single bit is dedicated to the flag. As shown in the data packet 107, the flag can be stored in any bit position within the data packet 107, including any bit position within one of the two values. In a particular embodiment, the flag is stored in a bit position (lsb or another bit) of a first of the two values, thereby reducing the precision of the first value, and the other value is stored at full precision in the data packet 107.

[0038] Each of the data packets 106 and 107 is read completely (atomically) so as to read the flag and the values simultaneously. Each of the data packets 106 and 107 is written completely (atomically) so as to write the flag and the values simultaneously. When a data packet 106 or 107 is written to the shared memory 105, the producer thread sets the flag in the data packet so as to toggle the flag. Specifically, the flag is toggled from being in a first state to being in a second state (e.g., from false to true or from true to false). In one embodiment, the flag and the values are encoded in the data packet 106 or 107 as a single 16-bit, 32-bit, 64-bit, or 128-bit word, such that the flag occupies a single bit in the data packet 106 or 107.

[0039] FIG. 1CA block diagram of another example multi-threaded shared memory communication system 140 is shown, in accordance with one embodiment. Although the shared memory system 140 is described in the context of processing units, one or more of the units 160 and 165 can be implemented as programs, custom circuitry, or by a combination of custom circuitry and programs. For example, the units 160 and / or 165 can be implemented by a GPU (graphics processing unit), a CPU (central processing unit), or any processor. In one embodiment, each of the units 160 and 165 is capable of implementing at least one layer of a neural network. Furthermore, one of ordinary skill in the art will appreciate that any system that performs the operations of the shared memory system is within the scope and spirit of the present embodiment.

[0040] The unit 160 is a multi-threaded parallel processing unit configured to receive an input and process the input according to first instructions executed by a first set of threads to produce first values. Prior to the units 160 and 165 beginning processing, the flag management unit 120 initializes the flags to a predetermined flag state (e.g., a first or second state). In one embodiment, the units 160 and 165 are programmable SMs 440 as shown in FIG. 4B. The first set of threads write the first values to memory locations 101 and 102 of the shared memory 105 simultaneously, while toggling the first flags stored in the memory locations 101 and 102. FIG. 4A The first set of threads write the first values to memory locations 101 and 102 of the shared memory 105 simultaneously, while toggling the first flags stored in the memory locations 101 and 102.

[0041] The flag state 125 within the units 160 and 165 is configured to track the flag state, providing the information needed to determine which of the two states corresponds to the valid value at any point in time. In one embodiment, when reading a data packet from the shared memory 105, the thread reading the shared memory 105 knows the flag state (e.g., the invalid state) prior to when the data packet was (or will be) written. In one embodiment, when reading a data packet from the shared memory 105, the thread reading the shared memory 105 knows the state the flag will have after the data packet is written (e.g., the valid state). In one embodiment, the flag state 125 within the unit 165 tracks each flag accessed by the second threads separately.

[0042] In one embodiment, when all of the first values must be written to the shared memory 105 prior to any of the first values being read by any of the threads in the second set of threads, the flag state 125 within the unit 165 tracks all of the flags accessed by the second set of threads as a group, effectively implementing a barrier between the first instructions executed by the first threads and the second instructions executed by the second threads.

[0043] The unit 165 reads the first values and the first flags from memory locations 101 and 102 simultaneously, and when the flags indicate that the first values are valid, the second group of threads processes the first values according to the second instruction to produce second values. In one embodiment, if a particular thread executing in the unit 165 is to process the values stored in memory locations 101 and 102, the thread will poll the respective flags stored in memory locations 101 and 102. In one embodiment, the thread waits for both flags to indicate that the values are valid before beginning processing according to the second instruction. In another embodiment, the thread begins processing according to the second instruction when the flag stored in memory location 101 changes state, and the thread waits for the flag stored in memory location 102 to change state when the instruction in the second instruction reaches a requirement for the value stored in memory location 102.

[0044] When each thread in the second group of threads completes processing, the thread writes a value to memory location 111 or 112, and simultaneously toggles the flag stored in memory location 111 or 112 from a first state to a second state. A third group of threads executing the third instruction in unit 160 reads the second values from memory locations 111 and 112, and when the respective flags indicate that the second values are valid, each thread in the third group of threads processes at least one of the second values according to the third instruction to produce a third value. The third group of threads writes the third value to memory locations 101 and 102 of shared memory 105, and simultaneously toggles the first flags stored in memory locations 101 and 102. In one embodiment, the first group of threads and the third group of threads are the same group of threads.

[0045] The first values stored in memory locations 101 and 102 are reused and overwritten with the third values, and the first flags are toggled back to the same state in which they were initialized. However, the flag management unit 120 can not reinitialize all of the flags again before executing the third group of threads. Instead, the flags are initialized once for the entire program including at least the first, second, and third instructions. In one embodiment, each new packet is written to a different memory location in an "array" available to the program within shared memory 105 until all of the memory locations in the array have been written. After the entire array has been written, the writing can "wrap around" and begin overwriting memory locations in the array. The number of memory locations in the array and / or the wrap-around capability are application specific and are determined to ensure that only consumed memory locations are overwritten. In contrast, conventional techniques write each memory location once and do not reuse any memory locations. Thus, more memory locations are required to execute the same program using conventional techniques.

[0046] FIG. 1DA conceptual diagram of shared memory communication using a circular buffer is shown in accordance with one embodiment. In one embodiment, a selected set of memory locations in shared memory 105 are configured as a circular array, and a flag stored in the memory locations that are initialized to the same state. For example, as shown in FIG. 1D memory locations 131, 132 through 141, 142 through 151, and 152 through 161 are initialized to a first state. In other embodiments, fewer or more memory locations in shared memory 105 can be included in the circular array. Thread A and thread B write memory locations 131 and 132 with data packets, and the associated flags stored in memory locations 131 and 132 toggle from the first state to a second state. Thread C polls memory location 131 by reading the value and flag stored in the location simultaneously until it determines that the flag is in the second state. Thread C processes the values and writes a second value to memory location 141, while toggling the flag stored in memory location 141. Thread C can process one or more additional values in addition to the values read from memory location 131. Thread D writes other values to memory location 142.

[0047] Upon determining that the flag stored in memory location 141 is in the second state, thread E can begin processing the second value. Since the second value is obtained in the same transaction as when the flag is read from memory location 141, a separate read to obtain the second value is not required. Thread E processes the second value and writes a third value to memory location 151, while toggling the flag stored in memory location 151. Thread F writes other values to memory location 152. Thread F can read and process the values stored in memory locations 141 and / or 142. Upon determining that the flag stored in memory location 151 is in the second state, thread A processes the third value and writes a fourth value to memory location 131, overwriting the previously written values in the circular array. In another embodiment, a different thread can process the third value and write the fourth value to the memory location, rather than reusing thread A, overwriting the previously written values in the circular array. Thread A toggles the flag stored in memory location 131 from the second state to the first state while writing the fourth value. In another embodiment, thread E toggles the flag stored in memory location 131 from the second state to the first state while writing the third value to memory location 131, overwriting the previously written values in the circular array. In yet another embodiment, one or more additional threads read the third value, generate a fourth value that is written to shared memory 105 while toggling the associated flag to continuously generate any number of values before overwriting in the circular array.

[0048] Compared to traditional shared memory synchronization techniques, the number of memory locations within shared memory 105 can be reduced when reusing memory locations. Furthermore, performance is improved since there is no need to reinitialize flags before reusing memory locations. Instead of initializing flags corresponding to one-time use memory locations, a small number of flags are toggled to reduce the number of reusable memory locations to ensure synchronization. Furthermore, flag state information is maintained to track flag states indicating whether values stored in memory locations are valid. In one embodiment, memory locations comprising the array are stored in on-chip caches, such as level 1 (LI) and / or level 2 (L2) caches.

[0049] FIG. 2A A flowchart of a method 200 for synchronizing shared memory communications according to one embodiment is shown. Although method 200 is described in the context of a processing unit, method 200 can also be performed by a program, custom circuitry, or a combination of custom circuitry and a program. For example, method 200 can be performed by a GPU, CPU, or any processor capable of accessing shared memory 105. Furthermore, one of ordinary skill in the art will appreciate that any system performing method 200 is within the scope and spirit of embodiments of the present invention.

[0050] At step 205, flag management unit 120 initializes all flags in an array comprising a plurality of memory locations in shared memory 105 and initializes flag state 125. At step 210, a first set of threads executing on a multi-threaded parallel processor (such as unit 110 or 160) processes input according to an instruction sequence. At step 215, a first thread in the first set of threads generates a first value. At step 220, the first value is written to a first location while updating a first flag stored in the first location of shared memory 105. The first flag is updated by toggling the first flag. The toggle updates the first flag from a first state to a second state when the flags in the array are initialized to the first state. As each memory location is overwritten when the shared memory communications wrap from the end of the array to reuse memory locations, the flags toggle from the second state back to the first state. When the shared memory communications wrap from the end of the array a second time, the flags toggle from the first state to the second state again, and so on.

[0051] FIG. 2BAnother flowchart illustrating a method 225 for synchronized shared memory communication according to one embodiment is shown. Although the method 225 is described in the context of a processing unit, the method 225 can also be performed by a program, custom circuitry, or a combination of custom circuitry and a program. For example, the method 225 can be performed by a GPU, CPU, or any processor capable of accessing the shared memory 105. Furthermore, one of ordinary skill in the art will appreciate that any system performing the method 225 is within the scope and spirit of the present embodiment.

[0052] At step 205, the flag management unit 120 initializes all flags in an array comprising a plurality of memory locations in the shared memory 105 and initializes the flag state 125. At step 212, thread A executes a first instruction to process an input and generate a first value. At step 222, thread A writes the first value to a first memory location 131 while toggling a first flag stored in the first memory location 131. At step 224, thread C begins executing a second instruction to process the first value. At step 226, thread C reads the flag stored in the first memory location 131 corresponding to the first value and indicates whether the first value has been written by thread A. In one embodiment, the flag state information stored in the flag state 125 is used to determine whether the flag has changed state indicating that the first value is valid.

[0053] If at step 226, the flag indicates that the first value is invalid, then step 226 is repeated. When at step 226, the flag indicates that the first value is valid, then at step 228, thread C reads and processes the first value to generate a second value. At step 228, the second value is written to a second memory location 141 while toggling a second flag stored in the second memory location 141.

[0054] At step 230, thread E begins executing a third instruction to process the second value. At step 232, thread E reads the second flag stored in the second memory location 141 corresponding to the second value and indicates whether the second value has been written by thread C. If at step 232, the second flag indicates that the second value is invalid, then step 232 is repeated. When at step 232, the second flag indicates that the second value is valid, then at step 234, thread E reads and processes the second value to generate a third value. At step 234, the third value is written to a third memory location 151 while toggling a third flag stored in the third memory location 151.

[0055] At step 240, thread A begins execution of a fourth instruction to process the third value. At step 242, thread A reads a third flag stored in the third memory location 151 corresponding to the third value and indicates whether the third value has been written by thread E. If at step 242, the third flag indicates that the third value is invalid, then step 242 is repeated. When at step 242, the third flag indicates that the third value is valid, then at step 244, thread A reads and processes the third value to generate a fourth value. At step 244, the fourth value is written to the first memory location 131 while toggling the first flag stored in the first memory location 131.

[0056] Storing a single flag and one or more values in each data packet, where the flag is toggled at the same time as the one or more values are written, eliminates the need for memory fences. The flag also supports synchronized data exchange between a producer thread and one or more consumer threads through shared memory without the need for barriers. The flag is toggled for each write and state information is maintained for use by the consumer threads to determine whether the state of the flag indicates that the value in the same data packet as the flag is valid. After all consumer reads of the value stored in the memory location, the memory location can be reused. The memory location can be reused without reinitializing the flag. Reusing the memory location reduces the number of memory locations required to execute a program and reduces cache footprint, which reduces the likelihood of cache thrashing.

[0057] Parallel processing architecture

[0058] FIG. 3 A parallel processing unit (PPU) 300 according to one embodiment is shown. In one embodiment, the PPU 300 is a multi-threaded processor implemented on one or more integrated circuit devices. The PPU 300 is a latency-hiding architecture designed for parallel processing of many threads. A thread (i.e., an execution thread) is an instance of a group of instructions configured to be executed by the PPU 300. In one embodiment, the PPU 300 is a graphics processing unit (GPU) configured to implement a graphics rendering pipeline for processing three-dimensional (3D) graphics data in order to generate two-dimensional (2D) image data for display on a display device, such as a liquid crystal display (LCD) device. In other embodiments, the PPU 300 can be used to perform general purpose computations. Although one exemplary parallel processor is provided herein for illustrative purposes, it should be specifically understood that this processor is set forth for illustrative purposes only and that any processor can be used in addition to and / or in place of this processor.

[0059] One or more PPU 300s can be configured to accelerate thousands of high-performance computing (HPC), data center, and machine learning applications. PPU 300s can be configured to accelerate numerous deep learning systems and applications, including autonomous vehicle platforms, deep learning, high-precision speech, image, and text recognition systems, intelligent video analytics, molecular simulations, drug discovery, disease diagnosis, weather forecasting, big data analytics, astronomy, molecular dynamics simulations, financial modeling, robotics, factory automation, real-time language translation, online search optimization, and personalized user recommendations, among others.

[0060] like FIG. 3 As shown, PPU 300 includes an input / output (I / O) unit 305, a front-end unit 315, a scheduler unit 320, a job allocation unit 325, a hub 330, a crossbar (Xbar) 370, one or more general purpose processing clusters (GPCs) 350, and one or more memory partitioning units 380. PPU 300 can be connected to a host processor or other PPU 300 via one or more high-speed NVLink 310 interconnects. PPU 300 can be connected to a host processor or other peripheral devices via interconnect 302. PPU 300 can also be connected to local memory 304, which includes multiple memory devices. In one embodiment, local memory may include multiple dynamic random access memory (DRAM) devices. The DRAM devices may be configured as a high-bandwidth memory (HBM) subsystem, where multiple DRAM dies are stacked within each device.

[0061] The NVLink 310 interconnect enables the system to expand and include one or more PPUs 300 in conjunction with one or more CPUs, supporting cache coherency between the PPUs 300 and the CPU, as well as CPU master control. Data and / or commands can be sent from or from the NVLink 310 to other units of the PPU 300 via hub 330, such as one or more copy engines, video encoders, video decoders, power management units, etc. (not explicitly shown). FIG. 5B A more detailed description of the NVLink 310.

[0062] The I / O unit 305 is configured to send and receive communications (e.g., commands, data, etc.) from a host processor (not shown) over the interconnect 302. The I / O unit 305 can communicate with the host processor directly via the interconnect 302, or through one or more intermediary devices such as a memory bridge. In one embodiment, the I / O unit 305 can communicate with one or more other processors (e.g., one or more PPUs 300) via the interconnect 302. In one embodiment, the I / O unit 305 implements a Peripheral Component Interconnect Express (PCIe) interface for communicating over a PCIe bus, and the interconnect 302 is a PCIe bus. In alternative embodiments, the I / O unit 305 can implement other types of known interfaces for communicating with external devices.

[0063] The I / O unit 305 decodes packets of data received via the interconnect 302. In one embodiment, the packets of data represent commands configured to cause the PPU 300 to perform various operations. The I / O unit 305 sends the decoded commands to various other units of the PPU 300 as specified by the commands. For example, some commands can be sent to the front-end unit 315. Other commands can be sent to the hub 330 or other units of the PPU 300 such as one or more copy engines, video encoders, video decoders, power management units, etc. (not explicitly shown). In other words, the I / O unit 305 is configured to route communications between and among various logical units of the PPU 300.

[0064] In one embodiment, a program executed by the host processor encodes a stream of commands in a buffer that provides a workload to the PPU 300 for processing. The workload can include a number of instructions and data to be processed by those instructions. The buffer is a region of memory that is accessible (e.g., read / write) by both the host processor and the PPU 300. For example, the I / O unit 305 can be configured to access the buffer in a system memory connected to the interconnect 302 via memory requests transmitted over the interconnect 302. In one embodiment, the host processor writes the stream of commands to the buffer and then sends the PPU 300 a pointer to a beginning of the stream of commands. The front-end unit 315 receives the pointer(s) to the stream(s) of commands. The front-end unit 315 manages the stream(s), reading commands from the stream(s) and forwarding the commands to various units of the PPU 300.

[0065] The front-end unit 315 is coupled to a scheduler unit 320, which is configured to schedule various GPCs 350 to process tasks defined by one or more workgroups. The scheduler unit 320 is configured to track state information related to various tasks managed by the scheduler unit 320. The state can indicate which GPC 350 a task is assigned to, whether the task is active or inactive, a priority associated with the task, etc. The scheduler unit 320 manages execution of a plurality of tasks on the one or more GPCs 350.

[0066] The scheduler unit 320 is coupled to a work distribution unit 325, which is configured to dispatch tasks for execution on GPCs 350. The work distribution unit 325 can track a number of scheduled tasks received from the scheduler unit 320. In one embodiment, the work distribution unit 325 manages a pending task pool and an active task pool for each GPC 350. The pending task pool can include a number of slots (e.g., 32 slots) that hold tasks assigned to be processed by a particular GPC 350. The active task pool can include a number of slots (e.g., 4 slots) for tasks that are currently being actively processed by the GPC 350. When a GPC 350 finishes processing a task, the task is evicted from the active task pool for the GPC 350, and one of the other tasks from the pending task pool is selected and scheduled for execution on the GPC 350. If the active task on a GPC 350 has idled, e.g., while waiting for a data dependency to be resolved, then the active task can be evicted from the GPC 350 and returned to the pending task pool, and another task from the pending task pool is selected and scheduled for execution on the GPC 350.

[0067] The work distribution unit 325 communicates with the one or more GPCs 350 via an XBar (crossbar) 370. The XBar 370 is an interconnect network coupling many units of the PPU 300 to other units of the PPU 300. For example, the XBar 370 can be configured to couple the work distribution unit 325 to a particular GPC 350. Although not explicitly shown, one or more other units of the PPU 300 can also be connected to the XBar 370 via the hub 330.

[0068] Tasks are managed by scheduler unit 320 and dispatched to GPC 350 by work allocation unit 325. GPC 350 is configured to process tasks and generate results. Results may be consumed by other tasks within GPC 350, routed to different GPCs 350 via XBar 370, or stored in memory 304. Results may be written to memory 304 via memory partitioning unit 380, which implements a memory interface for reading data from and writing data to memory 304. Results may be sent to another PPU 300 or CPU via NVLink 310. In one embodiment, PPU 300 includes U memory partitioning units 380, which is equal to the number of independent and different memory devices 304 coupled to PPU 300. The following will be combined with... FIG. 4B The memory partition unit 380 is described in more detail.

[0069] In one embodiment, the host processor executes a driver kernel that implements an application programming interface (API), enabling the execution of one or more applications on the host processor to schedule operations for execution on the PPU 300. In one embodiment, multiple computing applications are executed concurrently by the PPU 300, and the PPU 300 provides isolation, Quality of Service (QoS), and independent address spaces for the multiple computing applications. Applications can generate instructions (e.g., API calls) that cause the driver kernel to generate one or more tasks for execution by the PPU 300. The driver kernel outputs the tasks to one or more streams being processed by the PPU 300. Each task may include one or more associated thread groups, referred to herein as a warp. In one embodiment, a warp includes 32 associated threads that can execute in parallel. Cooperative threads can refer to multiple threads that include instructions for executing tasks and can exchange data via shared memory. FIG. 5A A more detailed description of threads and cooperative threads.

[0070] FIG. 4A An embodiment is shown. FIG. 3 The PPU 300 and GPC 350. For example... FIG. 4A As shown, each GPC 350 includes multiple hardware units for processing tasks. In one embodiment, each GPC 350 includes a pipeline manager 410, a pre-raster operation unit (PROP) 415, a raster engine 425, a work assignment crossbar switch (WDX) 480, a memory management unit (MMU) 490, and one or more data processing clusters (DPCs) 420. It should be understood that... FIG. 4A The GPC 350 may include replacements FIG. 4A Other hardware units of the unit shown or excludingFIG. 4A other hardware units beyond those shown in FIG. 3.

[0071] In one embodiment, the operation of GPC 350 is controlled by pipeline manager 410. Pipeline manager 410 manages configuration of one or more DPCs 420 for processing tasks allocated to GPC 350. In one embodiment, pipeline manager 410 can configure at least one of one or more DPCs 420 to implement at least a portion of a graphics rendering pipeline. For example, a DPC 420 can be configured to execute a vertex shading program on the programmable streaming multi-processor (SM) 440. Pipeline manager 410 can also be configured to route packets received from work distribution unit 325 to appropriate logical units in GPC 350. For example, some packets can be routed to fixed function hardware units in PROP 415 and / or raster engine 425, while other packets can be routed to DPC 420 for processing by primitive engine 435 or SM 440. In one embodiment, pipeline manager 410 can configure at least one of one or more DPCs 420 to implement a neural network model and / or compute pipeline.

[0072] PROP unit 415 is configured to route data generated by raster engine 425 and DPC 420 to a render operation (ROP) unit for processing. FIG. 4B PROP unit 415 is described in more detail below. PROP unit 415 can also be configured to perform optimization of color blending, organize pixel data, perform address translation, and / or the like.

[0073] Raster engine 425 includes a number of fixed function hardware units to perform various raster operations. In one embodiment, raster engine 425 includes a setup engine, a coarse raster engine, a cull engine, a clip engine, a fine raster engine, and a tile aggregation engine. The setup engine receives transformed vertices and generates a plane equation associated with the geometric primitive defined by the vertices. The plane equation is sent to the coarse raster engine to generate coverage information (e.g., x, y coverage masks) for the geometric primitive. The output of the coarse raster engine is sent to the cull engine where coverage masks associated with geometric primitives that fail a z-test are culled, and the output is sent to the clip engine where coverage masks of primitives that are outside the view volume are clipped. Those coverage masks that remain after clipping and culling can be passed to the fine raster engine to generate fragment data based on the plane equation generated by the setup engine. The output of the raster engine 425 includes fragments to be processed by a fragment shader implemented in DPC 420.

[0074] Each DPC 420 included in GPC 350 includes an M-pipeline controller (MPC) 430, a primitive engine 435, and one or more SMs 440. The MPC 430 controls the operation of the DPC 420, routing packets received from the pipeline manager 410 to the appropriate units within the DPC 420. For example, packets associated with vertices can be routed to the primitive engine 435, which is configured to retrieve vertex attributes associated with vertices from memory 304. Conversely, packets associated with shaders can be sent to the SMs 440.

[0075] The SM 440 includes a programmable streaming processor configured to process tasks represented by multiple threads. Each SM440 is multithreaded and configured to execute multiple threads (e.g., 32 threads) from a specific thread group concurrently. In one embodiment, the SM 440 implements a SIMD (Single Instruction, Multiple Data) architecture, where each thread in a thread group (e.g., a warp) is configured to process a different dataset based on the same instruction set. All threads in the thread group execute the same instructions. In another embodiment, the SM 440 implements a SIMT (Single Instruction, Multiple Threads) architecture, where each thread in a thread group is configured to process a different dataset based on the same instruction set, but where individual threads in the thread group are allowed to diverge during execution. In one embodiment, a program counter, call stack, and execution state are maintained for each thread bundle, enabling concurrency between the thread bundle and serial execution within the thread bundle when threads within the thread bundle diverge. In another embodiment, a program counter, call stack, and execution state are maintained for each individual thread, thereby achieving equal concurrency among all threads within and between thread bundles. When maintaining the execution state for each individual thread, threads executing the same instructions can converge and execute in parallel to achieve maximum efficiency. The following section combines... FIG. 5A A more detailed description of the SM440.

[0076] MMU 490 provides an interface between GPC 350 and memory partitioning unit 380. MMU 490 can provide virtual address to physical address translation, memory protection, and arbitration of memory requests. In one embodiment, MMU 490 provides one or more translation back buffers (TLBs) for performing translations from virtual addresses to physical addresses in memory 304.

[0077] FIG. 4B An embodiment is shown. FIG. 3 The PPU 300's memory partition unit 380. For example... FIG. 4BAs shown, the memory partition unit 380 includes a raster operations (ROP) unit 450, a level two (L2) cache 460, and a memory interface 470. The memory interface 470 is coupled to the memory 304. The memory interface 470 can implement a 32, 64, 128, 1024-bit data bus, etc. for high-speed data transfer. In one embodiment, the PPU 300 incorporates U memory interfaces 470, one for each pair of memory partition units 380, where each pair of memory partition units 380 is connected to a memory device of a corresponding memory 304. For example, the PPU 300 can be connected to up to Y memory devices, such as high bandwidth memory stacks or graphics double data rate version 5 synchronous dynamic random access memory or other types of persistent storage.

[0078] In one embodiment, the memory interface 470 implements an HBM2 memory interface and Y is equal to half of U. In one embodiment, the HBM2 memory stacks are located on the same physical package as the PPU 300, providing significant power and area savings compared to a conventional GDDR5 SDRAM system. In one embodiment, each HBM2 stack includes four memory dies and Y is equal to 4, where the HBM2 stack includes two 128-bit channels per die for a total of 8 channels and a data bus width of 1024 bits.

[0079] In one embodiment, the memory 304 supports single error correction double error detection (SECDED) error correcting code (ECC) to protect data. For computing applications that are sensitive to data corruption, the ECC provides higher reliability. In large cluster computing environments, the PPU 300 processes very large data sets and / or long-running applications, where reliability is especially important.

[0080] In one embodiment, the PPU 300 implements a multi-level memory hierarchy. In one embodiment, the memory partition unit 380 supports a unified memory to provide a single unified virtual address space for the CPU and PPU 300 memory, enabling data sharing between virtual memory systems. In one embodiment, the frequency of access to memory locations by the PPU 300 on other processors is tracked such that memory pages which are frequently accessed by the PPU 300 are moved to the PPU’s 300 physical memory. In one embodiment, the NVLink 310 supports an address translation service which allows the PPU 300 to access page tables of the CPU directly and provide full access to the CPU’s memory by the PPU 300.

[0081] In one embodiment, the copy engine transfers data between multiple PPUs 300 or between a PPU 300 and a CPU. The copy engine can generate a page fault for an address that is not mapped to a page table. The memory partition unit 380 can then service the page fault, map the address into a page table, after which the copy engine can perform the transfer. In conventional systems, memory is fixed (e.g., non-paged) for multiple copy engine operations between multiple processors, which significantly reduces the available memory. Due to the hardware page fault, an address can be passed to the copy engine without worrying whether the memory page is resident, and whether the copy process is transparent.

[0082] Data from memory 304 or other system memory can be retrieved and stored in the L2 cache 460 by the memory partition unit 380, which is on-chip and shared between various GPCs 350. As shown, each memory partition unit 380 includes a portion of the L2 cache 460 associated with the corresponding memory 304. Lower level caches can then be implemented within the various units within the GPC 350. For example, each SM 440 can implement a level one (LI) cache. The LI cache is a dedicated on-chip memory that is dedicated to a particular SM 440. Data from the L2 cache 460 can be fetched and stored into the LI cache of each SM 440 for processing of the functional units of the SM 440. The L2 cache 460 is coupled to the memory interface 470 and the XBar 370.

[0083] The ROP unit 450 performs graphics raster operations, such as color compression, pixel blending, and the like. The ROP unit 450 also implements depth tests with the raster engine 425, receiving a depth for a sample location associated with a pixel fragment from the culling engine of the raster engine 425. The depth for the sample location associated with the fragment is tested against a corresponding depth in a depth buffer. If the fragment passes the depth test for the sample location, the ROP unit 450 updates the depth buffer and sends the results of the depth test to the raster engine 425. It will be appreciated that the number of memory partition units 380 can be different from the number of GPCs 350, and thus each ROP unit 450 can be coupled to each GPC 350. The ROP unit 450 tracks the data packets received from the different GPCs 350 and determines to which GPC 350 the results generated by the ROP unit 450 are routed through the XBar 370. Although the ROP unit 450 is included within the memory partition unit 380 in FIG. 4B , in other embodiments, the ROP unit 450 can be outside of the memory partition unit 380. For example, the ROP unit 450 can reside in the GPC 350 or another unit.

[0084] FIG. 5A A streaming multiprocessor 440 is shown in accordance with one embodiment FIG. 4A FIG. 5A As shown, the SM 440 includes an instruction cache 505, one or more scheduler units 510, a register file 520, one or more processing cores 550, one or more special function units (SFUs) 552, one or more load / store units (LSUs) 554, an interconnect network 580, and shared memory / Ll cache 570.

[0085] As described above, the work distribution unit 325 dispatches tasks for execution on GPCs 350 of PPU 300. Tasks are assigned to particular DPCs 420 within a GPC 350, and if the task is associated with a shader program, the task can be assigned to an SM 440. The scheduler unit(s) 510 receives tasks from the work distribution unit 325 and manages instructions assigned to one or more thread blocks, which are assigned to the SM 440. The scheduler unit(s) 510 schedules thread blocks for execution as warps of parallel threads, with each thread block being assigned at least one warp. In one embodiment, each warp executes 32 threads. The scheduler unit(s) 510 can manage a plurality of different thread blocks, distributing warps of threads to different thread blocks, and then dispatching instructions from a plurality of different cooperative groups to various functional units (i.e., cores 550, SFUs 552, and LSUs 554) during each clock cycle.

[0086] Cooperative groups are a programming model for organizing groups of communicating threads that allow developers to express the granularity at which threads are communicating, enabling richer, more efficient parallel decomposition. A cooperative launch API supports synchronicity between thread blocks to execute parallel algorithms. Conventional programming models provide a single, simple construct for synchronizing cooperating threads: a barrier (e.g., a sync threads() function) across all threads of a thread block. However, programmers often wish to define groups of threads at a granularity smaller than a thread block and synchronize within the defined groups to enable higher performance, design flexibility, and software reuse in the form of collective group-wide function interfaces.

[0087] ​Cooperative groups enable programmers to explicitly define groups of threads at sub-block (e.g., as small as a single thread) and multi-block granularity and perform collective operations, such as synchronizations across threads in a cooperative group. The programming model supports clean composition across software boundaries so that libraries and utility functions can safely synchronize in their local environment without assuming convergence. Cooperative group primitives enable new patterns of cooperative parallelism, including producer-consumer parallelism, opportunistic parallelism, and global synchronization across an entire grid of thread blocks.

[0088] The dispatch unit 515 is configured to transmit instructions to one or more functional units. In this embodiment, the scheduler unit 510 includes two dispatch units 515 that enable two different instructions from the same thread bundle to be dispatched during each clock cycle. In alternative embodiments, each scheduler unit 510 can include a single dispatch unit 515 or additional dispatch units 515.

[0089] Each SM 440 includes a register file 520 that provides a set of registers for the functional units of the SM 440. In one embodiment, the register file 520 is partitioned among each of the functional units such that each functional unit is allocated a dedicated portion of the register file 520. In another embodiment, the register file 520 is partitioned among different thread bundles executed by the SM 440. The register file 520 provides temporary storage for operands of instructions.

[0090] Each SM 440 includes L processing cores 550. In one embodiment the SM 440 includes a large number of distinct processing cores 550 (e.g., 128 or more). Each core 550 can include a fully-pipelined, single-precision, double-precision, and / or mixed precision processing unit that includes a floating point

[0091] Tensor cores are configured to perform matrix operations, and in one embodiment one or more tensor cores are included in the cores 550. Specifically, the tensor cores are configured to perform deep learning matrix operations, such as convolution operations for neural network training and inference. In one embodiment, each tensor core operates on 4x4 matrices and performs matrix multiplication and accumulation operations D = A x B + C, where A, B, C, and D are 4x4 matrices.

[0092] In one embodiment, the matrix multiply inputs A and B are 16-bit floating point matrices, while the accumulation matrices C and D can be 16-bit floating point or 32-bit floating point matrices. The tensor core operates on 16-bit floating point input data and 32-bit floating point accumulation. The 16-bit floating point multiplication requires 64 operations to produce a full precision product, which is then accumulated using 32-bit floating point addition with other intermediate products of the 4x4x4 matrix multiplication. In practice, the tensor core is used to perform larger two-dimensional or higher dimensional matrix operations built up from these smaller elements. APIs, such as the CUDA 9 C++ API, expose specialized matrix load, matrix multiply and accumulate, and matrix store operations in order to efficiently use the tensor core from a CUDA-C++ program. At the CUDA level, the warp-level interface assumes 16x16 size matrices across all 32 threads of a warp.

[0093] Each SM 440 also includes M SFUs 552 that perform special functions, e.g., certain trigonometric functions, exponential functions, logarithm functions, etc. In one embodiment, SFU 552 can include a tree traversal unit configured to traverse a hierarchical tree data structure. In one embodiment, SFU 552 can include a texture unit configured to perform texture lookups of a texture map. In one embodiment, the texture unit is configured to load a texture map (e.g., a 2D array of texture pixels) from memory 304 and sample the texture map to produce sampled texture values for use in a shader program executed by SM 440. In one embodiment, the texture map is stored in shared memory / L1 cache 470. The texture unit implements texture operations for use in pixel operations, such as filtering operations using mipmaps (i.e., texture maps of varying levels of detail). In one embodiment, each SM 440 includes two texture units.

[0094] Each SM 440 also includes N LSUs 554 that implement load and store operations between shared memory / L1 cache 570 and register file 520. Each SM 440 includes an interconnect network 580 of conductors that connect each functional unit to register file 520 and to each other. In one embodiment, interconnect network 580 is a crossbar. In another embodiment, interconnect network 580 is a network that includes multiple numbers of switches coupled with high-speed links. In one embodiment, interconnect network 580 is used to distribute loads between functional units and to communicate data between functional units.

[0095] Shared memory / L1 cache 570 is an on-chip memory array that allows data storage and communication between the SM 440 and the geometry engine 435 and between threads within the SM 440. In one embodiment, shared memory / L1 cache 570 includes 128 KB of storage capacity and is in the path from the SM 440 to the memory partition unit 380. Shared memory / L1 cache 570 can be used for cache reads and writes. One or more of shared memory / L1 cache 570, L2 cache 460, and memory 304 are backing stores.

[0096] Combining data cache and shared memory functionality into a single memory block provides the best overall performance for both types of memory accesses. This capacity can be used by a program as a cache that does not use shared memory. For example, if the shared memory is configured to use half the capacity, then texture and load / store operations can use the remaining capacity. The integration within shared memory / L1 cache 570 causes shared memory / L1 cache 570 to function as a high-throughput pipeline for streaming data and, at the same time, provide high bandwidth and low latency access of frequently reused data.

[0097] When configured for general-purpose parallel computation, a simpler configuration can be used compared to graphics processing. Specifically, FIG. 3 The illustrated fixed function graphics processing units are bypassed, creating a simpler programming model. In a general-purpose parallel computation configuration, the work distribution unit 325 assigns and dispatches thread blocks directly to the DPCs 420. The threads in a block execute the same program, use the unique thread ID in the computation to ensure each thread generates a unique result, use the SM 440 to execute the program and perform the computation, use the shared memory / L1 cache 570 to communicate between threads, and use the LSUs 554 to read and write global memory through the shared memory / L1 cache 570 and the memory partition unit 380. When configured for general-purpose parallel computation, the SM 440 can also write commands that the scheduler unit 320 can use to launch new work on the DPCs 420.

[0098] The PPU 300 can be included in a desktop computer, laptop computer, tablet computer, server, supercomputer, smart- phone (e.g., wireless, hand-held device), personal digital assistant (PDA), digital camera, vehicle, head-mounted display, hand-held electronic device, etc. In one embodiment, the PPU 300 is contained on a single semiconductor substrate. In another embodiment, the PPU 300 is included on a system-on-a-chip (SoC) with one or more other devices, such as additional PPUs 300, memory 304, reduced instruction set computer (RISC) CPU, memory management unit (MMU), digital-to-analog converter (DAC), etc.

[0099] In one embodiment, the PPU 300 can be included on a graphics card that includes one or more memory devices. The graphics card can be configured to interface with a PCIe slot on a motherboard of a desktop computer. In yet another embodiment, the PPU 300 can be an integrated graphics processing unit (iGPU) or parallel processor contained in a chipset of a motherboard.

[0100] Exemplary computing system

[0101] Systems with multiple GPUs and CPUs are used in various industries as developers expose and utilize more parallelism in applications such as artificial intelligence computing. High performance GPU accelerated systems with tens to thousands of compute nodes are deployed in data centers, research institutions, and supercomputers to solve larger problems. As the number of processing devices within a high performance system increases, the communication and data transfer mechanisms need to scale to support this increased bandwidth.

[0102] FIG. 5B is a conceptual diagram of a processing system 500 implemented using the PPU 300 of FIG. 3 The exemplary system 565 can be configured to implement the method 200 shown in FIG. 2A and / or the method 225 shown in FIG. 2B The processing system 500 includes a CPU 530, a switch 510, and multiple PPUs 300 and corresponding memories 304. The NVLinks 310 provide high-speed communication links between each PPU 300. Although a specific number of NVLinks 310 and interconnects 302 connections are shown in FIG. 5B The switch 510 connects the interconnects 302 and the CPU 530. The PPUs 300, memories 304, and NVLinks 310 can be located on a single semiconductor platform to form a parallel processing module 525. In one embodiment, the switch 510 supports two or more protocols for interfacing to various different connections and / or links.

[0103] In another embodiment (not shown), NVLink 310 provides one or more high-speed communication links between each PPU 300 and CPU 530, and switch 510 interfaces between interconnect 302 and each PPU 300. PPU 300, memory 304, and interconnect 302 may reside on a single semiconductor platform to form parallel processing module 525. In yet another embodiment (not shown), interconnect 302 provides one or more communication links between each PPU 300 and CPU 530, and switch 510 uses NVLink 310 to interface between each PPU 300 to provide one or more high-speed communication links between PPUs 300. In another embodiment (not shown), NVLink 310 provides one or more high-speed communication links between PPUs 300 and CPU 530 via switch 510. In yet another embodiment (not shown), interconnect 302 directly provides one or more communication links between each PPU 300. One or more NVLink 310 high-speed communication links can be implemented as physical NVLink interconnects or on-chip or die interconnects using the same protocol as NVLink 310.

[0104] In the context of this specification, a single semiconductor platform can refer to a unique, single semiconductor-based integrated circuit fabricated on a bare die or chip. It should be noted that the term single semiconductor platform can also refer to a multi-chip module with increased connectivity, simulating on-chip operation and substantially improved by utilizing conventional bus implementation methods. Of course, various circuits or devices can also be placed separately or in various combinations of semiconductor platforms, depending on the user's needs. Optionally, the parallel processing module 525 can be implemented as a circuit board substrate, and each of the PPU 300 and / or memory 304 can be a packaged device. In one embodiment, the CPU 530, switch 510, and parallel processing module 525 reside on a single semiconductor platform.

[0105] In one embodiment, the signaling rate of each NVLink 310 is 20 to 25 gigabits per second, and each PPU300 includes six NVLink 310 interfaces (e.g., FIG. 5B As shown, each PPU 300 includes five NVLink 310 interfaces. Each NVLink 310 provides a data transfer rate of 25 gigabits per second in each direction, with six links providing 300 gigabits per second. When the CPU 530 also includes one or more NVLink 310 interfaces, the NVLink 310 can be specifically used for applications such as... FIG. 5BPPU-to-PPU communication is shown, or some combination of PPU-to-PPU and PPU-to-CPU.

[0106] In one embodiment, the NVLink 310 allows direct load / store / atomic access from the CPU 530 to the memory 304 of each PPU 300. In one embodiment, the NVLink 310 supports coherency operations, allowing data read from the memory 304 to be stored in the cache hierarchy of the CPU 530, reducing cache access latency for the CPU 530. In one embodiment, the NVLink 310 includes support for address translation services (ATS), allowing the PPU 300 to directly access page tables within the CPU 530. One or more NVLinks 310 can also be configured to operate in a low power mode.

[0107] FIG. 5C An exemplary system 565 is shown in which various previously described embodiments of various architectures and / or functionality can be implemented. The exemplary system 565 can be configured to implement the method 200 shown in FIG. 2A and / or the method 225 shown. FIG. 2B

[0108] As shown, a system 565 is provided that includes at least one central processing unit 530 connected to a communication bus 575. The communication bus 575 can be implemented using any suitable protocol, such as PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport, or any other bus or point-to-point communication protocol(s). The system 565 also includes a main memory 540. Control logic (software) and data are stored in the main memory 540, which can take the form of random access memory (RAM).

[0109] The system 565 also includes an input device 560, a parallel processing system 525, and a display device 545, such as a conventional CRT (cathode ray tube), LCD (liquid crystal display), LED (light-emitting diode), plasma display, or the like. User input can be received from the input device 560, e.g., keyboard, mouse, touchpad, microphone, etc. Each of the aforementioned modules and / or devices can even be located on a single semiconductor platform, e.g., a system on a chip. Alternatively, various modules can be located on different semiconductor platforms, which can be configured, e.g., to communicate over a communications interface.

[0110] Furthermore, the system 565 can be coupled to a network (e.g., a telecommunications network, local area network (LAN), wireless network, wide area network (WAN) such as the Internet, peer-to-peer network, cable network, etc.) for communication purposes via a network interface 535. ​

[0111] The system 565 can also include secondary storage (not shown). The secondary storage 610 includes, for example, a hard disk drive and / or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, digital versatile disk (DVD) drive, recording device, universal serial bus (USB) flash drive. The removable storage drive reads from and / or writes to a removable storage unit in a well-known manner.

[0112] Computer programs or computer control logic algorithms can be stored in the main memory 540 and / or the secondary storage. These computer programs, when executed, enable the system 565 to perform various functions. The memory 540, the storage, and / or any other storage is a possible example of computer-readable media.

[0113] The architectures and / or functionalities of the various preceding figures can be implemented in the context of a general- purpose computer system, a circuit board system, a game console system dedicated for entertainment purposes, a special purpose system, and / or any other desired system. For example, the system 565 can take the form of a desktop computer, laptop computer, tablet computer, server computer, super computer, smart telephone (e.g., wireless, hand held device), personal digital assistant (PDA), digital camera, vehicle, head mounted display, hand held electronic device, mobile telephone device, television, workstation, game console, embedded system, and / or any other type of logic.

[0114] While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the preferred embodiments should not be limited by any of the above described exemplary embodiments, but should instead be defined in accordance with the following claims and their equivalents.

[0115] Machine learning

[0116] Deep neural networks (DNNs) developed on processors such as the PPU 300 have been used for a variety of use cases: from self-driving cars to faster drug development, from automatic image captioning in online image databases to intelligent real-time language translation in video chat applications. Deep learning is a technology that models the neural learning process of the human brain, learns continuously, gets smarter over time, and delivers more accurate results faster over time. A child is initially taught by an adult to correctly identify and classify various shapes, and eventually is able to identify shapes without any coaching. Similarly, a deep learning or neural learning system needs to be trained in object identification and classification in order to become more intelligent and efficient in identifying basic objects, occluded objects, and the like while also assigning context to the objects.

[0117] At the simplest level, neurons in the human brain look at the various inputs received, assign a level of importance to each of these inputs, and pass the output to other neurons for processing. An artificial neuron or perceptron is the most basic model of a neural network. In one example, a perceptron can receive one or more inputs that represent various features of an object that the perceptron is being trained to recognize and classify, and each of these features is given a certain weight based on the importance of that feature in defining the shape of the object.

[0118] Deep neural network (DNN) models include multiple layers of connected nodes (e.g., perceptrons, Boltzmann machines, radial basis functions, convolutional layers, etc.) that can be trained with large amounts of input data to solve complex problems quickly and with high accuracy. In one example, the first layer of a DNN model breaks down an input image of a car into individual parts and looks for basic patterns such as lines and corners. The second layer assembles the lines to look for higher-level patterns such as wheels, windshields, and mirrors. The next layer identifies the type of vehicle, and the last few layers generate a label for the input image, identifying a specific make and model of car.

[0119] Once a DNN is trained, it can be deployed and used to recognize and classify objects or patterns in a process known as inference. Examples of inference (the process by which a DNN extracts useful information from a given input) include recognizing handwritten numbers deposited on a check for cashing at an ATM, recognizing images of friends in a photograph, providing movie recommendations to over 50 million users, recognizing and classifying different types of cars, pedestrians, and road hazards in a self-driving car, or real-time translation of human speech.

[0120] During training, data flows through the DNN in a forward propagation phase until a prediction is made that indicates a label corresponding to the input. If the neural network does not correctly label the input, the error between the correct label and the predicted label is analyzed and the weights are adjusted for each feature during a backward propagation phase until the DNN correctly labels that input and others in the training dataset. Training complex neural networks requires a large amount of parallel computing performance, including floating point multiplication and addition supported by PPU 300. Inference is less computationally intensive than training, and is a latency-sensitive process in which a trained neural network is applied to new inputs that it has not seen before to classify images, translate speech, and generally infer new information.

[0121] Neural networks rely heavily on matrix math operations, and complex multi-layer networks require large amounts of floating point performance and bandwidth to improve efficiency and speed. With thousands of processing cores, optimized for matrix math operations, and delivering tens to hundreds of TFLOPS of performance, the PPU 300 is a computing platform capable of delivering the performance required for deep neural network-based artificial intelligence and machine learning applications.

[0122] Note that the technology described herein can be embodied in executable instructions stored in a computer-readable medium for use by or in connection with a processor-based instruction execution machine, system, apparatus or device. It will be appreciated by those skilled in the art that, for some embodiments, the various types of computer-readable media can include one or more of a variety of computer-readable media for storing data. As used herein, "computer-readable medium" includes one or more of any suitable media for storing the executable instructions of a computer program so that the instruction execution machine, system, apparatus or device can read (or fetch) the instructions from the computer-readable medium and execute the instructions for performing the described embodiments. Suitable storage formats include one or more of electronic, magnetic, optical and electromagnetic formats. A non-exhaustive list of traditional example computer-readable media includes: portable computer disks; random access memories (RAM); read only memories (ROM); erasable programmable read only memories (EPROM); flash memory devices; and optical storage devices, including portable compact discs (CD), portable digital video discs (DVD), and the like.

[0123] It will be appreciated that the component arrangements shown in the drawings are for illustration purposes only, and other arrangements are possible. For example, one or more of the elements described herein can be implemented in whole or in part as electronic hardware components. Other elements can be implemented in software, hardware, or a combination of software and hardware. In addition, some or all of these other elements can be combined, some can be omitted entirely, and additional components can be added, still achieving the functionality described herein. As such, the subject matter described herein can be embodied in a multitude of different variations and all such are contemplated within the intended scope of the claims.

[0124] To facilitate an understanding of the subject matter described herein, many aspects are described in terms of sequences of actions. It will be recognized by those skilled in the art that the various actions can be performed by specialized circuits or circuitries, by program instructions being executed by one or more processors, or by a combination of both. The descriptions of any of the sequences of actions are not meant to imply that the particular order described for performing that sequence is the only order in which that sequence can be performed. Unless otherwise specifically noted, it is intended that all methods described herein can be performed in any suitable order.

[0125] The use of the terms “a” and “an” and “the” and similar referents in the context of describing the subject matter (especially in the context of following claims) are to be interpreted in encompass both the singular and plural, unless otherwise indicated herein or clearly contradicted by context. The use of the term “at least one” followed by a list of one or more items (for example, “at least one of A and B”) should be construed to mean one item from the list (A or B) or any combination of two or more of the listed items (A and B), unless otherwise stated herein or clearly contradicted by context. Furthermore, unless otherwise stated herein, the description above merely describes particular embodiments of the subject matter and does not limit the scope of the subject matter. Any and all examples or exemplary language (e.g., “such as”) provided herein are intended merely to better illuminate the subject matter and do not in any way limit the scope of the subject matter unless otherwise stated herein. The use of the terms “based on” and other like phrases should not be construed as limiting the scope of the subject matter to only those embodiments in which the stated condition is met. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Claims

1. A computer-implemented method for synchronized shared memory communication, comprising: executing a thread group by a multi-threaded parallel processor to process an input according to an instruction sequence; generating, by a first thread in the thread group, a first value, wherein the first value and a single flag associated with the first value are contained in a first data packet; and simultaneously writing the first value and the single flag associated with the first value in the first data packet to a shared memory, wherein the first value is written to a first location of the shared memory and simultaneously a first flag stored at the first location is updated from a first state to a second state, wherein the first flag is initialized to the first state when execution of the instruction sequence begins.

2. The computer-implemented method for synchronized shared memory communication of claim 1, further comprising: determining, by a third thread, that the first flag has changed from the first state to the second state; reading, by the third thread, the first value from the first location prior to updating a second flag stored in a second location of the shared memory written by a second thread in the thread group; and processing, by the third thread, the first value to produce an output.

3. The computer-implemented method for synchronized shared memory communication of claim 2, wherein determining that the first flag has changed from the first state to the second state comprises simultaneously reading, by the third thread, the first flag and the first value from the first location.

4. The computer-implemented method for synchronized shared memory communication of claim 3, wherein determining that the first flag has changed from the first state to the second state further comprises comparing the first flag to a valid state.

5. The computer-implemented method for synchronized shared memory communication of claim 1, wherein the first value and the first flag are encoded as one of a single 16-bit, 32-bit, 64-bit, or 128-bit word.

6. The computer-implemented method for synchronized shared memory communication of claim 1, wherein the first flag is stored in a location within the first location that replaces a bit of the first value.

7. The computer-implemented method for synchronized shared memory communication of claim 6, wherein the location corresponds to a least significant bit of the first value.

8. The computer-implemented method for synchronized shared memory communication of claim 1, wherein at least one additional value is associated with the first flag, and the method further comprises simultaneously writing the at least one additional value to the first memory location when the first value is written to the first memory location.

9. The computer-implemented method for synchronized shared memory communication of claim 1, wherein execution of the instruction sequence comprises performing one or more operations using a neural network.

10. The computer-implemented method for synchronous shared memory communication of claim 2, further comprising writing, by the third thread, the output to a third location while updating a third flag stored in the third location in the shared memory from the first state to the second state.

11. The computer-implemented method for synchronous shared memory communication of claim 10, further comprising: determining, by a fourth thread, that the third flag has changed from the first state to the second state; processing, by the fourth thread, the output to produce a fourth value; and updating the first flag stored in the first location from the second state to the first state while writing the fourth value to the first location.

12. A system for synchronous shared memory communication, comprising: a multi-core parallel processor coupled to a shared memory and configured to: execute a thread group to process an input according to an instruction sequence; generate, by a first thread in the thread group, a first value, wherein the first value and a single flag associated with the first value are contained in a first data packet; and write the first value and the single flag associated with the first value in the first data packet to the shared memory simultaneously, wherein the first value is written to a first location in the shared memory and a first flag stored in the first location is updated from a first state to a second state simultaneously, wherein the first flag is initialized to the first state when execution of the instruction sequence begins.

13. The system of claim 12, wherein the multi-core parallel processor is further configured to: determine, by a third thread, that the first flag has changed from the first state to the second state; read, by the third thread, the first value from the first location before updating a second flag written by a second thread in the thread group and stored in a second location in the shared memory; and process, by the third thread, the first value to produce an output.

14. The system of claim 13, wherein determining that the first flag has changed from the first state to the second state comprises reading, by the third thread, the first flag and the first value from the first location simultaneously.

15. The system of claim 14, wherein determining that the first flag has changed from the first state to the second state further comprises comparing the first flag to a valid state.

16. The system of claim 13, wherein the multi-core parallel processor is further configured to write, by the third thread, the output to a third location while updating a third flag stored in the third location in the shared memory from the first state to the second state.

17. The system of claim 16, the multi-core parallel processor is further configured to: determine, by a fourth thread, that the third flag has changed from the first state to the second state; process, by the fourth thread, the output to produce a fourth value; and ​ updating the first flag stored at the first location from the second state to the first state while writing the fourth value to the first location.

18. The system of claim 12, wherein the first value and the first flag are encoded as one of a single 16-bit, 32-bit, 64-bit, or 128-bit word.

19. The system of claim 12, wherein the first flag is stored in a location within the first location that replaces a location of the first value.

20. A non-transitory computer readable medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of: executing a thread group to process an input according to an instruction sequence; generating, by a first thread in the thread group, a first value, wherein the first value and a single flag associated with the first value are contained in a first data packet; and writing the first value and the single flag associated with the first value in the first data packet to a shared memory simultaneously, wherein the first value is written to a first location of the shared memory and a first flag stored at the first location is updated from a first state to a second state simultaneously, wherein the first flag is initialized to the first state when execution of the instruction sequence begins.

Images